Fundamentals

Third-Party Trackers: What They Are and How They Work

By Daniel Sardá · Published on October 21, 2026

6 min read1,182 words

A clear explanation of the data flow that lets outside services observe and connect digital activity across different websites and apps.

When you open an online store, the visible page is not always the only party involved in your visit. It may load a font from another server, display a video hosted on an outside platform, or send an event to an analytics provider. If that provider is also embedded in a newspaper, social network, or app, it may be able to connect some of those interactions.

That, broadly speaking, is what third-party trackers do: they are code, resources, or services outside the website a person is visiting that receive data about their activity. Some serve specific functions; others can help build profiles to measure audiences, personalize content, or target advertising.

Here, “tracker” does not mean a GPS or Bluetooth locator. It refers to digital tracking that can connect activity across different websites or apps.

What makes a tracker “third party”

The distinction depends on context. The first party is, in principle, the website or service a person chose to interact with. A third party is another entity involved because its technology has been incorporated into that site.

Imagine someone visits `shop.example`. The store may save its own cookie to keep products in a shopping cart. But it might also load an ad, a social button, or a measurement script from `provider.example`. When the browser requests that resource, the external provider receives the request needed to respond and may receive other data associated with the event.

Being a third party does not make a service malicious. An outside service may enable sign-in, process payments, detect fraud, or measure page performance. The relevant questions are what data it receives, how it uses that data, and whether it can connect it to other contexts.

Key idea: An external integration creates a communication with another server; it becomes cross-site tracking when that third party can correlate interactions from different contexts.

How activity is connected across sites

The process can be summarized as a flow:

1. A person opens a webpage or uses an app.
2. The service loads a resource from an outside provider or runs its code.
3. The browser or app sends a request to that provider’s server.
4. The request may include an event—such as a visit or click—and some signal that can help recognize a session, device, or account.
5. If the same provider appears in other services, it may try to connect those events.

Correlation does not require knowing someone’s legal name. A pseudonymous code that reappears across visits may be enough to associate them. Pseudonymous does not mean anonymous: withholding a name does not prevent recognition of a persistent pattern.

Nor does every external request create a profile. Loading an image or a font communicates certain technical data, but profiling requires collecting, retaining, and relating information. It is useful to distinguish technical possibility from actual practice.

Cookies, pixels, scripts, SDKs, and fingerprinting

These terms often appear together, although they describe different components:

• Cookie: stores a small piece of state in the browser associated with a site. It can preserve a session or shopping cart, but it can also act as an identifier. A third-party cookie is set by a domain different from the visible site.
• Tracking pixel: usually a tiny or invisible resource whose loading generates a request. That request can record that a page, advertisement, or message was opened.
• Script: runs instructions on a page. It can measure interactions, alter content, or collect signals and send them to a provider.
• SDK: integrates a provider’s functions into an app. It can offer analytics, authentication, advertising, or notifications, among other services.
• Fingerprinting: combines observable characteristics of a browser or device to distinguish it or recognize it again with some probability.

These technologies can work together. A script may record a click, a cookie may retain an identifier, and a pixel may transmit the event. Fingerprinting can correlate sessions even where cross-site cookies are restricted, although not every fingerprint is unique or infallible.

Key distinction: A cookie stores state; a pixel triggers a request; a script runs logic; an SDK integrates functions into an app; fingerprinting combines observable signals.

Between useful measurement and opaque profiling

Data collection can serve different purposes. A store may need to know whether its payment process failed. A publisher may measure how often a page loads. An authentication system may verify a session, while an advertising platform may infer interests from successive visits.

Not all of these activities have the same scope. To assess them, it helps to ask:

• Is the collection necessary to provide the requested function?
• Is the data also used for different purposes?
• Is it combined with information from other websites, apps, or accounts?
• Is the explanation understandable, and is the choice meaningful?
• Is there a reasonable way to decline the use without losing unrelated functions?

The central problem is often asymmetry. The intermediary knows its infrastructure, agreements, and ability to correlate data; the person sees a page and, often, a generic notice. Accepting that notice does not necessarily mean understanding the network of recipients or their later uses.

From the standpoint of individual liberty, digital autonomy requires more than a formality. It requires enough information to decide, practical alternatives, and accountability from those who collect or reuse data. This relates to digital privacy and security and to the question of who controls personal data.

Which controls reduce tracking, and what are their limits

Modern browsers offer protections against some forms of cross-site tracking. It is also possible to review permissions, clear stored data, decline optional uses, or use blocking tools. Choosing services that limit third-party integrations reduces another part of the exposure.

Still, no single control guarantees anonymity. Blocking third-party cookies closes one route, but it does not necessarily stop pixel requests, links carrying identifiers, account-associated activity, or fingerprinting techniques. A VPN changes the network address visible to the destination, but it does not remove stored identifiers or signed-in sessions. Private browsing limits what remains on the device after a session ends; it does not make browsing invisible to websites and providers.

Broad blocking can also affect legitimate functions, including some sign-ins, payments, or embedded content. The answer is not always to “block everything,” but to combine reasonable protections with transparent services and informed choices.

Key idea: Reducing tracking is possible; disappearing completely from digital observation is a much stronger promise than these tools can deliver.

Understanding the flow to make better choices

Third-party trackers are not a single technology, nor do they have one purpose. They are part of an architecture in which the visible site can share an interaction with outside providers. Their importance grows when those providers reuse identifiers or signals to connect contexts that a person perceived as separate.

Understanding who receives the data, what they can connect, and for what purpose helps distinguish a proportionate function from excessive profiling. That is more useful than assuming every third party is harmless or every form of measurement is illegitimate. Freedom of choice begins by making that distinction visible.