Capturing click ids on registration forms so paid credit survives the handoff

The media agency's report says the search campaign delivered 1,240 registrations. Your registration file says something else, and the meeting stalls on whose number is real.

Capturing click ids on registration forms is what turns that argument into arithmetic. The click id is the parameter the advertising platform sticks onto your landing page url at the moment somebody clicks, and if it ends up in a column on the registration row you have a key that joins your file to the platform's file, one record at a time.

What a click id is and where it comes from

Google's auto-tagging documentation, current in 2026, describes it plainly: the feature attaches the Google click identifier, gclid, to the url your customers click. Meta appends fbclid, Microsoft Advertising appends msclkid, LinkedIn appends li_fat_id, TikTok appends ttclid.

The important property is that the platform writes it. A campaign tag is a claim your link builder makes about itself, and your link builder is a colleague with a spreadsheet. A click id is evidence from the other side of the transaction, and the platform can look it up against its own billing record. When the two disagree, the click id is usually the one to believe.

The second property is that it identifies one click. Two people who arrive from the same ad on the same morning carry two different values in the same column. That granularity is what lets you answer questions a campaign tag cannot: whether registrations came from one ad or across the ad set, and how many distinct clicks preceded a single registration.

Capturing it at the moment of submit

The capture has two halves, and teams routinely build the first and forget the second.

On landing, read the query string for each known parameter and write the value into a hidden input on the registration form, along with the parameter name it came from, a timestamp, and the landing url. Write it to session storage too, so a visitor who wanders through three pages before registering still has it.

At submit, post those hidden fields with the rest of the form and store them on the registration row. One nullable column per parameter, plus click_id_captured_at and landing_url. Not a JSON blob, because the first thing you will want is a count grouped by which parameter was present, and that should be a group by rather than a parsing exercise.

The failure worth guarding against is the form that repopulates hidden fields on a later step from a variable that was only ever set on the first page. If your registration runs across more than one page, read the value back from storage on every step, and check it survives, which is the same discipline as testing the campaign tag hop by hop in B2.

Why does the platform report more conversions than your file?

Now the reconciliation. Take one edition, one paid search account, one date range.

The platform reports 1,240 conversions. Your registration file has 890 rows carrying a gclid inside the same window. The gap is 350, which is 28.2 per cent of the platform's number, and the useful work is splitting that 350 into causes rather than declaring one side wrong.

A decomposition on a file like this typically lands somewhere near: 120 conversions modelled by the platform where the visitor refused consent and no identifier was ever readable, 95 cross device journeys where the click happened on a phone and the registration on a laptop, 80 counted against a different conversion action or a different window than the one you queried, and 55 genuine capture failures on your own form. Those four add to 350.

Each has a different remedy. The 55 are yours to fix and worth fixing this month. The 95 cross device are a known property of how people research a show at work and register at home, and the honest treatment is to report them as a known band rather than to chase them. The 80 are a query definition problem, solved by matching the platform's conversion action and lookback before comparing anything. The 120 are not recoverable at all, which is the next section.

Turning that reconciliation into a standing report each edition is B20's subject. What matters here is that the click id is what makes the decomposition possible, because without it you are comparing two totals and have no way to ask which specific registrations are missing.

The join itself is a left join from your registration rows to the platform's click export, keyed on the identifier, and the direction matters. Joining from your file outwards tells you how many of your registrations the platform can account for, which is the question a finance director asks. Joining from the platform's file inwards tells you which reported conversions have no row behind them, which is the question that finds bugs. Run both, and expect the two counts to differ, because a single registration can carry an identifier from a click the platform recorded on a different day than the one you filtered on.

One more check belongs in the same query. Count the distinct registration rows sharing a single identifier. More than one usually means a duplicate registration rather than a tracking fault, because the same person completed the form twice from the same landing session, and those duplicates will inflate every conversion count you build on the column until somebody deduplicates them.

What consent changes about the join

Google updated consent mode in November 2023, adding ad_user_data, which sets consent for sending user data related to advertising to Google, and ad_personalization, which sets consent for personalised advertising. Those two parameters became a requirement for European Economic Area traffic during 2024, and they change what your join can see.

When a visitor refuses, the platform receives a signal without the identifiers that would let it stitch the click to the registration, and it fills the gap with modelled conversions. Modelled conversions are estimates. They are reasonable estimates, and they are not rows, so they will never appear in your registration file no matter how good your capture is.

That has a practical consequence for how you report. On a show with a large European audience, a click id join will always show fewer conversions than the platform, and the difference is partly a measurement of your consent rate rather than a defect. Report the joined number as joined, report the platform number as reported, and keep the two labelled. Merging them into one figure loses the only useful thing about having both.

It also means the consent banner is now part of your attribution stack. A banner that defaults to refusing everything is a defensible choice, and the cost of that choice shows up in this join, in this column, and somebody should be able to say what it is.

How long should you keep a click id?

Longer than the campaign, shorter than forever, and with a written reason.

The identifier is personal data in most readings, because it is attached to a person's registration record and can be used to look that click up at the platform. The reasonable retention period is the one that covers your reconciliation cycle plus your dispute window, which for most shows means through the post show reporting cycle and the following edition's planning, so roughly eighteen months.

Two habits make that defensible. Put the click id columns in the same retention policy as the rest of the registration record rather than in a separate untracked table, and drop them on the same schedule. And exclude them from the exports that go to exhibitors and partners, because a click id has no meaning to an exhibitor and no business being in a lead file.

The related question is whether to send the identifier back to the platform as an offline conversion, which is a different decision with a different privacy footprint. Uploading identifiers turns your registration file into training data for somebody else's bidding model, and that may be exactly what you want, since it usually improves delivery. It is a choice to make deliberately, with the person who owns your privacy notice, rather than a default somebody enables inside an advertising account on a Friday afternoon.

Where this stops

A click id proves a click happened and that a registration followed. It does not prove the click caused the registration, and on a show that people already intend to attend, a meaningful share of paid clicks are people who would have registered anyway.

The method also only covers platforms that issue an identifier. Email, print, partner links, an exhibitor's guest pass campaign and word of mouth carry no click id, which means the registrations you can join are systematically the paid ones, and a report built only on joinable rows will overstate paid share simply because paid is the part that is measurable. The same registrations that carry no identifier are the ones B7 decomposes.

There is one more failure that looks like a capture bug and is not. If the registration form sits on a vendor domain, the click id may be present on your landing page and absent by the time the form renders, which is a session problem rather than a form problem, and the cross domain handoff in B4 is where that gets fixed.

Start by counting. Run one query against your current edition that counts registration rows where any click id column is populated, grouped by week, and compare it to the click counts your platforms report for the same weeks. If the column does not exist yet, that query takes five minutes to answer and the answer is zero, which is still the most useful thing you will learn this week about how acquisition and attribution is working on your show.