Start a Project

Insights from XDS

Ensuring Cookie Consent Compliance for Life-Science Websites

Last Updated: October 2, 2026

TL;DR

Most life sciences cookie banners fail one of two ways. Either tracking still fires after a visitor clicks Reject, which is exactly what California CIPA lawsuits target, or analytics only runs after Accept, which hides most of your US traffic. Set geolocation rules in your consent platform, gate every tag in Google Tag Manager (including Meta, LinkedIn and other non-Google pixels), turn on Consent Mode v2, and test with a real Reject after every change. This is technical guidance, not legal advice.

Table of Contents

The short answer

A cookie banner that looks fine can still fail you in two opposite ways. It can let tracking fire after a visitor clicks Reject, which is the exact behavior plaintiffs' firms are suing over in California. Or it can block everything until a visitor clicks Accept, which most US visitors never do, and your analytics quietly falls off a cliff.

I've seen both this year, on real life sciences websites, and once I saw them compound. One company had a banner on every page and still had Meta, X, Google Ads, Floodlight and GA4 cookies landing after a rejection. Another deployed a new banner and watched sessions crater because analytics only ran on Accept. A third had a banner that didn't behave the way anyone thought it did, and it ended in a lawsuit.

None of them were careless. Consent breaks in the gap between the legal team that owns the consent platform, the agency that owns Google Tag Manager, and the media agency that owns the ad pixels. Each piece works on its own. Nobody tests the whole thing as a visitor from California would.

This is what we check now, how we configure it, and how you can tell in ten minutes whether your own site has the problem.

Because California plaintiffs found a 1967 wiretap law that pays per violation. The California Invasion of Privacy Act (CIPA) was written for phone taps. Firms now argue that a Meta Pixel, a session replay script or a chat widget that sends browsing data to a third party is an unauthorized interception. CIPA carries statutory damages of up to $5,000 per violation, so the math on a site with real traffic gets ugly fast, and most of these cases settle before anyone argues the merits.

Health and life sciences sites draw extra attention. A page about a condition, a clinical trial or a treatment is itself sensitive, and a pixel that ships that URL to an ad platform is the fact pattern these complaints are built on.

Three other frameworks shape how you configure things:

  • CCPA/CPRA (California). An opt-out model. You can set analytics and ad cookies by default, but you must honor "Do Not Sell or Share" and Global Privacy Control signals, and a reject has to actually stop the sharing.
  • GDPR and ePrivacy (EU, UK). An opt-in model. Non-essential cookies wait until the visitor says yes. No pre-ticked boxes, no "by continuing to browse you agree."
  • Washington's My Health My Data Act and similar state health-data laws. These treat consumer health data, including inferences from browsing, as needing consent before collection or sharing. If you run a disease-awareness or trial-recruitment site, read this one.

I'm not a lawyer and none of this is legal advice. Your counsel decides what the law requires of you. What I can tell you is what your site actually does, and in my experience that's where most companies are wrong.

Implied consent means tracking runs by default and the visitor can turn it off. That's the opt-out model, and it's the normal configuration for most US traffic. Explicit, or opt-in, consent means nothing non-essential runs until the visitor clicks Accept. That's the EU and UK standard.

The mistake I see most is picking one model for the whole world. Go opt-in everywhere and you throw away US analytics you were never required to give up. Go implied everywhere and your European traffic is out of compliance on page one. Every serious consent platform, whether OneTrust, CookieYes or Cookiebot, supports geolocation rules for exactly this reason.

Visitor locationDefault modelWhat fires before a choiceWhat a Reject must do
EU, EEA, UKOpt-inStrictly necessary onlyKeep everything else off
CaliforniaOpt-out, with GPC honoredAnalytics and ads, unless GPC is onStop sharing with ad platforms and third parties
Washington and other health-data statesYour counsel's call, often opt-in for health pagesDepends on page sensitivityStop collection and sharing of health data
Rest of USOpt-outAnalytics and adsStop non-essential cookies

Health companies sometimes choose opt-in for the US too, especially on trial and condition pages. That's a defensible choice. Just make it on purpose, with the analytics cost in front of you, and don't stumble into it through a default setting.

Failure 1: The banner was there. The Reject button did nothing.

We caught this one during a routine consent audit for a clinical-stage biotech, before their legal team or anyone outside the company had noticed. We ran the test the way a plaintiff's investigator would: fresh incognito window, load the homepage, click Reject All, open the cookie store.

Here's what was sitting there after the rejection:

  • _fbp from the Meta Pixel
  • _twpid from the X pixel
  • _gcl_au and the gad_* set from Google Ads
  • _ga and _gid from GA4
  • A Universal Analytics cookie from a property Google retired years ago
  • Marketo's _mkto_trk
  • A DoubleClick Floodlight cookie store

The consent platform was installed, configured and even loading the GTM container. It just wasn't wired to the tags. The main GTM container had dozens of tags and not one consent trigger gating them, so enforcement depended entirely on the platform's auto-blocking, which wasn't catching them.

Part of the gap was inherited. Many of the original tags had been loaded by the media agency before the consent setup existed, and new campaign pixels kept landing on the same All Pages trigger because nobody had told them the rules had changed.

The interesting part was a secondary site. Same company, separate container, and it was mostly right: GA4 and Marketo forms waited for consent. Two tags, the Meta Pixel and the Marketo base tag, still fired on All Pages. One tag on the wrong trigger is all it takes.

The fix wasn't a new banner. It was consent triggers on every non-essential tag in GTM, a cleanup of dead tags nobody had owned in years, and a geolocation rule in the consent platform.

Failure 2: The banner worked too well, and analytics disappeared

A health tech company deployed a new cookie banner, and within weeks their reporting showed a steep drop in sessions and users. The first theory was a traffic problem. It wasn't. Traffic was fine. Measurement was gone.

The banner had been set up so GA4 only fired after a visitor clicked Accept, for every visitor, everywhere. In the US you don't have to do that. Most people ignore a banner, close it or scroll past it, so under that setup the majority of real visits never showed up in GA4 at all.

This is the failure nobody writes about, because it doesn't make legal headlines. It still costs real money. Paid media optimizes against conversions it can no longer see. Dashboards tell leadership the site is shrinking. Budget decisions get made on a fraction of the data.

We've seen a milder version of it in our own client history. When one site tightened its consent tags, paid search click-through metrics dropped sharply overnight. The ads didn't get worse. The measurement got stricter, and nobody had warned the people reading the reports.

The fix: a geolocation rule so US visitors default to opt-out, GA4 mapped to the analytics category rather than the advertising one, and Google Consent Mode v2 configured so you still get modeled data when someone does say no. If those numbers feed your attribution, our healthcare attribution guide covers how to report around the gap.

Failure 3: Everyone assumed the banner worked. Then came the complaint.

A life sciences company in our space had a consent banner live and believed it was doing its job. It wasn't behaving the way anyone expected, and the company was sued over its tracking.

I won't get into the specifics of the case. The lesson doesn't need them. A banner on the page is not evidence of compliance. Plaintiffs' firms don't read your privacy policy or check whether you bought a consent platform. They open a browser, click Reject, and record what your site sends anyway. If a pixel fires, that recording becomes Exhibit A.

The uncomfortable truth is that a banner that doesn't enforce choices can be worse than no banner. It shows you knew consent mattered, offered visitors a choice, and then didn't honor it.

Cases like this are why we stopped treating consent as a launch task. It's a recurring test, run after every container publish, every new campaign pixel and every consent platform update.

The consent platform decides what the visitor agreed to. GTM decides what actually fires. You need both doing their jobs, and they need to agree.

  1. Set geolocation rules in the consent platform first. Opt-in for EU and UK, opt-out for most of the US, with GPC honored. Decide health-data pages with counsel.
  2. Categorize every cookie and script. Strictly necessary, analytics, functional, advertising. GA4 belongs in analytics. Meta, LinkedIn, X, TikTok and Floodlight belong in advertising. Uncategorized cookies are where leaks hide.
  3. Fire the consent default on the Consent Initialization trigger. It has to run before any other tag. If the default loads after GA4, GA4 already fired.
  4. Turn on Google Consent Mode v2. Map the platform's categories to analytics_storage, ad_storage, ad_user_data and ad_personalization. Google has required v2 for EEA ad measurement and remarketing since March 2024. Advanced mode lets Google tags send cookieless pings when consent is denied, which feeds modeled conversions. Basic mode holds them entirely. Pick with counsel.
  5. Gate every non-Google tag explicitly. This is the step most containers miss. Meta, LinkedIn, X and Marketo don't read Consent Mode the way Google tags do. Give each one a consent trigger or an additional consent check for its category. "No additional consent required" on an ad pixel is a red flag.
  6. Hunt for tags outside GTM. Pixels hardcoded in the site template, CMS plugins and chat widgets bypass GTM completely. The consent platform's auto-block has to catch these, or they need to move into GTM.
  7. Retire dead tags. Universal Analytics tags, old agency pixels, test tags. They still fire, still set cookies, and nobody is watching them.
  8. Use GTM's Consent Overview. It lists every tag and its consent settings on one screen. Anything with no consent setting is your to-do list.

After that, GA4 needs very little. Confirm the data stream receives consent signals (Admin, Data streams, consent settings), and annotate the date you changed consent so nobody mistakes the measurement shift for a traffic drop.

In almost every life sciences account we work on, consent is split like this:

PieceTypical ownerWhat breaks when it's missed
Consent platform console: banner, geo rules, categories, auto-blockLegal and ITWrong model by region, uncategorized cookies
GTM container, consent triggers, GA4 configurationDigital or analytics agencyTags fire regardless of choice, or nothing fires at all
Ad pixels and Floodlight tags inside GTMMedia agencyNew campaign pixels added on All Pages

Every defect I described above sat on a seam between two of those rows. Legal assumed the agency had gated the tags. The agency assumed the platform's auto-block caught them. The media agency added a pixel the way it always had.

Name one owner for the end-to-end test. It doesn't matter much which team it is. It matters that someone clicks Reject on the live site after every change and signs off on what they see.

You don't need a tool for the first pass. You need Chrome and ten minutes.

  1. Open an incognito window. Open DevTools, go to the Network tab and check Preserve log.
  2. Load your homepage. Don't touch the banner yet.
  3. Filter Network for facebook.com/tr, google-analytics.com/g/collect, doubleclick.net, px.ads.linkedin.com and analytics.twitter.com. Note anything that fired before you chose.
  4. Click Reject All.
  5. Open Application, then Cookies. Anything beyond the consent platform's own cookies and genuine infrastructure (bot management, load balancing) is a finding.
  6. Click to a second page and repeat step 3. Some tags only fire on navigation.
  7. Repeat from a California IP and an EU IP using a VPN. Geo rules fail more often than people expect.
  8. Check your trial, condition and microsite properties separately. They often run their own containers and their own consent configuration.

Then do the reverse test for Failure 2. Load the site as a US visitor, ignore the banner and browse. If GA4 sends nothing, you're opt-in by accident, and your reports are undercounting.

Frequently asked questions

Do US websites need a cookie banner?

There's no single federal requirement. California's CCPA requires a way to opt out of selling or sharing data and requires honoring Global Privacy Control, and state health-data laws add consent requirements for health information. Most life sciences companies with national traffic need a banner or an equivalent opt-out mechanism.

What is CIPA and why are companies being sued under it?

The California Invasion of Privacy Act is a wiretap law. Plaintiffs argue that pixels and tracking scripts sending browsing data to third parties without consent count as interception, with statutory damages of up to $5,000 per violation.

Why did my analytics drop after adding a cookie banner?

Usually because analytics is set to fire only after Accept for every visitor. Most visitors never click it. Use geolocation rules so US traffic defaults to opt-out, and turn on Consent Mode v2 so Google can model what it can't observe.

What is Google Consent Mode v2?

It's Google's framework for passing consent choices to Google tags through four signals: analytics_storage, ad_storage, ad_user_data and ad_personalization. Google has required it for EEA ad measurement and remarketing since March 2024.

Does Consent Mode block Meta, LinkedIn or other non-Google pixels?

No. Non-Google tags need their own consent triggers or additional consent checks in GTM. This is one of the most common gaps we find.

What's the difference between implied consent and opt-in consent?

Implied consent, or opt-out, lets tracking run until the visitor turns it off. Opt-in consent blocks non-essential tracking until the visitor agrees. The EU and UK require opt-in. Most US states allow opt-out.

How often should we test our cookie consent setup?

After every GTM publish, every new campaign pixel and every consent platform update, plus a full audit at least quarterly.

Want a second set of eyes on your consent setup?

XDS audits cookie consent for healthcare, biotech and medtech teams. We run the same Reject-and-record test a plaintiff's investigator would, review every tag in your GTM containers, map who owns what across legal, your agencies and IT, and hand you a prioritized fix list your counsel can sign off on. We fix the GTM and GA4 side ourselves, and we tell you exactly what your measurement will look like after. Talk with XDS about a consent and tracking audit.
All insights

We’ll Navigate the Chaos

Let’s work together.