← Zpět na blog Tracking

Sledování na straně serveru: Když zdání první strany maskuje realitu třetí strany

· 6 min čtení
Server-Side Tracking CNAME Cloaking GTM Server-Side GDPR Consent Management

Sledování na straně serveru se stalo hlavní reakcí reklamního průmyslu na opatření na ochranu soukromí na úrovni prohlížeče: ITP, ETP a ukončení podpory cookies třetích stran. Princip je jednoduchý – přesměrujte pixely dodavatelů přes vaši vlastní doménu a prohlížeč je bude považovat za cookies první strany. Co se však málokdy otevřeně přiznává, je to, že tato architektura může podle GDPR představovat nezákonné zpracování osobních údajů, a to bez ohledu na typ DNS záznamu použitý k její implementaci.

Tři implementační vzory – a jejich odlišné právní profily

1. Maskování CNAME

CNAME cloaking zahrnuje vytvoření DNS CNAME záznamu, který směřuje subdoménu vaší vlastní domény (např. metrics.example.com) na infrastrukturu dodavatele (např. data.vendor-cdn.com). Prohlížeč vidí pouze subdoménu, která sdílí eTLD+1 s vydavatelem — a proto přijímá cookies první strany. V praxi je HTTP požadavek nakonec vyřešen a zpracován servery dodavatele.

Technický důsledek: soubory cookie nastavené dodavatelem prostřednictvím tohoto koncového bodu CNAME zdědí rozsah první strany. Zásadní je, že opatření ITP proti maskování CNAME (zavedené v Safari 14) nyní omezuje dobu platnosti souborů cookie nastavených přes CNAME na 7 dní a Firefox 90+ blokuje známé sledovače CNAME prostřednictvím svého seznamu Enhanced Tracking Protection spravovaného Disconnect.me. Chrome v současné době žádné takové omezení neuplatňuje, což činí maskování CNAME nejúčinnějším právě v prohlížeči s největším podílem na trhu.

Z pohledu GDPR se zde stírá hranice mezi správcem a zpracovatelem. Servery dodavatele přijímají kompletní HTTP požadavek včetně Cookie, Referer, User-Agenta hlavičkami IP adresy – přesto subjekt údajů nemá žádnou indikaci, že je do procesu zapojena třetí strana. Bod 60 GDPR vyžaduje, aby oznámení o ochraně osobních údajů identifikovala skutečné příjemce osobních údajů. Oznámení o ochraně osobních údajů, které uvádí pouze „analytiku“ bez identifikace konkrétního dodavatele přijímajícího data prostřednictvím CNAME, je téměř jistě v rozporu s předpisy. Pokyny EDPB 05/2020 týkající se souhlasu potvrzují, že transparentnost se musí vztahovat na konkrétní třetí strany, nikoli na obecné kategorie.

2. Kontejnery GTM na straně serveru

Režim Google Tag Manager na straně serveru (sGTM) nasazuje kontejner založený na Node.js – obvykle na Google Cloud Run, ale přenositelný do jakékoli infrastruktury – na subdoméně první strany. Tagy na straně klienta odesílají jediný požadavek na tento koncový bod kontejneru (např. collect.example.com/g/collect), a kontejner poté rozesílá data ze serveru na server do Google Analytics 4, Meta CAPI, TikTok Events API a dalších.

Technická architektura je zde lépe obhajitelná než pouhé maskování CNAME: operátor ovládá serverový kontejner a může v zásadě filtrovat nebo redigovat data před jejich předáním. X-Forwarded-For Zpracování hlaviček se stává kritickým — pokud kontejner sGTM předá původní IP adresu klienta do GA4 nebo Meta, tvrzení o anonymizaci IP jsou neplatná, protože úplná IP adresa prochází do koncového bodu dodavatele. Provozovatelé by měli prostřednictvím protokolování na úrovni sítě ověřit, zda jejich konfigurace sGTM odstraňuje IP adresy před odesláním ven, nebo zda výchozí request.extractMacAddress() chování únik identifikátorů zařízení.

Podle čl. 26 GDPR platí společné správcovství, pokud provozovatel a Google společně určují účely a prostředky zpracování – k čemuž dochází, když jsou behaviorální data z kontejneru přiváděna do reklamní infrastruktury Google. Rozsudek Soudního dvora Evropské unie ve věci Fashion ID (C-40/17) stanovil, že zabudování funkcí třetích stran, které způsobují přenos dat, činí z toho, kdo je zabudoval, společného správce pro danou fázi shromažďování, a to i bez přístupu k samotným shromážděným údajům. sGTM tento vztah neruší; pouze přemísťuje místo shromažďování.

3. Zneužití koncových bodů prvotních dat

Jemnější vzorec zahrnuje legitimní koncové body první strany – API pro potvrzení objednávky, koncové body pro přihlášení, správce odběru newsletterů – které jsou využívány k předávání údajů o chování a transakcích na platformy dodavatelů. POST na api.example.com/checkout/complete může spustit událost na straně serveru do API Meta Conversions obohacenou o hashovanou e-mailovou adresu, hodnotu objednávky a otisk zařízení odvozený z User-Agent a Accept-Language z hlaviček.

Tím se zcela obchází správa souhlasů, protože se nespustí žádný JavaScript na straně klienta. Uživatel přijal „funkční soubory cookie“ nezbytné pro dokončení objednávky – ale výklad DPA (viz Orientierungshilfe DSK o sledování, 2022) jasně uvádí, že předávání transakčních dat na straně serveru na reklamní platformy za účelem přiřazení konverzí není funkčně nezbytné a vyžaduje výslovný souhlas podle čl. 6 odst. 1 písm. a) GDPR. Právní základ se nemění v závislosti na technické vrstvě, na které ke zpracování dochází.

Tvrzení o pseudonymizaci neobstojí při bližším zkoumání

Prodejci často argumentují, že hashované e-maily (SHA-256 [email protected]) představují dostatečnou pseudonymizaci ke snížení rizika. Tento argument neobstojí ve světle definice v čl. 4 odst. 5 GDPR: pseudonymizované údaje zůstávají osobními údaji, pokud je možná reidentifikace s využitím doplňujících informací, které má k dispozici jakákoli strana. Proces přiřazování v rámci Custom Audiences společnosti Meta je přesně tímto krokem reidentifikace – hash se porovnává s databází známých hashů společnosti Meta. Pokyny EDPB 04/2019 k článku 25 se tímto výslovně zabývají: pseudonymizace snižuje riziko pouze tehdy, pokud klíč zůstává u správce; v tomto případě je „klíčem“ předem vypočítaná hash tabulka společnosti Meta.

Selhání šíření řetězců souhlasu

Řetězce souhlasu TCF 2.2 jsou artefakty na straně klienta uložené v localStorage nebo v souborech cookie pod klíčem euconsent-v2. Architektury sledování na straně serveru systematicky narušují šíření řetězců souhlasu, pokud nejsou výslovně navrženy tak, aby je předávaly dál. Kontejner sGTM přijímající událost na straně klienta musí přečíst řetězec souhlasu z datové části příchozího požadavku a podmíněně blokovat odchozí volání dodavatelů na základě analýzy řetězce TC – což je chování, které vyžaduje vlastní implementaci, nikoli výchozí konfiguraci. Provozovatelé spoléhající se na sGTM pro distribuci dodavatelů bez ověřeného vynucení řetězce TC pravděpodobně spouštějí tagy dodavatelů v rozporu s politikami TCF organizace IAB Europe a, co je důležitější, v rozporu se zaznamenanými volbami souhlasu uživatele.

Doporučení k provedení

  • Auditujte záznamy CNAME: Spusťte dig CNAME metrics.yourdomain.com pro každou subdoménu analytiky/marketingu. Přiřaďte každý cíl CNAME k jeho konečnému správci. Zaznamenejte to do svých záznamů o zpracovávacích činnostech (RoPA) podle čl. 30 GDPR.
  • Zkontrolujte odchozí provoz sGTM: Povolte protokolování požadavků Google Cloud Run a analyzujte odchozí HTTP volání z vašeho kontejneru. Ověřte, zda se IP adresy klientů v požadavcích směřujících k dodavatelům zobrazují jako anonymizované (např. zkrácené na /24), a to kontrolou X-Forwarded-For a True-Client-IP hlavičkách.
  • Vynuťte řetězec TC v sGTM: Implementujte do svého kontejneru sGTM vlastní proměnnou, která analyzuje euconsent-v2 z datové náplně příchozí události klienta a řídí spouštění jednotlivých tagů na základě příslušného bitu souhlasu dodavatele (Účel 1, Účel 7 atd.).
  • Aktualizujte oznámení o ochraně osobních údajů: Podle pokynů EDPB 05/2020 uveďte konkrétní dodavatele, kteří přijímají data prostřednictvím předávání na straně serveru. „Externí poskytovatelé analytických služeb“ nesplňují požadavek čl. 13 odst. 1 písm. e) GDPR na identifikaci příjemců.
  • Přehodnoťte právní základ pro volání API konverzí na straně serveru: Pokud váš pokladní nebo CRM systém předává transakční data reklamním platformám, výslovně zdokumentujte právní základ. Je nepravděpodobné, že oprávněný zájem podle čl. 6 odst. 1 písm. f) obstojí v testu vyváženosti pro přiřazování reklamy vzhledem k citlivosti údajů o nákupním chování.
  • Povědomí o situaci v oblasti DPA: Francouzská CNIL již ve svých pokynech k souborům cookie z roku 2022 sankcionovala implementace maskování CNAME. Irská DPC a německá LfDI Baden-Württemberg vydaly formální stanoviska, která považují shromažďování na straně serveru bez souhlasu za rovnocenné porušením na straně klienta.

Základní právní realita je následující: GDPR reguluje toky dat, nikoli mechanismy shromažďování dat. Přesunutí pixelů na stranu serveru nepřesouvá právní odpovědnost – přesouvá pouze technickou viditelnost. Úřady pro ochranu osobních údajů mají stále větší technické znalosti a argument, že zpracování na straně serveru se ze své podstaty liší v právním charakteru od zpracování na straně klienta, nemá oporu v textu nařízení ani v aktuálních pokynech dozorových orgánů.

Související články