Home / Guides / How We Improved a GDPR Compliance Score from 42 to 91

Case Studies

How We Improved a GDPR Compliance Score from 42 to 91

A step-by-step walkthrough of how a B2C ecommerce site raised its GDPRChecker compliance score from 42 to 91 over four weeks by fixing pre-consent tracking, consent UI, and policy disclosures.

Author

GDPRChecker Editorial Team

Reviewed by

Privacy & Compliance Research Team

Last updated

June 2026

Reading time

8 min read

Educational guidance for compliance readiness — not legal advice. Requirements vary by jurisdiction and your specific processing activities.

Introduction

This case study documents the compliance journey of a mid-sized B2C ecommerce store—selling home goods to customers in the EU and UK—that ran its first GDPRChecker scan and received a score of 42 out of 100. The site had a privacy policy, a cookie banner of sorts, and Google Analytics installed. The founders assumed they were broadly compliant. The scanner told a different story.

Over four weeks, the team applied fixes in priority order—starting with pre-consent tracking, then consent UI, then policy accuracy, then runtime verification. The final rescan returned a score of 91. This walkthrough covers every finding, the root causes behind the score gaps, the specific changes made, and the lessons applicable to any ecommerce or marketing site with a similar stack.

Initial scan report: score 42. Red indicators across the three main compliance domains.

Baseline Scan Findings

The first scan ran against the homepage and two product pages. The scanner loaded each page as a new visitor with no stored cookies or local storage, then recorded all network requests before any user interaction.

The findings fell into four categories, each with a score weight:

  • Pre-consent tracking (highest weight): Google Analytics 4 fired on page load. Meta Pixel (Facebook) sent a PageView event before any accept action. Google Ads conversion tracking initialized immediately. TikTok Pixel loaded from an async GTM tag on all pages. None of these were gated behind the consent banner.
  • Consent banner (high weight): the site displayed a banner with an Accept cookies button and a close (×) icon. The close icon dismissed the banner without recording a rejection. There was no Reject all or Decline button on the first layer. The banner reappeared on the next page visit, suggesting consent was not being stored persistently. No preferences panel existed.
  • Privacy policy (medium weight): a privacy policy was linked in the footer. However, the policy was generated from a generic template in 2022, had not been updated since, and did not mention Google Analytics 4 (the site had migrated from Universal Analytics that same year), Meta Pixel, TikTok, or Stripe. International transfer disclosures were absent.
  • Runtime protection (medium weight): no GDPRChecker runtime script was detected. The site used a standalone CMP plugin that issued the banner but did not integrate with server-side blocking. Network requests to analytics and ad domains were not blocked regardless of consent state.

Score breakdown

Score breakdown at baseline: pre-consent tracking 4/30, consent UI 14/25, policy discovery 18/25, runtime monitoring 6/20. Total: 42/100.

Network requests captured on initial page load — four ad/analytics domains contacted before consent.

Root Causes Behind the Low Score

Understanding why each problem existed was as important as understanding what the problem was. The root causes split into three patterns that appear repeatedly across sites with similar stacks:

Root cause 1 — Tag execution order

GTM configured before CMP initialization: the site's Google Tag Manager snippet was placed in the <head> before the consent management plugin JavaScript. This meant GTM's All Pages trigger fired, executing GA4, Meta Pixel, Google Ads, and TikTok tags before the CMP had a chance to check consent state. The fix order matters as much as the fix itself.

Root cause 2 — Banner designed around conversion, not consent

Banner designed for aesthetics, not consent validity: the original banner was designed by a UX contractor who prioritized conversion rate—keeping analytics visibility high by discouraging rejections. The close (×) button was styled to look like a primary action. There was no legal review of the banner before launch. The resulting UI violated the equal-prominence requirement for consent and rejection options.

Root cause 3 — Policy treated as static documentation

Privacy policy drafted once and never revisited: the policy was created at site launch as a task-completion exercise rather than a living document. No process existed to update it when the marketing stack changed. The GA4 migration, the TikTok Pixel addition during a campaign, and the switch to Stripe from PayPal all added processing activities that never made it into the policy.

These root causes are not unique to this site. The GTM-before-CMP ordering issue alone accounts for a substantial share of pre-consent tracking failures across ecommerce sites using off-the-shelf consent plugins. The pattern is so common because the recommended GTM installation position (high in <head>) conflicts with the consent-first requirement that few plugin documentation pages adequately flag.

Fixes Applied and Their Score Impact

The team applied fixes over four weeks in three phases, rescanning after each phase to measure incremental improvement.

  1. Week 1 — Fix tag execution order: moved the GDPRChecker runtime-guard script to the first script in <head>, before GTM. Configured GTM to check consent state before firing any tag. Moved all analytics and ad tags to fire on consent_granted rather than All Pages. This single structural change moved pre-consent tracking from 4/30 to 22/30 at the week-1 rescan.
  2. Week 1 — Install GDPRChecker runtime: registered the site in GDPRChecker dashboard, installed the runtime.js snippet immediately after the runtime-guard, connected consent categories to blocking rules. Verified heartbeat signal in dashboard. This moved runtime monitoring from 6/20 to 18/20.
  3. Week 2 — Rebuild consent banner: replaced the close-button banner with a two-layer CMP using GDPRChecker's consent UI. First layer: Accept all, Reject all, and Manage preferences—equal visual weight on all three. Second layer: categorized toggles (Analytics, Marketing, Preferences) with descriptions. Banner state persisted in local storage with 6-month expiry. Consent UI score moved from 14/25 to 23/25.
  4. Week 3 — Rewrite privacy policy: audited the live site's tag list from the scan report. Drafted a new policy section by section using the Article 13 framework: controller identity, purposes and lawful bases, recipients (Google LLC, Meta Platforms Inc., TikTok Inc., Stripe Inc., Mailchimp/Intuit), international transfers with SCC disclosures for each US vendor, retention periods for each data category. Policy linked from footer and from the checkout page.
  5. Week 3 — Fix TikTok Pixel timing: discovered TikTok tag in GTM firing via a custom HTML tag that bypassed the consent integration. Migrated to TikTok's GTM template with built-in Consent Mode support and consent state check. Rescanned to confirm TikTok no longer appeared in pre-consent network requests.
  6. Week 4 — Verify and document: ran final scan with dashboard runtime verified. Score 91/100. Remaining 9 points: consent records (awaiting 30 days of post-fix data for verification) and one third-party embed (Trustpilot widget) that required a separate consent gate—scheduled for the next sprint.
Score progression over four weeks: 42 → 67 (tag order + runtime) → 84 (banner rebuild) → 91 (policy + verification).

Verification and Ongoing Monitoring

Reaching 91 was not the end of the work—it was the beginning of a maintenance practice. The site implemented three ongoing habits to prevent score regression:

First, a mandatory rescan was added to the deployment checklist for any GTM or theme change. The team configured a scheduled weekly scan in GDPRChecker to catch regressions automatically, with email alerts if the score dropped more than five points between scans.

Second, the marketing team adopted a new pixel addition workflow: any new analytics or advertising tag must be reviewed by the developer lead before going to GTM, with a checklist confirming consent gate integration and privacy policy update. This caught a LinkedIn Insight Tag addition—which would have loaded pre-consent under the old process—and ensured it was properly integrated before launch.

Third, the privacy policy was added to the quarterly review calendar with a checklist: scan report from the current period reviewed, new vendors identified, policy updated, policy date updated. The first quarterly review took three hours; subsequent reviews take about 45 minutes as the operational inventory is already documented.

Six-month follow-up

Six months after the initial improvement, a follow-up scan returned a score of 89. The two-point drop was traced to a Hotjar session recording tag added during a UX research project that had not been consent-gated. It was caught within a week, fixed within two days, and the score returned to 91 at the next scan. The monitoring system worked as intended.

FAQ

How long does it take to improve a GDPR compliance score significantly?
The most impactful fixes—blocking pre-consent tracking and publishing a compliant banner—can be completed in one to two weeks for most sites. Policy rewriting takes another week. Total time from first scan to score above 80 is typically two to four weeks for a focused team.
Which fixes have the biggest score impact?
Pre-consent tracking and consent banner fixes are the highest-weighted components. Blocking analytics and ad tags before consent typically contributes more to score improvement than any other single change because it is both heavily weighted and commonly failed.
Can I improve my score without a developer?
Some improvements—policy updates, banner configuration in a CMP dashboard—do not require development skills. However, fixing GTM tag execution order and installing runtime scripts requires developer access to the site template and tag manager. Budget at least a few developer hours for the structural fixes.
Does a score of 91 mean we are legally GDPR compliant?
Compliance scores reflect automated signals—observable technical behaviors—not a comprehensive legal assessment. A high score means you have addressed the most common and visible compliance failures. Full legal compliance requires human review of processing activities, vendor contracts, and internal procedures that automated tools cannot evaluate.
What causes compliance score regression after initial improvement?
The most common causes are: new ad or analytics tags added without consent gating, GTM configuration changes that re-introduce pre-consent firing, footer link removal after a site redesign, and consent banner UI changes that remove the reject option. Regular post-deploy scans catch these regressions quickly.
Is a TikTok Pixel more difficult to consent-gate than Google Analytics?
TikTok Pixel can be implemented via GTM with consent mode support, which works similarly to Google's consent state integration. The difficulty is that TikTok's official GTM template has historically lagged behind Google's. Using the official template and mapping it to your CMP's marketing consent category is the recommended approach.

GDPRChecker guides are educational resources and do not constitute legal advice. Use them to understand technical and operational privacy requirements, and consult qualified counsel for legal interpretation.

Check Your Website in Under 60 Seconds

  • No signup required
  • GDPR-focused checks
  • Cookie banner detection
  • Privacy policy verification