Revenue attribution: connect campaigns to actual payments
Follow a worked customer journey from campaign click to payment, then check revenue definitions, refunds, identity gaps, and attribution rules.
By Mika Garcia · Published
In this article
What revenue attribution tells you
Revenue attribution assigns revenue credit to recorded marketing interactions under a defined set of rules. It helps answer which campaigns preceded paid customers, rather than stopping at clicks, signups, or leads.
A form submission can tell you that a campaign generated interest. A linked payment tells you whether that person eventually bought, how much they paid, and which recorded interactions are eligible for credit. The distinction matters when two campaigns generate similar lead counts but very different customers.
This guide is written by DATALYR. The example below is illustrative, not a customer result or a claim about the revenue you will recover. It shows how to inspect an attribution record before using it to make a budget decision.
Define the revenue before assigning credit
Start with a sentence your marketing and finance teams can both interpret: ‘This report allocates successful customer payments, less refunds, in USD, grouped by payment date.’ That is a reporting definition, not a universal accounting policy. Your business may need a different definition, but it needs one.
A booked contract, a payment, and recognized revenue can occur on different dates. Likewise, a subscription’s first payment and its later renewals answer different questions. Combining them without labels makes an acquisition report difficult to interpret.
Keep the amount and the attribution rule separate. Changing which campaign gets credit should not silently change the amount available to allocate. If you switch from gross payments to payments after refunds, label that as a change to the revenue basis.
- Specify the event that counts: paid invoice, completed paid order, or another documented transaction.
- State whether amounts include taxes, shipping, refunds, fees, and disputes.
- Separate first purchases from repeat purchases or renewals when evaluating acquisition.
- Choose a date basis and timezone; do not silently compare payment-date revenue with click-date reporting.
- Compare one currency, or document how currencies are converted.
Follow one payment through two attribution rules
Consider this hypothetical journey. On October 1, a person clicks Campaign A and starts a trial. On October 4, the same identified person clicks Campaign B. On October 5, they pay $120. Assume both interactions were recorded, are eligible under the selected window, and are linked to the payment.
Under a simple first-touch rule, Campaign A receives $120 of credit. Under a simple last-touch rule, Campaign B receives $120. The business still received one $120 payment. Adding the two reports and calling the result $240 would count the same payment twice.
On October 8, the customer receives a $20 partial refund. For this example, the report assigns that adjustment back to the original transaction and its attributed campaign. The payment contributes $100 after refunds. That reconciliation policy is explicit; it is not a promise that every analytics tool automatically treats adjustments this way.
If the customer pays another $120 the following month, put that payment in a renewal category. You can analyze renewal revenue by original acquisition source, but describe it as a cohort view. The first campaign did not necessarily cause every later payment.
- Original payment: $120.
- Partial refund: $20.
- Revenue after the refund in this example: $100.
- First-touch view: Campaign A receives $100; Campaign B receives $0.
- Last-touch view: Campaign A receives $0; Campaign B receives $100.
- Both views describe the same $100, not separate revenue.
One payment, two allocation views
1. October 1
Campaign A
First eligible recorded click; trial begins.
2. October 4
Campaign B
Last eligible recorded click before payment.
3. October 5
$120 payment
First-touch credits A; last-touch credits B. Never add both views.
Build a record you can inspect
You do not need a complicated model to discover a broken link between a visit and a purchase. You need enough information to trace the transaction back through the events used in the report.
The following is a proposed review checklist, not a list of DATALYR database fields. Use the equivalent fields in your tools. Preserve transaction identifiers so that a retry or an additional payment notification does not become an additional sale.
Record missing information as missing. If a payment cannot be matched to a captured journey, keep it in an unattributed category. Allocating it to the best-looking campaign would make the report more complete-looking and less trustworthy.
- Transaction ID, payment status, timestamp, amount, and currency.
- Refund or adjustment reference, where applicable.
- The permitted identity link between the visit and the customer or payment.
- Recorded campaign parameters or click identifiers, with their timestamps.
- The model, eligibility window, and handling of direct visits.
- The reason a transaction was matched, excluded, or left unattributed.
Check the capture, identity, and payment stages
Inspect the actual landing URL after redirects. A campaign parameter present in the ad but missing from the landing page cannot identify that visit. Then inspect the handoff from the browser to checkout: a server-side payment record is useful, but it still needs a permitted way to connect to the earlier journey.
DATALYR’s documentation describes capture of campaign parameters and click IDs, then lookup through event, session, and linked-user information. It also describes identifying the same user across browser and server events. Those links depend on implementation and consent; they are not evidence that every touchpoint will be observable.
For Stripe, use the instructions for your actual checkout type. The current guide distinguishes Checkout Sessions from Payment Links and other Stripe objects. Do not assume that an integration being connected proves that a particular payment carries the expected visitor link.
Reconcile before changing your budget
Take a small, known set of transactions and reconcile its payment total before evaluating campaign performance. For a single allocation view, attributed revenue plus unattributed revenue should reconcile to the eligible transaction amount under that view’s documented rules. Investigate differences instead of quietly dropping the unmatched rows.
Next, inspect one new customer, one repeat customer, and one refunded transaction. Check whether each appears in the intended category and period. A report can have the right grand total while assigning revenue to the wrong cohort.
Only then compare the attribution view with an ad platform. Different conversion definitions, eligibility windows, dates, and models can still produce different totals. Delivering a conversion to a platform and receiving credit for it are separate events.
Reconcile the amount before assigning credit
1. Payment
+$120
One successful transaction.
2. Partial refund
−$20
Adjustment linked back to that transaction.
3. Amount to allocate
$100
Attributed plus unattributed revenue must total $100 in this example.
Use attribution as evidence, not proof of causation
A recorded interaction followed by a payment does not tell you what would have happened without the campaign. Attribution allocates credit under the chosen rules; an experiment addresses a different question about incremental impact.
Use the report to identify a specific next investigation. A campaign with many leads and few paid customers may need a closer look at lead quality or follow-up. A large unattributed bucket may require tracking repair before campaign comparisons are useful. A channel that changes dramatically between first- and last-touch views deserves a journey review rather than an immediate budget cut.
For your first check, choose one known payment and write down the amount, customer category, recorded journey, selected rule, and assigned source. If you cannot explain that row, adding more models will not fix the underlying uncertainty.