Privacy compliance has come a long way. Most organizations today have data maps, consent management platforms, vendor assessments, and governance frameworks in place, which is genuinely good progress. But there’s a blind spot most of those programs share: the browser.

Data Starts in the Browser, Not Your Systems

Here’s the mental model that underpins most privacy programs: a user interacts with a service, data gets collected at a defined point, then it flows into your systems, where your governance controls kick in. Works great for server-side infrastructure: your CRM, payment processor, HR tools, etc.

The problem? The web doesn’t actually work this way.

Data starts being generated in the browser long before anyone hits “submit.” Every keystroke in a form field, every click, every scroll, every letter typed — that’s all happening client-side, before your backend ever sees a single byte. If your privacy program draws the line at form submission, it’s in the wrong place.

Third-Party Pixels Have More Access Than Most Teams Realize

Around 92% of websites load some form of third-party pixels. On e-commerce sites, over half the pixels and tracking tags executing in the browser come from outside your codebase — analytics tools, ad pixels, tag managers, session replay tools, chat widgets, and more.

Browsers fail to make one thing obvious: by default, these scripts aren’t isolated from each other. There’s no sandbox wall between your analytics vendor and your advertising pixel. Each has access to the same page, the same DOM, and the same form fields that users interact with.

That means including a third-party pixel isn’t just adding a feature — it’s giving that vendor’s code the technical ability to observe what users do on your page. That can include email addresses as they’re typed, phone numbers digit by digit, health information entered into a search bar, financial details in a mortgage calculator, or sensitive data filled into an employment form, even if none of it is ever submitted.

There’s a further complication that vendor reviews and data processing agreements often miss: third-party scripts can quietly update their own behavior after deployment. A pixel that was reviewed and scoped at integration may later expand what it collects — without triggering a new vendor assessment or contract amendment. Some vendors also inject fourth-party scripts, pulling in additional code from other domains entirely, without any direct contractual relationship with your organization. By the time that happens, your DPA is already describing a version of the tool that no longer exists.

The Consent Timing Gap

In web architecture, milliseconds matter—and so does the sequence in which scripts execute. While many privacy teams assume that installing a Consent Management Platform (CMP) automatically pauses all tracking until a user clicks "Accept," the default behavior of web browsers tells a different story.

In reality, scripts start executing the moment a page loads. The consent banner appears, the user makes a choice, and only then does the Consent Management Platform act. But by that point, observation has already begun, creating a critical, often-overlooked consent timing gap.

Unless your web architecture is specifically configured to block third-party pixels from loading before consent is captured and confirmed, there’s a window of exposure your governance framework doesn’t account for.

Proof in Practice: What Popular Pixels Actually Collect

Jscrambler’s security research team analyzed what Meta and TikTok advertising pixels — two of the most widely deployed client-side technologies on the web — actually do at runtime on real websites across retail, hospitality, and healthcare.

The findings were eye-opening. These pixels collect detailed behavioral and transactional data: product names, prices, cart values, and the full customer journey. TikTok pixels were observed capturing physical addresses from store-locator fields at a major European retailer and sending them to TikTok servers. Meta’s pixel has a feature called automatic events — enabled by default — that scans page elements and captures data, including cardholder names and partial credit card numbers during checkout.

There’s also a timing dimension. In several cases, data was transmitted before the site’s consent management platform could intervene. In some cases, it continued even after a user clicked “reject all.”

The Compliance Risk

For privacy teams, the concern isn’t simply what data is collected, but whether collection aligns with user consent, regulatory obligations, and internal policy. If data is collected before consent is established — or continues after it’s withdrawn — organizations may be exposed to privacy compliance risks they don’t realize. And because third-party pixels can update their behavior post-deployment, the gap between what a vendor agreement says and what code actually does at runtime can widen over time without any visible trigger.

The Business Risk Nobody Talks About

Privacy isn’t the only concern. The same technologies that can observe customer interactions can also capture commercially sensitive behavioral data. Product interest, pricing comparisons, checkout behavior, feature evaluation, and conversion patterns are valuable intelligence. Many technology vendors operate across entire industries, meaning the data generated on your website may contribute to broader datasets that extend well beyond your organization. Your analytics vendor almost certainly serves your competitors, too.

Data observed in your users’ browsers doesn’t automatically stay with you.

Why Client-Side Governance Matters

Traditional privacy programs focus on governing data once it reaches enterprise systems. But modern web applications create and expose data before that point. Effective governance increasingly requires visibility into what third parties execute in the browser, what data they can access, and whether their behavior matches what was agreed to at procurement. Without that visibility, your program is governing a downstream slice of a much larger data flow.

Where to Start

Getting control of your client-side environment doesn’t require ripping everything up. This is where Jscrambler can help.  A useful first step is simply to understand what’s actually running on your web properties — not based on documentation, but on what’s executing at runtime. 

From there, you can assess which pixels have access to form inputs, identify any fourth-party scripts introduced without formal review, and test whether your consent implementation actually delays pixel execution or simply assumes it does.

Your website is the first place users interact with your service. If your privacy program can’t see what’s happening there, the gap between your commitments and your technical reality is likely bigger than you think.