Third Party Tracker

What third party trackers do

Third party trackers are usually embedded as small scripts, pixels, or tags that report back to another organisation. Their core function is measurement and profiling across sites or visits, so the privacy concern is not just that data is collected, but that it can be combined into a broader behavioural record outside the user’s direct relationship with the site they are visiting.

Because they operate through embedded code rather than a visible form or login flow, trackers are often easy to overlook in web property inventories. That makes them important to understand as a data collection mechanism, not just as a marketing feature.

How third party trackers gather and share data

Trackers can read page activity, browser metadata, referral information, and interaction events, then send that information to a separate domain for analysis, attribution, or audience building. In practice, this means the site owner and the third party may both receive data, but with different purposes and retention rules.

Some trackers are loaded directly in the page, while others arrive through tag managers, ad tech stacks, analytics bundles, or embedded widgets. The technical difference matters because the more indirect the deployment path, the harder it is for teams to know exactly which outside parties are receiving user data.

For that reason, organisations should treat these components as part of their third party exposure surface, not just front-end plumbing. The same embedded code that measures conversion can also expand data sharing relationships, create hidden dependencies, and complicate disclosure obligations.

Why third party trackers create privacy and trust issues

The main problem is that tracking can persist across browsing contexts and across organisational boundaries. Even when a user believes a private session reduces exposure, third party scripts may still observe activity on the page, and the resulting data can be reused for advertising, analytics, or correlation elsewhere.

This creates a trust gap between what users expect and what the site is technically disclosing. It also raises governance questions for site operators, because they may be responsible for data flows that are created by external code they did not author themselves. NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide is useful background when outside services are connected into a site or product through consented integrations and token-based access.

How organisations should assess and reduce exposure

Start with a real inventory of all third party tags, pixels, SDKs, and embedded services, then map what each one collects, where it sends data, and whether that flow is necessary. This is especially important for consent, retention, and vendor review, because a tracker may introduce data movement that is not obvious from the visible user interface.

Technical controls should then focus on minimising what is loaded, limiting which pages expose trackers, and validating that consent or preference settings are actually respected. In higher-risk environments, teams should also review whether any tracker is acting as a proxy for broader integration, since outside services can become a route into connected accounts or data stores.

Where the issue is not just tracking but the broader third party relationship, it helps to review related incident patterns. NHIMG’s Slack GitHub breach 2022 shows how a compromised vendor relationship can turn routine access into downstream data exposure, while Docker Hub breach 2019 illustrates how tokenised third party access can be abused if secrets are not tightly controlled.

What browsers and site owners can do to limit tracking

Browser privacy features, content blockers, and stricter cookie controls can reduce some tracker visibility, but they do not remove the need for site-side governance. Organisations should assume that any third party code they load may be subject to change, may collect more than the initial review suggested, and may create a lasting disclosure footprint if it is left in place indefinitely.

For site owners, the practical takeaway is to review third party trackers as a data-sharing decision, not only a web performance decision. That means checking purpose, necessity, vendor trust, and whether users are clearly informed about the collection. It also means revisiting old pixels and tags that remain active long after the original campaign or integration has ended.

When third party tracking is tied to identity-linked or account-linked systems, treat the integration layer with the same discipline you would apply to other external access paths. NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide helps frame why consented connections, scopes, and token revocation matter when external services sit inside the user journey.

Related resources from NHI Mgmt Group

• How do third-party SaaS integrations create NHI risk and how should they be managed?
• What are the implications of using OAuth tokens in third-party integrations?
• How should security teams govern third-party AI agents that use OAuth access?
• How should organisations govern third-party identity access more tightly?