Skip to main content
Create your own

Tracking Technologies: Under the Hood

Welcome to your first lesson. This course is designed to provide you with a deep, "first principles" understanding of the technologies and strategies that power modern digital marketing, from customer tracking to complex automation. Your background in development and business information systems will be a significant asset as we explore the architecture behind the tools.

This initial lesson addresses the very foundation of digital marketing analytics: data collection. We will start at the lowest level to answer the question, "How does a website or app actually know what a user did?" By the end of this session, you will be able to explain how tracking pixels and SDKs work at a technical level, focusing on the HTTP requests, cookies, and event payloads that form the backbone of web tracking.

1. The Simplest Tracker: The Pixel

At its core, all web tracking is about communicating information from a user's browser (the client) to a data collection server. The simplest mechanism for this is the tracking pixel, also known as a web beacon.

As the name suggests, this is often a literal 1x1 pixel, transparent, and completely invisible to the user. Its purpose is not visual; it's to trigger a standard browser action: fetching an image. When a browser loads an HTML page (or an email client renders an email), it must fetch all the resources referenced, including images. A tracking pixel is embedded using a standard <img> tag, but the src attribute points to a tracking server, not a normal image file.

<img src="https://analytics-provider.com/track?event=email_open&campaign_id=123" 
     width="1" height="1" border="0">

The browser sees this tag and dutifully sends an HTTP GET request to the specified URL to "fetch" the image. This request is the entire point of the exercise. The tracking server isn't really concerned with sending back a meaningful image; it's interested in the request itself, which carries valuable data.

To understand the mechanics, let's explore the article "Discover pixel tags and web beacons" from Swetrix. It provides a great overview of the technology.

Discover pixel tags and web beacons: A practical guide to analytics and privacy | Swetrix

This article breaks down how pixel tags function from a technical standpoint. It explains the core mechanism and the data that gets collected.

Please read the introduction to understand the basic concept. Then, focus on the section How Pixel Tags Work Behind The Scenes, which details the HTTP request, the data collected on the server, and how JavaScript can be used. Finally, read the first question in the FAQ to reinforce the definition.

As you've just read, the HTTP GET request initiated by the pixel contains two main sources of information:

  1. HTTP Headers: The browser automatically attaches headers to the request. Key headers for tracking include:

    • User-Agent: A string identifying the browser, its version, and the operating system (e.g., Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...).
    • Referer: The URL of the page that contained the pixel, telling the server where the user was.
    • IP Address: Although not a header, the server sees the IP address from which the request originated, which can be used for geolocation.
  2. Query String Parameters: This is where the event payload is explicitly defined. The URL is constructed with key-value pairs after the ?. In our example, event=email_open and campaign_id=123 are the payload, telling the server precisely what happened.

2. Achieving Statefulness: The Role of Cookies

HTTP is a stateless protocol, meaning each request is independent. A server has no memory of previous requests from the same user. This is a problem if you want to track a user's journey over time. Cookies solve this.

When the tracking server receives the initial pixel request, its HTTP response can include a Set-Cookie header. This instructs the browser to store a small piece of text—the cookie—associated with the tracking server's domain.

Set-Cookie: user_id=a1b2-c3d4-e5f6; expires=...; domain=analytics-provider.com

On any subsequent request to any page that loads a pixel from analytics-provider.com, the browser will automatically include this cookie in the Cookie request header. This allows the server to stitch together multiple page views, even across different websites, into a single user profile.

This leads to the crucial distinction between first-party and third-party cookies. The following video gives an excellent, step-by-step walkthrough of how this enables cross-site tracking.

Web tracking, 3rd party cookies, GDPR

This video explains the stateless nature of HTTP and demonstrates precisely how first-party and third-party cookies are set and used to track users across different websites.

Watch the initial recap on HTTP and cookies from the beginning. Then, see the clear example of a first-party cookie being set. Pay close attention to the explanation of how a third-party cookie is created by an ad server without you explicitly visiting it. Finally, see how this cookie is used to build a profile of your browsing behavior across multiple sites.

As the video illustrates, a third-party cookie from a domain like adex.com allows it to "see" you on nytimes.com, socks.com, and any other site that includes its tracking pixel. This is the fundamental mechanism behind ad retargeting, where your browsing history on one site leads to related ads on another.

3. Advanced Tracking: Software Development Kits (SDKs)

While pixels are effective for simple events like page views, modern applications require tracking of more complex, dynamic interactions (e.g., button clicks, form submissions, video plays). This is where a Software Development Kit (SDK) comes in.

An SDK is a set of tools and code libraries that a developer integrates directly into their website or mobile application. Instead of manually crafting pixel URLs, the developer calls simple functions provided by the SDK.

For a web app, it might look like this:

// A user clicks the 'Add to Cart' button
analytics.track('product_added_to_cart', {
  product_id: 'SKU-12345',
  product_name: 'Premium Leather Shoes',
  price: 199.99,
  currency: 'USD'
});

For a mobile app, the principle is the same, just in a different language like Java or Swift.

In this example from a mobile app, the developer calls the `MobileCore.trackState` method. The SDK then constructs and sends the actual HTTP request, which you can see as a URL in the Logcat output below. The payload includes data like `language=en` and `pageName=Settings`.

Under the hood, the SDK handles the construction of the event payload and the HTTP request, but it does so more efficiently than a simple pixel.

  • Payload Format: The event data is typically bundled into a structured JSON object sent in the body of an HTTP POST request, which is better suited for complex data than a long URL in a GET request.
  • Efficiency: SDKs employ several strategies to reduce network traffic and improve reliability.

The Moesif blog has an excellent article detailing these professional-grade SDK practices. While it's written for developers building SDKs, its principles perfectly explain how modern analytics SDKs operate.

Best practices for building SDKs for APIs | Moesif Blog

This article explains the engineering best practices that make SDKs robust and efficient.

Focus on the following sections to understand the "under the hood" mechanics: Batching: This explains why an SDK doesn't send a request for every single event. Local Queuing: This describes how SDKs handle offline scenarios and improve reliability. Compression: This shows how data payloads are made smaller. User-Agent: This explains another piece of metadata sent with the request.

In summary, an SDK is an abstraction layer. It gives developers an easy-to-use API while managing the complexities of payload construction, batching, queuing, compression, and sending the data reliably via HTTP requests.

4. Seeing it Live: Using Browser Developer Tools

The best way to solidify this knowledge is to see it in action. Your browser's developer tools are the perfect instrument for this. The "Network" tab records every single HTTP request the browser makes while loading and interacting with a page.

The following video is a masterclass in using the Network tab. It's highly technical, which should align well with your interests. We will focus on the part where he analyzes a real website and uncovers its tracking requests.

Demystifying the Browser Networking Tab in Developer Tools With Examples

The presenter, Hussein Nasser, dissects the network traffic of nginx.org, revealing the numerous third-party requests made for tracking and analytics purposes.

Watch the segment from this point. Observe how a single page load triggers dozens of requests. He points out requests to googletagmanager.com, google-analytics.com, and connect.facebook.net. Notice the different protocols used (HTTP/1.1, h2, h3) and how he identifies the purpose of these requests as tracking. Don't worry about understanding every detail of the protocols; the key is to see how these third-party tracking calls manifest as distinct network requests initiated by the primary website.

Your Turn:
I encourage you to try this yourself.

  1. Open a new Incognito/Private window in your browser.
  2. Open the Developer Tools (usually by pressing F12 or Ctrl+Shift+I / Cmd+Opt+I) and go to the Network tab.
  3. Visit a major e-commerce or news website.
  4. In the filter bar of the Network tab, try searching for terms like collect, tr, batch, or the names of known analytics providers like facebook, google, tiktok.
  5. Click on one of these requests. Examine its Headers tab to see the Request URL (with its payload in the query string), the Cookie and User-Agent headers. If it's a POST request, look at the Payload or Request tab to see the JSON data being sent.

This hands-on exploration directly exposes the mechanisms we've discussed today.

Conclusion

In this lesson, we have dissected the fundamental mechanics of web tracking. You now have a foundational, technical model for how user actions are captured and transmitted.

Key Takeaways:

  • Tracking Pixels use <img> tags to trigger HTTP GET requests to a tracking server. The event payload is encoded in the URL's query string.
  • SDKs provide a developer-friendly API to track complex events. They typically use HTTP POST requests with a JSON payload and employ efficiencies like batching, queuing, and compression.
  • HTTP Requests are the transport mechanism. Headers (User-Agent, Referer, Cookie) and the server's view of the client's IP Address provide implicit context.
  • Cookies are the primary tool for creating state, allowing servers to recognize a user across multiple requests, sessions, and even different websites (via third-party cookies).
  • The Event Payload is the structured data describing what the user did, sent either in the URL or the request body.

In our next lesson, we will build upon this technical foundation. We'll differentiate between first-party and third-party data and analyze how the entire tracking ecosystem is being reshaped by privacy-driven changes from browser makers and platform owners, such as Apple's Intelligent Tracking Prevention (ITP) and App Tracking Transparency (ATT).

Can't find a good explanation? Sign up and we'll make it for you

Sign up