Proč Amplitude vyžaduje souhlas

Výchozí Amplitude Browser SDK a mobilní SDK Amplitude dělají mnohem více než jen zaznamenávání zobrazení stránek. Při inicializaci nastavují identifikátor zařízení v úložišti první strany, generují identifikátor relace, zachycují odkaz, analyzují identifikátory UTM a kliknutí z URL a začínají řadit automaticky zachycené události do fronty: zobrazení stránek, kliknutí na prvky, interakce s formuláři, stahování souborů a — v nejnovějších vydáních — přehrávání relací. Také obohatí tyto události o geolokaci odvozenou z IP, data zařízení odvozená z uživatelského agenta a při konfiguraci o obohacení třetích stran od datových partnerů.

Každý z těchto kroků zapojuje samostatný právní základ souhlasu. Uložení identifikátoru zařízení je operace ukládání a přístupu podle článku 5 odst. 3 směrnice ePrivacy, která vyžaduje předchozí, svobodně udělený, konkrétní, informovaný a jednoznačný souhlas v Evropském hospodářském prostoru, Spojeném království a v jakékoli jurisdikci, která přijala stejný standard. Zachycení behaviorálních událostí vázaných na tento identifikátor je zpracování osobních údajů podle GDPR. Obohacování daty třetích stran zavádí druhý kontrolní vztah. CCPA a CPRA klasifikují stejné zpracování jako prodej nebo sdílení, pokud vydavatel nemá s Amplitude řádně vymezenou smlouvu o poskytování služeb — která je dostupná, ale pouze pokud je integrace nakonfigurována k deaktivaci reklamních funkcí.

Co Amplitude shromažďuje před souhlasem — a co musíte potlačit

Nejčastější chybou implementace je zacházení s Amplitude jako s lehkým analytickým nástrojem, který může běžet vedle banneru s cookies. Nemůže. Při výchozím volání amplitude.init() SDK zapíše při prvním vykreslení stránky alespoň jeden záznam cookie nebo lokálního úložiště, odešle volání identify a začne ukládat události do vyrovnávací paměti. Nic z toho není povoleno předtím, než uživatel kladně přijme příslušnou kategorii souhlasu.

Kompatibilní integrace proto musí odložit amplitude.init() do doby, než CMP signalizuje, že analytická kategorie souhlasu byla udělena. SDK by vůbec neměl být načten z tagu <script> řízeného souhlasem, který závisí na signálu účelu 8 (analytika) nebo účelu 1 (ukládání a přístup) CMP, v závislosti na tom, jaký rámec CMP zpřístupňuje. Pokud musí být SDK načten dříve — například proto, že je součástí kódu aplikace a nelze jej líně načíst — volání inicializace by mělo předat defaultTracking: false a optOut: true, takže nejsou emitovány žádné události, dokud není zaznamenán souhlas, a poté by odložená událost opt-in měla tyto příznaky přepnout.

Cookies a úložiště, které Amplitude zapisuje

Browser SDK 2.x standardně zapisuje jedinou cookie první strany s názvem AMP_{apiKey}, s ročním vypršením platnosti, obsahující identifikátor zařízení a metadata relace. Starší verze také zapisovaly amplitude_id_{apiKey}. Mobilní SDK uchovávají stejný identifikátor v izolovaném úložišti aplikace. Přehrávání relace přidává druhou cookie, AMP_MKTG_{apiKey}, a partneři pro obohacení dat Amplitude mohou nastavit další cookies třetích stran, pokud jsou povoleny moduly pro cílení experimentů nebo pro cílové skupiny. Všechny tyto jsou nezbytné a vyžadují souhlas.

Mapování Amplitude na rámce souhlasů

Amplitude nativně neimplementuje Google Consent Mode v2, IAB TCF ani IAB Global Privacy Platform. To není defekt — Amplitude je platforma analytiky první strany, nikoli dodavatel reklamních technologií — ale znamená to, že odpovědnost za integraci leží na vydavateli. Vzor, který funguje v praxi, je zacházet s každým modulem Amplitude jako se samostatnou branou souhlasu a vázat ho na specifický signál, který CMP již zpřístupňuje.

• Základní analytické události jsou vázány na analytický účel. V terminologii TCF je to nejčastěji účel 8 (měření výkonu obsahu) kombinovaný s účelem 1 (ukládání a/nebo přístup k informacím). Pro Google Consent Mode to odpovídá analytics_storage.
• Přehrávání relace by mělo být za přísnějším signálem. Přehrávání zachycuje vykreslený DOM, včetně hodnot formulářů, pokud nejsou explicitně maskovány, takže je vhodný samostatný opt-in pro preferences nebo functional, a přehrávání by mělo být ve výchozím nastavení vypnuto i při udělení analytiky.
• Cílové skupiny, kohorty a obohacení třetích stran jsou vázány na marketingový účel. V terminologii TCF je to účel 7 (měření výkonu reklam) nebo účel 9 (použití výzkumu trhu). Pro Google Consent Mode to odpovídá ad_storage a ad_user_data.
• Experimentování — Amplitude Experiment může fungovat s anonymním, dočasným přiřazením na základě oprávněného zájmu, ale trvalé přiřazení vázané na identifikátor uživatele vyžaduje stejný souhlas jako základní analytika.

Vzor integrace, který funguje

Referenční implementace, která přežije přezkum regulátora, má čtyři pohyblivé části: CMP, která zpřístupňuje událost v reálném čase, když uživatel změní souhlas, odložený zavaděč SDK, který načte Amplitude pouze po spuštění této události pro příslušnou kategorii, ochrana na úrovni relace, která respektuje odhlášení bez ztráty předchozího anonymního identifikátoru zařízení uživatele tam, kde to zákon povoluje, a serverový most pro události, které skutečně vyžadují sběr bez ohledu na souhlas — jako je telemetrie zabezpečení nebo detekce podvodů — směrované přes samostatný koncový bod s vlastním právním základem.

Webová implementace

Na webu je nejčistším vzorem zpřístupnit stav souhlasu CMP prostřednictvím objektu window.__cmp_consent nebo standardního zpětného volání __tcfapi, a pak mít malý zaváděcí skript, který se přihlásí k odběru změn souhlasu. Když se analytický souhlas přepne z false na true, zaváděcí skript načte SDK Amplitude z CDN spravovaného CMP, zavolá amplitude.init(apiKey, undefined, { defaultTracking: true }) a přehraje všechny události, které byly v paměti ve frontě, zatímco souhlas čekal na vyřízení. Když se souhlas přepne zpět na false, zaváděcí skript zavolá amplitude.setOptOut(true), smaže cookie AMP_ prostřednictvím vypršení platnosti document.cookie a odstraní veškerý stav v paměti. Zásadně, zaváděcí skript nesmí nikdy líně inicializovat Amplitude ve stejném toku požadavků jako vykreslení banneru — SDK musí čekat na explicitní udělení.

Mobilní implementace

Na iOS je ekvivalentem ponechat importovaný framework Amplitude, ale odložit Amplitude.instance().initialize(apiKey: apiKey) do doby, než tok souhlasu v aplikaci vrátí pozitivní analytický signál. Výzva ATT je samostatnou záležitostí: ATT řídí IDFA, zatímco identifikátor Amplitude je vlastní UUID SDK uložené v sandboxu aplikace. Oboje vyžaduje souhlas v EHP, ale právní základy a výzvy jsou odlišné. Na Androidu platí stejná logika s Amplitude.getInstance().initializeApolloClient() nebo ekvivalentem v závislosti na verzi SDK.

Serverový režim

Amplitude podporuje příjem na straně serveru prostřednictvím HTTP V2 API. Události na straně serveru nejsou osvobozeny od souhlasu — právní základ se řídí daty, nikoli přenosem — ale příjem na straně serveru dává vydavateli plnou kontrolu nad tím, která pole jsou odeslána, což usnadňuje dodržení částečného souhlasu. Běžným vzorem je zachytit minimální sadu událostí pouze pro základní potřeby na straně serveru na základě oprávněného zájmu a obohatit tyto události o behaviorální detaily pouze poté, co uživatel udělil analytický souhlas na klientovi.

Ověření integrace

Krok ověření je ten, který vydavatelé nejčastěji přeskakují a který regulátoři nejčastěji kontrolují. Správně integrované nasazení Amplitude by mělo projít čtyřmi kontrolami. Za prvé, prohlížeč se zobrazeným bannerem souhlasu, ale bez jakékoli volby, by měl generovat nulové požadavky na api.amplitude.com nebo api.eu.amplitude.com a nulové cookies AMP_ v document.cookie. Za druhé, odmítnutí kategorie analytiky by mělo zachovat tento stav — žádné události, žádné cookies, žádné záznamy lokálního úložiště s předponou AMP_. Za třetí, přijetí analytiky by mělo generovat jediný identify následovaný provozem událostí a cookie AMP_ by se měla zobrazit s atributem SameSite konzistentním s politikou CMP vydavatele. Za čtvrté, odvolání souhlasu ex post by mělo okamžitě zastavit další události a vymazat uložené identifikátory — zpožděné vyčištění je nálezem.

Auditní stopa je důležitá samostatně. Podle pokynů EDPB pro bannery cookies z roku 2023 a obnovených priorit pracovní skupiny pro rok 2026 regulátoři očekávají, že vydavatel bude schopen prokázat pro jakoukoli danou událost v projektu Amplitude, že uživatel, který ji vygeneroval, dal platný souhlas v okamžiku zachycení. To vyžaduje, aby protokol souhlasů CMP byl dotazovatelný podle identifikátoru zařízení nebo identifikátoru relace, a aby datová část události Amplitude nesla pole verze souhlasu, které odkazuje zpět na tento protokol. Ukládání řetězce souhlasu jako vlastní vlastnosti uživatele při každé události je nejjednodušší způsob, jak učinit toto propojení auditovatelným.

Výběr správného regionu a umístění dat

Amplitude provozuje dvě produkční oblasti: USA (api.amplitude.com) a EU (api.eu.amplitude.com). Pro provoz EHP a Spojeného království je oblast EU správným výchozím nastavením — udržuje data v rámci EHP a snižuje povrch rizika přenosu, který rozsudek Schrems II a Rámec pro ochranu soukromí EU-USA učinily ústředním bodem jakéhokoli analytického přezkumu. Přepnutí oblastí není retroaktivní: stávající data zůstávají tam, kde byla nejprve zpracována. Pro vydavatele plánující zavedení CMP se proto vyplatí potvrdit oblast před škálováním a zdokumentovat výběr v oznámení o ochraně soukromí, aby byl řetězec právních základů čistý od shromažďování po ukládání. Správně zvolená oblast, kombinovaná se správně řízeným SDK a dotazovatelným protokolem souhlasů, je to, co mění nasazení Amplitude z regulatorního rizika na obhajitelnou součást analytického zásobníku.