Tracking pixel audit: GDPR & ePrivacy compliance for SMBs

On most SMB sites, the highest compliance risk is not the cookie banner itself, it is the tracking pixels behind it. Pixels are how your site reports visitor behaviour to advertising networks, and they almost always fire on page load by default. In the EU and UK, that pattern is non-compliant on every visit.

This article covers what a tracking pixel audit looks at, the platform-by-platform behaviour, and the two installation patterns that actually keep pixels working without breaking the law.

What a pixel actually does

When a tracking pixel fires, four things happen in roughly 50 milliseconds:

1. The browser sends an HTTP request to the platform (e.g. connect.facebook.net).
2. The request includes the current URL, referrer URL, IP address, user agent, screen size, and any custom parameters the site attached (cart contents, signup intent, etc.).
3. Cookies get set. Some are third-party cookies on the platform’s own domain, but the ones that matter most are first-party: _fbp and _fbc are written by the pixel’s own JavaScript on your domain, which is precisely why they survive third-party-cookie blocking in Safari and Firefox. If the user is logged into Facebook, TikTok, or LinkedIn in the same browser, the platform can tie the visit to that user’s identity regardless.
4. The pixel loads its supporting JavaScript, which can fire additional events (PageView, ViewContent, AddToCart, Lead, Purchase) on subsequent interactions.

For an EU/UK visitor, every step beyond the first is a personal-data processing activity that needs a legal basis. The only feasible legal basis for advertising tracking is consent (Article 6(1)(a) GDPR), and that consent has to be given before the pixel fires.

What an audit checks, platform by platform

Meta Pixel (Facebook / Instagram)

The default install snippet from Meta’s admin loads fbevents.js immediately and fires PageView on every load. The audit confirms this and reports it as the most common failure on SMB sites in the EU. The Meta-recommended fix is to deploy via Google Tag Manager with consent-mode triggers, or to use the Pixel Helper’s fbq('consent', 'revoke') call before consent and grant after.

TikTok Pixel

The TikTok pixel similarly fires on page load by default. What Veracly observes is the pre-consent state: whether analytics.tiktok.com receives a pixel hit before the visitor has consented to anything. Whether your CMP then calls ttq.consent('granted') correctly is a manual check. We do not click your banner, so we never see the call that follows acceptance.

LinkedIn Insight Tag

LinkedIn’s Insight Tag fires on every page and stores both a first-party and a third-party cookie. It is particularly common to see it deployed unguarded on B2B SMB sites. The audit reports any first-load fire and any cookie set before consent.

Google Ads conversion tracking

Google Ads tracking integrates tightly with Consent Mode v2. What Veracly records is whether a conversion or remarketing request reaches googleadservices.com or doubleclick.net before consent. It does not read the consent state inside gtag, and it does not inspect request payloads at all: the finding is that the request happened, not what it contained. If Consent Mode v2 is not deployed, advertising signals fire regardless of the user’s choice, and that is the failure a pre-consent observation catches.

Pinterest, Snap, Twitter/X, Reddit

All similar in pattern: load on page load by default, set cookies, send page metadata to the platform. All require gating behind consent.

Why this is the highest-risk item

Pre-consent firing is the failure a regulator can prove without leaving their desk: open the site, open the network tab, watch the request go out before the banner has been touched. No forensics, no disclosure request, no expert witness. The best-documented European example is Swedish rather than French or Italian — in 2024 the IMY fined Apoteket roughly €3.2m over Meta Pixel data sharing.

Earlier versions of this article cited a CNIL 2024 pixel-enforcement priority and a run of small Italian Garante e-commerce fines in the €5,000 to €50,000 band. Neither stood up when we went back to the published sources, so both are gone rather than replaced with something equally convenient. The defensible version is narrower and still uncomfortable: the technical failure is trivial to demonstrate, it is present on a large share of SMB sites, and nothing about being small removes it from scope.

The two patterns that work

Pattern 1: CMP-gated script load

The cleanest approach. Your CMP exposes an event when the user has consented to a specific category. Listen for the event and load the pixel script only when it fires.

// Cookiebot example, replace with your CMP's API
window.addEventListener('CookiebotOnAccept', () => {
  if (Cookiebot.consent.marketing) {
    !function(f,b,e,v,n,t,s) { /* Meta Pixel snippet */ }
    fbq('init', 'PIXEL_ID');
    fbq('track', 'PageView');
  }
});

The advantage is total: no script is loaded, no cookie is set, no request is made until consent exists. The disadvantage is that the conversion happens after consent, so you lose visibility into rejected users, which is the whole point.

Pattern 2: Consent-mode integration

For platforms that support it (Google, Meta, TikTok), consent mode lets the script load but defer or anonymise its behaviour until consent. With Google Consent Mode v2, for example, you load gtag but pass consent: 'denied' until the user accepts; the platform then receives only aggregated, modelled signals.

Most regulators accept consent mode as a valid implementation; some (notably the Hamburg DPA in 2023 guidance) have raised concerns about whether the “modelled” signals constitute processing without consent. The pragmatic advice for SMBs: pattern 1 is safer, pattern 2 gives you better attribution. Pick based on your risk tolerance and revenue exposure.

Audit deliverables that matter

A useful pixel audit gives you, for each platform:

• The exact request URL fired, the timing relative to the consent banner, and the cookies set.
• The recommended fix, code snippet, GTM trigger configuration, or CMP setting.
• A re-test after the fix to confirm.

Two things people expect on that list are manual, and any tool claiming to automate them is overselling. Reading the consent state inside gtag, or validating a TCF consent string, means inspecting what a tag sends; Veracly does not inspect payloads. And confirming that the accept and reject paths behave differently means clicking the banner, which Veracly deliberately does not do, because a click is itself a consent gesture and would destroy the pre-consent reading the rest of the scan depends on. Do both by hand in DevTools, once, after you ship the fix.

How Veracly approaches pixel audits

Veracly matches outgoing requests against a registry of 69 hand-curated trackers (Meta, TikTok, LinkedIn, Google Ads, Pinterest, Snap, X/Twitter, Reddit, Hotjar, Microsoft Clarity, FullStory, HubSpot and the rest). It matches them on their firing endpoints rather than their loader scripts, so a tag that Consent Mode is correctly holding back is not reported as though it had fired. For each match you get the request URL, whether it arrived before the banner was touched, the cookies and storage keys observed, and a copy-paste fix for your CMP or tag manager.

Three limits, up front. The registry is curated by hand between releases, not scraped from a feed, so a tracker nobody has added yet will not be matched. Anything that never reaches the browser is outside what a browser-side scan can see — Meta’s Conversions API, a server-side GTM container, a tagging endpoint on your own domain. And scheduled re-scans run monthly on Starter; weekly and daily monitoring are the higher plans. Run a scan.

See also: What is a GDPR cookie audit? · What is a cookie banner audit?