UK PECR and GA4: what the privacy rules mean for analytics

Key Takeaway

UK PECR requires consent before setting analytics cookies, which means GA4 must run in consent mode with analytics_storage denied by default for UK visitors. Using GA4 without a cookie banner in the UK is a PECR violation.
Intermediate

UK organisations using GA4 need to think about both UK GDPR and PECR. For most standard cookie-based analytics setups, the practical question is whether analytics storage and related tracking behavior are being controlled in a way that matches the user's choice.

Why PECR matters to a GA4 implementation

PECR sits alongside UK GDPR and focuses on storing or accessing information on a user's device. The ICO's guidance on storage and access technologies is the most relevant operational reference for website analytics teams because it deals directly with cookies and similar tracking technologies. Retention is a related operational decision: seeGA4 data retention settingsfor the property-level controls that should match your stated retention period.

In practice, many standard GA4 website setups rely on cookies or similar identifiers, so teams usually need to review consent handling carefully rather than assuming analytics can load by default. Exactly how that applies to your setup should be confirmed with your legal or privacy team, and the data-handling side should be reviewed alongsideGDPR and GA4 compliance.

If your stack includes a server container, the consent path you describe to ICO needs to match the live behaviour we cover inserver-side consent signals and GA4.

UK GDPR and PECR are related but not the same

Teams often discuss them as if they were interchangeable. They are not. UK GDPR covers broader personal data processing, while PECR is often the more immediate rule set for cookie and tracking behavior on websites. At the tagging layer, this is where theConsent Mode v2 implementationhas to do real work — the banner alone is not what determines whether storage actually happens.

UK GDPR
PECR
Main focus
Personal data processing more broadly
Storage and access technologies and related communications rules
Typical GA4 relevance
Retention, transparency, access, governance, and processor questions
Cookie and identifier behavior on the user's device
Consent discussion
Part of the wider lawful-basis and transparency framework
Often the immediate question for analytics cookies and similar tracking
Operational impact
Policies, records, data handling, vendor review
Banner behavior, default tag state, withdrawal, and cookie controls
Best audit approach
Review governance and data processing design
Review real browser behavior before and after consent choices
1

Audit what the site stores or reads before user choice

Use browser tools to see whether GA4 or related identifiers are created before a user has made a consent choice. This is usually the first practical test teams need to run.

2

Review the consent banner and default measurement state

Check what the banner says, what choices it offers, and what the default tag state is before interaction. If you use consent mode, confirm the defaults and update behavior match the intended implementation.

3

Test grant and decline paths separately

Run a fresh test session for an accept path and a decline path. Compare whether GA4, ads tags, and any related identifiers behave as expected in each case. Do not rely on configuration screenshots alone.

4

Review withdrawal and change-of-choice behavior

A consent-aware setup should not only capture the initial choice. It should also let users revisit that choice and update measurement behavior accordingly.

5

Document the implementation and review it with the right stakeholders

Keep a written record of the CMP used, the consent logic, the relevant Google tag settings, and the policy wording. If there is any uncertainty about whether your setup relies on an exemption, escalate that question rather than guessing.

PECR review checklist for GA4

UK PECR checklist for GA4

  • The team has tested what happens before any consent choice is made
  • Consent-aware tagging behavior has been validated in the browser, not just in GTM
  • Grant and decline paths have both been tested end to end
  • Users can revisit and change their choice without unnecessary friction
  • The implementation has been documented and reviewed by the relevant legal or privacy owner
  • Policy and banner wording are aligned with the actual implementation

PECR implementation action plan

Validate

  • Test whether analytics-related storage or requests appear before user choice
  • Check the default consent state and the update behavior after a user responds
  • Verify the decline path changes measurement behavior in the intended way
  • Confirm the implementation documentation matches what the site actually does

Fix

  • Block or constrain measurement until the intended consent state is established
  • Rewrite banner or policy copy that does not describe analytics behavior clearly enough
  • Add a repeatable browser-based test for grant, decline, and withdrawal paths
  • Escalate exemption or lawful-basis assumptions to legal review instead of embedding them in tag logic

Watch for

  • GA4 or related identifiers appearing before a user has made a choice
  • CMP changes that quietly alter the default tag behavior
  • Policies claiming one thing while browser behavior shows another
  • Regulatory guidance changes from the ICO that should trigger a re-review of the setup

Audit your GA4 consent configuration

GA4 Audits checks consent signal behavior, CMP integration, and tag defaults. Technical findings should be reviewed alongside your legal and privacy team for UK PECR compliance.

Audit findings should be reviewed by a qualified analyst before they are used for major reporting, media, or implementation decisions. Review your findings

GA4 Audits Team

GA4 Audits Team

Analytics Engineering

Specialising in GA4 architecture, consent mode implementation, and multi-layer audit frameworks.

Share