Why the last click breaks AI channel attribution
Last-touch rule assigns all conversion to one source — the one that was in the chain immediately before the request. In a typical path, this is brand search or impressions to an already warmed-up audience, while the first contact came from a completely different channel.
End-to-end analytics may be correctly assembled: touchpoint data matches, visits are stitched by user, reports are built. But the distribution of channel contribution diverges from reality, and decisions about reallocating efforts are made based on a distorted signal.
Second layer of the problem — source tagging. Differences in case and spelling of labels, manual edits in campaigns, lost click identifiers split one channel into dozens of rows, and part of the traffic goes into "direct visits".
AI channel attribution on such input trains on noise: the model confidently reproduces tagging errors and reinforces them in the weights.
The cost of the error does not appear immediately. They turn off the top of the funnel, cut reach formats, increase impressions to a warm audience — and after a cycle see a drop in total conversions with formally good return for each remaining channel. The metric measured position in the chain, not channel contribution.
We break down how this is closed: from a unified touchpoint loop and tag normalization to calculating channel contribution using cooperative game theory methods that are robust to incomplete data.
What model-based distribution of channel contribution gives
Attribution ceases to be an argument about the last click: the contribution of each touchpoint is calculated by a distribution model, not by a manually assigned rule. Below are four effects visible in numbers on the dashboard.
Share of correctly attributed conversions
The Shapley method iterates through coalitions of touchpoints and gives the channel exactly the contribution by which the conversion probability changes when it is added or removed.
On labeled history, the model converges with control groups where last-click rules were systematically wrong: the share of correctly attributed conversions grows, and the unaccounted remainder stops hanging on brand traffic.
Dashboard recalculation speed
Weights are recalculated incrementally: a new touchpoint window is added to already calculated coalitions; a full run is needed only when the tagging scheme changes.
The dashboard updates at the same rate as spend data — the report does not lag behind budget decisions, and recalculation after data edits takes minutes, not an overnight run.
Fewer manual reconciliations
The discrepancy between the dashboard and the export from ad systems is explained by the model calculation log: you can see which touchpoint received weight and by which rule.
The analyst does not reconcile numbers manually but checks specific disputed chains — the number of manual reconciliations drops severalfold.
Eliminated class of reporting errors
Previously, part of conversions was double-counted when stitching touchpoints and settled on the last source.
Now the model distributes them among all participants in the chain, and the language model labels the meaning of the touchpoint — campaign, creative, query type — and removes duplicates by meaning, not by string.
AI attribution implementation formats: comparison of approaches
The choice of attribution model is a trade-off between accuracy of contribution distribution and data volume requirements.
The same touchpoint chain under different logic yields different conclusions about which channel brings revenue, so the model is selected for the journey structure and quality of deal history.
| Option | When it fits | Limitations |
|---|---|---|
| Last-touch rule | Short path to deal, one decisive contact | Overstates the role of closing channels, contribution of intermediate ones is zeroed out |
| Position-based model | Clear entry and closing, need an explainable report | Weights are set manually and are not recalculated from data |
| Markov chains | Long multichannel journeys, many deals with full history | Sensitive to data gaps, critical to sample volume |
| Shapley model | Channels intersect, need an honest estimate of contribution in combination | Number of combinations grows exponentially, sampling approximation is needed |
| Hybrid with language model | There are offline and brand touchpoints, context of the request matters | Requires reconciliation with the database by data, more expensive to maintain |
In practice, they take not one row but a combination: last-touch rule as control, Markov chains for redistributing contribution, Shapley model where channels duplicate each other, and the hybrid — for touchpoints that are not recorded as a click.
The first step is measurement: how many deals in history have a full journey. This share determines whether probabilistic models can be built or whether a positional one is still appropriate.
How we implement: stages of engineering work
Attribution breaks not on the model but on input data: diverging identifiers, lost touchpoints, conversions without a source. Therefore, work proceeds sequentially — from data audit to solution acceptance, and at each step an artifact remains that shows the result.
- Data and tagging audit. We consolidate event sources — ad systems, web and mobile analytics, CRM — verify keys, time zones, and retention depth. We calculate the share of touchpoints without an identified user, duplicates and session gaps, and record which conversions can be linked to a source at all.
- User identification scheme. We describe stitching of chains: deterministic matches by identifier on authenticated sessions, probabilistic — on anonymous ones, with a confidence threshold and match lifetime. The scheme determines how many touchpoints actually enter the customer journey — the quality of all AI attribution depends on it.
- Model assembly. We distribute contribution among touchpoints via Shapley values — a channel receives a share, not the entire credit to the last click. Separately, we configure the conversion window, offline touchpoints, and rules for repeat purchases.
- Validation on historical slices. We run the model on a closed period and compare it with actual data and with the familiar last-touch model. We look at whether channel estimates are stable month to month and where discrepancies are explainable.
- Calibration and recalculation policy. We refine weights at checkpoints, set a recalculation schedule and rules for reacting to changes in data sources so that estimates do not "drift" after tagging edits.
- Solution acceptance and handover. We check metrics on agreed scenarios, provide access credentials, field descriptions, and the procedure for resolving discrepancies. After that, the client's team runs the calculations independently.
Model, data schemas, and policy: what remains with you
Attribution is not a one-time report but a reproducible calculation: when the set of channels changes or a new touchpoint source appears, the model must be recalculated by the same rules, not reassembled from the analyst's memory.
Therefore, we deliver the result of an AI attribution project as a set of artifacts, each of which can be opened, checked, and handed to a new engineer.
Below is what remains in your environment after launch.
- A trained model with a feature description: which touchpoints are included in the calculation, in which window they are counted, on which data the stability of channel contribution was validated.
- A data flow diagram: from event sources to the calculation dashboard, with aggregation points and load schedules.
- A metrics dictionary: unambiguous definitions — what we count as a conversion, how we separate new customers from repeat ones, where the attribution window boundary is.
- Rules for handling gaps: what we do with undelivered events, duplicates, and truncated sessions before they distort channel contribution.
- Recalculation policy: frequency, conditions for an unscheduled run, procedure for reconciling the result and rolling back to a previous calculation.
- Instructions for the team: data updates, adding a channel, investigating discrepancies between reporting and the model.
Acceptance is performed on your data: recalculation is run according to the policy together with your team, so that discrepancies surface during handover, not a month later in reporting.
Case: budget allocation using the Shapley model
Before attribution implementation, the customer journey was assembled from three disconnected systems: ad platforms, web analytics, and CRM.
The discrepancy in the number of conversions reached 13%, and every seventh deal was disputed — each system recorded the result to its own channel, and resolution was manual.
What was changed
We consolidated touchpoints into a single storage and recalculated channel contribution using the Shapley model: it divides the result among all points of contact rather than giving it to the last click.
Unstructured touchpoints — calls, emails, chats — are labeled by a language model, so deals that were previously absent from web data participate in the distribution.
What happened to the metrics
The discrepancy rate between reports decreased to 2%, disputed conversions fell from 14% to 2% — instead of manual investigations, one distribution rule works.
A full dashboard recalculation takes tens of minutes instead of a nightly window of several hours, so reporting updates during the day, not the next morning.
Planning logic shifted: channels are evaluated by contribution to the result, not by the last touchpoint. Budget goes where the model shows growth on the overall data picture, not where it is more convenient to report with a separate system.
Shapley model vs Markov chains: which to choose
A Markov chain divides contribution through transitions between touchpoints: a channel's contribution is the drop in conversion probability when its transition is removed from the graph.
The Shapley model calculates differently — it averages the gain across all orders of touchpoints, so it correctly accounts for synergy: two channels working together receive more than each separately.
Hence the differences in stability. The Markov model is reliable on short paths and with few conversions — transitions are estimated from the entire history.
The Shapley calculation iterates through all subsets of touchpoints, so in practice it uses sampling: shares are stable with sufficient data volume, but noticeably fluctuate on sparse segments.
| Approach | How it divides contribution | When to choose | Limitations |
|---|---|---|---|
| Markov chains | By drop in conversion probability when a transition is removed | Few conversions, short paths, simple explainability needed | Weakly sees channel synergy, sensitive to touchpoint order |
| Shapley model | Average gain across all orders of touchpoints | Many conversions, long multichannel paths | Sampling needed, shares fluctuate on small segments |
| Hybrid with language model | Touchpoint features from unstructured data plus contribution distribution | Calls, chats, offline requests in the shared journey | Requires labeling validation and reproducibility control |
The hybrid is needed where part of the journey leaves no numerical traces: the language model extracts touchpoint features from calls and messages — topic, stage, objection — and brings them to the same vector as digital touchpoints. Then contribution is divided by familiar mathematics, not "last click".
The practical rule of choice is simple: first look at conversion volume and path length, then at the share of unstructured touchpoints. Small volume and short paths — Markov chains; large flow and multichannel chains — Shapley; a noticeable share of offline — hybrid.
We usually calculate both distributions on the same data and compare where the discrepancy is explainable and where it indicates a hole in tagging.
Technical doubts we resolve before start
Five questions that come up at the evaluation stage — they are not about choosing a method, but about what happens after launch. Below are short answers; if your case differs from the typical one, we will analyze it on your data.
There is not enough touchpoint data — what then?
We calculate on what is available, and display touchpoints without a source as a separate row: it is not smeared across channels and does not mask gaps in collection.
A discrepancy between click logs and server logs above the threshold is a reason to fix collection, not to adjust weights.
The last-click rule already works — will it have to be broken?
No. Contribution distribution is calculated in parallel, the last-click report remains as is — you see both and the difference between them. Usually it shows channels that close the deal but do not create demand.
How much history is needed?
A full deal cycle plus a buffer for seasonality — in practice, from six months. On a short window, weights are noisy, so older periods enter with less weight: a change in mix does not distort the current picture.
What happens when a new channel appears?
It enters the tagging without retraining: weights are recalculated on the overall sample, the source receives a share based on contribution to conversion.
For the first weeks it carries a "low data" mark — we do not draw conclusions about it until touchpoints accumulate.
Who is responsible for tagging after launch?
We hand over the tagging scheme, source naming rules, and a validator that catches unknown parameters on input. After that, your team maintains tagging, and we provide support: we adjust rules when the advertising perimeter changes.
Let's discuss the task and come back with a work plan
An AI attribution estimate relies on data, not on a general description of the task. To break down channel contribution via Shapley and not hit incomplete exports at the first step, we need to see the structure of sources and constraints on their processing in advance. Below is the minimum set sufficient to come back with a work plan.
- Data access — exports from ad platforms and web analytics for a comparable period, read access to storage or regular scheduled reports.
- List of channels — which sources we consider paid, which auxiliary, where campaigns overlap by audience and touchpoint overlap is likely.
- Current reporting logic — which model is used now, which slices go to the business and how often.
- Conversion events and attribution window — what we consider a conversion and how many days after a touchpoint we count.
- Data processing constraints — what cannot be exported outside the perimeter, anonymization requirements and retention periods.
- Contacts on both sides — who on your side is responsible for data and acceptance, who on ours — for the model and reconciliation of results.
If some data is not yet available, that is also a result: we note blockers and build the plan so that the start does not wait for the last access.
Describe the task — we will come back with an estimate, work plan, and procedure for reconciling the new model with current reporting.
