The Hidden Trackers OneTrust, Cookiebot, and TrustArc Miss

OneTrust. Cookiebot. TrustArc. These are the biggest names in consent management. Companies trust them to handle CCPA compliance. The problem? They're all missing the same things, not because of a vendor-specific bug, but because of what a browser-based consent management platform can and can't see.

Here are the structural gaps that show up regardless of which CMP is in place.

What Every Client-Side CMP Structurally Misses

1. Shadow Pixels

A pixel is supposed to be a single tracking element. A shadow pixel is a pixel that loads additional tracking without your knowledge, usually because the vendor added it after you installed their script.

Example: You install a retargeting pixel. A month later, that vendor starts sharing your data with 5 other networks. Your CMP doesn't know. You don't know. But the trackers are firing.

2. Pixel Piggybacking

Similar to shadow pixels, but this happens when one of your authorized scripts loads additional scripts from other domains, often completely unrelated to the original vendor.

Example: Your chat widget loads. Inside it, there's a Facebook tracker, a Google Analytics fallback, and a data enrichment script. None are in your CMP. All are firing.

3. Server-Side Tracking

Server-side GTM, server-side analytics, server-side everything: the industry trend is moving tracking to the server. But client-side consent tools can't see it.

Your OneTrust dashboard says tracking is blocked. Meanwhile, your server can be sending user data to other endpoints directly. The CMP never sees any of it.

4. Pre-Consent Firing

The user visits your site. Before the consent banner appears, before they click anything, trackers can fire. This happens because:

• Scripts are in the <head> before the CMP loads
• Third-party widgets load synchronously
• Analytics fires on page load, not after consent

5. Dark Pattern Gaps

Even when a CMP technically supports rejecting cookies, implementations can slip into patterns that make rejection harder than acceptance:

• "Reject All" takes more clicks than "Accept All"
• Reject options hidden in secondary menus
• Pre-checked "marketing" boxes that require opt-out

CMP-by-CMP Breakdown

OneTrust

• Good at: Blocking what you explicitly configure
• Bad at: Detecting unauthorized additions to existing pixels
• Gap: Server-side tracking completely invisible

See our full OneTrust compliance comparison for a detailed breakdown of what it catches and what it misses.

Cookiebot

• Good at: Scanning and categorizing scripts
• Bad at: Catching scripts that load after initial scan
• Gap: Pre-consent firing on most implementations

See our full Cookiebot compliance comparison for the same breakdown.

TrustArc

• Good at: Enterprise policy management
• Bad at: Real-time blocking at the network level
• Gap: Multiple third-party tags slip through

The Bottom Line

None of these CMPs are bad products. They're solving a hard problem. But the problem is harder than they admit, and the liability falls on you, not your vendor.

The only way to know what's really happening is to scan your site at the network layer, the way regulators do.