Custom Attribution Model: How to Set the Weights and Prove They Work
TL;DR
- A custom attribution model is a credit allocation rule you write yourself: which touchpoints can earn credit, and what share of the order each one gets. It does not add data, it redistributes the data you already have, so a model change moves credit between channels rather than telling you something new.
- Almost every guide stops at "choose weights that match your journey", which skips the four decisions that matter more than the weights: eligibility, lookback window, credit date, and whether you divide revenue or contribution margin. Eligibility comes first, so a paid-only rule drops orders with no paid touch and your attributed total falls. That is the rule working, not the data breaking.
- Polar gives you the whole rule as settings rather than three fixed options. Ten attribution models, a lookback window you set from a fixed number of days out to unlimited, a paid-only toggle for eligibility, cash or accrual for the credit date, and models that credit contribution margin instead of revenue. Causal Lift then holds the weights honest, since multi-touch attribution splits observed revenue and only an incrementality test shows what was truly incremental.
Most operators arrive at the idea of a custom attribution model the same way. Meta says it drove 40 orders. Google says it drove 32. Shopify says most of the revenue came from Direct. The three numbers cannot all be right, they add up to more orders than the store actually shipped, and the next budget decision is waiting on an answer nobody can produce. A custom attribution model is the usual response: stop accepting anyone else's credit rule and write your own.
That is the right instinct. The problem is that almost every guide on the subject tells you to "choose weights that reflect your customer journey" and then stops, exactly where the work begins. This piece goes the other way. It shows the five decisions a custom attribution model is actually made of, the arithmetic for each weighting scheme on one real journey, and the checks that tell you whether the model you built is measuring your business or just flattering your budget.
What a custom attribution model actually is
A custom attribution model is a credit allocation rule you define yourself: which touchpoints in a conversion path are eligible for credit, and what share of the order each one receives.
That is the whole of it. It is not a different data set, and it is not a better one. Every model, fixed or custom, reads the same journeys and reaches a different verdict about them. Switching models does not add information, it redistributes it.
Custom models are a standard platform feature rather than an exotic one. Google documents them in Campaign Manager 360, and Adobe Analytics ships a similar set. What varies is how much of the rule you are allowed to change, and that turns out to be the thing that matters.
Two things a custom attribution model is not. It is not a media mix model, which works from aggregate spend and revenue over time and never looks at an individual journey. And it is not an incrementality test, which withholds spend from a region or an audience and measures what happens. Those answer a different question: whether the revenue would have arrived anyway. A custom model answers how to divide revenue you have already observed. Keep the two separate, because a custom model built to prove incrementality will quietly be built to prove whatever you already believe.
Why the fixed models stop working
The default models are not wrong. They are opinionated, and their opinions are visible.
Last click gives everything to the final touch, which in ecommerce means it systematically overpays Direct and brand search, the two channels that sit closest to checkout and cause the least demand. First click does the reverse and overpays the top of the funnel. Both are defensible. Neither survives a conversation with a CFO who wants to know why the channel with the best reported return is the one nobody spends money on.
Platform-reported numbers have a sharper problem: each platform only sees its own touchpoints, and each claims the conversion. Meta, Google and TikTok will all take credit for the same order, so summing them overstates what the store sold. Deduplication is not a refinement here, it is the difference between a real number and an impossible one.
Analytics platforms narrow the choice rather than widen it. GA4 exposes three attribution models, per Stape's rundown of the current set, and the ones it retired are the ones operators most often want to compare against. That gap between "the models I can select" and "the model my business runs on" is what sends people looking for a custom build in the first place.
The appetite is real and measured. Amplitude reports that roughly 75% of marketers are moving away from last-click attribution, and only about 22% are confident last-click measurement reflects long-term business impact.
The five decisions inside every custom attribution model
Here is the part the rest of the internet skips. A custom attribution model is not one choice about weights. It is five choices, and four of them are made before any weight is applied. Get the order wrong and the weights are meaningless, because they are dividing up the wrong set of touchpoints.
| Decision | What you are choosing | Options | Why it matters |
|---|---|---|---|
| 1. Eligibility | Which touchpoints can receive credit at all | All touchpoints, or paid only | Applied before weights. A paid-only rule drops whole orders that had no paid touch, so your attributed order count falls. |
| 2. Lookback window | How far back a touchpoint can sit and still count | A fixed number of days, or unlimited | Changes which touchpoints enter the path, not how credit is split among them. Short windows quietly delete top-of-funnel work. |
| 3. Weights | What share of the order each eligible touchpoint gets | First, last, linear, position based, time decay, marginal contribution | The only decision most guides discuss, and the one that matters least if the four around it are wrong. |
| 4. Credit date | Which day the credited revenue lands on | Cash (day of order) or accrual (day of touchpoint) | Decides how a month closes. Irrelevant at a two-day consideration cycle, structural at three weeks. |
| 5. Credited metric | What is being divided up | Revenue, or contribution margin | A model optimising revenue points budget at your least profitable SKUs and is right by its own definition. |
Decision one and decision three get confused constantly, so it is worth stating plainly: eligibility comes before weighting. A paid-only rule does not shift credit from email to Meta. It removes non-paid touchpoints from the path entirely, and if a journey has no paid touchpoint at all, that order leaves the model. Your attributed order count drops. That is the rule working, not the data breaking, and it is the single most common reason someone concludes their attribution tool is broken on day one.
Decision four is the one nobody thinks about until month-end. If a customer touches an ad on 28 August and buys on 3 September, which month owns the revenue? Cash accounting puts the whole order on 3 September, the day it was placed. Accrual puts each touchpoint's share on the day that touchpoint happened, so part of the order lands in August. For a brand with a two-day consideration cycle this is a rounding difference. For furniture, supplements or anything else people research for three weeks, it changes the shape of every month.
Decision five is the one that changes behaviour. Most models credit revenue. Revenue is the wrong target if your products have different margins, because a model optimising for revenue will point your budget at your least profitable SKUs and be right by its own definition. Crediting contribution margin instead means the model rewards the channel that made money rather than the channel that made noise.
How to set the weights
Now the arithmetic. Take one journey and hold it fixed:
A customer clicks a Meta ad on day 0, clicks a Google brand search ad on day 3, opens a Klaviyo email on day 6, then types the URL directly on day 9 and buys. Order value $180. Contribution margin $72, so 40%.
Four touchpoints, one order, and seven defensible answers about who earned it.
Position based, 40/20/40
Give 40% to the first touch, 40% to the last, and split the remaining 20% across everything in the middle. On our journey: Meta $72, Direct $72, and the two middle touchpoints take 10% each, so $18 to Google and $18 to Klaviyo.
This is the sane default for most stores, and the reason is structural rather than statistical. First and last touch are the two points you can measure with the least ambiguity, so weighting them heaviest puts the most credit where the data is strongest.
The 20/40/40 variant
Operators who have spent real money on this rarely land on a symmetric split. A common shape is 20% to first touch, 40% to last click, 40% spread across the middle. On the same journey: Meta $36, Direct $72, Google $36, Klaviyo $36.
The logic behind it is that the middle of an ecommerce journey is where retargeting, email and reviews do their work, and 20% is too small a budget for all three. It moves $18 out of first touch and $18 out of nowhere into the middle of the funnel, and it will make your retention channels look materially better. Whether that is accuracy or self-justification depends entirely on whether you validate it, which is the next section.
Time decay
Weight each touchpoint by how recently it happened, using a half-life. With a seven-day half-life, a touch seven days before the order carries half the weight of one on the day of the order.
The raw weights on our journey are 2^(-9/7) = 0.41 for Meta, 2^(-6/7) = 0.55 for Google, 2^(-3/7) = 0.74 for Klaviyo, and 1.00 for Direct. Those sum to 2.70, so normalise each by that total: Meta 15.2%, Google 20.4%, Klaviyo 27.5%, Direct 36.9%. In dollars, $27.40, $36.70, $49.50 and $66.40.
Time decay is the right choice for impulse categories and the wrong one for considered purchases, because it punishes the top-of-funnel touch that created the demand purely for being early.
Linear
25% each, so $45 per touchpoint. Linear is usually a placeholder rather than a belief, but it is the correct starting point when you genuinely do not know the shape of your journey yet, and it is the only model that cannot be accused of a thesis.
Paid only, position based
Now apply eligibility first. Drop Direct and Klaviyo, leaving Meta and Google. With two touchpoints there is no middle, so the 40/40 renormalises to 50/50: Meta $90, Google $90.
Look at what happened. Meta went from $72 to $90 and Direct's $72 vanished. Every paid channel's return improves under a paid-only model, always, because the same revenue is being divided among fewer channels. A paid-only model is useful for answering "of the money I control, where should the next dollar go", and actively misleading as a measure of total channel performance.
Credit contribution margin instead of revenue
Same 20/40/40 weights, applied to $72 of contribution margin rather than $180 of revenue: Meta $14.40, Google $14.40, Klaviyo $14.40, Direct $28.80.
Nothing about the split changed. What changed is what you are dividing, and therefore which channel wins when you rank them. On a mixed-margin catalogue the two rankings routinely disagree.
One journey, seven models, seven answers
Every number below describes the same customer buying the same $180 order.
| Model | Meta, day 0 | Google, day 3 | Klaviyo, day 6 | Direct, day 9 |
|---|---|---|---|---|
| First click | $180.00 | $0 | $0 | $0 |
| Last click | $0 | $0 | $0 | $180.00 |
| Linear | $45.00 | $45.00 | $45.00 | $45.00 |
| Position based, 40/20/40 | $72.00 | $18.00 | $18.00 | $72.00 |
| Custom, 20/40/40 | $36.00 | $36.00 | $36.00 | $72.00 |
| Time decay, 7 day half life | $27.40 | $36.70 | $49.50 | $66.40 |
| Paid only, position based | $90.00 | $90.00 | not eligible | not eligible |
The spread is the point. Meta's credit ranges from $27.40 to $90, a factor of more than three, with no change in the underlying data. Anyone who tells you their attribution number is correct is telling you which rule they picked.
This is also the honest answer to what an example of an attribution model looks like: pick a rule, apply it to a path, show the split. Our guide to the nine standard attribution models walks the fixed set in more detail, and the same journey runs through all of them.
How to validate a custom attribution model
Zero of the top-ranking guides on this keyword include this section, which is why so many custom models are quietly wrong. A model you built yourself has no external check on it. You have to supply one.
Reconcile the total first. Sum attributed orders across all channels and compare against orders actually placed. Under any full-credit model the two should match. If they do not, you have either a double-counting problem or an eligibility filter you forgot you set.
Expect fractional conversions. Under linear, our single order contributes 0.25 conversions to each of four channels. A channel showing 12.5 conversions is arithmetically correct, not corrupt. Only the single-touch models produce whole numbers, and a report full of decimals is evidence the multi-touch split is running.
Watch the denominator when you switch. Toggling between two full-credit models should leave your total order count untouched and only move credit between channels. Toggling to a paid-only model should reduce it. If a plain model change moves the total, the models are not reading the same journey set and the comparison is void.
Test the model against a holdout. This is the only real check. Turn a channel off in one region, or hold back a segment from a campaign, and measure what actually happened to revenue. Then ask what your model predicted. A custom model that credits Meta with 30% of revenue, in a market where switching Meta off costs you 5%, is not a model, it is a preference. Multi-touch attribution divides observed revenue and cannot tell you what was incremental, so the holdout is the part that keeps the weights honest.
Re-run it on a period you already understand. Apply the new model to last quarter, a quarter whose story you know from the outside: the launch that worked, the channel that stalled. If the model contradicts things you watched happen, the weights are wrong.
Where custom models go wrong
The weights get tuned until the answer is the one you wanted. This is the failure mode, and it is not usually deliberate. You try 40/20/40, retargeting looks weak, you try 20/40/40, it looks better, and you keep the second. Nothing in the process was dishonest and the output is now unfalsifiable. Fix the weights from a thesis about your journey, write the thesis down first, then check the model against a holdout rather than against your expectations.
Click-based models cannot see impressions. Meta and TikTok do not hand over view data in a form that supports per-touchpoint credit, so a click-based custom model will underrate any channel whose main job is being seen. That is a constraint of click attribution rather than a flaw in your weights, and no reweighting fixes it. View-through has to be captured as its own touchpoint type or the gap stays.
Channels no pixel can see get zero. Podcast reads, word of mouth, a practitioner recommending the product: none of them leave a click. A custom model will happily assign 0% to a channel driving real demand, and the model will look internally consistent while doing it. Post-purchase survey answers are the usual fix, treated as genuine touchpoints in the path rather than as a separate report, at which point they can carry real weight in the model.
Too many models is its own failure. One agency describes combining more than 25 models for a single ecommerce client. That is a defensible engagement for a team of analysts and a poor target for an in-house operator. Two models you can explain beat twenty you cannot.
The model becomes the strategy. A model is a lens for allocating budget. When teams start optimising to the model's verdict rather than to profit, the lens has become the target, and the number goes up while the business does not.
Build it in SQL, or configure it
Two honest paths, and the right one depends on where your constraint is.
Build it yourself when your journey logic is genuinely unusual: unusual channel groupings, offline touchpoints, a subscription path where the second order matters more than the first. You need journey-level touchpoint data in a warehouse, and you write the credit rule as SQL over the touchpoint array. The cost is not the first version, it is the maintenance: every new channel, every pixel change, every lookback adjustment is a code change, and the model becomes something only its author can modify.
Configure it in a platform when the shape of your journey is normal and what you need is to change the rule quickly and compare the results. Polar ships ten attribution models rather than three, and the settings that surround them are the ones the five decisions require: a lookback window you set yourself, from a fixed number of days out to unlimited; a paid-only toggle that controls eligibility; cash or accrual for which date credit lands on; and models that credit contribution margin rather than only revenue. The data-driven attribution option weights channels by estimated marginal contribution instead of by position, using a Shapley value calculation over observed paths, which is the closest thing to a custom model you do not have to hand-tune.
Deduplication is handled underneath either path, so platform-reported totals and attributed totals can be compared directly instead of summed into fiction. And because the weights are a setting rather than a deploy, the validation loop above takes an afternoon instead of a sprint.
The deeper point holds regardless of which path you pick, and it is covered in our piece on multi-touch attribution for ecommerce: the model is rarely the thing that is broken. Journey resolution is. A model splitting credit across a path that is missing half its touchpoints will produce a confident, precise, wrong answer under any weighting you choose. Fix the path first, then argue about the weights.
FAQ
Table of contents
Frequently asked questions
