Guide
Partner Attribution for SaaS: When Your Numbers and Theirs Don't Match
Short answer: partner attribution breaks when two companies count different events under different rules and only discover it when money is due. Fix it before the first payout: pass a partner ID through every path a user can take, agree whose system is the source of truth, write down the attribution window, and share one monthly report both sides confirm line by line. Then measure 30, 60 and 90-day retention of partner-sourced users against direct signups, because a conversion rate without retention is a vanity number.
A founder on a SaaS forum who had run a revenue-share integration put the problem better than any framework does:
"The part I'd sort out before the second deal is attribution, because rev-share only stays friendly while both sides trust the numbers. A unique signup link or a partner ID passed through the widget, plus a simple shared monthly report, saves you the awkward conversation where your dashboard says 40 and theirs says 12."
Nobody in that conversation is lying. That is what makes it awkward. Both dashboards are accurate; they are measuring different things, and nobody agreed in advance which thing the partnership pays on. This guide is the agreement you should make instead.
Why don't partner attribution numbers match?
When a partner's count and yours diverge, the cause is almost never fraud and rarely a bug. It is one of these, usually several at once:
| Source of the gap | What the partner counts | What you count |
|---|---|---|
| Different event | Clicks on the integration, or trials started | Accounts that paid |
| Different window | Anyone who signed up within 90 days of a click | Only same-session signups |
| Lost identifier | Users who clicked, then signed up on another device | Those users as "direct", because the cookie never followed them |
| Late return | The user who clicked, left, and came back three weeks later | The same user as organic search |
| Double claim | A user who touched two partners, claimed by both | One partner, or neither |
| Refunds and churn | Gross signups, forever | Net paying accounts this month |
| Calendar edges | The month in their time zone | The month in yours |
Every row is a decision that should have been made at signing. If it wasn't, it gets made at the first payout, by whoever is angrier.
How to set up partner attribution both sides trust
1. Pass a partner ID through every path
Attribution should be a fact stored on the customer record, not an inference rebuilt later from analytics. That means one identifier per partner, carried the whole way:
- Marketing traffic: a unique signup link per partner. Read the parameter on landing, keep it through the signup flow (not only in a cookie), and write it to the account when the account is created.
- In-product traffic: if the partner embeds your feature, a widget or a handoff button, pass the partner ID through that embed as a parameter. This is the cleanest attribution there is, because the user is standing inside the partner's product when they sign up.
- Billing: copy the partner ID onto every charge as metadata. Now revenue can be attributed by reading your own billing records, with no join against an analytics tool that samples, expires or gets blocked.
If you can only do one of these, do the last two. In-product traffic is where integration partnerships make their money, and billing metadata is what the share is paid from.
2. Agree one source of truth
Two dashboards can never agree, so stop asking them to. Decide in writing whose system is the record. The sensible default is the system where the money is collected: the seller's billing records, filtered by the partner ID on the charge. The other side gets read access to that report, or a monthly export, and the right to dispute specific lines. Your analytics tool and theirs become diagnostics, not evidence.
3. Write down the attribution window
Four decisions, each one sentence in the agreement:
- Length. How long after a partner touch a signup still counts. Base it on your real time from first visit to first payment, not on a round number.
- First-touch or last-touch. Pick one. For a small number of partners, first-touch is simpler and fairer to whoever did the work of being first.
- In-product signups. A user who signed up inside the partner's product is that partner's for the life of the account. There is no ambiguity to window.
- Collisions. What happens when two partners both touched a user. "First touch wins" is fine. "Both get paid" is how shares quietly pile up past what you meant to give away.
4. Share one monthly report, with fixed columns
The commenter's "simple shared monthly report" is the whole trick, as long as it is the same report every month and both sides confirm it:
| Column | Why it is there |
|---|---|
| Partner ID | The attribution itself, from the record, not from memory |
| Customer id | An internal id, never a name or email; enough to dispute a line |
| Signup date / first paid date | Shows the window was respected |
| Status this month | Active, cancelled, refunded |
| Revenue collected in the period | What the share is calculated on |
| Refunds and chargebacks | So clawbacks are visible, not surprises |
| Share owed | The number that actually matters to the other side |
Add one summary line: totals, plus the retention figures from the next section. Then each side either confirms the report or disputes named lines. A dispute about line 14 takes ten minutes. A dispute about "your total feels low" takes a relationship.
5. Agree how a dispute ends
One paragraph: who raises it, by when, what evidence counts (the billing record, by default), and what happens if you still disagree after a fixed period. Put it in the same integration partnership agreement as the share itself. You will probably never use it, which is exactly why it is cheap to write now.
Why a conversion rate isn't enough: measure retention
The same founder's last point is the one most partnerships skip:
"Check how many of those users are still active after a month, because people who only ever touch you through someone else's product often churn faster than people who found you directly."
That is a real mechanism, not pessimism. A user who meets your feature inside a partner's interface may never see your own product. The value they feel lives in the host. When the host changes the placement, or the user's need fades, nothing holds them to you. A partner channel can convert brilliantly and still produce customers who are gone by month three.
It applies to us too. We publish a 32% figure (32% of the founders who clicked through from a partner's product created an Ordana account), and the honest follow-up question to that number is exactly this one: how many of them were still active a month later?
How to measure partner-sourced retention
- Cohort by signup month. Group partner-sourced customers by the month they signed up, per partner.
- Define "retained" once. For example: not cancelled, and active within the last 14 days. Use the same definition for every cohort and every partner.
- Read it at 30, 60 and 90 days. Thirty days catches the users who never activated. Ninety catches the ones who tried it and drifted.
- Compare against direct signups over the same months. Retention means little in isolation. The question is whether partner-sourced customers stay as well as the ones who found you on their own.
- Put it in the monthly report. Both sides see it, every month, next to the money.
What to do when partner-sourced users churn faster
- Look at where they meet you. If the integration is a thin placement, the user is buying the host's convenience, not your product. A deeper capability integration, where your feature does real work inside the host, tends to hold users better than a link in a sidebar. The three types of SaaS integration is the vocabulary for that conversation.
- Fix the first session. Partner-sourced users arrive with context the host gave them. Onboarding that ignores that context and starts from zero loses them.
- Raise it with the partner as data, not blame. A shared retention line turns "your users are bad" into "this cohort drops at day 30, what changed on your side that month?"
- Decide whether it is still worth it. Lower retention can still be good business if those users would never have found you. That is a judgment, but make it with the number in front of you.
Common partner attribution mistakes
- Agreeing the share before agreeing the count. The rate is the easy conversation. The definition of an attributed customer is the one that matters.
- Cookie-only tracking. It loses every cross-device signup and every browser that blocks it. Persist the ID on the account.
- Reporting totals instead of rows. Totals cannot be checked, so they get argued about.
- One side reporting alone. If only the host or only the provider produces the numbers, the other side is trusting, not verifying. Even one independent figure a month from the other side, such as its own count of active accounts from the partnership, turns one story into two that can be compared.
- Celebrating conversion, never checking retention. The partnership looks great for a quarter and then nobody can explain why revenue is flat.
Attribution is one of the problems that only shows up after launch, alongside credential upkeep, duplicate deliveries and outages. The others are in seven common SaaS integration problems. None of them are hard to build around; all of them are expensive to discover late.
Settle the count before the rate
On Ordana, the members build the integration themselves; the platform handles the part both sides have to trust, which is the agreement and a revenue share tracked and paid through Stripe, so each side reads the same record instead of two dashboards. If you are setting up an integration partnership that shares revenue, settle the count before the rate, whichever tool you use.
Related reading:
- What to Put in an Integration Partnership Agreement — where the attribution window, the source of truth and the dispute clause belong.
- 7 Common SaaS Integration Problems (and How to Fix Each) — attribution and retention next to the five that break the plumbing.
- Revenue-share integration partnerships — how the share itself is structured once the count is agreed.