Email attribution for event registrations that survives forwarding and shared inboxes

The campaign report says the deadline mailing produced 512 registrations. The audience manager thinks it produced closer to 700, because she has spent two weeks reading replies from people saying a colleague sent them the mail. Both of them are working from the same data and neither can prove anything.

Email attribution for event registrations breaks on this specific thing more than on any other. A trade show audience forwards mail constantly, registers in groups, and works from mailboxes shared by four people, and a measurement design that assumes one address equals one person will undercount every send.

What does a send identifier need to carry?

Two values, on every link, in every mail.

The first is a send identifier that names the mailing itself: the edition, the programme, the specific drop. Not the campaign, not the channel, the individual send. It has to be stable, so a mail resent to a suppressed segment three days later carries a different value and can be counted separately.

The second is a recipient identifier, unique to the person the mail was addressed to. This is the one that gets misused. It is not a claim about who clicked. It is a record of who the mail was sent to, and the difference between those two statements is the whole subject of this post.

Both go on the URL as parameters, and both must be written to the registration row at submit. If they only exist in your email platform's click log, every question that follows needs a join across two systems on a timestamp, which is exactly as unreliable as it sounds.

Why does a forwarded email break the report?

A senior buyer receives your deadline mail. She does not register herself. She forwards it to two people on her team who do the trade shows, and both of them click the link in the forwarded copy and register.

Every click carries her recipient identifier, because the URL was written for her. So the click log says she clicked twice. The registration file says two registrations came in with her identifier attached and two different email addresses on the records. If your attribution runs on recipient identifier alone, you have credited her with two registrations she did not make, and your engagement scoring now thinks she is your most active contact.

If instead your attribution runs on matching the registration address to the mailed address, both registrations fall out of the email programme entirely and land in whatever bucket you use for unknown source. The mailing produced two registrations and gets credit for zero.

The way out is to attribute the send at one level and the person at another. The send identifier earns the credit, because the mailing genuinely caused those registrations. The recipient identifier gets a status flag: registered by addressee, or registered by somebody else. Both facts are true and they answer different questions, one for the campaign report and one for the contact record.

The recipient to registrant join

Person-level attribution needs the mailed file and the registration file to agree on what an email address is. They usually do not, because one came from a customer database and the other was typed on a phone.

Normalise both sides before comparing. Google's Customer Match documentation, current in 2026, sets out the normalisation it expects before hashing with SHA-256: remove leading and trailing whitespace, lowercase the whole address, and for gmail.com and googlemail.com specifically, strip periods and any plus suffix from the username. That specification is worth copying wholesale for internal joins, including the detail that the period rule applies only to those two domains. Dots are significant in most corporate addresses, so a blanket rule that strips them will merge two colleagues at the same employer into one person.

Hashing matters here even though the join is internal. Once both files are reduced to normalised hashes, the join can run in a reporting environment without moving addresses around, and the same hashed keys are what you would push to an ad platform anyway.

Then join on three keys in order: exact hash of the address, then hash of the address after normalisation, then company domain plus surname for the residual. The third key is a candidate list for review and never an automatic match, because a large employer will produce false pairs at a rate that will embarrass you.

Working one send end to end

Take a deadline mailing to 18,400 delivered addresses that produced 3,210 clicks carrying a recipient identifier, and count registrations completed within fourteen days of the send.

640 registrations carry the send identifier. They break down as follows. 512 were completed with the same address that was mailed. 96 carry a recipient identifier but were completed with a different address, and of those 71 share the mailed contact's company domain while 25 are on a different domain entirely. The remaining 32 carry the send identifier with no recipient identifier, which happens when somebody copies the link from a web version or a parameter gets stripped in transit.

Now the two numbers people argue about. Registrations by the person you mailed: 512, which is a list quality measurement. Registrations produced by the send: 640, which is a campaign measurement. The gap is 128 registrations, exactly 20 per cent of the send's true output, and reporting only the first number understates every mailing you run by roughly that much.

The 71 same-domain records are the interesting ones. That is one buyer telling colleagues to register, which is the behaviour every organiser says they want and almost nobody counts. Track it as its own series across sends and you learn which messages travel inside an account.

For the arithmetic to hold, the fourteen day window has to be fixed before you look, and the same window has to apply to every send in the comparison. A window chosen after seeing the data is not a measurement.

One more count belongs in the same query, and it is the one that stops two sends claiming the same person. If a registration carries send identifiers from two mailings inside the window, because the reader clicked the agenda mail on Tuesday and the deadline mail on Friday, decide once whether the last send or the first send takes it, write the rule down, and apply it to every edition. On a well-run programme with weekly sends, somewhere between five and fifteen per cent of registrations will carry more than one send identifier, and the choice is worth about that much to whichever mailing wins.

Registrations from addresses you never mailed

In the same fourteen days, suppose 1,180 registrations arrive from addresses that appear in no send file at all. That bucket needs splitting rather than assuming.

Some are forwards where the tagged link was lost, and the tell is a shared company domain with a mailed contact plus a registration timestamp inside a day of the send. Suppose 214 of the 1,180 fit that pattern. They are not attributable to the send with any confidence, so do not move them into the email column. Report them as a named line, forward candidates, with the rule that produced them written next to the number.

Some are people who register with a personal address after reading a mail sent to their work address. Same person, two identities, and no way to link them without asking.

The rest are people who genuinely came from somewhere else. How large that residual is, and whether it is shrinking, is the subject of tracking what share of registrations carry a usable source, and it is a better health metric for this programme than any per-send figure.

Shared mailboxes deserve a rule of their own. Microsoft's Microsoft 365 documentation, in its 2026 version, describes a shared mailbox as an address a group of people monitor and send from together, with sign-in blocked by default and no licence of its own in most cases. When your mail lands in one of those, several people read it, several may register, and every click carries the same recipient identifier. Maintain a list of local parts that indicate a mailbox rather than a person, such as info, events, marketing and reception, flag those recipient rows, and keep them out of any per-person engagement score.

Where this stops

Person-level email attribution is capped by the honesty of the addresses you hold, and there are three places it gives up.

The first is the mail that produces a registration with no click at all. Somebody reads the deadline in your mail, closes it, and goes to the show website directly two days later. Nothing in the registration row will ever connect that to the send. A holdout is the only instrument that sees it, and that measurement belongs with comparing a mailed cohort against a held-back tenth.

The second is that click data has become a poor signal of human behaviour in general, because security scanners and privacy proxies fetch links and images automatically. Clicks are still far better than opens for this purpose, and why opens now measure infrastructure instead of people is a separate argument with its own evidence.

The third is that this method credits a send for a registration it may only have accelerated. The person who was going to register in the final week and registered on the day of your mail counts fully in the 640. That is a known bias, it applies to every last touch count in your acquisition and attribution reporting, and it is why the send-level number belongs next to a tested figure rather than replacing one.

Start this week with one query. Take your last deadline send and count registrations carrying its send identifier where the registration address does not equal the mailed address. If that count is more than a few per cent of the send's total, your email programme has been reporting a number that is systematically too low, and you can say by how much by the end of the afternoon.