Your Privacy Policy vs Your Actual Trackers

Since 2022, plaintiffs' firms have filed an estimated 50,000 to 100,000 claims, letters and arbitration demands under California's 1967 wiretapping statute, and roughly 1,500 of those became filed lawsuits in the 18 months to August 2025, almost all aimed at sites running trackers their own policies never disclosed. The script that triggers one of these is the same one you pasted in during a launch sprint and forgot.

This is the policy-versus-behavior front, the sixth of the seven surfaces Tabkeel checks, and it is the one where the evidence against you is sitting in your own page source. A privacy policy on an AI-built site tends to be written once, early, from a template. The trackers arrive later, one tool at a time, and nobody goes back to amend the document.

The policy gets written once. The trackers keep showing up.

Here is the sequence that produces almost every mismatch. You ask a code assistant for a privacy policy, it returns a competent-looking document that mentions "cookies" and "analytics" in general terms, and you ship it. Over the next month you add Google Analytics, a Meta Pixel for an ad test, Intercom for support, and Hotjar because you wanted to watch where people rage-click. None of those four go back into the policy.

An undisclosed tracker is a third-party script your pages load that your privacy policy never names or describes. The policy above is not false, exactly. It is just thin enough to cover none of what the site does. "Cookies to improve your experience" says nothing about recording a visitor's mouse movements, or sending their behavior to an advertising network, or routing identifiers to a support vendor. The document and the site were true at different moments, about different versions of the product, and the distance between them is now live on your domain, the same way a pricing page and terms drift apart when they are written by two processes that never compare notes.

Why the mismatch turned into a legal problem

Policy-versus-behavior consistency is the match between what your privacy policy promises and what your site actually does in a visitor's browser. It matters now for one blunt reason: the enforcers read the behavior, and the behavior is machine-readable.

Two separate pressures are pushing on the same gap. The first is older and federal. The US Federal Trade Commission has treated a company that does not follow its own privacy policy as running a deceptive practice since the GeoCities case in 1998, where the site promised not to share personal information with third parties and then did. It made the same call against Twitter in 2010 over a safeguarding claim the company was not meeting. The FTC's own guidance is consistent: if you say it, it has to be true, and silence about a tracker that is clearly running reads as the policy being incomplete rather than merely quiet.

The second pressure is newer and is what is generating the lawsuit volume. Plaintiffs' firms have repurposed state wiretapping laws, led by California's, against ordinary website trackers. The tools in the crosshairs are exactly the ones an AI-built SaaS reaches for first: Google Analytics, the Meta Pixel, session-replay tools like Hotjar and FullStory, and live-chat widgets. A 2025 federal decision, Lakes v. Ubisoft, pointed at the way out: a consent banner and policy that actually match the trackers running can defeat the claim. The defense is consistency. The exposure is the gap.

None of this is legal advice, and the specifics turn on your jurisdiction and who your visitors are. The part a founder can act on without a lawyer is narrower: your policy should not stay silent about a tracker that is plainly running, and a banner should not claim a choice it does not enforce. Fix those two and you have closed the gap that generates most of the noise.

Find every tracker on your site in about ten minutes

You cannot reconcile a list you have never seen. Before you touch the policy, get the real inventory straight from the browser, because that is the same place a crawler, a regulator, or a plaintiff's expert will look.

1. Open your site in a private window and launch DevTools. Right-click, Inspect, then the Network tab. A private window keeps your own logged-in session from hiding scripts that only fire for anonymous visitors, which is most of them.
2. Reload the page with Network recording on. Every request the page makes appears in the list. What goes wrong here is stopping too early: some trackers load a few seconds after the page settles, or only after a scroll or a click, so interact with the page before you read the list.
3. Sort by domain and mark everything that is not yours. Requests to google-analytics.com, facebook.net, hotjar.com, intercom.io, sentry.io and the like are third parties collecting or receiving data. Each distinct domain is a vendor your policy should account for.
4. Check the Application tab for cookies and storage. Cookies, localStorage and sessionStorage entries show what is being written to the visitor's device. A tracker that sets a persistent identifier is a different disclosure obligation from one that does not.
5. Write the vendor list next to your policy. You now have two columns: what loads, and what the policy admits to. The rows in the first column that are missing from the second are your findings.

The common AI-built stack produces a predictable set of these. The table below is the shortlist to look for and what each one obliges you to say.

A real finding, and the fix as a prompt

The shape the exam returns most on this front is the generic-policy-over-a-loaded-site pattern. The policy claims cookies for "experience," the Network tab shows four named vendors the document has never heard of, and the two are quoted side by side with the source on each so there is nothing to hunt for.

The correction comes back the way every Tabkeel finding does, as a prompt you paste into the same assistant that built the site, not as code dropped into your repo:

My privacy policy only says "we use cookies to improve your experience," but my site loads Google Analytics 4, the Meta Pixel, Intercom and Hotjar session recording, none of which are named. Rewrite the data-collection and third-party sections to name each tool, state the category of data it collects and why, and add a short cookie table listing the provider and purpose for each row. Keep the plain language, do not invent trackers I did not list, and flag which of these should be gated behind a consent banner before the script is allowed to load.

The value is not that something spotted a thin paragraph. It is that it read your running page and your legal document together, which you were never going to do, and handed back the exact lines that disagree.

What your policy has to say, and what it doesn't

A frequent overcorrection is to assume every cookie has to be listed by name. It does not. Under the GDPR and similar regimes the obligation is transparency and, for non-essential trackers, consent: tell visitors what categories of data you collect, why, and who receives it, and let them refuse the trackers that are not strictly necessary. Naming every individual cookie is good practice and often technically impossible, since a single vendor can set dozens with changing names.

What you cannot do is stay silent about a whole vendor. "We use analytics cookies, provided by Google, to measure site usage" is a real disclosure. "We use cookies to improve your experience," with a Meta Pixel quietly shipping behavior to an ad network, is the gap that gets flagged. A cookie policy is the detailed inventory of trackers and their purposes; a privacy policy is the broader statement of what personal data you handle and why. Small sites fold the first into the second, which is fine, as long as the trackers that actually run are in there somewhere a reader and a crawler can find them. If you want the wider picture of why contradictions between what a page says and what it does are their own category of launch bug, the seven-front pre-launch checklist walks all of them.

Where founders get this wrong

Two mistakes account for most mismatches that survive a first pass.

The first is treating the generated policy as finished. It felt like a chore, the assistant produced something that reads like law, and you never opened it again. But the document is the thing a regulator and a card network read, not your intentions, and it stopped describing your site the day you added the second tracker. If the policy says something you would not say out loud to a user about what you collect, that is the finding.

The second is installing a consent banner and assuming the job is done. A banner that appears but does not actually block the scripts until the visitor clicks accept is worse than no banner, because now you are collecting consent you ignore, and the Network tab proves it: the Meta Pixel fires on load, before anyone agreed. Wire the banner to gate the tags, then reload and confirm the third-party requests are gone until you accept. The same discipline of making the visible promise and the actual behavior agree is what carries over to QA on an AI-built SaaS as a whole.

If you ship more than once, redoing this by hand every time a teammate adds a tag gets old fast. The Founder plan exists for that rhythm: it runs the full exam across your sites on a schedule and returns each policy-versus-behavior gap as a paste-ready prompt, so adding a tracker becomes a two-minute recheck instead of a forgotten obligation. For the launch in front of you today, point the Tabkeel exam at your URL and it crawls the site, lists the trackers it finds against what your policy admits to, and writes the reconciliation as a prompt, with the evidence quoted on each finding. To test only this front first, the policy versus behavior tool runs on a single URL with nothing to set up, and the scoring behind every front is documented in the methodology.

Frequently asked questions