Consent Mode v2 for Healthcare Advertisers: What Changes and What Doesn't

Consent Mode v2 for healthcare gets discussed as though it were a compliance product. It is not, and the mismatch causes real problems, because a practice that installs it and considers the matter closed has bought a measurement feature and filed it under legal protection. Understanding what it actually governs takes about ten minutes and prevents a specific and common mistake.

What follows is the healthcare cut specifically. If the prior question is which mode your site is currently running, which is decided at install time rather than by anyone's choice, that is covered separately in which Consent Mode is your site actually running.

The four signals, and what each one governs

Consent Mode is a set of parameters your site sets, which Google's tags then read and respect. Version 2 added two signals to the original two, and the additions are the ones most practices have never looked at.

The two v2 additions matter more than the originals for a medical practice, and for a reason that is easy to miss. The v1 signals are about storage, meaning cookies on the visitor's device. The v2 signals are about transmission and use, meaning whether data goes to Google and what Google may do with it. Storage and transmission are different questions, and the original two signals never addressed the second one.

The practical implication is that a site configured only for v1 signals could deny cookie storage while continuing to transmit. That is a coherent position for a general retailer. It is a poor one for a practice whose page addresses name treatments.

What happens when a signal is denied

This is where expectations and behaviour diverge, and the divergence is documented rather than hidden. Google describes it plainly in its consent mode overview.

When consent is denied, the tag does not go silent. It continues to send what Google calls cookieless pings: requests that omit identifiers but still carry context such as the page, the timestamp, the user agent and general location. Those pings feed conversion modelling, which is the entire commercial purpose of the feature. The point of Consent Mode is to preserve measurement when consent is withheld, not to stop data flowing.

For most advertisers that design is exactly right. For a practice whose page path reads as a treatment name, a cookieless ping still carries the page path. The identifier is gone. The health context is not.

Conversion modelling deserves a note of its own, because it is the reason the feature exists and it is widely misunderstood in both directions. When identifiers are unavailable, Google estimates the conversions it cannot observe, using patterns learned from the traffic where consent was granted. The estimates are genuinely useful for deciding where to spend money. They are also estimates, which means the number in the interface is partly observed and partly inferred, and the ratio between those is not shown to you.

For a practice reconciling ad platform conversions against consultations that actually appeared in the calendar, that distinction matters operationally rather than legally. Modelled conversions do not correspond one to one with people. Treating them as a patient count, rather than as a spend-allocation signal, produces confident reporting about volumes that were never observed.

Why Consent Mode v2 for healthcare is not a compliance control

Put the two facts together and the conclusion follows without much argument.

The question that governs a medical practice's exposure is whether a vendor receives protected health information, which turns on the combination of an identifier and health context arriving together. Consent Mode, in its default configuration, removes the identifier and preserves the context. That is a genuine reduction in exposure and it is not the same as no disclosure.

More importantly, the mechanism is a request to a tag that is already running. It is an instruction rather than a barrier. Instructions can be misconfigured, overridden by a second tag manager container, silently reset by a plugin update, or simply never wired to the banner in the first place, which is by far the most common failure. A barrier that was never installed fails visibly. An instruction that stopped being honoured fails silently, and nobody finds out.

That distinction deserves its own treatment, and it gets one in Consent Mode is not tag blocking. The short version is that one governs behaviour and the other governs presence.

There is a further asymmetry worth naming, because it decides how much weight this feature can carry. Consent Mode governs Google's tags. It has no authority over anyone else's. A practice site typically runs scripts from several vendors, and the ones that arrived through a page builder, a chat widget or a scheduling embed are not listening to these signals at all. A correct Consent Mode configuration can therefore be entirely accurate about Google's behaviour and entirely silent about most of what your pages are doing, which is a state of affairs that reads as compliance from inside the tag manager and does not survive contact with a network log. Consent gating operates at the page level instead, which is the level at which the question was actually asked.

Configuring Consent Mode v2 for healthcare sensibly

Assuming you run Google advertising and want measurement to survive, a few decisions matter more than the rest.

Set all four signals to denied by default, before any tag fires. The default call has to execute ahead of the tags it governs. If it runs after, there is a window in which the tags behave as though consent were granted, and that window is where the interesting data goes.

Do not treat granted as the default while you wait for a decision. Deny by default is the only posture consistent with the rest of a healthcare configuration, and it is the posture that makes the audit trail meaningful. A record showing that consent was assumed until refused documents something nobody wants documented.

Check the region settings if you have any. Consent Mode supports applying different defaults by region, which is a sensible feature that becomes a liability when someone configures denial only for European visitors and leaves the rest of the world on granted. That configuration is common, because it was written to satisfy a European requirement and never revisited. For a practice in the United States it produces the exact posture you were trying to avoid, on every visitor you actually have.

Wire the update call to the actual banner interaction. A surprising number of installations set defaults correctly and never send the update, so consent is denied forever and measurement quietly collapses. The reverse also happens, where an update fires on page load regardless of what the visitor did, which is worse.

Do not send field values as event parameters. No consent signal governs what you choose to put into an event payload. If a form submission event carries the condition a patient typed, Consent Mode has no view on that at all. This is the single most damaging misconfiguration on practice sites, and it sits entirely outside the feature.

Keep the two questions separate in your own head. Consent Mode answers what Google's tags should do. Whether those tags belong on a given page is a prior question, answered by whether protected health information is present, which is the analysis in analytics on patient-facing pages. Configuring the first while ignoring the second is the mistake this whole piece exists to prevent.

One last practical note. Google documents the available privacy controls in Analytics separately from Consent Mode, and the two interact. Retention settings, IP handling and data-sharing toggles are worth reviewing at the same time, because a correct Consent Mode implementation sitting on top of a property configured to share data broadly is a partial fix wearing the appearance of a complete one. Consent gating sits underneath all of it, and it is the layer that does not depend on any of these settings staying correct.