Setting an Attribution Policy Your Team Will Actually Follow
An attribution policy that works fits on one page: which model is the default for routine reporting, what reporting window each channel uses, how often an incrementality test runs, and — critically — what happens when the attribution model and the incrementality test disagree. Written down before a bad number arrives, not debated after one does.
What this looks like in a real account
Why most attribution policies exist only in someone's head
Most accounts don't lack an attribution approach — they lack a written one. The default model in use is whatever the dashboard shows, the reporting window is whatever the platform sets, and the incrementality-testing cadence is whatever someone remembers to schedule. That works fine until a number looks bad, at which point everyone in the room reaches for whichever methodology happens to defend their prior position, and the resulting argument is really a disagreement about measurement rules nobody ever actually agreed on.
What belongs on the one page
Four things, stated plainly and specifically enough that two people reading the document independently would build the same report. First, the default attribution model for routine reporting — last-touch, linear, position-based, whichever fits your funnel, named explicitly rather than left as "whatever the dashboard shows." Second, the reporting window for each ad product — Sponsored Products' 7 or 14-day click window, Sponsored Brands and Sponsored Display's 14-day click plus the shorter post-2026 view model, DSP's split between in-store and offsite. Third, the incrementality-testing cadence — how often a holdout or geo-lift runs, and on which channels, stated as a schedule rather than an aspiration. Fourth, and most important: a rule for what happens when the attribution model and the incrementality test disagree.
The disagreement rule, worked through
This is the clause that actually earns the document's keep. A reasonable default: when an incrementality test and the standard attribution model disagree meaningfully on a specific channel or campaign, the incrementality result governs the budget decision for that channel, and the attribution model's reporting continues unchanged for everything the incrementality test hasn't covered. That's not because attribution models are worthless — they're the only continuously available signal for day-to-day optimisation — but because a properly designed causal test answers a stronger question than any credit-splitting rule can, and the policy should say so in writing before the disagreement actually happens, not in the meeting where it does.
The common mistake, including ours
The mistake is writing an attribution policy once, during a strategy kickoff, and never revisiting it as the account changes. We've operated against a client's own written policy for nearly a year before realising it still named a 14-day blanket view window for DSP that had been replaced by the shorter, machine-judged model months earlier — the document had been accurate when written and quietly wrong ever since, and nobody had a trigger to check it. A policy that isn't reviewed on a schedule decays the same way any other unmaintained documentation does.
What to do if you're starting from nothing
If no policy currently exists, don't try to write a comprehensive one in a single sitting — start with the disagreement rule and the reporting-window table, since those two elements prevent the most common and most expensive arguments, and add the model-choice and testing-cadence sections once the account has enough history to make an informed default choice rather than an arbitrary one. A partial policy that's actually followed is worth more than a comprehensive one that took three months to finish and was abandoned before anyone used it.
A practical review schedule
Review the policy quarterly at minimum, and immediately after any known Amazon attribution methodology change — which, given the pace of updates in 2026 alone, is a real and recurring trigger, not a hypothetical one. Assign the review to a specific person or role, not "the team," since an unowned recurring task is the one most likely to lapse silently.
Getting buy-in from people who don't care about measurement methodology
The document needs to survive contact with a stakeholder who has no interest in the difference between last-touch and position-based attribution and just wants to know whether to keep funding a channel. Write the disagreement rule specifically for that reader — a single sentence like "when a test and the dashboard disagree, we follow the test" does more real work in a budget meeting than a page of methodology explanation, because it's the one line that tells a non-technical stakeholder what will actually happen the next time a number looks wrong.
What to do when the policy itself produces a bad-news result
If following the written policy leads to a genuinely uncomfortable conclusion — a channel the team has defended for a year showing flat or negative incremental lift under the agreed test design — the policy's whole value is in having pre-committed to acting on that result rather than relitigating the methodology after the fact. The temptation, every time, is to question the test rather than the channel. Checking the test design for a genuine flaw is legitimate and worth doing quickly; using that check as a delay tactic to avoid an uncomfortable budget decision is exactly the failure mode a written policy, agreed in advance, is supposed to prevent.
| Policy element | What it should specify | Review trigger |
|---|---|---|
| Default attribution model | Named explicitly per channel, not left as dashboard default | Quarterly, or after a funnel-structure change |
| Reporting windows per ad product | Current, sourced figures for each surface | After any known Amazon methodology change |
| Incrementality testing cadence | A schedule, not an aspiration | Quarterly |
| Disagreement rule | Which result governs when models conflict | Reviewed after any actual disagreement occurs |
Which one you should actually pick
Any team can write and maintain this policy internally — it's a documentation discipline, not a technical capability. reMKTR builds this document with every managed client at the start of the relationship specifically because we've operated against our own stale version of one before, as part of the same discipline behind Full Circle's $500M+ in managed Amazon spend across 100+ brands.
Shortlist on the job, not the feature grid. Pull your search-term report for the last 90 days and total the spend against terms that produced no orders — 33.6% on the account above. Then ask each vendor on your list what they would do about it in week one, and see who answers with a process rather than a screenshot.
Common questions
How long should an attribution policy document be?
One page is the practical target — long enough to cover model choice, windows, testing cadence and a disagreement rule, short enough that people actually read and follow it.
Who should own reviewing the attribution policy?
A named person or role, not a general team responsibility — an unowned recurring review is the task most likely to lapse without anyone noticing.
What should happen when an incrementality test contradicts the standard attribution model?
A reasonable default is that the incrementality result governs the budget decision for that specific channel, while the attribution model continues to guide day-to-day optimisation elsewhere — stated in the policy before the disagreement happens, not decided in the room where it does.
How often should the policy be reviewed?
At least quarterly, and immediately after any known Amazon attribution methodology change — these have happened more than once recently and can silently make a written policy inaccurate.
We show the method before the number.
Claim the free auditRead next
- Acorn Cost: What Decides the Invoice, and What to AskPricing · acorn cost
- Criteo Review: Read the Primary Sources, Not the RatingsReview · criteo review
- Pacvue Pricing: No Public Number — What to AskPricing · pacvue pricing
- Skai vs Pacvue: Contracts, Not Feature GridsHead to head · skai vs pacvue