Mechanically, How Does a Web Analytics Tracker Actually Collect and Send a Hit?
Every web analytics tracker - regardless of vendor - does the same four things in sequence: it detects an event (a page load, a click, a custom trigger), it assembles a payload describing that event as key-value parameters, it attaches identifiers (a client/user ID, usually from a first-party cookie) and context (timestamp, page URL, referrer), and it transmits that payload to a collection endpoint, typically an HTTP request to a 1x1 tracking pixel or a dedicated collection API. Everything a vendor SDK adds on top - batching, retries, consent checks, session logic - is refinement of that same four-step loop.
The four-step mechanism, in order
Detection: a tracker needs something to trigger on. For a pageview, that's usually the browser firing the tracker's initializing script on page load. For a click or a form submission, the tracker (or a tag manager sitting in front of it) attaches an event listener to the DOM element in question, which fires when the visitor interacts with it. Nothing is being "watched" continuously - trackers are reactive, not passive observers, aside from the small number of built-in automatic events most platforms now fire by default.
Payload assembly: once triggered, the tracker builds a structured record - an event name plus a set of parameters (a button's text, a product's ID, a page's category) - either from values you explicitly pass in code, or from values a tag manager pulls out of the page's dataLayer or DOM at the moment of firing.
Identity and context attachment: the tracker reads (or creates, on a first visit) a client identifier, almost always from a first-party cookie or comparable local storage value, and layers on context the vendor’s SDK collects automatically - timestamp, current URL, referrer, device/browser signals, and, where relevant, a consent state that determines whether the hit should even be sent.
Transmission: the finished payload is sent to a collection endpoint, historically as a GET request to a 1x1 transparent image (the "tracking pixel," chosen decades ago because an <img> tag reliably fires a request in every browser without needing JavaScript to complete), and increasingly as a direct HTTP POST to a dedicated collection API, which allows a larger, more structured payload than a URL’s query string ever could.
How to apply this model when building or debugging tracking
- 1
Use the mechanism to localize a bug before touching any code
When an event is missing, ask which of the four steps failed: did the trigger never fire? Did the payload assemble with a missing or malformed parameter? Did identity/consent block the send? Did the network request itself fail? Each has a different fix, and guessing without this sequence wastes debugging time.
- 2
Inspect the actual network request, not just the vendor's dashboard
Every step above is ultimately visible in your browser’s Network tab: filter for the vendor’s collection domain and inspect the request’s query string or POST body directly. This is the ground truth - a vendor’s own debug tool is a convenience layer on top of the same request.
- 3
Design your own custom events around the same four steps
When instrumenting a new event, deliberately define what triggers it, exactly what parameters belong in the payload (named consistently with your existing event schema), what identity/consent state must be true for it to send, and confirm the transmission actually reaches the collection endpoint - rather than copying an existing event and hoping the parameters generalize.
- 4
Remember that a 1x1 pixel and a POST-based API are the same mechanism with different transport
If you're integrating a tool that still describes itself as a "tracking pixel," it is doing exactly the same four-step job as a modern collection API - the difference is transport format and payload size limits, not the underlying purpose.
How to see this mechanism happening on any site, including yours
Open DevTools' Network tab, filter by the vendor's collection domain, and trigger a tracked action on your own site.
Passing: A new request appears in the Network tab at the moment you trigger the action, and its query string or request payload shows the event name and parameters you expect.
Still broken: If no request appears, the failure is at detection or payload-assembly. If a request appears but looks wrong, the failure is downstream, in identity, consent, or how the parameters were built.
Inspect the request's identifier parameter (a client/user ID field) across two separate visits from the same browser.
Passing: The same identifier value persists across visits, confirming the underlying cookie or storage value is being read correctly rather than regenerated every time.
Still broken: If the identifier changes on every page load, the tracker is failing to read its own previously-set cookie - check for cookie-blocking browser settings, an overly narrow cookie domain/path, or code that's inadvertently clearing storage between page loads.
If this is happening on a client-critical property, we'll verify it directly.
A data audit checks this exact failure mode against your actual implementation, not a generic checklist.