Set up Consent Mode v2 and handle data deletion requests

This page shows how to handle the two privacy jobs every tracking setup inherits: respecting what visitors agree to, and removing a person's data when they ask. You will pick a consent model that fits the business, send Google's Consent Mode v2 signals through Tag Manager, hold back your own tags until consent allows them, and set up a deletion routine that finds a person's records everywhere they live.

Two problems, two fixes

They are separate jobs. A perfect cookie banner does not delete a CRM record, and deleting a record does nothing about tomorrow's cookies.

Before you begin

• A Tag Manager container with GA4 installed, as in the quickstart.
• A list of every tag in the container and what it stores or sends, especially Custom HTML tags that save click IDs to cookies or fill hidden form fields.
• A list of every system that holds personal data from the website: the CRM, form notification inboxes, email and text message platforms, spreadsheets, and any tracking database.
• A decision from the business, made with its advisor, about which consent model applies.

Choose a consent model

Not every business needs the same setup. Choose based on where visitors actually come from and where the ads can reach.

Consent Mode also supports region-specific defaults, so one site can deny by default for visitors in the EEA and the UK while allowing by default everywhere else. If you use an opt-out model, ask the business's advisor whether the site must also honor browser opt-out signals such as Global Privacy Control.

How Consent Mode v2 works

Consent Mode is a set of signals that tell Google's tags what they are allowed to do. Version 2 has four core signals, each set to granted or denied:

Every page load starts with a default state, set before any tag fires. When the visitor makes a choice, the banner sends an update, and tags follow the new state from then on. The stored choice is replayed as an update on each later page, so the visitor is not asked again.

Google describes two ways to run it. In basic consent mode, Google's tags do not load at all until the visitor makes a choice. In advanced consent mode, the tags load with everything denied and send cookieless pings, which Google uses for modeling, until consent is granted. Advanced gives Google more to model with, and basic sends nothing before a choice. Decide with the business's advisor.

Set up consent signals in Tag Manager

1. Set the default before any tag fires

   The cleanest way is a consent management platform's Tag Manager template, set to fire on the Consent Initialization - All Pages trigger, which runs before every other trigger. Without a platform, set the default in the page itself, above the Tag Manager snippet. Order matters: if this code runs after Tag Manager loads, the defaults do not work.

   <script>
     window.dataLayer = window.dataLayer || [];
     function gtag(){dataLayer.push(arguments);}
     gtag('consent', 'default', {
       ad_storage: 'denied',
       ad_user_data: 'denied',
       ad_personalization: 'denied',
       analytics_storage: 'denied',
       wait_for_update: 500
     });
   </script>

   wait_for_update tells Google's tags how many milliseconds to wait for the banner's update before sending data.

2. Add the banner and send the update

   When the visitor accepts, send an update that grants the signals they agreed to. When they reject, leave everything denied. Save the choice in a first-party cookie, replay it as an update on each page load, and add a link, usually in the footer, that reopens the choice. A simple self-built banner can do this for a US-focused local business. For real EEA or UK traffic, or when visitors need separate choices for analytics and advertising, use a consent management platform. Platforms send the same update signals, so nothing else in this guide changes.

3. Review the consent overview

   Open Tag Manager's consent overview, which lists the consent checks on every tag (turn it on in the container settings if you do not see it). Google's own tags have built-in consent checks and adjust automatically. Custom HTML tags and other vendors' pixels need their consent requirements set by hand.

4. Gate your own tags behind consent

   Open each Custom HTML tag that saves click IDs or UTM values to cookies, or fills hidden form fields, and in its advanced consent settings require additional consent for ad_storage. If a tag only saves the GA4 client ID, require analytics_storage instead. Until the visitor accepts, those tags do not run, and that visit carries no click ID into the form. That lost attribution is the cost of doing this properly, not a bug to engineer around.

5. Gate the server-side cookie setter too

   If you run server-side tagging, the Google tag passes the consent state to the server container with each request, and Google's own server tags respect it. A custom tag that writes cookies from the server does not, unless you build the check in. Have it read the consent state that arrives with the request, skip the click ID cookies when ad_storage is denied, and handle the analytics identifier according to analytics_storage. Apply the same check to any tag that copies events into a database.

Verify consent behavior

1. Check the default

   Open a private browser window, start Tag Assistant preview, and load the site without touching the banner. Select the earliest consent event: the Consent tab should show the on-page default for every signal as denied, or as the default you chose for that region.

2. Reject and look for leaks

   Click reject. In the browser's developer tools, confirm that no GA4 cookie (_ga) and no click ID cookie was written, that the gated Custom HTML tags did not fire, and that responses from the tagging subdomain, if there is one, set no click ID cookies.

3. Accept in a fresh window

   In a new private window, accept. The most recent consent event should show the update as granted, the cookies should appear, and the gated tags should fire.

4. Browse and come back

   Move between pages and reload. The banner should stay closed, the choice should hold, and the link that reopens the choice should work.

Google's own walkthrough of these checks is in Verify consent mode implementation.

Handle a deletion request

A deletion routine is only as good as the list of places a person's data lives. Build that list before the first request arrives, and update it whenever a new tool touches customer data.

1. Log the request first

   Before deleting anything, write down the date received, how the request arrived, the type of identifier (email or phone), and who is handling it. Logging first means a record exists even if the work gets interrupted.

2. Confirm the request is genuine

   Make sure the request comes from the person whose data it is, for example by replying to the email address in question, so nobody can erase someone else's records.

3. Search every system on the list

   Search with every identifier you have: email, phone, and any click IDs or GA4 client IDs found on their records. Those IDs are what connect a CRM contact to the tracking data and to GA4.

4. Delete or anonymize, and note what you found

   Work through the list and record, system by system, whether a record existed and what was done with it.

5. Close the request

   Add the completion date to the log and tell the person their request has been processed. The confirmation does not need to list what was found.

Keep the log itself small. It is the one record that survives after everything else is gone, so it should prove the request was honored without holding more personal data than necessary. If you need to recognize the same address again, for example to keep it off a re-imported list, store a hashed version rather than the address itself.

Two habits make deletion easier. Set a retention period for raw tracking data so it does not pile up forever, and keep the business's data exportable so it can be handed over when an engagement ends, as covered in offboarding and data portability.