Miért igényel az Amplitude hozzájárulást

Az alapértelmezett Amplitude Browser SDK és a mobil SDK-k sokkal többet tesznek, mint egyszerűen oldalmegtekintéseket rögzítenek. Az inicializáláskor eszközazonosítót állítanak be az első felek tárolójában, munkamenet-azonosítót generálnak, rögzítik a hivatkozót, elemzik az URL-ből az UTM- és kattintásazonosítókat, és megkezdik az automatikusan rögzített események sorba állítását: oldalmegtekintések, elemkattintások, űrlapinterakciók, fájlletöltések és — a legújabb kiadásokban — munkamenet-visszajátszások. Ezeket az eseményeket IP-alapú geolokációval, felhasználói ügynök alapú eszközadatokkal is gazdagítják, és ha be van állítva, adatpartnerektől származó harmadik féltől érkező gazdagítással is.

Ezek a lépések mindegyike külön hozzájárulási jogalapot igényel. Az eszközazonosító tárolása az ePrivacy irányelv 5. cikke (3) bekezdése szerinti tárolási és hozzáférési művelet, amely az Európai Gazdasági Térségben, az Egyesült Királyságban és minden olyan joghatóságban, amely ugyanazt a standardot vette át, előzetes, szabadon adott, konkrét, tájékozott és egyértelmű hozzájárulást igényel. Az ehhez az azonosítóhoz kapcsolt viselkedési események rögzítése a GDPR szerinti személyes adat feldolgozása. A harmadik féltől való gazdagítás egy második adatkezelői kapcsolatot vezet be. A CCPA és a CPRA ugyanezt a feldolgozást értékesítésnek vagy megosztásnak minősíti, kivéve ha a kiadónak megfelelően körülhatárolt szolgáltatói szerződése van az Amplitude-dal — ami elérhető, de csak akkor, ha az integráció a hirdetési funkciók letiltására van konfigurálva.

Mit gyűjt az Amplitude a hozzájárulás előtt — és mit kell letiltani

A leggyakoribb implementációs hiba az, hogy az Amplitude-ot könnyű elemzőeszközként kezelik, amely a cookie-banner mellett futhat. Nem futhat. Alapértelmezett amplitude.init() hívásnál az SDK az oldal első megjelenítésekor legalább egy cookie-t vagy helyi tároló bejegyzést ír, azonosító hívást küld, és megkezdi az események pufferelését. Mindez nem megengedett, mielőtt a felhasználó határozottan elfogadta a vonatkozó hozzájárulási kategóriát.

Egy megfelelő integrációnak tehát el kell halasztania az amplitude.init() hívást, amíg a CMP nem jelzi, hogy az elemzési hozzájárulási kategória megadásra került. Az SDK-t egyáltalán nem szabad betölteni egy olyan hozzájárulástól függő <script> tagből, amely a CMP 8. céljától (elemzés) vagy 1. céljától (tárolás és hozzáférés) függ, attól függően, hogy a CMP melyik keretrendszert teszi elérhetővé. Ha az SDK-t korábban kell betölteni — például mert be van csomagolva az alkalmazáskódba és nem tölthető be lustán — az inicializáló hívásnak defaultTracking: false és optOut: true értéket kell átadnia, hogy ne bocsásson ki eseményeket a hozzájárulás rögzítéséig, majd egy késleltetett opt-in eseménynek kell átváltania ezeket a jelzőket.

Az Amplitude által írt cookie-k és tárolók

A Browser SDK 2.x egyetlen első fél cookie-t ír, amelynek neve AMP_{apiKey}, alapértelmezetten egyéves lejárattal, amely tartalmazza az eszközazonosítót és a munkamenet-metaadatokat. A régebbi verziók amplitude_id_{apiKey} nevet is írtak. A mobil SDK-k ugyanazt az azonosítót az alkalmazás sandboxolt tárhelyén belül tartják fenn. A munkamenet-visszajátszás egy második cookie-t ad hozzá, AMP_MKTG_{apiKey}, és az Amplitude gazdagítási partnerei további harmadik féltől való cookie-kat állíthatnak be, ha a kísérlet-célzási vagy közönség-modulok engedélyezve vannak. Mindezek nem lényegesek és hozzájárulást igényelnek.

Az Amplitude leképezése hozzájárulási keretrendszerekre

Az Amplitude natívan nem implementálja a Google Consent Mode v2-t, az IAB TCF-et vagy az IAB Global Privacy Platform-ot. Ez nem hiányosság — az Amplitude egy első fél elemzési platform, nem hirdetéstechnológiai szállító — de ez azt jelenti, hogy az integrációs felelősség a kiadónál van. A gyakorlatban működő minta az, hogy minden Amplitude modult külön hozzájárulási kapuként kezelünk, és a CMP által már közzétett konkrét jelzőhöz kötjük.

• Az alapvető elemzési események az elemzési célhoz kötődnek. TCF keretében ez leggyakrabban a 8. cél (tartalomteljesítmény mérése) kombinálva az 1. céllal (információ tárolása és/vagy hozzáférése). A Google Consent Mode esetén ez az analytics_storage leképezésnek felel meg.
• A munkamenet-visszajátszást szigorúbb jelző mögé kell helyezni. A visszajátszás rögzíti a megjelenített DOM-ot, beleértve az űrlapértékeket is, hacsak kifejezetten nincs maszkolva, ezért egy külön preferences vagy functional opt-in megfelelő, és a visszajátszásnak alapértelmezetten kikapcsolt állapotban kell lennie, még akkor is, ha az elemzés engedélyezett.
• A közönségek, kohorszok és harmadik féltől való gazdagítás a marketing célhoz kötődnek. TCF keretében ez a 7. cél (hirdetési teljesítmény mérése) vagy a 9. cél (piackutatás alkalmazása). A Google Consent Mode esetén ez az ad_storage és az ad_user_data leképezésnek felel meg.
• A kísérletezés — az Amplitude Experiment futtatható anonim, efemer allokációval legitim érdek alapján, de a felhasználói azonosítóhoz kötött tartós allokáció ugyanolyan hozzájárulást igényel, mint az alapvető elemzés.

A működő integrációs minta

A szabályozói felülvizsgálaton átmenő referencia-implementációnak négy mozgó része van: egy CMP, amely valós idejű eseményt tesz közzé, amikor a felhasználó módosítja a hozzájárulást, egy késleltetett SDK-betöltő, amely csak az esemény aktiválódása után hozza le az Amplitude-t a vonatkozó kategóriában, egy munkamenet-szintű őr, amely tiszteli az opt-out-ot anélkül, hogy elveszítené a felhasználó korábbi névtelen eszközazonosítóját, ahol a törvény ezt megengedi, és egy szerver oldali híd azokhoz az eseményekhez, amelyekhez hozzájárulásoktól függetlenül valóban szükséges az adatgyűjtés — például biztonsági telemetria vagy csalásészlelés — saját jogalapjával ellátott külön végponton keresztül irányítva.

Web implementáció

A weben a legtisztább minta az, ha a CMP hozzájárulási állapotát egy window.__cmp_consent objektumon vagy a szabványos __tcfapi visszahíváson keresztül tesszük elérhetővé, majd egy kis bootstrap szkript feliratkozik a hozzájárulási változásokra. Amikor az elemzési hozzájárulás hamisról igazra vált, a bootstrap letölti az Amplitude SDK-t a CMP által kezelt CDN-ről, meghívja az amplitude.init(apiKey, undefined, { defaultTracking: true }) függvényt, és visszajátssza az összes eseményt, amely a hozzájárulás függőben léte alatt memóriában volt sorba állítva. Amikor a hozzájárulás visszavált hamisra, a bootstrap meghívja az amplitude.setOptOut(true) függvényt, törli az AMP_ cookie-t a document.cookie lejáratával, és eltávolít minden memóriában lévő állapotot. Kritikusan fontos, hogy a bootstrap soha ne inicializálja lustán az Amplitude-t ugyanabban a kérésfolyamban, mint a banner renderelése — az SDK-nak explicit engedélyre kell várnia.

Mobil implementáció

iOS-en a megfelelője az, hogy az Amplitude keretrendszer importált marad, de az Amplitude.instance().initialize(apiKey: apiKey) meghívását addig halasztjuk, amíg az alkalmazáson belüli hozzájárulási folyamat pozitív elemzési jelzést nem adott vissza. Az ATT prompt külön kérdés: az ATT az IDFA-t szabályozza, míg az Amplitude azonosítója az SDK saját UUID-je, amelyet az app sandboxban tárolnak. Mindkettő hozzájárulást igényel az EEA-ban, de a jogalapok és a promptok különböznek. Androidon ugyanez a logika érvényes az Amplitude.getInstance().initializeApolloClient() vagy az SDK verziójától függő megfelelő hívással.

Szerver oldali mód

Az Amplitude támogatja a szerver oldali adatbevitelt a HTTP V2 API-n keresztül. A szerver oldali eseményekre nem vonatkozik hozzájárulási mentesség — a jogalap az adatot követi, nem az átvitelt — de a szerver oldali bevitel teljes kontrollt ad a kiadónak afelett, hogy mely mezőket küldi el, ami megkönnyíti a részleges hozzájárulás tiszteletben tartását. Egy általános minta az, hogy minimális, csak alapvető eseménykészletet rögzítünk szerver oldalon legitim érdek alapján, és ezeket az eseményeket csak akkor gazdagítjuk viselkedési részletekkel, ha a felhasználó az ügyfélen megadta az elemzési hozzájárulást.

Az integráció validálása

A validálási lépés az, amelyet a kiadók leggyakrabban kihagynak, és amelyet a szabályozók leggyakrabban ellenőriznek. Egy helyesen integrált Amplitude telepítésnek négy ellenőrzésen kell átmennie. Először: egy böngésző, amelyen a hozzájárulási banner megjelenik, de döntés még nem született, nem küldhet kérést az api.amplitude.com vagy az api.eu.amplitude.com felé, és nem tartalmazhat AMP_ cookie-kat a document.cookie-ban. Másodszor: az elemzési kategória elutasításának fenn kell tartania azt az állapotot — nincs esemény, nincs cookie, nincs helyi tároló bejegyzés AMP_ előtaggal. Harmadszor: az elemzés elfogadásának egyetlen identify hívást kell produkálnia eseményforgalom előtt, és az AMP_ cookie-nak meg kell jelennie egy SameSite attribútummal, amely összhangban van a kiadó CMP-politikájával. Negyedszer: a hozzájárulás utólagos visszavonásának azonnal meg kell állítania a további eseményeket és törölnie kell a tárolt azonosítókat — a késleltetett cleanup egy megállapítás.

Az audit trail külön számít. Az EDPB 2023-as cookie-banner iránymutatásai és a megújított 2026-os munkacsoport-prioritások alapján a szabályozók elvárják, hogy a kiadó bármely, az Amplitude projektben szereplő eseményről be tudja bizonyítani, hogy az azt generáló felhasználó érvényes hozzájárulást adott a rögzítés pillanatában. Ehhez a CMP hozzájárulási naplójának eszközazonosító vagy munkamenet-azonosító alapján lekérdezhetőnek kell lennie, és az Amplitude esemény hasznos terhelésének tartalmaznia kell egy hozzájárulás-verzió mezőt, amely visszaköt erre a naplóra. A hozzájárulási karakterlánc egyéni felhasználói tulajdonságként való tárolása minden eseményen a legegyszerűbb módja annak, hogy ezt a kapcsolatot auditálhatóvá tegyük.

A megfelelő régió és adattárolási hely megválasztása

Az Amplitude két termelési régiót működtet: az USA-t (api.amplitude.com) és az EU-t (api.eu.amplitude.com). Az EEA és az Egyesült Királyság forgalmához az EU régió a helyes alapértelmezett — az adatot az EEA-n belül tartja, és csökkenti az átviteli kockázati felületet, amelyet a Schrems II döntés és az EU-US Data Privacy Framework minden elemzési felülvizsgálat középpontjába helyezett. A régióváltás nem visszamenőleges: a meglévő adatok ott maradnak, ahol először bevitték. Ezért a CMP bevezetését tervező kiadók számára érdemes megerősíteni a régiót a skálázás előtt, és érdemes dokumentálni a döntést az adatvédelmi nyilatkozatban, hogy a jogalapok lánca tiszta legyen a gyűjtéstől a tárolásig. Egy helyesen megválasztott régió, egy helyesen korlátozott SDK-val és egy lekérdezhető hozzájárulási naplóval párosítva az, ami egy Amplitude telepítést szabályozói kockázatból az elemzési architektúra védhető részévé tesz.