How registration source tracking breaks between the ad click and the record

The paid social platform says the ad set delivered 3,180 link clicks. The registration file, filtered to that campaign value, has 96 rows in it. Somebody asks the obvious question, which is whether the ads worked, and the honest answer is that nobody in the room can tell.

Registration source tracking is a relay, and the tag has to be handed off cleanly six times between the click and the saved row. Most teams treat it as one thing that either works or does not. It is six things, each of which fails independently, and each of which can be tested in about ten minutes with a single link.

Where does the tag actually live?

The campaign value starts life as text in a url query string. That is the only place it exists when the visitor arrives.

From there it has to be moved into something that persists. Usually that is a first party cookie written by JavaScript, or a value in the browser's session storage, or a hidden input on the registration form. Then it has to be posted with the form, written to a column on the registration row, and included in whatever export feeds your reporting.

Every one of those moves is code somebody wrote, and every one of them can be missing without producing an error. The tag does not throw an exception when it disappears. The row is simply saved with an empty column, which looks exactly like a person who typed your url from a printed programme.

The six hops

The landing page redirect. Your ad points at yourshow.com/register and the server sends a 301 to yourshow.com/register/ or to a country subfolder. Redirects that are written without a query string rule drop everything after the question mark. This is the most common single failure and the cheapest to fix.

The registration domain. The form lives at register.yourshow.com or on a vendor domain entirely. The cookie your JavaScript wrote on www is not readable there, and unless the link between the two carries the value explicitly the second domain starts from nothing. Fixing this handoff properly is B4's subject, and it deserves the space.

The session timeout. Somebody clicks on Tuesday, reads the agenda, and registers on Friday. Whether the value is still there depends on how it was stored and for how long.

Form step two. Multi step registration forms often post step one to a new url and rebuild the page. Hidden fields that were populated on the landing page are gone unless step two repopulates them from storage.

The payment return. Paid registrations leave your domain for the payment provider and come back to a confirmation url that the provider constructs. That url carries the provider's parameters and nothing of yours.

The nightly export. The export view selects a column list somebody wrote two years ago. New columns are not in it. Or the column is there and truncated to 32 characters, which quietly turns tech26-exhibitor-guest-invites into tech26-exhibitor-guest-inv. Truncation is the worst of the six failures to detect, because the value is present, looks correct at a glance, and joins to nothing.

Running the test with one link

Build one link with a campaign value nobody else will use. Something like utm_campaign=hoptest2608. Then walk the whole path yourself, on a real device, and record what the value looks like at each hop.

Check the address bar after the landing page loads. Open the browser console and read the cookie or storage key you expect. Click through to the form and read the hidden field with the element inspector. Complete step one and read it again. Pay with a test card and read the confirmation page. Then find your own row in the admin interface, and finally in the export file the next morning.

Six checks, one afternoon, and the output is a survival rate for each hop rather than a general feeling that tracking is unreliable. The important property of this test is that most hop failures are total. A redirect either preserves the query string or it does not. That is why hop losses hide so well in aggregate reporting and surface immediately when you follow one link.

Multiplying the survival rates

Take a cohort of 1,000 sessions that arrived with a campaign value attached, and suppose the test returns these survival rates: 100 per cent through the redirect, 62 per cent through the registration domain, 94 per cent through the session timeout, 71 per cent through form step two, 100 per cent through the payment return, and 88 per cent through the export.

Multiply them. 0.62 times 0.94 is 0.5828. Times 0.71 is 0.4138. Times 0.88 is 0.3641. So 36.4 per cent of tags survive the whole relay.

Now put a registration number against it. If 640 of those 1,000 sessions ended in a registration, you would expect 233 rows to carry the campaign value and 407 to carry nothing. The ads did not fail. The relay dropped two thirds of the batons, and the report showed you the third that arrived.

The multiplication is what makes the case for fixing hops in the right order, because a hop at 94 per cent is not worth an afternoon and a hop at 62 per cent is worth a week.

What the seven day cookie cap does to a nine month campaign

The session timeout hop deserves its own treatment, because the answer changed in 2019 and a lot of registration tracking was built before that.

Apple shipped Intelligent Tracking Prevention 2.1 in February 2019, described by John Wilander on the WebKit blog, and it capped all persistent client side cookies, meaning cookies created through document.cookie, to a seven day expiry. Your analytics tag writes exactly that kind of cookie. So a Safari visitor who clicks a paid link in March and registers in April arrives with an empty attribution cookie, and the registration is recorded as direct.

For a show that opens registration nine months before doors, this is not an edge case. It is the normal buying pattern for the senior end of your audience, who see the campaign early, put the show in the diary, and register when their travel budget is confirmed.

There are two honest responses. Write the value into a hidden field on the registration form the moment the visitor lands, so that a registration completed in one visit carries it regardless of cookie lifetime. And capture the platform click identifier alongside it, which B3 covers, because it gives you a second, independent way to reconcile against the platform's own count.

The thing not to do is try to recover the campaign from the referrer. Chrome changed its default referrer policy to strict-origin-when-cross-origin in version 85 in 2020, so cross origin requests carry only the origin. You get the domain and never the query string, which means the referrer can tell you a visitor came from a search engine and can never tell you which campaign paid for it.

Which hop do you fix first?

Rank by the arithmetic, not by how annoying the fix is.

In the example above, repairing form step two lifts end to end survival from 36.4 per cent to 51.3 per cent, because 0.3641 divided by 0.71 is 0.5128. Repairing the registration domain handoff lifts it to 58.7 per cent, because 0.3641 divided by 0.62 is 0.5873. The domain handoff is the bigger prize even though the form fix looks smaller and closer to hand.

Then look at what each fix costs. A redirect rule is a one line change in a web server config. A hidden field on step two is an hour of a developer's time. A cross domain handoff on a vendor platform may need a support ticket and a release cycle, and sometimes the honest answer is that the vendor will not do it, at which point you are choosing between a different capture method and a permanent known loss.

There is a sequencing trap worth naming. Fixing a hop changes the shape of your reporting mid campaign, so paid channels will appear to grow the week after the repair even though nothing about the media changed. Note the date of every tracking fix in the same place you note price tier boundaries and registration open dates, because the next person comparing this edition against the last one will otherwise read a plumbing change as a demand change. A single line in a change log costs nothing now and saves an hour of confusion in the post show review.

Where the test stops

A hop test measures whether a value survives. It says nothing about whether the value was right in the first place, and a link tagged with the wrong medium will pass all six checks and still put registrations in the wrong channel.

The test is also a snapshot. It tells you what happened on the day you ran it, on one browser, through one path. Registration platforms release changes mid campaign, and a hop that passed in June can fail in September without anyone announcing it. The cheap guard is a synthetic registration once a week using the test campaign value, checked in the export the next morning.

The last limit is scope. Even a perfect relay only carries values for people who clicked a tagged link. Registrations that arrive from a printed programme, a colleague's forwarded message or the registration desk have no tag to lose, and they need a decomposition of their own, which is B7's subject rather than this one's.

Do the ten minute version this week. Take one live campaign link, click it on your phone, and check whether the campaign value is still in the address bar after the landing page finishes loading. If it is gone at that first hop, everything downstream of it has been measuring nothing for as long as that redirect has been in place, and you can put a date on it from your own deploy history. That single check is the cheapest useful thing in the whole acquisition and attribution stack.