Schrems II та пікселі відстеження: де вас залишає DPF у 2026 році

У липні 2020 року Суд Європейського Союзу (CJEU) виніс рішення у справі Schrems II (C-311/18). Privacy Shield, який був механізмом за замовчуванням для передачі даних між ЄС та США з 2016 року, було визнано недійсним. За одну ніч кожна маркетингова команда, що використовувала Meta Pixel або Google Tag, опинилася в ситуації, коли вона або передавала дані без дійсного юридичного механізму, або поспіхом впроваджувала Стандартні договірні умови (SCCs), або сподівалася на оптимістичне тлумачення, що GDPR якимось чином не поширюється на JavaScript-код у браузері користувача.

Слідом за цим настали три роки роз'яснень щодо додаткових заходів, шаблонів Оцінки впливу на передачу даних (TIA) та дій наглядових органів. Потім, у липні 2023 року, Європейська Комісія ухвалила рішення про адекватність Рамкової угоди про конфіденційність даних між ЄС та США (DPF), відновивши адекватність для сертифікованих DPF американських компаній. Meta, Google, Salesforce та HubSpot - усі вони є у списку.

Питання для маркетингових команд та спеціалістів із комплаєнсу у 2026 році полягає не в тому, чи існує DPF - вона існує. Питання в тому, що вона насправді охоплює, де залишаються залишкові ризики, і як на практиці виглядає архітектура передачі даних, яка витримає потенційне оскарження DPF.

TL;DR#

• Privacy Shield (2016) був визнаний недійсним рішенням Schrems II у липні 2020 року. SCCs разом із додатковими заходами закривали прогалину з 2020 по 2023 рік.
• Рамкова угода про конфіденційність даних між ЄС та США (DPF) (липень 2023 року) є поточним рішенням про адекватність. Передача даних компаніям, сертифікованим за DPF, користується перевагами адекватності без необхідності впровадження SCCs або проведення TIA.
• Клієнтські пікселі, що передають дані постачальникам, сертифікованим за DPF, є юридично захищеними у 2026 році за умови, що отримувач сертифікований, суб'єкт даних поінформований, а також отримана згода ePrivacy, де це необхідно.
• DPF є об'єктом очікуваного юридичного оскарження. Дворежимне відстеження - клієнтське під покриттям DPF та серверне пересилання з інфраструктури ЄС як структурний резервний варіант - це архітектура, яка переживе третє рішення Schrems.

Що насправді сказано у рішенні Schrems II#

Рішення варто прочитати в оригіналі, а не в переказі. Основна аргументація міститься в пунктах 180–202. Головний висновок полягає не в тому, що передача даних до США сама по собі є незаконною. А в тому, що законодавство США про стеження - зокрема FISA 702 та Виконавчий указ 12333 - надає розвідувальним службам США доступ до персональних даних суб'єктів з ЄС у спосіб, що не забезпечує цим суб'єктам ефективних засобів правового захисту згідно зі статтями 77–79 GDPR.

Стаття 44 GDPR забороняє передачу даних до третіх країн, якщо не застосовується один із механізмів Розділу V. Privacy Shield був рішенням про адекватність згідно зі статтею 45. Висновок Суду про недійсність Privacy Shield позбавив підстави адекватності кожну передачу даних, яка на нього покладалася.

Стандартні договірні умови (SCCs) не були визнані недійсними, але Суд у тому ж рішенні постановив, що SCCs не є автоматично достатніми для передачі даних до США. Контролер або процесор, який використовує SCCs, повинен у кожному конкретному випадку перевіряти, чи перешкоджатиме правова система країни призначення функціонуванню захисту на рівні SCCs на практиці. Цією вимогою є Оцінка впливу на передачу даних (TIA): задокументована оцінка законодавства США про стеження та його впливу на дані, що передаються.

Рекомендації EDPB 01/2020 щодо додаткових заходів впровадили цю вимогу в життя. Вони визначили шестиетапний процес та каталог додаткових заходів - технічних (шифрування, псевдонімізація), договірних та організаційних - які контролери повинні оцінювати при використанні SCCs для передачі даних до США. Для стандартних маркетингових пікселів більшість із цих технічних заходів були практично неможливими: ви не можете змістовно зашифрувати корисне навантаження, метою якого є надання Meta можливості приписати конверсію до показу реклами.

Це архітектура, з якою маркетингові команди жили з липня 2020 року по липень 2023 року. SCCs були підписані. TIAs були спробовані. Наглядові органи в Австрії, Франції та Італії визнали конкретні впровадження - насамперед Google Analytics - невідповідними, незважаючи на SCCs, оскільки додаткові заходи були недостатніми.

Що змінилося з появою Data Privacy Framework#

Рамкова угода про конфіденційність даних між ЄС та США (DPF) (Рішення Комісії (EU) 2023/1795, чинне з 10 липня 2023 року) є рішенням про адекватність згідно зі статтею 45 GDPR. Його юридична передумова полягає в тому, що правова база США - зі змінами, внесеними Виконавчим указом Президента Байдена 14086, та наступними правилами, що заснували Суд з перегляду захисту даних - забезпечує рівень захисту, що по суті еквівалентний гарантованому в ЄС.

Для практичних цілей DPF означає наступне: передача даних американським компаніям, сертифікованим за DPF, користується перевагами адекватності. Вам не потрібні SCCs. Вам не потрібна TIA. Вам потрібно лише переконатися, що організація-отримувач є у списку учасників DPF, який є публічним, доступним для пошуку та оновлюється майже в реальному часі.

Meta Platforms, Inc. сертифікована за DPF. Google LLC сертифікована за DPF. Salesforce, Inc. сертифікована за DPF. HubSpot, Inc. сертифікована за DPF. Для цих постачальників передача персональних даних суб'єктів з ЄС у зв'язку з рекламою та аналітикою покривається адекватністю станом на липень 2023 року, за умови, що вони отримують дані у межах своєї сертифікації DPF.

Важливі два уточнення. По-перше, сертифікація DPF є добровільною. Не кожна американська компанія, що обробляє дані ЄС, пройшла самосертифікацію. Список учасників є авторитетним джерелом; не припускайте наявність сертифікації автоматично. По-друге, сертифікація DPF охоплює конкретні види діяльності. Компанія, сертифікована за DPF, може обробляти ваші дані пікселів у межах сертифікованої сфери або на іншій юридичній підставі залежно від типу та мети даних. Для стандартної атрибуції маркетингу через піксель сфера DPF це охоплює.

Що це означає для маркетингових пікселів на практиці#

За наявності покриття DPF, юридична позиція для клієнтських маркетингових пікселів, що передають дані сертифікованим постачальникам, виглядає так.

Клієнтський Meta Pixel, коли він передає дані Meta Platforms Inc. (сертифікована за DPF), є передачею до країни з адекватним рівнем захисту. Механізмом передачі є рішення про адекватність DPF, а не SCCs. Ваш запис у RoPA згідно зі статтею 30 для Meta Pixel документує підставу передачі як "рішення про адекватність (DPF)", а не "SCCs". TIA, яка була б необхідна у разі використання SCCs, не потрібна.

Такий самий аналіз застосовується до Google Tag Manager та GA4, що передають дані Google LLC, пікселя відстеження HubSpot, що передає дані HubSpot Inc., та подій атрибуції Salesforce Marketing Cloud, що передають дані Salesforce Inc.

Проте адекватність - це лише один рівень багатошарової картини відповідності. Перед тим, як ця позиція стане стійкою, мають бути виконані три додаткові вимоги.

Згода ePrivacy. Директива про конфіденційність та електронні засоби зв'язку 2002/58/EC, Стаття 5(3), вимагає отримання згоди перед будь-яким несуттєвим зберіганням або доступом до термінального обладнання користувача. Маркетингові пікселі не є суттєвими. Банери згоди повинні стосуватися саме конкретного пікселя, бути добровільними та мати можливість відкликання. Той факт, що місце призначення передачі даних є адекватним згідно з DPF, не впливає на вимогу щодо згоди ePrivacy. Це окремі юридичні інструменти.

Прозорість перед суб'єктами даних. Стаття 13 GDPR вимагає від контролера інформувати суб'єктів даних під час збору про отримувачів їхніх даних та будь-яку передачу до третіх країн. DPF не змінює це зобов'язання щодо прозорості. Якщо у вашому повідомленні про конфіденційність зазначено "ми використовуємо Meta Pixel" та "передача даних до США покривається рішенням про адекватність", цього достатньо. Якщо там взагалі не згадується передача до США, рішення про адекватність не виправляє порушення Статті 13.

DPA згідно зі статтею 28 з постачальником. Постачальник пікселя залишається процесором згідно зі статтею 28 GDPR. DPF охоплює механізм передачі; він не замінює DPA. Стандартні умови обробки даних Meta, Google та HubSpot є інструментами Статті 28 для відносин щодо пікселів. Переконайтеся, що вони підписані або прийняті.

Залишкові ризики#

DPF не є остаточним рішенням. Це рішення про адекватність, яке може бути оскаржене в CJEU будь-яким судом держави-члена, Європейським парламентом або будь-яким національним наглядовим органом. Макс Шремс та NOYB публічно заявили про намір оскаржити DPF - потенційний Schrems III. Юридична теорія цього оскарження подібна до Schrems II: що EO 14086 та Суд з перегляду захисту даних по суті не забезпечують засобів захисту, еквівалентних тим, що доступні за законодавством ЄС.

Наглядові органи не чекали рішення CJEU. Австрійський DSB постановив щодо впровадження Google Analytics ще у 2022 році - до набрання чинності DPF - що передача даних була незаконною, оскільки SCCs та додаткові заходи були недостатніми. Французький CNIL та італійський Garante винесли подібні рішення. Ці рішення були прийняті за режиму, що передував DPF, але вони встановлюють схему нагляду: наглядові органи готові перевіряти технічну механіку передачі даних через пікселі, а не лише договірні документи. Майбутнє рішення у справі за позовом проти DPF, ймовірно, вивчатиме, чи справді правопорядок, встановлений EO 14086, реально обмежує доступ FISA 702 до збережених даних сертифікованих компаній.

Специфічне занепокоєння щодо пікселів відстеження виходить за межі юридичного механізму. Клієнтський піксель робить більше, ніж просто передає дані сертифікованій компанії. Він виконує JavaScript у браузері користувача, встановлює власні та сторонні файли cookie в контексті домену пікселя та надсилає дані безпосередньо з браузера. Дані, що виходять із браузера, перебувають поза вашим контролем - ви не можете застосувати хешування ідентифікаторів до їх відправлення, ви не можете обмежити поля, що заповнюються, і ви не можете перевірити, що піксель насправді надсилає під час виконання, без перевірки мережі. Адекватність DPF охоплює місце призначення; вона не стосується того, що піксель збирає до передачі.

Це поєднання - потенційне юридичне оскарження DPF, прискіпливість наглядових органів до механіки, а не лише документів, та структурні обмеження щодо того, що контролер може перевірити в поведінці клієнтського пікселя - є причиною того, що одноканальна клієнтська стратегія залишається архітектурно вразливою.

Практична позиція: дворежимне відстеження#

Архітектура, яка вистоїть як за умов дії DPF, так і у разі потенційного скасування DPF - це дворежимне відстеження.

Перший режим - це клієнтські пікселі для сертифікованих DPF постачальників, що працюють під поточним рішенням про адекватність за наявності згоди ePrivacy. Це забезпечує найширший сигнал атрибуції доти, доки діє DPF. Для більшості маркетингових команд це режим, який наповнює ваші дашборди атрибуції сьогодні.

Другий режим - це серверне пересилання конверсій з інфраструктури ЄС. Коли користувач натискає на посилання, edge Elido у регіоні ЄС отримує клік, реєструє його в аналітичній інфраструктурі ЄС і пересилає сигнал конверсії з сервера на сервер до API рекламної платформи - Meta CAPI, GA4 Measurement Protocol або еквівалента. Браузер користувача не контактує з кінцевою точкою в США. Дані, що залишають інфраструктуру ЄС, були хешовані (SHA-256 для адрес електронної пошти та номерів телефонів, як того вимагає Meta CAPI), і передача походить з інфраструктури під вашим контролем, а не з коду, що виконується в браузері користувача.

Якщо DPF буде скасовано, клієнтський піксель стане невідповідним механізмом передачі до моменту впровадження замісної структури. Серверний шлях, що працює через SCCs із застосуванням додаткових заходів - зашифрований під час транспортування, з хешованими ідентифікаторами до відправлення, з вузько визначеним сигналом атрибуції - це резервний варіант, який ваша юридична команда зможе захистити за допомогою послідовної TIA. Оскільки серверний шлях спочатку обробляє дані в інфраструктурі ЄС, передачу можна задокументувати як відносини контролер-процесор, а не як пряму передачу з браузера до кінцевої точки в США.

Де це можливо, надавайте перевагу кінцевій точці постачальника в ЄС. GA4 з data_collection_endpoint, спрямованим на region1.google-analytics.com, залишає більше обробки в інфраструктурі Google в ЄС, хоча деяка обробка все ще відбувається в інфраструктурі США згідно з власною документацією Google. Meta CAPI наразі не пропонує кінцеву точку в регіоні ЄС; передача між серверами спрямована до США у будь-якому випадку. Додатковим заходом тут є хешування ідентифікаторів, а не географія кінцевої точки.

Детальна механіка шляху серверного пересилання та його інтеграція з атрибуцією кліків за короткими посиланнями описана в статті пояснення безкукісної атрибуції. Для ширшої картини резиденції даних в ЄС - де починається і закінчується "хостинг в ЄС" у маркетинговому стеку інструментів - перегляньте супутній допис резиденція даних в ЄС для маркетингу.

Згода суб-процесора в межах DPF#

Кожен сертифікований DPF постачальник пікселів залишається процесором згідно зі статтею 28 GDPR. Рішення про адекватність DPF охоплює механізм передачі; воно нічого не говорить про зобов'язання процесора, які застосовуються паралельно.

Це означає, що контролеру потрібна Угода про обробку даних (DPA) з кожним постачальником пікселів, що охоплює зобов'язання згідно зі статтею 28(3)(a)-(h). Стандартні умови рекламних даних Meta, додаток про обробку даних Google та DPA HubSpot є такими інструментами. Вони підписуються заздалегідь і включаються шляхом відсилання, коли ви погоджуєтеся з умовами надання послуг постачальника; питання лише в тому, чи задокументували ви цю згоду у своїх записах про відповідність.

Список суб-процесорів, про який запитає ваш DPO, охоплює цих постачальників. Кожен постачальник пікселів стає суб-процесором у ланцюжку атрибуції між вашою платформою відстеження посилань та рекламною платформою. Публічний список суб-процесорів Elido називає своїх п'ятьох постачальників; постачальники пікселів є суб-процесорами на рівні контролера, а не на рівні Elido. Ваш RoPA згідно зі статтею 30 має перелічувати їх окремо.

Один нюанс: Стаття 28(2) GDPR вимагає, щоб процесор отримав дозвіл контролера перед залученням суб-процесорів. У відносинах щодо пікселів ви залучаєте Meta або Google безпосередньо - це відносини контролер-процесор, а не ланцюжок суб-процесорів через Elido. DPA згідно зі статтею 28 укладається між вами та постачальником пікселя. Серверний етап пересилання - де edge Elido пересилає події до Meta CAPI від вашого імені - це відносини з суб-процесором: Elido є процесором, Meta CAPI є суб-процесором, і зобов'язання DPA випливають зі стандартної DPA Elido.

Ця різниця важлива для вашого RoPA. Команда з комплаєнсу DPA, переглядаючи ваші записи, хоче бачити два окремі записи: один для відносин із процесором Elido (що охоплює події кліків на рівні посилань), і один для кожного постачальника пікселів (що охоплює дані атрибуції на стороні браузера). Поєднання їх призводить до того, що запис у RoPA буде неточним в обох напрямках.

Для повного ознайомлення із зобов'язаннями процесора згідно з статтями GDPR зверніться до наріжної статті GDPR для скорочувачів URL у цьому кластері.

Чек-лист DPO щодо закупівлі для постачальників пікселів#

П'ять запитань, які слід поставити кожному постачальнику пікселів відстеження під час закупівлі. Вони написані для перевірки в епоху DPF; скоригуйте запитання щодо механізму передачі, якщо статус DPF змінився на момент читання цього тексту.

1. Чи входить ваша компанія наразі до списку учасників DPF, і які види діяльності охоплює ваша сертифікація?

Список знаходиться на dataprivacyframework.gov. Запитуйте про конкретну сферу сертифікації, а не загальне "так, ми сертифіковані". Сертифікація поширюється на певні види діяльності; постачальник може бути сертифікований за DPF для даних про людські ресурси, але не для комерційних даних про атрибуцію кліків.

2. Де насправді зберігаються дані, які я надсилаю через піксель, і чи є кінцева точка в регіоні ЄС, яку я можу використовувати?

DPF охоплює передачу сертифікованому отримувачу в США. Якщо доступна кінцева точка в регіоні ЄС, її використання зменшує ризики передачі та може вплинути на аналіз TIA, якщо DPF згодом буде оскаржено. Задокументуйте відповідь у своєму записі RoPA.

3. Яка ваша стандартна Угода про обробку даних (DPA), і чи охоплює вона зобов'язання згідно зі статтею 28(3)(a)-(h) у явному вигляді?

Попередньо підписані DPA, які включаються шляхом відсилання в умовах надання послуг, - це нормально; вам потрібно знати, що DPA існує і де її знайти. DPA регулює відносини з процесором незалежно від механізму передачі.

4. Як ви обробляєте запити суб'єктів даних щодо їхніх прав - зокрема видалення згідно зі статтею 17 - для даних, зібраних пікселем?

Для клієнтських пікселів видалення зазвичай здійснюється через засоби контролю конфіденційності платформи (Privacy Centre Meta, My Ad Centre Google). Задокументуйте цей процес, щоб ви могли відповісти на запит суб'єкта даних без імпровізацій.

5. Якщо DPF буде визнано недійсним, який резервний механізм передачі ви запропонуєте і в які терміни?

Це запитання перевіряє, чи має постачальник план на випадок надзвичайних ситуацій. Під час переходу від Privacy Shield до SCCs (2020–2021) деякі постачальники повільно оновлювали свої угоди. Постачальник, який вже задокументував SCCs як резервний варіант на випадок скасування DPF - із зазначенням додаткових заходів - виконав цю роботу. Постачальник, який каже "ми оновимо нашу DPA, коли це буде необхідно", ні.

Для впровадження саме в Elido: серверне пересилання конверсій доступне вже сьогодні з хешуванням ідентифікаторів SHA-256 до того, як будь-які дані залишать інфраструктуру ЄС. Конфігурація встановлюється для кожного робочого простору та задокументована у стандартній DPA за адресою /legal/dpa. Якщо ваша толерантність до ризиків DPF є низькою, серверний шлях доступний як основний механізм пересилання, а не лише як резервний.