Join Keys: GCLID, Floodlight, and the Physics of Attribution

At 11:42 on a Tuesday morning, someone on an Android phone types “waterproof hiking boots” into Google. Forty-one minutes later they buy a pair for £129.99 on a retailer’s site. Between those two moments, a single alphanumeric string gets written into a URL, copied into a first-party cookie, read back out by a tag manager, attached to a hashed email address, sent to two separate Google measurement systems, credited to a keyword, fed into a bidding model, exported to a data warehouse, and used to build a remarketing audience. That string is the whole reason anyone knows the search and the purchase belong to the same person. Take it away and you have two unrelated facts in two unrelated databases.

The string is a GCLID, and the chain it holds together is the closest thing digital advertising has to a physical law. Every hop in the chain is a join: two records that have to be matched on a shared key. Every privacy intervention of the last six years, and every regulatory remedy still being argued in court, is an attack on one of those keys.

The Click Is the Primary Key

When a Google Ads click lands on an advertiser’s site with auto-tagging enabled, Google appends a gclid parameter to the destination URL (Google Ads Help: auto-tagging). The parameter is opaque. It encodes nothing an advertiser can decode locally. Its value is entirely relational: Google’s systems can look up that ID and retrieve the account, campaign, ad group, keyword, match type, device, and, critically, the cost of that click. The auction mechanics that produced the cost are the subject of The Auction That Ate Advertising. What matters here is that the auction record and the conversion record live in different systems, and the GCLID is the only thing that lets you put them in the same row.

Clicks routed through Display & Video 360 or Campaign Manager 360 get a different parameter, dclid, from the DoubleClick lineage rather than the AdWords one. Two click-ID namespaces, two provenances, one company. Only one click ID is honoured per integration, so an advertiser running both Google Ads and DV360 against the same landing page has to decide which system owns the join.

The GCLID does not stay in the URL. The Google tag reads it on page load and writes it into a first-party cookie in the _gcl_* family, typically _gcl_aw for Google Ads clicks, with a default lifetime of 90 days (Google tag platform: cookie usage). This is the single most consequential design decision in the chain. Because the click ID lives in a first-party cookie set on the advertiser’s own domain, it survives Safari’s Intelligent Tracking Prevention and Firefox’s Enhanced Tracking Protection, which target third-party cookies. Google’s conversion measurement was structurally insulated from the browser privacy crackdown years before that crackdown arrived, not by strategy in retrospect but by the ordinary mechanics of putting the key on the advertiser’s own domain.

Where the URL cannot carry a GCLID at all, Google invented substitutes. gbraid handles app-to-web journeys on iOS where a click originates in an app, and wbraid handles web-to-app. Both exist because Apple’s App Tracking Transparency broke the identifier the original scheme relied on. The pattern repeats throughout this chapter: when a join key is removed, Google ships another one.

Page Load: Two Measurement Systems Start Counting

The tag fires next, and this is where the architecture gets strange. Google Tag Manager evaluates its triggers, the consent management platform resolves the visitor’s choices, and, assuming consent is present, two different conversion-measurement systems begin recording the same visit.

GA4 writes session_start and page_view events into its event stream (GA4: automatically collected events). GA4’s event model, and the deliberate abolition of the session as a first-class object, is the subject of The Death of the Session. Its lineage runs back to Urchin Software, acquired in March 2005 and relaunched as free Google Analytics that November.

In parallel, if Campaign Manager 360 is in the media plan, a Floodlight counter activity fires (CM360 Help: about Floodlight). Floodlight is the DoubleClick-lineage conversion tag, and it is shared across CM360, DV360, and SA360. Its data model is activities, not events. Its attribution windows, its click-versus-view logic, and its reporting surface are separate from GA4’s. The two-layer relationship between CM360 and the buying platforms is covered in Two Layers, One Ledger.

Here is the central architectural fact of the modern Google stack, and it is one Google has never resolved: GA4 events and Floodlight activities are two parallel measurement systems inside one company, and both of them will claim credit for the same purchase. They are not redundant copies. They disagree. They use different attribution models, different lookback windows, different identity resolution, and different definitions of what counts as a conversion. Reconciling a GA4 number against a Floodlight number is a permanent line item on every enterprise measurement team’s backlog, and the reason is corporate history, not engineering necessity.

	GA4 events	Floodlight activities
Lineage	Urchin Software, acquired March 2005	DoubleClick, acquired March 2008
Unit of record	event with parameters	activity (counter or sales) inside a Floodlight group
Primary consumers	GA4, Analytics 360, BigQuery export, Google Ads	CM360, DV360, SA360
Default identity	first-party cookie, User-ID, Google Signals	DoubleClick cookie, CM360 device ID, hashed match
View-through conversions	not a native concept	first-class, with separate windows
Warehouse path	free native BigQuery export	Data Transfer files or Ads Data Hub

The Hash Replaces the Cookie

Forty-one minutes in, the purchase fires. GA4 records a purchase event with items, value, currency, and a transaction_id. Floodlight records a matching sales activity. The GTM web container forwards the payload to a server-side container running on the advertiser’s own subdomain, which is where the interesting transformation happens. Why the data layer, rather than the tag, is the real contract in this system is argued in The dataLayer Is a Message Bus.

Enhanced Conversions, introduced in 2021, takes the first-party personal data the customer just typed into the checkout form and turns it into a join key. Email addresses and phone numbers are normalised, then hashed with hex-encoded SHA-256, and only the hash leaves the advertiser’s infrastructure (Google Ads: enhanced conversions for web). Google matches the hash against its own store of hashed identifiers for signed-in accounts and, on a match, attaches the conversion to the click (Google Ads API: enhanced conversions).

Read that mechanism as an architectural pivot rather than a feature. Identity moved from a third-party cookie, which any browser vendor could unilaterally delete, to a hashed first-party attribute matched against a logged-in account graph. The privacy properties genuinely improve: no raw email crosses the wire, and the advertiser controls what gets hashed. The competitive properties are the interesting part. A matching scheme that depends on a signed-in account graph structurally advantages whichever company has the most signed-in users. Google has Gmail, Android, YouTube, and Chrome sync. Independent measurement vendors have none of that. Every step toward hashed first-party matching is also a step toward measurement that only large platforms can perform.

Google Signals, launched in 2018, was the earlier version of the same idea: cross-device journey stitching using data from users signed in with ads personalisation enabled (GA4: Google Signals). It also shows the limits. In 2024 Google curtailed device-level Google Signals data in reporting, citing privacy considerations. A capability Google built, promoted, and taught practitioners to depend on was narrowed by the same regulatory pressure Google’s own compliance teams were absorbing.

Write-Back: Two Ledgers, One Purchase

The conversion now travels back up the chain, and it travels twice.

Google Ads credits the conversion against the keyword and campaign the GCLID resolves to, using data-driven attribution as the default model since 2021 (Google Ads Help: data-driven attribution). That credit is not just a reporting artifact. It is training data. Smart Bidding consumes attributed conversions to set the next bid, which means the attribution model is inside the bidding loop. Change the attribution model and you change what the algorithm bids on, which changes which clicks you buy, which changes the conversions the model learns from next. The loop is closed and self-reinforcing, and an advertiser who does not understand this will read attribution-model changes as reporting noise rather than as a change to their media buy.

Floodlight, meanwhile, records the same purchase for CM360, and from there DV360 and SA360 read it. Same event. Different ledger. Different credit assignment. A media team can and routinely does report two different conversion counts for one quarter, both correct within their own system, and neither reconcilable to the other without manual work.

The Warehouse Becomes the System of Record

The last two hops are where practitioner behaviour changed most in the 2020s. GA4 exports raw event data to BigQuery on a free tier, daily and streaming (GA4: BigQuery export). Google Ads, CM360, and DV360 data arrive through BigQuery Data Transfer Service or, where user-level joins are restricted, through Ads Data Hub’s privacy-safe aggregate queries.

Once raw events land in a warehouse the advertiser controls, the reporting UI stops being the system of record. Blended CAC and ROAS get computed in SQL, not read off a dashboard. Audience definitions get written as queries. Predicted lifetime value gets modelled in the warehouse and pushed back into Google Ads as a Customer Match list, which is uploaded as, again, hex-encoded SHA-256 hashes of email addresses (Google Ads Help: Customer Match).

Note what closes the loop. The same hashing primitive that carried the conversion into Google now carries the audience back out. The join key is the identity, in both directions, and it is a hash matched against an account graph Google owns.

Trace the chain once and the pattern is impossible to miss. Query to click is a URL parameter join. Click to page load is a cookie join. Page load to conversion is a session join, twice, in two incompatible systems. Conversion to identity is a hash join. Identity to bidding is an attribution join. Bidding to warehouse is a schema join. Warehouse to activation is a hash join again. Nearly every hop is a join-key problem, and every regulatory intervention of the last five years, consent gating, cookie policy, Digital Markets Act limits on cross-service data sharing, hashed-only matching, is an attack on one specific key in that list. The next chapter takes the sharpest of those attacks and shows how a competition-law deadline turned into a tagging specification: Consent as an API.

Key Sources

Source	Author/Org	Year	Link	Why it matters
About auto-tagging	Google Ads Help	2024	support.google.com	Defines the GCLID append behaviour that starts the entire attribution chain
Google tag platform cookie usage	Google for Developers	2024	developers.google.com	Documents the _gcl_* first-party cookie family and its default lifetimes
Automatically collected events	Google Analytics Help	2024	support.google.com	Specifies session_start and page_view, the GA4 side of the double count
About Floodlight	Campaign Manager 360 Help	2024	support.google.com	The DoubleClick-lineage conversion system that records the same purchase in parallel
Enhanced conversions for web	Google Ads Help	2023	support.google.com	The pivot from cookie identity to hashed first-party identity
Enhance your conversions	Google Ads API docs	2024	developers.google.com	Specifies hex-encoded SHA-256 normalisation and the sha256_ field conventions
Google Signals	Google Analytics Help	2024	support.google.com	Cross-device stitching via signed-in users, and its 2024 curtailment
About data-driven attribution	Google Ads Help	2024	support.google.com	Shows attribution sitting inside the Smart Bidding training loop
BigQuery Export	Google Analytics Help	2024	support.google.com	The free export that made the warehouse, not the UI, the system of record
About Customer Match	Google Ads Help	2024	support.google.com	Closes the loop with the same hashing primitive running outbound

PM Lens