Cross domain tracking for registration when the form lives on another domain

Sessions on the registration pages are up 40 per cent on last edition and the conversion rate has fallen by a third. Both numbers come from the same report, both are being read as real, and one of them is an artefact of where the form is hosted.

Cross domain tracking for registration is the piece of plumbing that decides which of those numbers you can trust. Almost every show has the problem, because almost every show sends people from yourshow.com to a registration platform on a different domain, and the browser treats that as a visit to a different website by a different person.

Why does one person become two?

The mechanism is in the cookie specification rather than in your analytics tool. RFC 6265, written by Adam Barth and published in 2011, sets out how the Domain attribute works, and it is explicit that if the server omits the Domain attribute the user agent returns the cookie only to the origin server. A cookie set on yourshow.com is not sent to registration-vendor.com, and there is no configuration on either side that changes that.

So when the visitor crosses, the analytics library on the second domain finds no client identifier, generates a fresh one, and opens a new session. Google's cross domain measurement documentation, current in 2026, puts the consequence plainly: without it, a single user visiting two different root domains on the same device is identified separately, as two users and two sessions rather than one user and one session.

The fix is a handoff in the url. The library appends a parameter, _gl in the current Google implementation, carrying the identifiers so the second domain adopts them instead of minting new ones. That parameter is the whole trick, and checking whether it is present is the whole test.

What a self referral looks like in the report

Open your channel report and look for your own domain in the source column. That is the signature.

A visitor arrives on yourshow.com from a paid social ad, browses the agenda, clicks register, and lands on the registration domain. The second session's referrer is yourshow.com, so the report says the registration came from a referral, and the referring site was you. The paid social click that actually paid for the visit is attached to the first session, which ended without a registration.

Two things break at once. The registration is credited to the wrong source, and the session count doubles for every visitor who crosses. The second effect is the one that gets noticed, because it makes traffic look healthy while conversion looks terrible.

How large is this on your own show?

Before fixing anything, size it, because the answer decides whether this is an afternoon or a project.

Filter sessions on the registration domain to those whose source is one of your own hostnames, and express that as a share of all sessions on that domain. Anything above about 10 per cent means the handoff is failing for most visitors. On the file in the next section it is 40 per cent, which is what a completely unlinked handoff looks like on a show where the majority of registrants come through the main site.

There is a second reading available without touching analytics at all. If your registration platform stores a referrer against each record, count the registration rows whose stored referrer is your own domain. That count is the number of registrations whose true source was thrown away at the crossing, and unlike the session figure it is denominated in the thing your commercial team cares about.

Then check the dates. Self referrals usually start on a deploy day, a platform migration or the morning somebody changed the registration button to point at a new url. Plot the share by week across two editions and the step change will be visible, which tells you both when the problem started and which historic numbers were affected. That matters more than it sounds, because the edition on edition comparison everyone is about to make spans the break.

The linker check, done by hand

Settings screens lie, or rather they tell you what was configured rather than what is happening. Check the behaviour.

Open your show site with a tagged link, in a normal browser window rather than a private one. Click through to registration the way a visitor would, using the button on the page rather than typing the address. Read the address bar on the registration domain and look for the linker parameter. Then open the console on each domain in turn and read the client identifier out of the cookie. Same value on both sides means the handoff worked.

Three failures show up in this check. The parameter is absent, meaning the linker is not configured for that destination domain. The parameter is present but the identifier still changes, meaning the second domain's library is not configured to accept it. Or the button that takes people to registration is a server side redirect that rebuilds the url and drops the parameter on the way, which is the same failure mode that loses campaign values and is worth testing hop by hop as B2 sets out.

While you have the report open, add the registration domain and your own domains to the referral exclusion list. That stops the second session being labelled a referral even in the cases where the linker fails, though it does not recover the original source, so it is a tidying step rather than a fix.

Collapsing 3,000 sessions to 1,800

Here is what the repair does to a real looking set of numbers.

Before the fix, the registration path shows 3,000 sessions and 640 registrations, a conversion rate of 21.3 per cent. Of those 3,000 sessions, 1,200 have your own domain as their source. Those are the duplicates: the second half of a journey that was already counted once.

Exclude them and you have 1,800 sessions and the same 640 registrations, a conversion rate of 35.6 per cent. The show did not get better at converting. The denominator stopped counting the same people twice.

Then the credit moves. Those 1,200 sessions were sitting in the referral channel with your own domain against them. With the handoff working, they carry the source they started with, and on a typical mix that might redistribute as 520 to paid social, 300 to email, 240 to organic search and 140 to genuine direct. Paid social gains 520 registrations worth of journey it was always responsible for, and the referral channel loses a line that was never a real acquisition source.

That redistribution is the part worth showing your media agency, because a channel report that has been quietly moving 40 per cent of paid journeys into a self referral bucket has been understating paid performance for as long as the form has been hosted elsewhere. Where those redistributed pairs then land in your eight channel report is a taxonomy question that B5 handles separately.

What if the vendor will not change the domain?

Sometimes you cannot fix it. The registration platform does not expose the tag configuration, or support says the linker is not supported, or the contract has fourteen months left on it.

Three options remain, in the order I would try them. Ask whether the vendor supports a custom subdomain, so registration runs at register.yourshow.com with a cookie scoped to yourshow.com, which removes the problem rather than working around it. Failing that, pass your own identifier explicitly as a query parameter on the link to registration and have the vendor store it as a custom field on the registration record, which many platforms do support because it is just a hidden field. Failing that, fall back to capturing the platform click identifier as B3 describes, and accept that session level reporting on the registration path is not going to be reliable this edition.

The one thing not to do is leave it broken and keep quoting the conversion rate. A number nobody can defend is worse than a missing number, because somebody will make a budget decision with it.

Where cross domain tracking stops

A working linker joins two sessions on one device in one browser. It does nothing about the same person moving between a phone and a laptop, and on shows where people browse at work and register at home that is a real share of journeys.

It also does nothing for visitors who arrive at the registration domain directly, from a link an exhibitor emailed or a code printed in a programme, because there is no first session to link to. Those arrive as their own source and are correctly labelled, even when the label is unhelpful.

The honest limit is that all of this is browser plumbing, and browser plumbing keeps changing. Storage partitioning, cookie lifetime caps and referrer trimming have all moved in the last few years and will move again. Anything you build on a cookie handoff needs a check that runs on a schedule rather than a one off configuration you trust for three years.

Do the check this week and write down what you find. Click one tagged link on your show site, follow it to the registration form, and read the address bar. If there is no linker parameter on that url, every registration completed on that domain since the platform went live has been credited to your own website, and the size of that misallocation is one filter away in your acquisition and attribution reporting.