The most urgent issue for Vampire Vape is that tags are firing after users select Reject All on the consent banner, meaning third-party tracking is active without a legal basis — a serious GDPR compliance risk that needs to be resolved immediately. This single failure is likely responsible for the majority of the 35 high-severity issues identified across the 6 URLs audited, and it has driven the overall audit score to zero. Compounding the problem, personally identifiable information in the form of phone numbers is being sent to GA4, which represents an additional data breach risk and a direct violation of Google's terms of service. The combination of non-consensual tag firing and PII leakage means Vampire Vape is currently exposed on multiple regulatory fronts simultaneously. We would recommend pausing affected tags as an emergency measure while the consent management platform configuration is reviewed and corrected, and scrubbing the GA4 data stream of any collected phone number data.
Vampire Vape's GA4 property carries a trust score of 76/100, meaning a meaningful portion of reported data cannot be fully relied upon for strategic decisions. Two high-severity issues — a 147% spike in session_start events and a client-side event failing to reach GA4 — indicate likely tagging regressions or data loss that could be distorting traffic volumes and attribution. With £218,784 in tracked revenue and 6,939 purchases on record, resolving these integrity gaps is critical before using this data to inform budget allocation or funnel optimisation.
Vendors firing despite Reject All: GA4. This breaches GDPR/PECR and is incompatible with Consent Mode v2 'denied' signals.
Fix: Add consent-aware GTM triggers (Consent Mode v2 'ad_storage' / 'analytics_storage' = denied) and verify tags wait for an Update signal before firing.
Detected phone in params ['_p', 'cid', 'gtm', 'sid', 'uafvl'] of https://region1.google-analytics.com/g/collect?…
Fix: Hash, redact, or remove PII before sending. Use Enhanced Conversions / CAPI with hashed values where required.
Detected phone in params ['nocache'] of https://consent.Cookiebot.com/logconsent.ashx?…
Fix: Hash, redact, or remove PII before sending. Use Enhanced Conversions / CAPI with hashed values where required.
Went from 41,442 to 102,220. A change this large usually indicates a tagging regression (deploy / theme update) or a data outage.
Fix: Check deploy history and GTM change log around the inflection. Verify the event still fires via DebugView.
The tracking-auditor saw these events fire in the browser, but GA4 has no record of them in the audit window. Common causes: ad-blocker / CMP denial in the real traffic mix, beacon sent to wrong endpoint, Measurement Protocol payload malformed, or a tag filter dropping the event server-side.
Fix: In GTM Preview mode, confirm the event lands in the /g/collect endpoint with the right `tid`. If yes, enable GA4 DebugView and check for a filter/data retention issue. If the gap is large, suspect adblock/CMP denial — consider server-side GTM.
URL: https://www.vampirevape.co.uk/e-liquid/vampire-vape-max-watermelon-10ml-nic-salt-e-liquid — client-side: 1 GA4 events fired client-side (view_item); GA4: 0 page_views in window
These URLs are in the crawl / tracking-audit config but GA4 shows no page_view events for them in the audit window. Either the pages aren't getting traffic, or the GA4 tag isn't firing on them.
Fix: Verify the GA4 / GTM tag fires on these templates (view the page in GTM Preview). If traffic is genuinely zero, remove from the audit list.