How web tracking actually works

A first-principles tour of the data flow behind every analytics hit — from a user action to a row in a warehouse — and the seams where implementations break.

Web tracking is a deceptively simple pipeline with a dozen places to go wrong. Every analytics platform — GA4, Adobe Analytics, Segment, Snowplow, a Meta pixel — implements the same underlying data flow, and every debugging session, privacy audit, and architecture decision comes down to knowing which stage of that flow you are looking at. This is the pillar reference: it walks the full path of a single event, names the failure modes at each seam, and links out to the deeper guide for each stage.

The lifecycle of one event

A pageview or custom event passes through seven stages. Everything else on this site is an elaboration of one of them.

Script load. The page includes a tag — directly, or via a tag manager like GTM or Adobe Launch. The browser fetches vendor JavaScript, which registers listeners and prepares to observe. This is the first interception point: if the script never loads, nothing downstream happens.
Identity. The script looks for an existing identifier (usually a first-party cookie) and mints one if absent. Everything the platform later calls a “user” is really this identifier.
Event assembly. When something happens — a pageview, click, purchase — the script gathers context: URL, referrer, screen size, campaign parameters, and whatever the site pushed into a data layer. Structure here is governed by your event schema and, ideally, a written data layer spec.
Beacon. The assembled event is serialized into a vendor-specific request — query string, POST body, or pixel URL — and sent from the browser to a collection endpoint.
Collection. The endpoint receives the request, timestamps it, reads identifiers, and (in compliant setups) checks consent state before accepting the hit.
Processing. Raw hits are validated, bot-filtered, geo-enriched, stitched to identities, and grouped into sessions — the logic covered in sessionization and channel grouping.
Storage and activation. Processed events land in the vendor’s reporting store, and often in your own warehouse (see BigQuery for web analytics), where attribution models and audience activation run.

The stages are sequential and each depends on the one before it. A missing consent signal at stage 5 or a blocked request at stage 4 does not degrade the data — it deletes it. That asymmetry is why tracking debugging always works backward from “which stage did the event die at?”

Stage 1–2: script load and identity

The script-load stage decides whether tracking happens; the identity stage decides who the event belongs to. Identity is where the engineering and the privacy debate collide, because there are four fundamentally different ways to recognize a returning browser:

Cookies. A small value the browser stores and automatically re-sends. First-party analytics cookies (GA4’s _ga, Adobe’s s_ecid) are set on your domain and survive as long as browser policy allows. Cookies are transparent — a user can inspect and delete them, and you can audit any site’s with the Cookie Scanner.
localStorage. A JavaScript-accessible store with no expiry and no automatic transmission. Vendors use it as a cookie backup or to persist identifiers past cookie deletion. It is origin-scoped, so it can only ever support first-party identity.
Fingerprinting. No stored value at all: the browser is identified by the combination of its observable properties — user agent, screen, fonts, canvas rendering, timezone. It requires no consent artifact to inspect, cannot be “cleared,” and is therefore treated by both regulators and browser vendors as the adversarial end of the spectrum. Browsers increasingly randomize or flatten these signals; the tracking prevention overview covers who does what.
Server-side identity. The identifier lives in your backend — a hashed login, a CRM ID — and the browser holds only a session credential. This is the most durable and most accurate form of identity, and also the one that most clearly crosses from “measuring traffic” into “profiling a known person,” which is why consent and purpose limitation matter most here. When identifiers must be shared with vendors, hashing is the standard transport (see the PII Hasher for how normalization affects match rates).

Real platforms layer these: a cookie as primary, localStorage as backup, a login ID for stitching across devices. The stitching logic — deciding that cookie A and login B are the same person — is a processing-stage concern, but the raw material is captured here.

First party vs third party

“First party” and “third party” describe a relationship, not a technology. A cookie set by the site you are visiting, on its own domain, is first-party. A cookie set by a different domain whose resources the page embeds — an ad pixel, a social widget — is third-party, and it is the mechanism that historically let one company observe you across many sites. All major browsers now block or partition third-party cookies, which is the single biggest structural change in tracking of the past decade. The industry’s response has been to move identity into first-party position: CNAME subdomains, first-party endpoints, and server-side collection. The data flow is often unchanged — the same vendor still receives the events — but the browser can no longer distinguish it from the site’s own traffic. That gap between technical first-partyness and actual data-sharing relationships is exactly what the privacy scorecard methodology is designed to score.

Stage 3: event assembly

Assembly is where implementation quality is decided. The tag can only send what the page exposes, and the page exposes context through three channels:

The environment — URL, referrer, title, viewport — which the tag reads for free.
Campaign parameters — utm_source and friends, appended to landing URLs and parsed into acquisition dimensions. Garbage in here is unfixable downstream, which is why a written UTM standard (and the UTM Builder that enforces it) exists.
The data layer — a JavaScript structure the site populates with things the DOM cannot express: product data, user state, transaction totals. The classic failure mode is a race: the tag fires before the data layer is populated, and the event goes out half-empty. The dataLayer Validator exists to catch exactly this class of bug, and the events and schemas guide covers how to design the structure so it stays validatable.

Stage 4: the beacon

The beacon is the only stage you can observe from outside — it is the event, serialized on the wire. Every vendor invents its own format, but they cluster into three conceptual families:

GA4 / Measurement Protocol style: a POST to a /collect-style endpoint (/g/collect for GA4) where the query string carries client ID, session, and page context, and the body carries one or more named events with ep./epn.-prefixed parameters. The same protocol is exposed as a server API, which is what makes GA4’s server-side story coherent: browser hits and backend hits speak one language.
Adobe style: a request to a data-collection domain where dimensions ride as codes — pageName, events, c1–c75/v1–v250 style variables mapped to meanings only the implementation doc knows. Adobe’s model predates named-event thinking: the beacon is a flat variable set, and the Adobe Analytics guide covers how processing rules reshape it.
Meta / pixel style: a GET disguised as an image request (facebook.com/tr?id=...&ev=...), the oldest trick in tracking — any <img> fetch is a loggable event. Modern pixel tags add POST fallbacks and hashed-PII parameters, but the conceptual shape is unchanged: identity plus event name plus properties, sent to an advertising graph rather than an analytics store.

You do not need to memorize any of these formats. Paste a captured request into the Beacon Decoder and it will name the vendor, unpack the parameters, and label what each one means — which is also the fastest way to audit what a page actually sends, as opposed to what the tag plan says it sends.

Consent is not a stage of the pipeline; it is a gate that can be enforced at several points, and where you enforce it defines your compliance posture:

Before script load: the tag manager holds vendor tags until consent is granted. Strongest guarantee — no code runs, nothing is sent — but requires the consent platform to load first.
At event assembly: scripts load but run in a restricted mode (Google’s consent mode is the canonical example), sending cookieless pings instead of identified hits until consent arrives.
At collection: the beacon is sent regardless, carrying a consent flag, and the server is trusted to drop or anonymize non-consented hits. Weakest guarantee, because the data left the device.

Alongside banner-based consent there are browser-level signals: Global Privacy Control is an HTTP header and JavaScript property that expresses opt-out automatically, legally binding in several US states. The GPC and consent guide covers the legal texture; the GPC Tester shows you what signal your own browser sends, and the Consent Checker audits whether a site’s tags actually respect the choices its banner records — the gap between the two being one of the most common findings in the State of Web Tracking report.

Where blocking intervenes

Each interception layer attacks a different stage, which is why they compose rather than replace each other:

DNS blocking (Pi-hole, NextDNS, blocking VPNs) kills stage 1: the vendor hostname never resolves, so the script never loads. It is network-wide and browser-independent, but blunt — it can only act on hostnames, not paths or payloads. See DNS, VPN, and network-level blocking.
Extension blocking (uBlock Origin and kin) acts inside the browser at stages 1 and 4: filter lists match script URLs and beacon endpoints, and can also surgically remove page elements. The extension stack guide covers a layered setup.
Browser engines intervene at stage 2: Safari’s ITP caps the lifetime of script-set cookies and strips link decoration; Firefox partitions third-party state; Brave blocks by list and randomizes fingerprinting surfaces. The per-browser texture lives in the Safari/iOS, Firefox hardening, and Chromium/Brave/Edge guides, and the Tracking Prevention Tester shows what your own browser blocks in real time.

Server-side collection changes the geometry of all three. With a first-party endpoint, DNS and extension blocking lose their target: the beacon goes to mp.yoursite.com, indistinguishable by hostname from the site itself. ITP’s script-cookie caps stop applying when identifiers are set in HTTP response headers from genuinely first-party infrastructure. What blocking cannot be prevented from doing is running on the user’s device — element hiding, script neutering, and consent signals still work — and what server-side collection cannot do is manufacture consent: the legal obligations attach to the data relationship, not the hostname. The server-side tracking guide states this tradeoff plainly; the maintainers’ view of the arms race lives at ad.rip.

Stage 6–7: processing, warehouses, and CDPs

Processing turns hits into analysis-ready structures, and the critical thing to understand is that every derived concept — user, session, channel, conversion — is computed, not observed. Two systems with identical raw hits will report different session counts if their sessionization rules differ, and different channel mixes if their classification rules differ. This is the root cause of most “the numbers don’t match” investigations.

Downstream, three architectures consume the processed stream:

Vendor reporting — the GA4 or Adobe UI, fed by the vendor’s own store. Fast, opinionated, and a black box at the edges.
The warehouse — raw events exported to BigQuery, Snowflake, or similar, modeled with tools like dbt into tables you fully control. This is where you rebuild sessionization and attribution on your own terms and where emerging questions — AI referral traffic, AI crawler measurement, geo-level measurement — get answered, because vendor UIs lag new questions by years.
The CDP — Segment and peers sit at stages 3–5 rather than at the end: one collection API in, many destinations out, with identity resolution in the middle. A CDP is best understood as a programmable fan-out layer for the pipeline, and increasingly the warehouse itself plays this role via reverse-ETL.

See each stage live

Every stage above is observable with free tools on this site — the fastest way to internalize the pipeline is to watch it run on a real page:

Pixel Scanner — stage 1: which vendors’ scripts a page loads.
Cookie Scanner — stage 2: what identifiers get set, by whom, for how long.
dataLayer Validator — stage 3: what context the page exposes to tags.
Beacon Decoder — stage 4: what actually leaves the browser, decoded.
Consent Checker and GPC Tester — the gate: whether consent signals exist and are honored.
Tracking Prevention Tester — the interception layer: what your browser blocks.
GTM Explorer and Launch Explorer — the orchestration layer: what a container is configured to fire.
Attribution Simulator and CWV Impact — the consequences: how model choice changes credit, and what tags cost in page performance.

The full set lives at /tools.

Where to go next

Platform-specific depth: GA4, Adobe Analytics, GTM, Segment, Snowplow — or compare them structurally in the directory and comparison matrix, with privacy grades on the scorecard. For the defense-side view, start at the privacy hub. The State of Web Tracking report tracks how these architectures are shifting year over year — the newsletter covers the changes as they land (subscribe here).