Adding a New Tracking Tool? A Consent Runbook Before You Go Live

The moment a new tag becomes a liability

Someone on the marketing team wants to add a new tool. Maybe it's a heatmap, a LinkedIn Insight Tag, a chat widget, or a fresh analytics platform. They paste a snippet into Google Tag Manager or drop it in the site header, it starts collecting data, and everyone moves on. What just happened, in compliance terms, is that a third party began setting cookies and opening connections on your visitors' devices, probably before anyone consented, and your cookie policy no longer describes what your site actually does.

This is the most common way a compliant site quietly becomes non-compliant. Not a redesign, not a migration, just a single tag added without a process. The fix isn't to slow marketing down. It's to have a short, repeatable runbook that anyone can follow when a new tool goes in.

Step 1: Decide the category before you install anything

Every non-essential tracker needs prior consent under Article 5(3) of the ePrivacy Directive and its national implementations. So the first question isn't technical, it's legal: what is this tool for? Analytics, advertising, personalization, functional? That answer determines which consent category it belongs to and whether it can fire before opt-in.

Almost nothing new qualifies as strictly necessary. A chat widget that only loads after a click might, but the analytics inside it doesn't. Be honest here. Mislabeling an advertising pixel as necessary to skip the consent gate is exactly the pattern regulators fine. When in doubt, treat it as consent-required.

Step 2: Install it blocked by default

Add the tag in a state where it cannot run until the visitor consents. There are two reliable ways to do this:

• Consent-gated tag management. In Google Tag Manager, set the tag's consent settings so it only fires when the relevant consent type is granted, and pass Google Consent Mode signals. See our GTM consent setup guide.
• Script blocking through your consent platform. Your CMP can hold the script until the matching category is accepted, then release it. This is the cleaner approach for scripts added directly to the page. See how to block scripts before consent.

The default state matters. A tag that fires and then gets "switched off" on rejection has already set its cookies. Block first, release on consent, never the reverse.

Step 3: Scan the tool to see what it actually sets

Vendors under-disclose. The tool's documentation might list two cookies; in practice it sets five and opens connections to three domains you've never heard of. Run a scan on a page where the tool is active (in your accept-all test state) so you can see the real cookies, scripts, and network connections it introduces. This is the only way to categorize accurately, because you're categorizing what the tool does, not what its docs claim.

Pay attention to connections, not the cookies alone. Modern tracking often works through network requests and local storage rather than classic cookies, and a cookie-only scan misses those. If your scanner captures outbound connections, review them the same way you review cookies.

Step 4: Update your disclosures to match

Your cookie policy is a legal document that has to describe your real cookies. A new tool means new entries: the cookie names, their purpose, who receives the data, and retention. If the vendor is a new data recipient, that also touches your records of processing. Two updates to make now, while it's fresh:

• Add the new cookies to your cookie policy and your banner's category listings. See writing a cookie policy that matches your cookies.
• Add the vendor to your records of processing if it's a new processor or recipient. A new adtech vendor can also be a material change that affects whether existing consent still covers your processing.

Step 5: QA the consent gate before launch

Test the tool the way a regulator's automated crawler would. In a fresh browser session with dev tools open:

1. Reject all. Confirm the new tool sets nothing, no cookies, no network calls to its domains. This is the test most sites fail.
2. Accept the relevant category. Confirm the tool now loads and works as intended.
3. Accept only unrelated categories. Confirm an analytics tool stays blocked when only, say, functional cookies are accepted.
4. Withdraw consent. Confirm the tool stops and, where appropriate, its cookies are cleared.

If the tool fires on reject-all, it's blocked incorrectly. Fix it before the change ships, not after a complaint.