In July 2020 the CJEU handed down Schrems II (C-311/18). Privacy Shield, which had been the default mechanism for EU-US data transfers since 2016, was invalidated. Overnight, every marketing team running a Meta Pixel or a Google Tag was either transferring data without a valid legal mechanism, scrambling to execute Standard Contractual Clauses, or relying on the hopeful interpretation that the GDPR somehow didn't reach a JavaScript snippet in a user's browser.
Three years of supplementary measures guidance, Transfer Impact Assessment templates, and supervisory authority enforcement actions followed. Then, in July 2023, the European Commission adopted the EU-US Data Privacy Framework adequacy decision, restoring adequacy for DPF-certified US companies. Meta, Google, Salesforce, and HubSpot are all on the list.
The question for marketing and compliance teams in 2026 is not "does the DPF exist" — it does. The question is what it actually covers, where the residual risk sits, and what a transfer architecture that holds up under a potential DPF challenge looks like in practice.
TL;DR#
- Privacy Shield (2016) was invalidated by Schrems II in July 2020. SCCs plus supplementary measures covered the gap from 2020 to 2023.
- The EU-US Data Privacy Framework (July 2023) is the current adequacy decision. DPF-certified companies' transfers benefit from adequacy without requiring SCCs or a TIA.
- Client-side pixels to DPF-certified vendors are legally defensible in 2026, provided the receiving entity is certified, the data subject has been informed, and ePrivacy consent is in place where required.
- The DPF is the subject of anticipated legal challenge. Dual-mode tracking — client-side under DPF coverage, server-side forwarding from EU infrastructure as a structural fallback — is the architecture that survives a third Schrems judgment.
What Schrems II actually said#
The judgment is worth reading directly rather than via a summary. The operative reasoning is in paragraphs 180–202. The core finding is not that US data transfers are per se illegal. It is that US surveillance law — specifically FISA 702 and Executive Order 12333 — gives US intelligence agencies access to personal data of EU subjects in a way that provides no effective remedy to those subjects under GDPR Articles 77–79.
GDPR Article 44 prohibits transfers to third countries unless one of the Chapter V mechanisms applies. Privacy Shield was an adequacy decision under Article 45. The Court's finding that Privacy Shield was invalid therefore stripped the adequacy basis from every transfer relying on it.
Standard Contractual Clauses were not invalidated — but the Court held in the same judgment that SCCs are not automatically sufficient for transfers to the US. The controller or processor using SCCs must verify, on a case-by-case basis, whether the destination country's legal system would prevent the SCC-level protections from functioning in practice. That requirement is the Transfer Impact Assessment: a documented assessment of US surveillance law and its effect on the transferred data.
The EDPB Recommendations 01/2020 on supplementary measures operationalised this requirement. They set out a six-step process and a catalogue of supplementary measures — technical (encryption, pseudonymisation), contractual, and organisational — that controllers should assess when relying on SCCs for US transfers. For standard marketing pixels, most of those technical measures were practically impossible: you cannot meaningfully encrypt a payload whose purpose is to let Meta attribute a conversion to an ad impression.
This is the architecture that marketing teams lived with from July 2020 to July 2023. SCCs were signed. TIAs were attempted. DPAs in Austria, France, and Italy found specific implementations — Google Analytics chief among them — to be non-compliant despite the SCCs, because the supplementary measures were insufficient.
What changed with the Data Privacy Framework#
The EU-US Data Privacy Framework (Commission Decision (EU) 2023/1795, effective 10 July 2023) is an adequacy decision under GDPR Article 45. Its legal premise is that the US legal framework — as amended by President Biden's Executive Order 14086 and the subsequent rules establishing the Data Protection Review Court — provides an essentially equivalent level of protection to that guaranteed in the EU.
For practical purposes, the DPF means this: transfers to DPF-certified US companies benefit from adequacy. You do not need SCCs. You do not need a TIA. You need to verify that the receiving entity is on the DPF participant list, which is publicly searchable and updated in near real-time.
Meta Platforms, Inc. is DPF-certified. Google LLC is DPF-certified. Salesforce, Inc. is DPF-certified. HubSpot, Inc. is DPF-certified. For these vendors, transfers of EU personal data in connection with advertising and analytics are covered by adequacy as of July 2023, provided they are receiving the data in their DPF-certified capacity.
Two clarifications matter. First, DPF certification is voluntary. Not every US company that processes EU data has self-certified. The participant list is the authoritative source; do not assume certification. Second, DPF certification covers specific activities. A company that is DPF-certified may process your pixel data under the certified scope or under a different legal basis depending on the data type and purpose. For standard marketing attribution via pixel, the DPF scope covers it.
What this means for marketing pixels in practice#
With DPF coverage in place, the legal posture for client-side marketing pixels to certified vendors looks like this.
The client-side Meta Pixel, when firing to Meta Platforms Inc. (DPF-certified), is a transfer to an adequate destination. The transfer mechanism is the DPF adequacy decision, not SCCs. Your Article 30 RoPA entry for the Meta Pixel documents the transfer basis as "adequacy decision (DPF)" rather than "SCCs." The TIA that would have been required under the SCC path is not required.
The same analysis applies to Google Tag Manager and GA4 firing to Google LLC, HubSpot's tracking pixel firing to HubSpot Inc., and Salesforce Marketing Cloud's attribution events firing to Salesforce Inc.
However, adequacy is one layer of a multi-layer compliance picture. Three additional requirements must be in place before this posture holds.
ePrivacy consent. The ePrivacy Directive 2002/58/EC, Article 5(3), requires consent before any non-essential storage or access on the user's terminal equipment. Marketing pixels are non-essential. Consent banners must be specific to the pixel in question, freely given, and revocable. The fact that the transfer destination is DPF-adequate does not affect the ePrivacy consent requirement. These are separate legal instruments.
Transparency to data subjects. GDPR Article 13 requires the controller to inform data subjects, at the time of collection, about the recipients of their data and any transfers to third countries. The DPF does not change this transparency obligation. If your privacy notice says "we use Meta Pixel" and "transfers to the US are covered by adequacy," that is sufficient. If it does not mention the US transfer at all, the adequacy decision does not cure the Article 13 gap.
Article 28 DPA with the vendor. The pixel vendor remains a processor under GDPR Article 28. The DPF covers the transfer mechanism; it does not substitute for the DPA. Meta's, Google's, and HubSpot's standard data processing terms are the Article 28 instruments for the pixel relationship. Ensure they are executed.
The remaining risks#
The DPF is not a permanent settlement. It is an adequacy decision that can be challenged before the CJEU by any Member State court, the European Parliament, or any national supervisory authority. Max Schrems and NOYB have publicly signalled intent to challenge the DPF — a potential Schrems III. The legal theory for that challenge is similar to Schrems II: that EO 14086 and the Data Protection Review Court do not, in substance, provide remedies equivalent to those available under EU law.
Supervisory authorities have not waited for a CJEU ruling. The Austrian DSB ruled on a Google Analytics implementation as recently as 2022 — before the DPF was in force — that the transfer was unlawful because the SCCs and supplementary measures in place were insufficient. The French CNIL and the Italian Garante issued similar findings. These rulings were under the pre-DPF regime, but they establish a supervisory pattern: DPAs are willing to examine the technical mechanics of pixel-based transfers, not just the contractual paperwork. A future ruling under a post-DPF challenge would likely examine whether the legal order EO 14086 established genuinely limits FISA 702 access to certified companies' stored data.
The specific concern with tracking pixels goes beyond the legal mechanism. A client-side pixel does more than transfer data to a certified company. It executes JavaScript in the user's browser, sets first-party and third-party cookies in the pixel domain's context, and sends data directly from the browser. The data that leaves the browser is outside your control — you cannot apply identifier hashing before it departs, you cannot limit which fields are populated, and you cannot verify what the pixel actually sends at runtime without a network inspection. The DPF adequacy covers the destination; it does not address what the pixel collects before the transfer.
This combination — potential DPF legal challenge, supervisory authority scrutiny of mechanics rather than just paperwork, and structural limits on what a controller can verify about client-side pixel behaviour — is why a single-track client-side strategy remains architecturally fragile.
The practical posture: dual-mode tracking#
The architecture that holds under both DPF and a potential DPF invalidation is dual-mode.
The first mode is client-side pixels to DPF-certified vendors, operating under current adequacy with ePrivacy consent in place. This provides the broadest attribution signal for as long as the DPF holds. For most marketing teams, this is the mode that fills your attribution dashboards today.
The second mode is server-side conversion forwarding from EU infrastructure. When a user clicks a link, Elido's Frankfurt edge receives the click, logs it in EU ClickHouse infrastructure, and forwards the conversion signal server-to-server to the ad platform's conversion API — Meta CAPI, GA4 Measurement Protocol, or equivalent. The user's browser does not contact the US endpoint. The data leaving EU infrastructure has been hashed (SHA-256 on email addresses and phone numbers, as Meta CAPI requires), and the transfer is originating from infrastructure under your control rather than from code running in the user's browser.
If the DPF is invalidated, the client-side pixel becomes a non-compliant transfer mechanism until a replacement framework is in place. The server-side path, running via SCCs with supplementary measures applied — encrypted in transit, identifier-hashed before departure, narrowly scoped to the attribution signal — is the fallback that your legal team can defend with a coherent TIA. Because the server-side path processes data in EU infrastructure first, the transfer can be documented as controller-to-processor rather than as a direct browser-to-US-endpoint transfer.
Where available, prefer the vendor's EU endpoint. GA4 with data_collection_endpoint pointed to region1.google-analytics.com keeps more of the processing in Google's EU infrastructure, even though some processing still occurs in US infrastructure per Google's own documentation. Meta CAPI does not currently offer an EU-region endpoint; the server-to-server transfer is US-bound regardless. The supplementary measure is identifier hashing, not endpoint geography.
For the full mechanics of the server-side forwarding path and how it integrates with short-link click attribution, cookieless attribution explained covers the technical architecture. For the broader EU residency picture — where "EU-hosted" starts and stops in a marketing tool stack — EU data residency for marketing is the companion post.
Sub-processor consent under DPF#
Every DPF-certified pixel vendor is still a processor under GDPR Article 28. The DPF adequacy decision covers the transfer mechanism; it says nothing about the processor obligations that apply in parallel.
This means the controller needs a Data Processing Agreement in place with each pixel vendor, covering the Article 28(3)(a)-(h) obligations. Meta's standard advertising data terms, Google's data processing addendum, and HubSpot's DPA are the instruments here. They are pre-signed and incorporated by reference when you agree to the vendor's terms of service; the question is whether you have documented that agreement in your compliance records.
The sub-processor list your DPO will ask about covers these vendors. Each pixel vendor becomes a sub-processor in the attribution chain between your link tracking platform and the ad platform. Elido's public sub-processor list names its five vendors; the pixel vendors are sub-processors at the controller layer, not at the Elido layer. Your Article 30 RoPA should enumerate them separately.
One nuance: GDPR Article 28(2) requires the processor to obtain the controller's authorisation before engaging sub-processors. For the pixel relationship, you are the controller engaging Meta or Google directly — this is a controller-to-processor relationship, not a chain-sub-processor relationship through Elido. The Article 28 DPA is between you and the pixel vendor. The server-side forwarding leg — where Elido's edge forwards events to Meta CAPI on your behalf — is a sub-processor relationship: Elido is the processor, Meta CAPI is the sub-processor, and the DPA obligation flows through Elido's standard DPA.
This distinction matters for your RoPA. A DPA compliance team reviewing your records wants to see two separate entries: one for the Elido processor relationship (covering the link-layer click events), and one for each pixel vendor relationship (covering the browser-side attribution data). Conflating them produces a RoPA entry that is accurate in neither direction.
For the article-level GDPR processor obligations in full, GDPR for URL shorteners is the cornerstone post in this cluster.
The DPO's procurement checklist for pixel vendors#
Five questions to ask every tracking-pixel vendor at procurement. These are written for a DPF-era review; adjust the transfer mechanism question if the DPF status has changed by the time you're reading this.
1. Is your company currently listed on the DPF participant list, and which activities does your certification cover?
The list is at dataprivacyframework.gov. Ask for the specific certification scope, not a blanket "yes, we're certified." The certification is activity-scoped; a vendor may be DPF-certified for human resources data but not for commercial click-attribution data.
2. Where is the data I send via the pixel actually stored, and is there a EU-region endpoint I can use?
The DPF covers the transfer to a certified US recipient. If an EU-region endpoint is available, using it reduces the transfer exposure and may affect the TIA analysis if the DPF is later challenged. Document the answer in your RoPA entry.
3. What is your standard Data Processing Agreement, and does it cover Article 28(3)(a)-(h) obligations explicitly?
Pre-signed DPAs that are incorporated by reference in terms of service are fine; you need to know that the DPA exists and where to find it. The DPA governs the processor relationship independent of the transfer mechanism.
4. How do you handle data subject rights requests — specifically deletion under Article 17 — for pixel-collected data?
For client-side pixels, deletion is typically handled by the platform's privacy controls (Meta's Privacy Centre, Google's My Ad Centre). Document the process so you can answer a data subject request without improvising.
5. If the DPF is invalidated, what fallback transfer mechanism will you offer, and on what timeline?
This question tests whether the vendor has a contingency plan. Under the Privacy Shield to SCCs transition (2020–2021), some vendors were slow to update their agreements. A vendor that has already documented SCCs as the DPF-invalidation fallback — with supplementary measures specified — has done this work. A vendor that says "we'll update our DPA when necessary" has not.
For the Elido-specific implementation: server-side conversion forwarding is available today, with SHA-256 identifier hashing before any data leaves EU infrastructure. The configuration is per-workspace and documented in the standard DPA at /legal/dpa. If your DPF risk tolerance is low, the server-side path is available as the primary forwarding mechanism, not just the fallback.