Do Analytics Cookies Need Consent in the UK in 2026? The New PECR Exception Explained

UK websites no longer need prior consent for every analytics cookie or similar storage technology. Since the Data (Use and Access) Act 2025 changes took effect in February 2026, PECR includes a narrow statistical purposes exception. It can cover analytics used solely to create aggregate statistics about how a website or online service is used so that the operator can improve that same service.

But this is not a blanket exemption for Google Analytics, product analytics, session replay, conversion tracking or advertising measurement. The exception fails if the technology is also used to identify or profile people, retain individual-level data beyond what aggregation requires, measure ads, share conversion activity with advertising partners, or support other non-statistical purposes.

The practical rule is:

Aggregate service-improvement statistics only
+ clear information
+ simple free opt-out
+ no incompatible secondary purpose
= prior PECR consent may not be required

This guide explains how to test an analytics setup against that rule.

What changed in UK cookie law in 2026?

The Data (Use and Access) Act 2025 amended regulation 6 of the Privacy and Electronic Communications Regulations, commonly called PECR.

The UK Information Commissioner's Office now recognises five exceptions to the normal prohibition on storing information on, or accessing information from, a user's device without consent. One of the new exceptions is the statistical purposes exception, also called the analytics exception.

The ICO's current storage and access technologies guidance says the exception can apply when:

• you provide an information society service, such as a website or app;
• the sole purpose of the storage or access is collecting statistical information about use of that service;
• you use the statistics with a view to improving the service or website;
• you provide clear and comprehensive information about the analytics use; and
• users have a simple and free way to object.

The relevant statutory changes came into force on 5 February 2026, and the ICO published its final updated storage and access technologies guidance on 29 April 2026.

That means many older UK cookie articles are now incomplete.

Does this mean analytics cookies no longer need consent?

No. Some analytics can use the exception, but only if the entire purpose and implementation stay within its narrow conditions.

The ICO is explicit that the exception is about how a service is used, not who uses it.

A qualifying analytics design is aimed at producing aggregate answers such as:

• How many visits did this page receive?
• Which pages do visitors spend most time on?
• What is the average scroll depth?
• Which browser or device types are common?
• Which pages have high bounce or exit rates?
• How did visitors reach the service?
• Does version A or B of a page perform better?

The exception is not designed to answer questions such as:

• Which specific person visited these pages?
• Which user belongs to a high-value audience segment?
• Which visitor clicked an advert and later purchased?
• Which individual should see a personalised message?
• What did one identifiable visitor do during an entire session?
• How can this person be tracked across websites or apps?

If the analytics technology crosses that line, consent may still be required.

The eligibility test: five questions to ask

Before moving any analytics category from "consent required" to "statistical exception", test the implementation itself.

1. Is the purpose genuinely statistical?

The output should be statistical information about use of the service.

The ICO gives examples including total visits, page traffic, average scroll depth, device/browser information, referrer information, A/B testing, coarse non-identifying geolocation, loading speed, bounce rates and exit pages.

If the real purpose is advertising, personalisation, individual behavioural analysis or profiling, the statistical exception does not fit.

2. Is improvement of your own service the objective?

The exception is tied to collecting statistics with a view to improving the service or website.

A good internal purpose statement is specific:

Measure aggregate page and navigation performance
to improve site structure, content and loading speed.

A weak statement is:

Analytics, marketing and optimisation.

The second description mixes purposes and should trigger a deeper review.

3. Is the purpose exclusive?

The word sole matters.

If the same stored identifier or analytics event is also used for:

• advertising attribution;
• audience creation;
• cross-service tracking;
• personalised marketing;
• profiling;
• ad measurement; or
• sharing visitor/conversion activity with advertising partners,

you cannot simply label the whole technology "analytics" and rely on the exception.

Separate the purposes technically, not only in the privacy notice.

4. Does the system end in aggregate, non-identifying statistics?

The ICO says the resulting statistical information must be aggregate information that cannot be used to identify people.

Individual-level data may be collected temporarily when necessary to produce those statistics, but the organisation must not keep personal data longer than needed for aggregation.

That makes retention architecture part of the compliance design.

5. Can the user object easily and for free?

The exception is not "silent analytics".

The ICO requires clear information plus a simple means of objecting, free of charge.

If someone objects, the organisation must stop the relevant storage or access.

What counts as a simple means of objecting?

PECR does not prescribe one exact interface.

The ICO says an existing cookie/consent mechanism can be used. For example, a website could have a Statistical purposes or Analytics toggle enabled by default under the exception, while still allowing the user to switch it off at any time.

A practical design might be:

Privacy / Cookie settings
        ↓
Essential                 Always on
Statistical analytics     On by default
Advertising               Off until consent
Personalisation           Off until consent

The important distinction is that the statistical analytics toggle is not relying on consent if the exception applies. It is the mechanism by which the user can object.

If the user switches it off:

Object recorded
→ stop eligible analytics storage/access
→ keep preference so it remains off

The ICO also says organisations should not rely solely on browser settings as proof that a user has not objected.

Do you still need a cookie banner?

You still need transparency and an accessible objection mechanism, but the qualifying analytics category does not need the same prior opt-in consent as non-exempt advertising or tracking technologies.

That can change the design of a cookie banner.

For example, a site may be able to load qualifying statistical analytics before an affirmative "Accept" click while still requiring prior consent for advertising technologies.

Conceptually:

Before user choice
├── strictly necessary technologies
├── qualifying statistical analytics
└── no advertising / non-exempt tracking

After advertising consent
└── advertising and attribution technologies may load

This is only appropriate if the analytics implementation really satisfies the statistical exception.

Do not move a technology into the exempt category merely to improve consent rates.

Can a third-party analytics provider use the exception?

Yes, potentially. The ICO does not limit the statistical exception to first-party analytics software.

This is one of the most important corrections to older or oversimplified guidance.

The ICO says a website operator can:

• build its own analytics solution; or
• use a third-party analytics provider.

But the third party must only assist the operator in achieving the qualifying statistical purpose.

The ICO says, for the exception to apply, the provider must:

• act on your behalf;
• use the information to help improve your service;
• not link the information with other information it handles for other purposes; and
• fit the appropriate UK GDPR role, with the ICO stating that the provider must be a processor, not a joint controller, for this exception.

You must also tell users that you use the third party and explain what it does with the information.

So the correct rule is not:

Third-party analytics = consent required

and it is not:

Third-party analytics = automatically exempt

It is:

Third-party analytics
        ↓
Acts only on your behalf?
        ↓
Only service-improvement statistics?
        ↓
No linking to other provider data/purposes?
        ↓
Aggregate output + short individual-level retention?
        ↓
Potentially within statistical exception

Does Google Analytics 4 qualify for the UK exception?

The product name alone does not answer the question. You need to assess the exact configuration, contractual roles and data uses.

The ICO deliberately describes the conditions functionally rather than publishing a whitelist of analytics products.

For any analytics service, ask:

1. What information is stored on or read from the user's device?
2. What identifiers are generated?
3. Is individual activity retained, and for how long?
4. Does the provider use the information only on your behalf?
5. Can the provider link it with data from other services or accounts?
6. Is advertising functionality enabled?
7. Are conversions or visitor identifiers shared with advertising systems?
8. Is the output used to profile or target individual users?
9. Can users object easily?
10. Does your UK GDPR controller/processor analysis support the arrangement?

If any answer introduces advertising, cross-service linking, profiling, independent provider purposes or unnecessary individual-level retention, the statistical exception may no longer be available.

Do not make the compliance decision from a default installation tutorial.

Analytics activity: likely exception or consent?

The ICO's final guidance provides enough examples to build a useful screening table.

"Likely" still assumes the other requirements are met, including sole purpose, aggregation, retention, transparency and opt-out.

Session replay is not the same as aggregate UX analytics

This distinction matters for product teams.

You may want to understand:

Where do users struggle with this form?

A qualifying aggregate method might measure:

• field error rates;
• average completion time;
• average scroll depth;
• percentage reaching each form step; or
• aggregate drop-off points.

A session replay system that records one visitor's detailed actions creates a different dataset.

The ICO specifically lists logs or recordings of individual visitors and the actions they took as outside the statistical purposes exception, unless another exception such as security applies to the particular use.

So "UX analytics" is not one legal category. The implementation matters.

Advertising measurement remains consent-based

The new statistical exception does not cover online advertising purposes.

The ICO says advertising-related storage and access still requires consent. Its guidance includes:

• ad measurement and performance;
• linking website conversions to advertising partners;
• advertising attribution;
• behavioural advertising;
• cross-site tracking; and
• profiling for advertising.

This creates a useful technical boundary.

A site may have:

Aggregate website analytics
→ statistical exception may apply

while simultaneously having:

Meta Pixel
Google Ads conversion tracking
remarketing tags
cross-site attribution
→ prior consent required

Do not merge those into one "Analytics" category in the tag manager.

Separate statistical analytics from advertising technically

A privacy notice cannot repair an architecture where the same event stream feeds both purposes.

A better analytics design separates destinations and triggers.

For example:

Page view
   ├── Aggregate analytics endpoint
   │      └── service improvement only
   │
   └── Advertising conversion endpoint
          └── blocked until advertising consent

Likewise in a tag manager:

Statistical Analytics
Trigger: allowed unless user objects

Advertising / Remarketing
Trigger: only after valid consent

The categories should have distinct:

• purposes;
• destinations;
• identifiers;
• retention rules;
• trigger conditions; and
• user controls.

This is easier to audit and much harder to accidentally misuse.

A practical consent-manager architecture

A UK-focused consent manager can model more than a binary "accepted cookies" state.

For example:

type PrivacyPreferences = {
  statisticalAnalyticsObjected: boolean
  advertisingConsent: boolean
  personalisationConsent: boolean
}

Then:

const allowStatisticalAnalytics =
  !preferences.statisticalAnalyticsObjected

const allowAdvertising =
  preferences.advertisingConsent

This is only an architectural example. The real implementation must match the technologies and legal basis your organisation actually uses.

The point is that an objection and a consent are different legal signals.

Do not store both as one boolean called:

cookiesAccepted

when the site uses a mixture of exceptions and consent.

What should happen when someone objects?

The website should stop eligible statistical storage/access promptly and remember the preference.

A robust flow is:

User selects "Statistical analytics: Off"
        ↓
Preference stored
        ↓
Analytics library prevented from initialising
        ↓
Existing analytics storage cleaned up where appropriate
        ↓
Future pages respect the preference

If the analytics vendor has already been initialised before the preference is read, the opt-out can become cosmetic.

Test the actual network and storage behaviour.

What should the privacy or cookie notice say?

The ICO requires clear and comprehensive information.

For statistical analytics, a useful notice should explain:

• what the analytics does;
• what categories of information it uses;
• that the purpose is aggregate measurement and service improvement;
• whether a third-party provider is used;
• what that provider does;
• how long individual-level information is kept before aggregation where relevant;
• how to object; and
• where to change the preference later.

Avoid vague wording such as:

We use cookies to improve your experience.

That tells the user almost nothing about the storage, purpose or objection mechanism.

PECR exemption does not remove UK GDPR obligations

This is another common mistake.

PECR answers whether consent is required for storing information on or accessing information from a device.

UK GDPR governs processing of personal data.

If the statistical analytics workflow involves personal data before aggregation, the ICO says the organisation must also comply with UK GDPR.

That can include:

• identifying a lawful basis;
• transparency;
• data minimisation;
• purpose limitation;
• processor contracts;
• international transfer requirements;
• security;
• retention controls; and
• data protection by design and default.

So:

PECR statistical exception applies

does not mean:

UK GDPR no longer applies

The two assessments should be documented separately.

How long can individual-level analytics data be retained?

PECR and UK GDPR do not give one universal number for this statistical exception.

The ICO's guidance says organisations should only retain individual-level information for as long as necessary for the aggregation process.

It gives an example that daily aggregation may be appropriate for some services and more frequent aggregation may suit very high-volume services.

The correct design is therefore:

Collect minimum event data
        ↓
Aggregate on a justified schedule
        ↓
Delete / irreversibly transform unnecessary individual-level data
        ↓
Keep aggregate statistics

Do not choose a 13-month user-level retention period merely because an analytics product offers it as a default.

A privacy-oriented analytics data model

A qualifying statistical system does not need to know everything about each visitor.

For a content site, the useful raw event may be as small as:

{
  "page": "/services/web-app-development",
  "event": "page_view",
  "deviceClass": "mobile",
  "referrerClass": "organic-search",
  "timestampBucket": "2026-09-07T14:00"
}

The system can then aggregate:

page
+ hour/day
+ device class
+ source class
→ counts / rates

without building a persistent visitor dossier.

Avoid adding a stable visitor ID unless the statistical requirement genuinely needs it and the whole design still fits the exception.

The exception rewards an architecture that collects less.

What about authenticated SaaS product analytics?

Authenticated product analytics can be harder to fit within the statistical exception because product teams often want individual-level histories:

User 1842
→ clicked feature A
→ used feature B
→ returned 9 days later
→ belongs to account X

That is no longer obviously just aggregate statistics about service use.

A SaaS company should separate questions.

Aggregate product improvement

What percentage of accounts use Feature A?
Where do users abandon onboarding?
What is the median time to complete workflow X?

A carefully designed aggregate system may be able to fit the statistical purpose.

Customer-success or behavioural profile

Which named customer has stopped using the product?
Who should receive an activation email?
Which users are likely to churn?

That is an individual/account-level operational use and should not be smuggled into the statistical exception.

The same analytics vendor can support both workflows, which is exactly why configuration and data separation matter.

What about A/B testing?

The ICO explicitly lists A/B testing as an activity that can fit the statistical purposes exception.

The qualifying use is statistical comparison of how users interact with different versions of a website or sections of it.

But the rest of the conditions still apply.

For example:

Randomly assign version A/B
→ measure aggregate completion rate
→ improve page

is different from:

Build behavioural profile
→ predict individual preference
→ permanently personalise content

The latter introduces profiling/personalisation beyond a simple aggregate experiment.

What about referrer data and campaign measurement?

The ICO lists information about how users reached your service, including referrer URLs or email campaigns, as an example that can fit the statistical exception.

But do not confuse aggregate acquisition statistics with advertising attribution.

Potentially qualifying:

Organic search: 41%
Email newsletter: 18%
Direct: 27%
Other: 14%

Not qualifying under the statistical exception:

Visitor abc123 clicked Ad X
→ purchased Product Y
→ conversion sent back to advertising network

The second use links an individual visitor's site activity to advertising.

What about coarse geolocation?

The ICO says coarse geolocation, such as city or region level, can fit where it does not allow people to be identified.

That is useful for performance and content planning.

For example:

Region-level traffic
→ identify where mobile performance is poor
→ improve CDN / page delivery

The exception is not a licence to turn precise location into a persistent behavioural identifier.

Use the least precise geography that satisfies the statistical question.

How should a UK business audit its current analytics stack?

Start with network reality rather than the cookie-policy text.

Step 1: inventory technologies

Include:

• first-party cookies;
• third-party cookies;
• local storage;
• tracking pixels;
• JavaScript SDKs;
• tag-manager tags;
• link decoration;
• device/browser identifiers;
• session replay;
• server-side tagging that still relies on device storage/access; and
• embedded services.

The ICO's guidance covers storage and access technologies broadly, not only files literally named "cookies".

Step 2: record each purpose

For every technology, write one or more precise purposes.

Bad:

marketing / analytics

Better:

aggregate page performance
advertising conversion attribution
fraud prevention
remember language preference

Step 3: map each purpose to PECR

Possible outcomes include:

strictly necessary exception
statistical purposes exception
appearance exception
consent required

Step 4: split multi-purpose technologies

If one tool mixes eligible statistics with advertising or profiling, either:

• configure the non-exempt purpose off;
• split the implementation; or
• keep the technology behind prior consent.

Step 5: assess UK GDPR separately

For any personal data, document lawful basis, processor roles, retention, transfers and transparency.

Step 6: test the user controls

Verify with developer tools that:

• non-exempt tags do not fire before consent;
• statistical analytics stops when the user objects;
• preferences survive navigation/reload as intended; and
• changing a preference actually changes network/storage behaviour.

A decision tree for each analytics tool

Use this per technology, not per vendor brand.

Does it store/access information on the user's device?
        ↓ yes
Is the sole purpose aggregate statistics about use
to improve this same service/site?
        ↓ yes
Does it avoid identifying, tracking, profiling or deciding
about individuals/groups?
        ↓ yes
Is individual-level data kept only as long as needed
to create aggregate statistics?
        ↓ yes
If third party: does it act only on your behalf,
without linking the data to other information/purposes?
        ↓ yes
Do users receive clear information and a simple free opt-out?
        ↓ yes
Statistical purposes exception may apply
        ↓
Still assess UK GDPR if personal data is processed

At any "no", investigate another exception or obtain valid consent before storage/access.

A useful implementation matrix for UK websites

This is a screening framework, not a substitute for reviewing your exact implementation.

Common mistakes after the 2026 change

Mistake 1: "Analytics cookies are exempt now"

Only narrowly defined statistical analytics is exempt.

Mistake 2: "Only first-party analytics can qualify"

The ICO expressly permits third-party analytics where the provider acts only on your behalf for the qualifying purpose and meets the other conditions.

Mistake 3: "If PECR consent is not required, privacy law is finished"

UK GDPR still applies where personal data is processed.

Mistake 4: Leaving advertising features enabled inside the analytics product

A mixed statistical + advertising purpose can destroy the exception.

Mistake 5: Keeping raw visitor histories indefinitely

The ICO says individual-level data should not be retained longer than necessary for aggregation.

Mistake 6: Hiding the opt-out deep in a privacy policy

The exception requires a simple, free means of objecting.

Mistake 7: Treating the cookie banner as the compliance system

The real system is the tags, SDKs, storage, destinations, retention and data-use contracts behind the banner.

A migration plan from consent-only analytics to the statistical exception

If a UK website currently blocks all analytics until consent, do not simply change the banner switch to "on".

Use this sequence.

1. Define the statistical metrics you genuinely need

For example:

• aggregate visits;
• conversion through an internal non-advertising funnel;
• average page engagement;
• device/browser mix;
• performance metrics;
• aggregate acquisition sources.

2. Remove incompatible purposes

Disable or separate:

• advertising integration;
• remarketing;
• cross-service identifiers;
• individual profiles;
• session replay;
• ad conversion sharing;
• behavioural personalisation.

3. Review the analytics provider relationship

Confirm what the provider does with the data and whether it acts only on your behalf for the exempt workflow.

4. Minimise identifiers and retention

Reduce raw event retention to what your aggregation process actually needs.

5. Add the objection control

Make the analytics preference easy to find and change.

6. Update transparency

Explain the statistical analytics, provider, purpose and opt-out.

7. Test with browser developer tools

Confirm actual cookies, local storage, requests and tag firing match the policy.

8. Record the decision

Keep a short internal assessment showing why each condition is satisfied.

That record is far more useful than a screenshot of a green consent-management dashboard.

Does the new exception mean cookie banners will disappear?

Probably not for many commercial websites.

A typical marketing website still uses technologies for:

• paid advertising;
• conversion tracking;
• embedded media;
• social media;
• personalisation;
• A/B testing;
• fraud/security;
• analytics.

Some of those can use exceptions. Others still require prior consent.

The likely change is not "no cookie controls".

It is a more nuanced design:

Necessary
→ exception

Qualifying statistical analytics
→ exception + opt-out

Qualifying appearance/preferences
→ exception + opt-out

Advertising / non-exempt tracking
→ prior consent

That can reduce unnecessary consent friction while preserving control for higher-risk tracking.

Why this matters for SEO and conversion analysis

Historically, UK sites that blocked all analytics until consent often measured only the users who opted in.

The new exception creates a path to broader aggregate service-performance measurement without converting that measurement into individual tracking.

For SEO and website optimisation, useful aggregate metrics can include:

• landing-page traffic;
• referrer categories;
• device/browser distribution;
• page speed;
• bounce/exit behaviour;
• average page interaction;
• A/B test results.

That can support decisions about site architecture and content while keeping advertising attribution behind consent.

For organisations reviewing SEO and growth optimisation, the valuable question is no longer merely "which analytics platform should we install?" It is "what minimum data do we need to improve the website, and which purposes genuinely require user-level tracking?"

A 2026 UK analytics compliance checklist

• □Every storage/access technology is inventoried.
• □Each technology has a precise purpose.
• □Statistical analytics is separated from advertising and profiling.
• □The statistical purpose is solely about service/site use and improvement.
• □Output is aggregate and non-identifying.
• □Individual-level retention is limited to what aggregation requires.
• □Third-party analytics providers are assessed for role and secondary use.
• □Third-party providers do not link exempt data with other data they handle.
• □Users receive clear and comprehensive information.
• □A simple, free analytics objection control is available.
• □The website actually stops exempt analytics after an objection.
• □Non-exempt advertising/tracking remains blocked until consent.
• □UK GDPR lawful basis, contracts, transfers and retention are separately assessed.
• □Consent-manager behaviour is tested at the network/storage level.
• □The compliance rationale is documented and reviewed when analytics configuration changes.

FAQs

Do analytics cookies need consent in the UK in 2026?

Not always. The new PECR statistical purposes exception can allow storage/access without prior consent when the sole purpose is producing aggregate statistics about use of the website or service to improve it. The organisation must still provide clear information and a simple free way to object.

Can third-party analytics be used without consent in the UK?

Potentially, yes. The ICO says a third-party analytics provider can be used under the statistical exception if it acts on your behalf, uses the information only to help improve your service, does not link it with other information for other purposes, and the other conditions are satisfied.

Does Google Analytics automatically qualify for the exception?

No analytics product qualifies merely because of its name. Assess the actual configuration, provider role, identifiers, retention, advertising integrations, data linking and purposes. If the setup supports advertising, profiling, cross-service tracking or other incompatible purposes, consent may still be required.

Does session replay qualify as consent-free statistical analytics?

Generally no under the statistical purposes exception. The ICO specifically identifies logs or recordings of individual visitors and their actions as outside this exception, unless another applicable exception covers the particular purpose.

Can advertising conversion tracking use the analytics exception?

No. The ICO says online advertising purposes remain subject to consent. Connecting visitor activity or purchases to advertising partners is specifically outside the statistical purposes exception.

Do I need an opt-out if I rely on the statistical exception?

Yes. The user must have a simple and free means to object. If they object, the relevant storage or access must stop.

Conclusion

The UK's 2026 PECR change creates a useful middle ground between "track everyone" and "measure nothing until a user accepts every cookie".

A compliant statistical analytics design looks more like this:

Minimum data
→ aggregate measurement
→ improve the same service
→ short raw-data retention
→ no profiling or advertising reuse
→ clear notice
→ easy opt-out

The key word is statistical. The exception is designed for understanding service usage, not building persistent visitor identities.

For many UK businesses, the best architecture is therefore to split measurement into two lanes:

Aggregate service analytics
→ statistical exception may apply

Advertising / attribution / individual tracking
→ prior consent

If your website currently mixes analytics, ad tags and product tracking in one consent category, the 2026 change is a good reason to audit the actual data flows rather than merely rewrite the cookie banner.

If you need to redesign the measurement layer around privacy, search performance and reliable web analytics, Softotic's SEO and growth optimisation service can help with the measurement strategy, while web application development can implement the consent, tag-loading and analytics architecture.

Sources and references

• ICO: What are the exceptions? — Storage and access technologies
• ICO: Guidance on the use of storage and access technologies
• ICO: How do the PECR rules relate to the UK GDPR?
• ICO: How do the rules apply to online advertising?
• GOV.UK: Data (Use and Access) Act factsheet — PECR
• legislation.gov.uk: Data (Use and Access) Act 2025 explanatory notes