First-Party Data: Stop renting customer insights and start owning them

---

Why Did I Have to Update Something I Already Published?

I published a piece on first-party data that stated Chrome's Privacy Sandbox was degrading attribution in the same way Safari and Firefox do. That claim is no longer accurate, and I'm correcting it directly here rather than quietly editing the original and hoping nobody notices.

In April 2025, Google abandoned forced third-party cookie deprecation in Chrome. Google replaced the Privacy Sandbox deprecation timeline with user-choice controls. Chrome still allows third-party cookies for users who don't actively change their settings.

Safari has blocked third-party cookies by default since 2020. Firefox since 2019. Those facts remain accurate. But Chrome, which holds roughly 66.8% of global browser share, is no longer on a forced deprecation path. Attribution degradation from Chrome is now driven by consent rejection rates, not a blanket browser block. That is a meaningful distinction, and one I've seen cause real confusion among clients who assumed the Chrome reversal reduced urgency.

The rest of this post builds on the original argument. It doesn't contradict it. The case for owning your first-party data has only strengthened since I wrote the original piece, because of what the ICO finalised in April 2026, what the Data (Use and Access) Act 2025 did to the penalty structure, and what those two things together mean for any business running affiliate tracking pixels without a consent gate.

When the evidence changes, you update the record. That's what this is.

---

What Does 'Renting' Customer Data Actually Mean in 2026?

Renting customer data means you own the report, not the signal, and that distinction has material consequences for every campaign you run. When you fire a Meta pixel or a Google tag in the browser, the platform collects an event on its own infrastructure and reflects a processed, modelled version back to you. You own the report. You do not own the underlying signal.

The distinction between owning the signal and owning the report matters for three reasons.

First, the platform's picture of your customers is structurally incomplete before any browser blocking happens. Ethyca processes more than 744 million preferences annually across 200-plus brands globally, and their data shows 50–60% of users opt out entirely when given a genuine rejection option on a consent banner. The majority of your potential customers are invisible to the platform before a single ad blocker or browser restriction enters the picture.

Second, even for consenting users, pixel-only setups lose roughly 30–40% of events. That is Meta's own vendor-stated benchmark, not independently audited, but it gives you a floor. In my experience auditing tracking setups for UK businesses, that loss is almost always higher than the business owner expects, and it compounds silently. You are working from an incomplete dataset even when everything is supposedly working.

Third, and this is the angle most people miss: under the US CLOUD Act, American authorities can legally compel US-owned platforms and SaaS tools to produce data regardless of where it is physically stored. "Your" customer data sitting in a US-owned analytics tool or CRM is subject to foreign surveillance law regardless of which data centre it lives in. I wrote about this in more depth when I explained why I'm switching from HubSpot to Twenty, the data residency risk isn't about server location, it's about corporate ownership and jurisdiction. An EU-hosted HubSpot instance is still a US-owned data processor.

Data you rent gets processed, modelled, and returned to you on the platform's terms. Data you own sits in infrastructure you control, with consent records you hold, under a legal jurisdiction you've consciously chosen.

---

What Are the Three Consent Pillars Most Businesses Collapse Into One?

Most businesses collapse their first-party data into a single consent bucket, and that conflation is where both the regulatory exposure and the signal loss originate. First-party data is not a single bucket. It is three legally and technically distinct systems, and collapsing any two of them creates either regulatory exposure or signal loss.

Pillar 1: Enhanced Conversions, the measurement layer

Enhanced Conversions is a consent-gated measurement system that fires only when ad_storage consent is granted. The architecture I recommend hashes PII (personally identifiable information, such as names, email addresses, and phone numbers) before it leaves the data layer, not because the standard Google setup is illegal, but as a defence-in-depth measure. If something upstream misfires, if a tag fires out of sequence, if a developer makes a configuration error, the hashed data is structurally less dangerous than clear-text PII. Defence-in-depth means the architecture holds even when individual components fail.

The June 2026 removal of the Google Signals safety net makes a correctly wired ad_storage signal non-negotiable now. If your Consent Mode configuration was wrong before, Google Signals was quietly papering over it. That paper is gone. I covered what this means in detail in Google Analytics was quietly fixing your broken consent setup. Until now.

Pillar 2: Customer Match, the audience layer

Customer Match requires explicit, separate consent for the specific purpose of audience matching, and in my experience, this is the pillar most businesses get wrong. A user who accepted ad_storage on your consent banner has consented to measurement. They have not consented to being uploaded to a Customer Match list and matched against Google's identity graph. That distinction is both a legal requirement and a strategic one.

Legally, sending Customer Match data on measurement-only consent is a GDPR exposure. Strategically, a consent-gated Customer Match list built from your own CRM is the signal architecture moat. It compounds over time. Every customer who opts in explicitly makes your Google AI-driven campaigns work harder than competitors whose audience signals are inferred by the platform rather than sourced from the business.

I wrote about why this matters for campaign performance in Stop working in your Google Ads. Start working on them., a Customer Match list built on your first-party CRM data is one of the five core infrastructure pillars that separates accounts operating with Google's AI from accounts fighting it.

Pillar 3: Email, the owned channel

Email is a separate opt-in system governed by PECR independently of GDPR consent. Email is not a subset of marketing consent, is not covered by your ad_storage signal, and requires its own explicit opt-in, managed separately from both your measurement consent and your Customer Match consent.

The trap I see regularly is businesses that gate Customer Match uploads behind the same consent check they use for email, because "it's all marketing." The result is a Customer Match list that barely grows because the consent event fires rarely. Or the reverse: a business that uploads email subscribers to Customer Match without separate explicit consent for audience matching, because both are "opted in to marketing."

Both are errors. Keep the three pillars separate in your consent architecture and your CRM records. The legal exposure and the signal loss both come from conflation.

---

What Did the ICO's April 2026 Guidance Actually Change?

The ICO's April 2026 guidance materially expanded the scope of what requires consent under PECR, and several standard configurations that businesses assumed were covered are no longer compliant. The ICO finalised its guidance on storage and access technologies on 29 April 2026, following two public consultations. Four specific changes are relevant to your business.

Scope expansion. PECR Regulation 6 now explicitly covers tracking pixels, device fingerprinting, link decoration, web storage, and scripts/tags, not just cookies. If your consent banner was designed with cookies as its mental model, it needs to be reassessed against this wider scope.

Affiliate pixels now require consent. This is the one most businesses running performance programmes haven't acted on yet. The ICO has, for the first time, stated expressly in writing that tracking pixels used for affiliate marketing require consent. If your affiliate programme uses pixels to attribute commissions and those pixels fire without a consent gate, you are non-compliant as of 29 April 2026. This isn't a grey area interpretation. It's a direct, written regulatory statement.

The analytics exception is sole-purpose only. The anonymised statistical purposes exception under PECR only applies where the storage or access technology is used for that purpose alone. If your analytics tag simultaneously feeds your ad platform, which is the default configuration for a linked GA4 and Google Ads account, you cannot claim the analytics exception for it. This affects a large number of standard configurations that businesses assumed were covered.

"Strictly necessary" is assessed from the user's perspective. You cannot argue that a tracking script is strictly necessary because it funds your service. The ICO's position is clear: this exception is assessed from the user's point of view, not the organisation's. If the user doesn't need the tracking for the service to function for them, it isn't strictly necessary.

One forward-looking note: the ICO has signalled it may submit evidence to the UK Government on potential privacy-preserving advertising exemptions that could eventually not require consent. As of July 2026, no statutory change has been made. Do not build your compliance position on an exemption that hasn't been enacted.

---

What Does the DUAA 2025 Penalty Uplift Mean for a Business Your Size?

The Data (Use and Access) Act 2025 penalty structure changes the risk calculus for small businesses in ways that the headline figure obscures, the number that matters for your business is 4% of your annual turnover, not £17.5 million. The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025. Under DUAA 2025, maximum PECR penalties increased to £17.5 million or 4% of annual worldwide turnover, whichever is higher.

The £17.5 million headline figure sounds like enterprise risk. Do the maths for a smaller business. At £2 million annual turnover, the operative cap is 4%, which works out at £80,000. That is a company-threatening fine for a non-deliberate tracking misconfiguration, not a headline number reserved for corporations.

Between 2019 and September 2025, the ICO imposed 119 penalty notices under PECR totalling approximately £10.5 million. The Capita penalty in October 2025, £14 million for inadequate cybersecurity enabling a ransomware attack affecting 6.6 million data subjects, shows the ICO is prepared to use the new powers at scale.

To be direct about enforcement: the ICO's compliance focus has been on the top 1,000 UK websites for cookie consent. Smaller businesses are not the primary current enforcement target. But the penalty regime applies in full regardless of size, and the ICO acts on complaints. The risk calculus has changed materially since the old £500,000 cap.

There's a parallel risk worth naming alongside the compliance one. The Cyber Security Breaches Survey 2025 found that 43% of UK businesses experienced a cyber security breach or attack in the past twelve months. The data architecture you're building for compliance is also the architecture you're defending against breach. These aren't separate conversations.

---

What Does Server-Side Tracking Fix, and What Doesn't It Touch?

Server-side tracking is a signal accuracy solution for users who have already consented, it does not resolve upstream consent failures, and treating it as a compliance tool is one of the most common and costly mistakes I see in tracking setups. The distinction matters more than most setup guides acknowledge.

What server-side tracking fixes: event loss for consenting users. Adding Meta's Conversions API can drop event loss from 30–40% down to roughly 5%, that's Meta's own vendor-stated benchmark, not independently audited, but the directional improvement is real. Cookie lifespan is another genuine fix: Safari caps most first-party cookies set via HTTP at 7 days in practice, regardless of the 400-day headline maximum. A server-set cookie via your own domain survives this restriction. Google Tag Gateway, which became generally available in May 2025, serves Google tag scripts from your own domain, making them harder for ad blockers to intercept.

What server-side tracking doesn't fix: the 50–60% of users who reject consent. No server-side setup reaches them legally. A misconfigured consent gate also isn't fixed by moving the tag server-side, if ad_storage never fires correctly, the server-side tag has nothing clean to send upstream. And the April 2026 affiliate pixel ruling applies regardless of where the pixel is hosted. Moving a pixel server-side does not make it consent-exempt.

On infrastructure costs: a managed server-side GTM setup via a third-party host starts around $20 per month. A self-managed Google Cloud Run configuration for a minimum three-server production setup runs roughly $90–$135 per month (figures from Digital Applied's 2026 server-side playbook). These are not large numbers, but they're worth knowing before the conversation about whether to self-host or use a managed service.

For how modelled conversions fill the attribution gap for non-consenting users, the GA4 attribution models piece covers the mechanics of how data-driven attribution operates across the users your measurement layer can and can't see.

---

Why Does the Data You Own Compound While the Data You Rent Resets?

Owned first-party data compounds because it accumulates in infrastructure you control and feeds better signals into AI-driven campaigns with each passing month, rented platform data resets whenever your spend pauses or the platform's model shifts. A consent-gated Customer Match list built from your own CRM grows every month. It feeds Google's AI-driven campaign types with better signal than a competitor using platform-inferred audiences. The performance gap between those two inputs widens over time, not because one business is spending more, but because one business has a better signal.

In my experience running these architectures, the Customer Match list is also the switching cost: if you part ways with an agency that built it on your behalf using your data, you take the list with you. That's what data ownership means in practice.

A Deloitte study, cited in StackAdapt's first-party data report, puts numbers on the personalisation side: 80% of consumers prefer brands that offer personalised experiences, and those customers spend 50% more. Those figures are global consumer data, not UK-specific, but the directional case holds. A first-party CRM with clean consent records gives you the personalisation layer. A platform-rented audience gives you a model of your customers that resets every time ad spend pauses.

EMARKETER's August 2025 data shows 55.1% of marketers worldwide reporting that first-party data is much more important today than two years ago, with 70% of B2B marketers increasing investment in it. The businesses driving that shift aren't responding to a compliance nudge, they're responding to a compounding return that platform-rented data structurally cannot replicate.

---

What Should You Actually Do, and in What Order?

The correct order is compliance prerequisites first, performance infrastructure second, businesses that skip to server-side tagging without fixing their consent architecture have better plumbing for a leaking system. Steps 1–3 are compliance prerequisites. Steps 4–6 are performance infrastructure.

Step 1: Audit your consent banner against the ICO's April 2026 guidance. A compliant banner now covers pixels, scripts, and web storage, not just cookies, and offers a genuine rejection option before any tag fires. Check whether your banner covers pixels, scripts, and web storage, not just cookies. Check whether it offers a genuine rejection option, not a pre-ticked accept. Verify it fires consent signals before any tag fires. If you're running affiliate tracking pixels and they fire before consent is granted, that's a specific non-compliance you need to fix now.

Step 2: Fix your Consent Mode configuration before you touch server-side. A correct ad_storage and analytics_storage signal is the prerequisite for everything downstream, and without it, everything you build on top is unreliable. The June 2026 removal of the Google Signals safety net means a misconfigured Consent Mode is no longer papered over. Fix the foundation before you build on it.

Step 3: Audit every tracking pixel in your affiliate programme. Under the April 2026 ICO guidance, each affiliate pixel requires a consent gate, this is finalised guidance, not implementation advice, and it applies from 29 April 2026. This isn't gradual implementation guidance; the guidance is finalised and in force.

Step 4: Implement server-side tagging for event accuracy on consenting users. Once steps 1–3 are solid, server-side tagging improves signal quality for the users you can legally reach. The event loss reduction is real and it feeds cleaner data into your bidding and attribution.

Step 5: Build your Customer Match infrastructure separately. Explicit consent, separate from measurement consent, with a clear CRM-sourced upload process. This is the long-term signal moat, the asset that compounds while competitors rely on platform-inferred audiences.

Step 6: Keep email as a third, separate opt-in. Email requires its own consent record, governed by PECR on its own terms, and must remain separate from both measurement consent and Customer Match consent. Don't collapse it into either of the other two pillars.

The architecture I've described, consent-gated measurement, explicit-consent audience matching, and separately governed email, isn't complex. But it does require treating three distinct systems as three distinct systems, not one marketing consent bucket. Most of the risk, and most of the signal loss, lives in the conflation.

---