Client-side tracking & consent

Executive Summary

The most urgent problem for Vampire Vape is that tags are firing after users select "Reject All" on the consent banner, which represents a serious compliance risk under UK GDPR and PECR and is almost certainly the primary driver of the site's score of zero. Across the 25 URLs audited, this single issue accounts for the overwhelming majority of the 54 high-severity findings, meaning that tracking is systematically ignoring users' consent choices at scale. This exposes the business to potential regulatory scrutiny from the ICO and could undermine user trust if it came to light publicly. Separately, a duplicate GA4 installation was also identified, which, once the consent issue is resolved, will need to be addressed to prevent inflated session counts and skewed analytics data. Fixing the consent signal integration with the tag management setup should be treated as an immediate priority before any further data collection takes place.

At a glance

Top recommendations

1. HIGH GA4 fires after Reject All: implement Consent Mode v2 blocking immediately

   GA4 tags firing after a user clicks Reject All is a direct breach of GDPR Article 6 and PECR, exposing the business to regulatory fines and Cookiebot consent log evidence already exists in your network traffic.

   How to fix

   1. In GTM, open every Google Tag / GA4 Configuration tag and confirm it has NO built-in consent override — remove any 'consent_override' or 'no-check' settings.
   2. In the Cookiebot GTM template (or your CMP's GTM integration), ensure the dataLayer push fires `gtag('consent', 'default', {analytics_storage: 'denied', ad_storage: 'denied', wait_for_update: 500})` before the GTM snippet loads, placed in a tag with trigger 'Consent Initialization - All Pages'.
   3. Add a Consent Update tag that calls `gtag('consent', 'update', {...})` on the Cookiebot `CookiebotOnAccept` / `CookiebotOnDecline` custom events, mapping Cookiebot's `CookieConsent.statistics` → `analytics_storage`.
   4. On every GA4 tag, set the built-in Consent Setting to 'No additional consent required' and rely solely on Consent Mode signals — do NOT add an additional consent trigger, as Consent Mode handles blocking natively.
   5. Validate in GTM Preview mode: reject all cookies, confirm GA4 tags show status 'Blocked by Consent Mode' (orange icon) and that no `g/collect` requests appear in the browser network tab after rejection.

2. HIGH Phone number PII leaking to GA4 and Cookiebot across multiple parameters

   Sending phone numbers as personal data to Google Analytics (params `cid`, `sid`, `_p`, `ep.ga_temp_client_id`, `uafvl`) and Cookiebot (`nocache`) violates GDPR Article 5(1)(c) data minimisation and Google's own measurement terms of service, risking account suspension and regulatory action.

   How to fix

   1. Identify the source: in GTM, audit all GA4 Event tags and the GA4 Configuration tag for any Variable that reads from form fields, URL parameters, or dataLayer keys (`ga_temp_client_id`, `cid`, `sid`) that could contain user-entered phone numbers — check Custom Dimensions and Event Parameters mapped in the tag.
   2. For any field value that may contain a phone number, create a GTM Custom JavaScript Variable that applies a regex sanitiser, e.g. `return inputValue.replace(/(\+?\d[\s\-.]?){7,15}/g, '[REDACTED]')`, and use that variable instead of the raw value.
   3. In the GA4 Configuration tag, ensure `client_id` is derived only from the `_ga` first-party cookie (`{{Cookie - _ga}}`), not from any user-supplied dataLayer key; remove any `ga_temp_client_id` mapping if it surfaces form data.
   4. For the Cookiebot `nocache` parameter: this is a timestamp appended by Cookiebot's own SDK — verify your site is not appending additional query string data to Cookiebot URLs via GTM tag URL overrides or custom HTML tags; if clean, the phone detection is likely a false positive on the numeric timestamp, but confirm by inspecting the raw `nocache` value in the network tab.
   5. Enable GA4's built-in Data Redaction setting: in the Google Tag (gtag configuration), set `redact_device_info` and in GA4 Admin → Data Streams → More Tagging Settings → Enable Redaction of Emails (extend regex pattern to cover phone formats under Advanced Settings).
   6. Validate by triggering the affected forms in GTM Preview, inspecting the outgoing `g/collect` request payload in the browser Network tab, and confirming no digit sequences matching phone patterns appear in `cid`, `sid`, `_p`, or `ep.*` parameters.

3. HIGH Remove duplicate GA4 installs (3 instances found) to stop event double/triple-counting

   Three simultaneous GA4 hits per user interaction will triple reported conversions, sessions, and revenue in GA4, making every KPI in your dashboards and Google Ads bidding models incorrect.

   How to fix

   1. In GTM, go to Tags and filter by tag type 'Google Tag' and 'Google Analytics: GA4 Event' — list every tag firing the Measurement ID `G-B0FRYP2L33`.
   2. Check for hardcoded GA4 snippet (`gtag.js`) in the site's HTML `<head>` outside GTM — use browser DevTools Sources panel to search for `G-B0FRYP2L33`; if found, remove it from the CMS/template and let GTM own all GA4 loading.
   3. In GTM, ensure there is exactly ONE Google Tag (formerly GA4 Configuration tag) with ID `G-B0FRYP2L33` set to fire on 'All Pages'; delete or pause all duplicates.
   4. Check for additional GTM containers or hardcoded `gtag('config', 'G-B0FRYP2L33')` calls in custom HTML tags or third-party scripts and remove them.
   5. Validate in GTM Preview + GA4 DebugView: load any page and confirm exactly one `page_view` event appears in DebugView; also inspect the Network tab and count `g/collect` requests on page load — there should be one, not three.

4. HIGH Remove duplicate GTM container installs (3 instances found) to eliminate cascading tag fires

   Three GTM container loads mean every tag inside GTM fires three times, which is the root cause amplifying the duplicate GA4 hits and PII leaks detected above — fixing this will proportionally reduce all other issues.

   How to fix

   1. In browser DevTools Network tab, filter by `gtm.js` and note all container IDs loading — confirm whether it is the same container ID loading three times or multiple different container IDs.
   2. Search the site codebase (CMS templates, `<head>` partials, footer includes, React/Vue component mounts) for the GTM snippet (`googletagmanager.com/gtm.js`) and ensure it appears exactly once in `<head>` and the `<noscript>` iframe exactly once in `<body>`.
   3. If using a CMS (e.g. WordPress), check plugins such as MonsterInsights, WPCode, or theme options panels that may inject a second or third GTM container independently of the developer-placed snippet — disable duplicate injections.
   4. If multiple container IDs are legitimately needed, use GTM's Zones or a single container with environment-specific workspace rather than loading separate containers on the same page.
   5. Validate with GTM Preview: open the Summary panel and confirm only one container initialisation event appears; in the Network tab, `gtm.js` should be requested exactly once per page load.

Consent matrix (trackers fired by state)

Issues (5 types across 54 occurrences)