A client came to me with a letter no business owner wants to receive.
It was a pre-litigation demand letter alleging that the client’s website violated the California Invasion of Privacy Act, better known as CIPA. The sender proposed a monetary settlement and threatened to take the matter to court if the parties could not resolve it.
To be clear, a demand letter alleges a violation; it does not establish one. But when a letter like this arrives, it gets your attention very quickly.
The legal response belonged to the client’s attorney. My part was figuring out what the website was doing before a visitor made any privacy choice. Which trackers loaded? Where did they come from? Did the consent banner actually stop them, or did it appear after the data had already left the browser?
That was how I ended up researching a California privacy law written in 1967. Yes, 1967. CIPA predates WordPress, Google Analytics, cookies, pixels, chat widgets, and the commercial Internet itself.
I’m keeping the client anonymous, and I won’t discuss the settlement demand or legal strategy. The useful part of this story is the technical problem the letter exposed. On many marketing websites, the banner says one thing while the website does another.
What is CIPA?
CIPA stands for the California Invasion of Privacy Act. It is part of the California Penal Code, beginning at Section 630. This is not the Children’s Internet Protection Act, which happens to use the same acronym.
California enacted CIPA to protect private communications from wiretapping, eavesdropping, and recording without the required consent. The law was written when an “invasion of privacy” meant someone tapping a telephone line or secretly recording a conversation. It doesn’t give website owners a convenient checklist for Meta Pixel, session replay, call tracking, or live chat.
So how did a 1967 wiretapping law find its way into website privacy claims?
Modern websites routinely send information to third party services. A single page may contact analytics platforms, advertising networks, call-tracking providers, chat systems, video hosts, schedulers, and CRM tools. Depending on the tool and its configuration, that exchange may include information about the page, device, clicks, form activity, or chat interaction.
The argument in many CIPA website claims is that a third party intercepted or recorded a visitor’s communication before the visitor consented. Whether that argument succeeds depends on the facts, the technology, and how the court interprets the statute. Courts have not treated every website-tracking case the same way, and the law in this area is still contested.
This distinction matters. A CIPA demand letter needs a qualified privacy attorney, not a marketer pretending to be one. The attorney also needs accurate information about what the website actually did. That’s where the technical audit begins.
CIPA is not the same as CCPA or CPRA
Most California privacy conversations focus on the CCPA and CPRA. Those laws cover issues such as notice, access, deletion, correction, and the right to opt out of certain data practices.
CIPA comes from a different place. It is a communications privacy and wiretapping law. That means a website can have a polished privacy policy and a visible CCPA opt-out link and still face a separate allegation about information transmitted during the first page load.
Here is the practical question I care about: which third parties receive a request before the visitor has agreed to non-essential tracking?
That question does not decide the law. It does give the business and its lawyer a set of facts instead of assumptions.
Why a cookie banner may not protect the website
Most website owners assume that installing a cookie banner solves the problem. I understand why. The banner is visible, it has Accept and Reject buttons, and a plugin dashboard may show a long list of settings.
But the banner is only useful if it controls what the website does.
Open many marketing websites in a private browser window and watch the Network tab before touching the banner. Analytics may already be measuring the visit. Call tracking may already be swapping the phone number. A chat tool may have created a session. Meta Pixel may have fired. An embedded video may have contacted several third party domains.
If all of that happened before the visitor clicked anything, the banner arrived too late.
A later opt-out cannot pull back a request that already left the browser. This is why I do not start a CIPA-related technical review by choosing banner colors. I start by looking at the network activity.
What a proper website tracker audit includes
Trackers usually enter a WordPress website through a few predictable places:
- Google Tag Manager or another tag container;
- WordPress plugins and integrations;
- scripts pasted into the theme or a template;
- embedded maps, video, forms, schedulers, social content, and chat tools.
The hardcoded scripts are often the most interesting. Someone added them years ago, the campaign ended, the employee left, and the script stayed. Sometimes the current team does not know which account receives the data or why the tool is still there.
I also do not stop at the home page. A blog post may load YouTube. A landing page may have a scheduler. A contact page may combine a form, map, chat widget, and call tracking. The audit has to cover representative page types or it will miss the exact tools most likely to create a problem.
The result should be a clear inventory: the service, where it loads, what it appears to do, and which pages use it. Counsel can review that list, and the technical team can use it as the implementation plan.
The banner is the control panel, not the whole system
After the inventory is complete, the consent platform can be configured around the business’s approved model. That includes regions, cookie categories, wording, refusal options, and a way for visitors to change their choice later.
The wording needs to describe the real website. A template that mentions only “analytics cookies” is not enough when the site also uses call tracking, Meta Pixel, chat, booking software, heatmaps, and video platforms.
Accept and Reject must produce different technical results. If both choices load the same trackers, the banner isn’t controlling consent. It’s collecting button clicks.
Google Consent Mode v2 is only one piece
Google Analytics, Google Ads, and remarketing tags can use Google Consent Mode v2. The website sends a default consent state before Google’s tags load and updates that state after the visitor makes a choice.
The order has to be tested. A green check mark in a plugin dashboard does not prove that the default signal reached Google before the tag container loaded.
There is another common misunderstanding: Google Consent Mode controls Google services. It doesn’t automatically stop Meta Pixel, call tracking, CRM scripts, chat, booking tools, heatmaps, or video players.
Every non-Google tracker needs its own gate. Some can be controlled inside the consent platform. Others need revised Tag Manager triggers. Hardcoded scripts may have to be moved or rewritten so the browser does not request the third party file early.
This is the unglamorous part of the project, and usually the most important one.
The consent model is not my decision
There are two broad models that appear frequently on US websites. I can explain the technical trade-offs and implement either one. I can’t choose the legal posture for the business.
Ask before non-essential tracking
Under an ask-first model, non-essential trackers stay off until the visitor actively agrees. This is my default technical setup when the concern is a claim that information left the browser before consent.
The marketing trade-off is real. Visitors who do not accept may be missing from ordinary analytics. Attribution becomes less complete, and remarketing audiences become smaller. Google’s consent tools may model some activity, but the reports will not look exactly as they did when every tag fired automatically.
Notify and provide an opt-out
Under an opt-out model, tracking begins immediately and the visitor receives a way to stop it afterwards. Some businesses use this approach under particular US privacy frameworks because it preserves more analytics and advertising data.
This setup does little to answer a complaint about tracking that happened before consent. It may also be inappropriate for visitors in jurisdictions that require prior consent for non-essential tracking.
The business or its privacy counsel should make this choice in writing. A developer or marketing agency should not make it quietly because one configuration is easier.
Policies and consent records need to match reality
A cookie policy should come from the actual site scan. It needs to identify what is collected, which service receives it, why it is used, and how long it is retained. The policy should connect to the site’s privacy documentation and consent interface.
Consent logging matters as well. If a question comes later, “we had a banner” is not much of an answer. The selected platform should record the visitor’s choice according to the retention settings approved for the business.
A technical team can point out that the policy and the website behave differently. Only counsel can decide whether the disclosure is legally sufficient.
How long does technical CIPA implementation take?
For a typical single-domain WordPress website, our working estimate is 9 to 17 hours. A clean site with ready access may fall near the middle of that range. A site with years of plugins, custom scripts, and stacked caches may not.
| Stage | Estimated hours |
|---|---|
| Tracker audit and inventory | 1–2 |
| Consent banner, regions, categories, and consent logic | 1–2 |
| Google Consent Mode v2 | 1 |
| Binding non-Google trackers to consent | 2–4 |
| Tag Manager review and trigger changes | 1–2 |
| Video and social placeholders | 0.5–2 |
| Cookie policy and document linkage | 0.5–1 |
| Banner styling | 1–2 |
| Final verification and written handover | 1 |
| Total | 9–17 |
This is an estimate, not a fixed quote. The tracker audit is often where the website finally reveals everything nobody remembered was installed.
What usually adds time
Caching is a repeat offender. A WordPress site may have a plugin cache, server cache, CDN, and security layer serving different versions of the same page. A correct change can look broken because the browser keeps receiving an older copy.
Hardcoded trackers take longer than clean Tag Manager tags. Firewalls and bot protection may block testing. The audit may also uncover broken scheduled jobs, plugin conflicts, or redirect rules that have nothing to do with consent but still interfere with verification.
And then there is access. Hosting, CDN, Tag Manager, and plugin licences may belong to four different people. In my experience, waiting for the right login can take longer than changing the code.
What this work does not include
I want to be precise about the boundary. Technical implementation doesn’t include:
- legal advice or representation;
- a legal guarantee that a website is “CIPA compliant”;
- a promise about the outcome of a demand letter or lawsuit;
- rewriting the business’s privacy policy;
- ongoing monitoring after handover;
- repairs to unrelated website faults;
- third party platform licence fees.
Trackers also change. A new chat widget, ad pixel, or video plugin can reintroduce early requests after the original work is complete. A one-time cleanup is not permanent monitoring.
Medical practices have another issue to consider: website tracking may also create HIPAA questions. That is a separate analysis, which I cover in Do I Need HIPAA Compliant Marketing?
How you can see whether the setup works
Open the website in a private browser window and open developer tools before touching the banner. Under an ask-first model, there should be no requests to non-essential analytics, advertising, call-tracking, chat, or video domains before consent.
Accept the relevant categories, and the permitted requests should appear. Open a new private window, decline, and they should stay off.
I run this test across the home page, a content page, and pages with forms, chat, scheduling, or embedded media. The handover should document what was found, what changed, and how the result was verified.
It’s a simple test, and far more useful than a screenshot of a settings page.
What I learned from the client’s demand letter
The letter started as a legal problem. For me, it exposed a gap between how website owners think consent works and what their websites actually do.
I no longer begin this conversation by asking which cookie-banner plugin someone wants. I begin with three questions: What leaves the browser? When does it leave? What choice did the visitor have before it happened?
If your organization receives a CIPA demand letter, privacy counsel should lead the response. In parallel, a technical audit can preserve the current configuration, identify the third party requests, and give the attorney facts instead of guesses.
