Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Lead source attributor series ~5 min read

How visits get stitched

A first-time visitor who enquires immediately is easy. Almost nobody does that. The accuracy in attribution comes from correctly linking the visit where somebody enquired to the four earlier visits where they were deciding, and that is a harder problem than the capture step by a wide margin.

Key takeaways

  • A first-party cookie links visits on one device. That covers most of the value.
  • The enquiry itself is the strongest stitch: an email address links devices retroactively.
  • Record how a link was made, so a weak stitch can be excluded from a strict report.
  • Never buy or join third-party identity data. The line is firm and worth stating.
  • Unstitched visits stay unstitched rather than being guessed into a plausible path.
How visits from the same person are linked togetherA vertical chain of five steps entered by a box labelled A new touch, someone arriving. Step one asks whether a visitor id already exists, first-party and on this device; if so it exits to Strong link, same device, certain. Step two asks whether they enquired, giving an email address; if so it exits to Retroactive link, which merges other devices. Step three asks whether a one-time link token from an email we sent is present; if so it exits to Strong link, because we know who we sent it to. Step four leaves it unstitched as a standalone touch. Step five records the confidence alongside the link. A note says there is no fourth branch that guesses, and unstitched stays unstitched.AWS ACCOUNTA new touchsomeone arrivingA visitor id already?first-party, this deviceStrong linksame device, certainyesDid they enquire?giving an emailRetroactive linkmerges other devicesyesA one-time link token?from an email we sentStrong linkwe know who we sent it toyesLeave it unstitcheda standalone touchRecord the confidencewith the linkThere is no fourth branch that guesses. Unstitched stays unstitched.
Fig 1. The three stitching signals, in order of strength. The absence of a probabilistic fallback is a deliberate choice rather than an omission.
  • Compute
  • Database
  • App integration
  • Machine learning
  • Networking

The enquiry is the strongest signal

When somebody finally fills in the form and gives an email address, that address links backwards to every earlier visit on that device, and forwards to any other device where the same address has been used. It is the highest-quality identity signal in the system and it arrives at the end, which means stitching has to be able to run retroactively over touches already stored.

That has a practical consequence worth planning for: the attribution of an enquiry can change after it is recorded. Somebody enquires on their phone, and a week later logs in on a laptop where they had visited three times from a newsletter. The path grows, and the report for that quarter should reflect it. Reports are therefore computed on demand from the stored path rather than frozen at enquiry time.

Recording confidence

Each link carries how it was made — same-device cookie, email match, token from a sent message — and reports can be run at different strictness levels. A strict report uses only same-device and token links; a looser one includes email matches across devices.

The gap between the two is itself informative. If the strict and loose reports say roughly the same thing, the stitching is not doing much work and the result is robust. If they diverge sharply, the answer depends on identity assumptions and should be presented as a range.

The line this does not cross

The identity techniques this attribution system refuses to useA horizontal row of five boxes. Own visits: linked, which is fine. Own emails: linked, which is fine. Bought identity graph: refused. Fingerprinting: refused. Cross-site tracking: refused. A note says the refused three would improve the numbers, and that is not a sufficient argument.WHAT THIS SYSTEM REFUSES TO DOOwn visitslinked -- fineOwn emailslinked -- fineBought identity graphrefusedFingerprintingrefusedCross-site trackingrefusedThe refused three would improve the numbers. That is not a sufficient argument.
Fig 2. The boundary, stated plainly. Everything on the right would raise the stitch rate, which is exactly why the line has to be drawn on something other than accuracy.

Fingerprinting deserves a specific mention because it is technically available, it genuinely works, and it is presented in vendor material as a neutral fallback for when cookies are unavailable. It is not neutral: it exists to identify people who have configured their browser to make that harder, which is a fairly direct way of overriding a stated preference.

The practical cost of refusing all three is a lower stitch rate and a larger unattributed column, which the report shows honestly. That is a better position than a complete-looking report built on data whose provenance nobody in the business could explain.

What unstitched costs

At typical volumes, somewhere between a fifth and a third of touches never get linked to an enquiry. They sit in the store as standalone arrivals and contribute to the denominator without contributing to any path.

That is not waste; it is the measurement. A source that generates a lot of unstitched traffic and few enquiries is telling you something, and averaging it away into an attributed-only report is how a channel keeps a budget it has not earned.

Next: assigning the credit.

All posts