Skip to content

Running multi touch attribution for events on a single registration file

Acquisition and attributionUpdated 2026-08-188 min read

In short

Multi touch attribution for events assembles every recorded touch against one registration, then splits credit across those touches by a stated rule. A W shaped split of 30, 30, 30 and 10 gives weight to the first touch, the touch that identified the person and the touch that registered them, with the remainder spread across the middle.

The paid media manager and the email manager both walk out of the campaign review believing they delivered the same 400 registrations. Neither is lying. The paid report counts a click that led to a registration inside the window, the email report counts a click that led to a registration inside its window, and the same person did both.

Multi touch attribution for events is the exercise of settling that argument on one file, once, with a rule everybody agreed to before they saw the numbers. It is less sophisticated than it sounds and more work than it sounds, and almost all of the work sits below the model.

The one table this needs

Before any weighting, you need a touch table. One row per recorded interaction, with five columns that matter: a person key, a timestamp, a channel, a campaign identifier, and the registration id the touch was later joined to.

The rows come from wherever your touches are logged. Ad platform click exports carry a click identifier and a timestamp. The email platform carries clicks by recipient. Site sessions carry a client identifier and whatever campaign parameters survived the journey. A registration file carries the completing session and, if you were careful, the click identifier that arrived with it.

Joining those into one person key is the entire project. An ad click on a phone, an email click from a laptop at work and a registration form completed on a tablet at home are three device identities and one buyer. The practical spine is the email address, hashed and lowercased, plus the click identifier passed into a hidden field on the registration form so a paid click can be matched back to the platform without depending on cookies. Whatever your team decides here bounds the accuracy of everything downstream, and it is a data engineering decision rather than a marketing one.

Assume you have that table. For one show with 9,400 registrations, a reasonable touch table runs to 40,000 to 70,000 rows, most of them email clicks and site sessions.

Why the weights are a policy rather than a discovery

A W shaped model gives 30 per cent to the first touch, 30 per cent to the touch that turned an anonymous visitor into a known contact, 30 per cent to the registering touch, and spreads the last 10 per cent evenly across everything in between.

Those numbers are an assertion. Nobody measured them. Shao and Li set out the alternative in the proceedings of the seventeenth ACM SIGKDD conference in 2011, where they framed attribution as assigning credit for a desirable action across multiple advertisements and argued that the domain needs a stable interpretation of each touchpoint's influence, which ordinary classification objectives do not deliver. Their answer was a bagged logistic model estimated from the data.

I would still start with the heuristic, and I would say so out loud. A heuristic weight set is transparent, reproducible by anyone with a spreadsheet, and stable across editions, which matters when the comparison you actually care about is this show against the same show last year. A learned model changes its answer when the data changes, which is correct and makes year on year comparison harder to explain to a show director.

The place to be firm is on how the weights get chosen. Pick them before you see the ranking they produce. If the number moves after someone objects to their channel's share, the model has become a negotiation.

What does W shaped credit look like on one registration?

Take one registration and lay out its six touches, counted in days before the show opens.

At 132 days, a paid social prospecting click. At 96 days, an organic search visit. At 71 days, an email click on the sector newsletter, which is where this person first gave an email address and stopped being anonymous. At 30 days, a paid search click on the show name. At 9 days, an email click on the deadline reminder. At 8 days, a direct visit that completed the registration.

The W shape marks touch one, touch three and touch six. Each gets 30 per cent. The remaining 10 per cent divides across touches two, four and five, which is 3.33 per cent each.

Credit by channel: paid social 30, organic search 3.33, email 33.33, which is the 30 from the identifying newsletter click plus 3.33 from the reminder, paid search 3.33, direct 30. That totals 99.99, and rounding is the only reason it is not 100.

Now compare. Last touch gives direct 100 and everything else zero. First touch gives paid social 100 and everything else zero. The W shaped split is the only one of the three that credits the newsletter click, which is the touch that made every later touch addressable.

The direct visit holding 30 per cent should bother you, and it is the standard objection to any position based rule. A direct visit is frequently a channel failure rather than a channel. The defensible fix is to define the registering touch as the last non-direct touch within the window, which moves that 30 per cent onto the deadline email. Decide it once and write it into the definition, because it moves credit by a third on a large minority of registrations.

What changes when you sum it over the file?

Single journeys are illustrative. The decision comes from the whole file.

Across the 9,400 registrations, suppose paid social holds the first touch on 3,100 of them and the registering touch on 260. Its W shaped credit is 3,100 times 0.30 plus 260 times 0.30, which is 930 plus 78, so 1,008 registrations, before the middle share is added. Under last touch, paid social's number is 420. The channel triples, and nothing about the campaign changed.

Email moves the other way on most shows. It is rarely the first touch, since almost nobody's first contact with a show is an email from the show, and it is frequently the identifying touch and the registering touch. A channel that looks dominant under last touch and modest under first touch is doing the job of closing, which is worth knowing and is not the same job as finding the audience. The full ranking flip between those two single touch views has its own comparison and its own meeting.

Two sanity checks stop this becoming a spreadsheet nobody trusts. Total credit summed across all channels must equal the registration count, so 9,400. And the count of registrations with at least one recorded touch must be reported next to the model output, because registrations with no touches at all cannot be in it and are usually a tenth of the file or more.

Keying touches to one person, which is where this fails

The model is arithmetic. The join is the risk.

Three failures show up on every show I have looked at. Email clicks that arrive from a shared inbox, so one person key collects the touches of four colleagues. Registrations completed by an assistant on behalf of a delegate, where the touch history belongs to the assistant and the registration belongs to the delegate. And click identifiers that never reach the registration record because the form sits on a different domain from the landing page, which silently converts a paid registration into a direct one.

The third is the most common and the most fixable, and it is a tagging and form problem rather than a modelling problem.

There is also a quieter failure worth naming. If your touch table is built by joining email addresses, then registrations from people who never gave you an email before registering will have exactly one touch, the registering one, and the W shape collapses to last touch for them. Those registrations are not evenly distributed. They skew towards first time attendees, which is precisely the group most acquisition budgets exist to reach.

Where this stops

A weighted split cannot tell you what would have happened without a channel. It divides the credit for registrations that happened, which is an accounting exercise, and an accounting exercise answers the question of what to report rather than the question of what to buy.

Google's own Analytics Help documentation makes the direction of travel clear: the first click, linear, time decay and position based models were removed as of November 2023, leaving data driven attribution and two last click variants. Whatever you build, you are building it in your warehouse on your own touch table, and any weighted model you run is yours to explain.

The deeper limit is that a fixed weight set is wrong in a specific direction for a deadline driven business. Weight given to the middle of a nine month journey is weight taken from the fortnight when registrations actually arrive, and a scheme that treats a touch at 132 days and a touch at 9 days as members of the same middle is throwing away the timing information you have. The alternative is to make time itself the weighting variable, which an exponential decay model does directly, or to let the sequence data set the weights through a transition matrix built from the journeys themselves. Both are more defensible than 30, 30, 30 and 10. Both are also harder to explain in a room where somebody is about to lose budget, which is the practical reason the heuristic survives.

Build the touch table first and stop there for a week. Take one edition, join ad clicks, email clicks and site sessions to a hashed email, count how many of your registrations have at least two touches, and see whether the answer supports any multi touch work at all before you argue about weights. If most registrations carry one touch, the problem is capture, and the acquisition and attribution pillar is the place that argument starts.

Questions people ask about multi touch attribution for events

What does a W shaped attribution model give credit to?
Three touches carry 30 per cent each and the remaining 10 per cent is spread evenly across everything between them. For a show the three are the first recorded touch, the touch where an anonymous visitor became a known contact, and the touch on which the registration completed. Every other touch shares a tenth of the credit.
What data do you need before multi touch attribution will run?
One table with a row per touch, carrying a person key, a timestamp, a channel, a campaign and the registration it belongs to. The person key is the hard part, because it has to survive an ad click, an email click and a registration form filled on a different device three weeks later.
Can Google Analytics do multi touch attribution for a show?
Not with the rules based models any more. Google's Analytics Help documentation states that the first click, linear, time decay and position based models were removed as of November 2023, leaving data driven and last click options. A weighted split across your own touch table has to be computed in your own warehouse.

Related reading

All attribution articles