Attribution models
Six models on the same purchase. All sent, in parallel, as their own events.
Most tools let you switch attribution model in a dashboard. The ad platform never hears about it — it is still being fed one last-click conversion. Tracyn evaluates every model server-side and delivers each one to Meta, Google Ads and TikTok as a separate custom event, so a model is something you can bid on rather than something you can only read.
Why parallel
Every platform grades its own homework, in last click.
Meta credits the Meta touch. Google credits the Google touch. Both default to the last one, which is why the channel that closes always looks efficient and the channel that found the customer always looks expendable. Picking a different model in a reporting tool does not correct this, because the tool is not what decides where the next euro goes — the platform’s bidding model is, and it never saw your report.
The models
One order. Six answers to who earned it.
No black box: each model is a fixed rule for splitting one order across the touches that preceded it. Here is the same journey — a 180 € order, four Meta touches over 12 days — run through all six.
-
T1 · 12 days before
Prospecting ad click
-
T2 · 9 days before
Came back, viewed product
-
T3 · 3 days before
Retargeting ad click
-
T4 · order day
Final click, then bought
| Model | T1 −12d | T2 −9d | T3 −3d | T4 day 0 |
|---|---|---|---|---|
| Last click 100% to the final touch | 0%
0 €
| 0%
0 €
| 0%
0 €
| 100%
180 €
|
| First click 100% to the first touch | 100%
180 €
| 0%
0 €
| 0%
0 €
| 0%
0 €
|
| Linear Equal share to every touch | 25%
45 €
| 25%
45 €
| 25%
45 €
| 25%
45 €
|
| Time decay Halves every 7 days before the order | 12%
22 €
| 17%
30 €
| 30%
54 €
| 41%
74 €
|
| Reversed time decay Halves every 7 days after the first touch | 41%
73 €
| 30%
54 €
| 17%
30 €
| 12%
23 €
|
| U-shape 40 / 20 / 40 across first, middle, last | 40%
72 €
| 10%
18 €
| 10%
18 €
| 40%
72 €
|
Read a row and you have one model’s verdict on this order. Read a column and you have the range of what a single touch is worth depending on who is asking — the prospecting click that found this customer is worth 180 € or nothing at all, and the entire argument about cutting prospecting budget lives in that gap.
-
Last click
The platform default, and the reason the channel that closes always looks efficient while the one that found the customer looks expendable.
-
First click
Credits discovery. Usually the model that rescues a prospecting budget from being cut on last-click numbers.
-
Linear
No opinion about position. A useful baseline: when linear and last click disagree sharply, there is real mid-funnel work happening.
-
Time decay
Recent touches weigh more, on GA4’s default curve. Fits considered purchases where interest builds and then closes.
-
Reversed time decay
The mirror image, weighting the top of the funnel. For merchants whose upper-funnel channels do the persuading.
-
U-shape
The canonical position-based split: the touch that found them and the touch that closed them share most of the credit.
What arrives at the platform
Every model, every segment, its own event name.
One purchase produces one event per enabled combination, each with its own event ID so the platform keeps them apart instead of merging them. The name is built from the model and the customer segment — last click carries no prefix, because it is the baseline everything else is compared against.
| Model | New customer | Returning customer | Every customer |
|---|---|---|---|
| Last click | NewCustomerPurchase | ReturningCustomerPurchase | AllCustomerPurchase |
| First click | FirstClickNewCustomerPurchase | FirstClickReturningCustomerPurchase | FirstClickAllCustomerPurchase |
| Linear | LinearNewCustomerPurchase | LinearReturningCustomerPurchase | LinearAllCustomerPurchase |
| Time decay | TimeDecayNewCustomerPurchase | TimeDecayReturningCustomerPurchase | TimeDecayAllCustomerPurchase |
| Reversed time decay | ReversedTimeDecayNewCustomerPurchase | ReversedTimeDecayReturningCustomerPurchase | ReversedTimeDecayAllCustomerPurchase |
| U-shape | UShapeNewCustomerPurchase | UShapeReturningCustomerPurchase | UShapeAllCustomerPurchase |
A single purchase is either new or returning, so each enabled model fires the variant matching that buyer plus the every-customer variant — not the whole grid. Every one of them carries the same hashed customer data, the same click IDs and the same consent verdict as the purchase it came from.
Scoped per platform
Meta is never credited with a Google click.
Before a model runs for a destination, the touch list is filtered to that platform’s own touches and to that platform’s published click window. Each platform is scored on the journey it actually took part in, inside the window it would use itself — which is what makes the numbers comparable to what the ad account reports.
Windows are adjustable per destination when your buying cycle is longer than the platform default.
- Meta
- 7 days
- TikTok
- 7 days
- Google Ads
- 30 days
What you do with it
An attribution model you can spend against.
-
Compare models on the same orders
Every variant describes the same set of purchases, so a difference in reported CPA between two of them is a difference in crediting — not a difference in tracking, timing or sample.
-
Bid on the model, not just read it
Each variant arrives as a custom event, so you can build a custom conversion on it in Ads Manager and optimise a campaign against first-click or U-shape credit instead of last click.
-
Split new from returning
Every model also arrives segmented, so you can optimise prospecting against new-customer credit while retention keeps running on the full set.
-
Change your mind without re-instrumenting
Switching the model you steer by is a change in the ad account, not an integration project. The events for the others were already arriving.
The honest part
How to read this without fooling yourself.
Parallel models are powerful and easy to misread. These four are the ones that matter, and the first one matters most.
-
Never add the variants together
Each one carries the full value of the same order, because each is a complete answer to "what produced this sale". They are six views of one purchase, not six purchases. Read one at a time; summing them in a report is how a merchant scares themselves with a revenue number that never existed.
-
You choose which ones are sent
Models and segments are switched on per destination, not sprayed by default. Sending all eighteen variants to a platform you are not steering with them is event volume for nothing.
-
A model needs a journey to model
Where Tracyn recorded only one touch for a visitor, every model returns the same answer, because there is nothing to distribute. Model disagreement is information; identical numbers mean short journeys, not a broken pipeline.
-
The platform still bids on what you tell it to
These arrive as custom events alongside your standard purchase conversion. Nothing changes about your campaigns until you point a custom conversion at one of them.
Before you install
What media buyers ask about attribution.
How is this different from the attribution report in my analytics tool?
A report changes what you see. This changes what the ad platform is told. Every model is delivered to Meta, Google Ads and TikTok as its own event, so a model can be the thing a campaign optimises against — not just a column you read and then go back to bidding on last click.
Does sending six models inflate my reported revenue?
Not unless you add them up yourself. Each variant is a separate custom event carrying the full value of the same order, and each one answers "who deserves credit for this sale" differently. Your standard purchase conversion is unaffected and stays the number to report on. The variants are for comparing and for optimising, one at a time.
Which touches count, and for how long?
For each ad platform, only the touches that belong to that platform, inside that platform’s own click window — seven days for Meta and TikTok, thirty for Google Ads, and adjustable per destination. Meta is never credited with a Google click, which is the failure mode that makes most in-house attribution unusable.
Where does the touch history come from?
From the visits Tracyn already recorded: the pre-purchase events from the browser and the click IDs captured when the visitor landed, resolved server-side against the order. The models run on the server precisely because the browser has never seen the visitor’s full history — only the server has it.
Do I need the whole thing switched on to start?
No. Most merchants start with last click alongside one alternative — usually first click — and only add models once they know which disagreement they care about. Growth and Scale include multi-touch attribution; you can turn a model on or off per platform at any time.
Keep reading
- Hybrid tracking Your browser pixel and a server-side twin, merged into one conversion.
- Ad-blockers and ITP Why the bundle keeps running where a standard pixel gets dropped — and why the sale is safe either way.
- Pricing Priced on sessions, not seats or platforms. Every plan captures orders server-side.
Ready to scale on numbers you can trust?
Run Tracyn free for 14 days. We do not charge at all in that window, so if your tracked revenue and match quality have not moved, you walk away having paid nothing.
- Five-minute setup, no developer
- Tracking live the same day
- No contract, cancel anytime