2. How Web Tracking Actually Works

Strip away the dashboards, the SDKs, and the buzzwords, and all web tracking reduces to three primitives:

1. HTTP requests that carry data to a platform,
2. cookies that make a browser recognizable on the next visit,
3. identifiers that let a platform join those requests together into "a user who clicked an ad and later purchased".

If you can read those three fluently, you can debug any tracking setup on any platform — and everything about server-side tagging will make sense, because server-side tagging is just moving where these primitives happen.

The request is the tracking

A tag's entire job is to make HTTP requests. The "data" a platform receives is whatever the browser put in the URL parameters and body of those requests — nothing more. When GA4 records a purchase, what physically happened is this:

POST https://www.google-analytics.com/g/collect?v=2
   &tid=G-ABC123XYZ          ← which GA4 property this belongs to
   &cid=1712345678.1699...   ← client ID: "who" (from the _ga cookie)
   &sid=1718105400           ← session ID
   &en=purchase              ← event name: "what"
   &ep.transaction_id=T-1024 ← event parameter (text)
   &epn.value=99.5           ← event parameter (number)
   &cu=EUR                   ← currency
   &dl=https://shop.example/checkout/thanks    ← page URL
   &dr=https://google.com/                     ← referrer

Read that slowly once and GA4 stops being magic: a property id, a user id, an event name, parameters. Every platform's tracking request is a variation of the same shape. Meta's pixel, for instance:

GET https://www.facebook.com/tr/?id=1234567890
   &ev=Purchase              ← event name
   &cd[value]=99.5           ← custom data
   &cd[currency]=EUR
   &fbp=fb.1.1699...4567     ← Meta's browser ID cookie
   &fbc=fb.1.1699...IwAR2x   ← Meta's click ID cookie (came from an ad click)
   &dl=https://shop.example/checkout/thanks

A few mechanical details that matter later:

• Tags send these as image GETs (the 1×1 pixel trick from Chapter 1), as POSTs via fetch, or via navigator.sendBeacon() — a browser API that queues the request so it survives the user navigating away mid-send. GA4 uses beacons heavily; it's why purchase events on "thank you" pages usually survive a fast redirect.
• The hostname is the kill switch. Every one of these requests goes directly to the vendor's domain — google-analytics.com, facebook.com. Anything that can see hostnames (an ad blocker, a DNS filter, the browser itself) can block the request outright. File that away for Chapter 3.

Cookies: first-party vs third-party

A cookie is a small key=value the browser stores per domain and automatically attaches to matching requests. Two distinctions do all the work in this guide.

First- vs third-party is about whose domain, relative to the address bar:

you are browsing  shop.example
──────────────────────────────────────────────────────────────
first-party cookie    set for .shop.example
                      → readable on every future shop.example visit
 
third-party cookie    set for .facebook.com, because the Meta pixel
                      made a request to facebook.com from this page
                      → readable on ANY site that loads facebook.com
                        requests: that's cross-SITE recognition

Third-party cookies are how classic retargeting worked: one facebook.com cookie, visible from every site carrying the pixel, stitched your browsing into one profile. That mechanism is dead or dying — Safari and Firefox block third-party cookies outright, and Chrome restricts them — which is why modern tracking (including everything in Part 3) is built on first-party cookies plus click IDs.

Who set the cookie — JavaScript or an HTTP response — matters just as much:

• document.cookie = "_ga=..." — set client-side by JS. This is how nearly all tag cookies are set today. Safari's tracking prevention caps these at 7 days (sometimes 24 hours).
• Set-Cookie: FPID=...; HttpOnly; Max-Age=... — set server-side by an HTTP response header. Far more durable, and invisible to page JavaScript. You need to control a server on your own domain to do this — remember that when you reach Chapter 11; it's one of server-side tagging's biggest prizes.

The identifier zoo

Open DevTools → Application → Cookies on any commercial site and you'll meet the same cast. All of these are first-party, JavaScript-set by their tags:

And alongside the cookies, the click IDs — URL parameters an ad platform appends when someone clicks an ad:

The attribution loop

Cookies and click IDs combine into the single most important mechanism in paid advertising. Walk through one Meta ad click:

1. CLICK      user clicks your ad on Facebook
              → lands on  shop.example/product?fbclid=IwAR2xK9…
 
2. CAPTURE    the Meta pixel JS sees ?fbclid in the URL
              → writes it into the first-party _fbc cookie
              → also ensures _fbp (browser ID) exists
 
3. BROWSE     user looks around, adds to cart… (cookies persist)
 
4. CONVERT    purchase event fires
              → request to facebook.com/tr carries fbp + fbc
 
5. JOIN       Meta's servers match fbc/fbp to the ad click
              → conversion credited to the campaign, ad set, ad
              → feeds the bidding algorithm

Google Ads works the same way with gclid → _gcl_au (that capture step is exactly what GTM's "Conversion Linker" tag does). This loop is why a marketer's "the campaign shows no conversions" is usually an engineer's "step 2 or 4 broke" — and why losing cookies (Chapter 3) doesn't just lose analytics, it blinds the bidding algorithms that spend the money.

What a "conversion" technically is

"Conversion" means something slightly different on each platform, and knowing the mechanics saves hours of confusion:

• GA4 — there are only events. A "key event" (formerly "conversion") is just an event name you've flagged in the GA4 admin UI. Technically, a purchase is a /g/collect request with en=purchase — nothing more special than a page_view.
• Google Ads — a conversion is a platform-side join: a conversion event (imported from GA4, or fired by a Google Ads conversion tag) that Google could match to an ad click via gclid/_gcl_au — or, lacking those, via hashed user data ("enhanced conversions", Chapter 14).
• Meta — a standard event (Purchase, Lead, AddToCart…) received with enough identity signal (_fbp, _fbc, hashed email/phone) for Meta to match it to a person, within the campaign's attribution window (e.g. 7-day click).
• TikTok / LinkedIn — same pattern as Meta: event + click ID/browser ID + optional hashed PII, matched server-side within a window.

The common thread: a conversion is always an event plus a successful identity match on the platform's side. Send a perfect purchase event with no usable identifiers and the platform shrugs — it can't credit anything. That's why so much of this guide obsesses over identifiers rather than events.

When cookies aren't enough: hashed PII

Every major platform now also accepts hashed personal data — email or phone, SHA-256 hashed — alongside events (Meta "advanced matching", Google "enhanced conversions", TikTok "advanced matching"). The platform hashes its own logged-in users' emails the same way and compares. Same email hash = same person, no cookie required. This is deliberately built to survive the cookie collapse, and it's a centerpiece of server-side setups (Chapters 13–14) — where hashing can happen on your server instead of in browser JavaScript.

See it yourself (five minutes)

The fastest way to make this chapter stick — and the literacy that Chapter 8 builds on:

1. Open any commercial site → DevTools → Network tab.
2. Filter for collect — click through pages and watch GA4's /g/collect requests. Open one → Payload tab → find en, cid, dl.
3. Filter for facebook.com/tr — find ev, fbp, and (if you arrived via ?fbclid=…) fbc.
4. Application → Cookies — find _ga, _fbp, _gcl_au and match their values to what the requests sent.

Once you've done this on a site you don't own, do it on one you do. Every debugging session in your tracking career is some version of these four steps.

Where this leaves us

So: tags make vendor-bound requests, identified by JS-set first-party cookies and click IDs, and platforms join events to ad clicks server-side. Every link in that chain — the vendor hostname, the JS-set cookie, the third-party script — lives in the browser, and the browser stopped being friendly territory years ago.

Next: Chapter 3 — The Tracking Apocalypse, where ad blockers, Safari's ITP, GDPR, and iOS 14.5 each break a different link, and we count what's actually lost.