Dlaczego Amplitude wymaga zgody

Domyślny Amplitude Browser SDK i mobilne SDK Amplitude robią znacznie więcej niż rejestrowanie odsłon stron. Podczas inicjalizacji ustawiają identyfikator urządzenia w pamięci pierwszej strony, generują identyfikator sesji, przechwytują referer, parsują identyfikatory UTM i kliknięć z adresu URL oraz zaczynają kolejkować automatycznie przechwytywane zdarzenia: odsłony stron, kliknięcia elementów, interakcje z formularzami, pobieranie plików i — w najnowszych wydaniach — odtwarzania sesji. Wzbogacają też te zdarzenia o geolokalizację wywnioskowaną z IP, dane urządzenia wywnioskowane z klienta użytkownika i, jeśli skonfigurowano, wzbogacenie zewnętrzne od partnerów danych.

Każdy z tych kroków angażuje odrębną podstawę prawną zgody. Przechowywanie identyfikatora urządzenia to operacja przechowywania i dostępu na podstawie art. 5 ust. 3 dyrektywy ePrivacy, która wymaga uprzedniej, dobrowolnej, konkretnej, świadomej i jednoznacznej zgody na terenie Europejskiego Obszaru Gospodarczego, Zjednoczonego Królestwa i każdej jurysdykcji, która przyjęła ten sam standard. Przechwytywanie zdarzeń behawioralnych powiązanych z tym identyfikatorem stanowi przetwarzanie danych osobowych na podstawie GDPR. Wzbogacanie o dane zewnętrzne wprowadza drugą relację administratora danych. CCPA i CPRA klasyfikują to samo przetwarzanie jako sprzedaż lub udostępnianie, chyba że wydawca posiada właściwie skonstruowaną umowę z dostawcą usług z Amplitude — co jest dostępne, ale tylko jeśli integracja jest skonfigurowana tak, aby wyłączyć funkcje reklamowe.

Co Amplitude zbiera przed wyrażeniem zgody — i co należy zablokować

Najczęstszy błąd wdrożeniowy polega na traktowaniu Amplitude jako lekkiego narzędzia analitycznego, które może działać obok banera cookie. Nie może. Przy domyślnym wywołaniu amplitude.init() SDK podczas pierwszego renderowania strony zapisuje co najmniej jeden wpis do pliku cookie lub pamięci lokalnej, wysyła wywołanie identify i zaczyna buforować zdarzenia. Nic z tego nie jest dozwolone przed wyraźną akceptacją przez użytkownika odpowiedniej kategorii zgody.

Zgodna integracja musi zatem opóźniać amplitude.init() do momentu, gdy CMP zasygnalizuje, że kategoria zgody na analitykę została przyznana. SDK w ogóle nie powinien być ładowany ze znacznika <script> bramkowanego zgodą, który zależy od sygnału celu 8 (analityka) lub celu 1 (przechowywanie i dostęp) CMP, w zależności od tego, który framework udostępnia CMP. Jeśli SDK musi być załadowany wcześniej — na przykład dlatego, że jest dołączony do kodu aplikacji i nie może być pobierany leniwie — wywołanie inicjalizacji powinno przekazywać defaultTracking: false i optOut: true, tak aby żadne zdarzenia nie były emitowane do momentu zarejestrowania zgody, a następnie odroczony event opt-in powinien odwrócić te flagi.

Pliki cookie i pamięć zapisywana przez Amplitude

Browser SDK 2.x domyślnie zapisuje jeden plik cookie pierwszej strony o nazwie AMP_{apiKey}, z rocznym terminem ważności, zawierający identyfikator urządzenia i metadane sesji. Starsze wersje zapisywały też amplitude_id_{apiKey}. Mobilne SDK przechowują ten sam identyfikator w izolowanej pamięci aplikacji. Odtwarzanie sesji dodaje drugi plik cookie, AMP_MKTG_{apiKey}, a partnerzy wzbogacający Amplitude mogą ustawiać dodatkowe pliki cookie zewnętrzne, jeśli moduły targetowania eksperymentu lub odbiorców są włączone. Wszystkie są nieistotne i wymagają zgody.

Mapowanie Amplitude do ram zgody

Amplitude nie implementuje natywnie Google Consent Mode v2, IAB TCF ani IAB Global Privacy Platform. To nie jest wada — Amplitude jest platformą analityki pierwszej strony, a nie dostawcą technologii reklamowej — ale oznacza, że odpowiedzialność za integrację spoczywa na wydawcy. Wzorzec, który działa w praktyce, to traktowanie każdego modułu Amplitude jako osobnej bramy zgody i powiązanie go z konkretnym sygnałem, który CMP już udostępnia.

• Podstawowe zdarzenia analityczne są powiązane z celem analitycznym. W terminologii TCF jest to najczęściej cel 8 (pomiar wydajności treści) połączony z celem 1 (przechowywanie i/lub dostęp do informacji). Dla Google Consent Mode odpowiada to analytics_storage.
• Odtwarzanie sesji powinno być za surowszym sygnałem. Odtwarzanie przechwytuje wyrenderowany DOM, w tym wartości formularzy, chyba że są wyraźnie maskowane, więc odpowiednia jest osobna opcja opt-in dla preferences lub functional, a odtwarzanie powinno być domyślnie wyłączone, nawet gdy analityka jest przyznana.
• Odbiorcy, kohorty i zewnętrzne wzbogacanie są powiązane z celem marketingowym. W terminologii TCF jest to cel 7 (pomiar wydajności reklam) lub cel 9 (stosowanie badań rynku). Dla Google Consent Mode odpowiada to ad_storage i ad_user_data.
• Eksperymentowanie — Amplitude Experiment może działać z anonimową, efemeryczną alokacją na podstawie uzasadnionego interesu, ale trwała alokacja powiązana z identyfikatorem użytkownika wymaga tej samej zgody co podstawowa analityka.

Wzorzec integracji, który działa

Implementacja referencyjna, która przetrwa weryfikację regulatora, ma cztery ruchome elementy: CMP udostępniające zdarzenie w czasie rzeczywistym, gdy użytkownik zmienia zgodę, odroczony program ładujący SDK, który pobiera Amplitude dopiero po uruchomieniu tego zdarzenia dla odpowiedniej kategorii, ochronę na poziomie sesji, która respektuje rezygnację bez utraty poprzedniego anonimowego identyfikatora urządzenia użytkownika tam, gdzie prawo na to pozwala, oraz serwerowe przejście dla zdarzeń, które naprawdę wymagają zbierania niezależnie od zgody — takich jak telemetria bezpieczeństwa lub wykrywanie fraudu — kierowane przez osobny punkt końcowy z własną podstawą prawną.

Implementacja webowa

W internecie najczystszy wzorzec to udostępnienie stanu zgody CMP przez obiekt window.__cmp_consent lub standardowe wywołanie zwrotne __tcfapi, a następnie subskrybowanie zmian zgody przez mały skrypt bootstrap. Gdy zgoda na analitykę przełącza się z false na true, bootstrap pobiera SDK Amplitude z CDN zarządzanego przez CMP, wywołuje amplitude.init(apiKey, undefined, { defaultTracking: true }) i odtwarza wszelkie zdarzenia, które były kolejkowane w pamięci podczas oczekiwania na zgodę. Gdy zgoda przełącza się z powrotem na false, bootstrap wywołuje amplitude.setOptOut(true), usuwa plik cookie AMP_ przez wygaśnięcie document.cookie i usuwa wszelki stan w pamięci. Co krytyczne, bootstrap nigdy nie może leniwie inicjalizować Amplitude w tym samym przepływie żądań co renderowanie banera — SDK musi czekać na wyraźne przyznanie zgody.

Implementacja mobilna

Na iOS odpowiednikiem jest zachowanie importowanego frameworka Amplitude, ale odroczenie Amplitude.instance().initialize(apiKey: apiKey) do momentu, gdy przepływ zgody w aplikacji zwróci pozytywny sygnał analityczny. Monit ATT jest odrębną kwestią: ATT rządzi IDFA, podczas gdy identyfikator Amplitude to własny UUID SDK przechowywany w piaskownicy aplikacji. Oba wymagają zgody w EOG, ale podstawy prawne i monity są różne. Na Androidzie ta sama logika obowiązuje z Amplitude.getInstance().initializeApolloClient() lub odpowiednikiem w zależności od wersji SDK.

Tryb po stronie serwera

Amplitude obsługuje pozyskiwanie po stronie serwera przez HTTP V2 API. Zdarzenia po stronie serwera nie są zwolnione z obowiązku uzyskania zgody — podstawa prawna podąża za danymi, a nie za transportem — ale pozyskiwanie po stronie serwera daje wydawcy pełną kontrolę nad wysyłanymi polami, co ułatwia respektowanie częściowej zgody. Popularnym wzorcem jest gromadzenie po stronie serwera minimalnego zestawu tylko niezbędnych zdarzeń na podstawie uzasadnionego interesu, a wzbogacanie tych zdarzeń o szczegóły behawioralne dopiero po udzieleniu przez użytkownika zgody na analitykę po stronie klienta.

Walidacja integracji

Krok walidacji jest tym, który wydawcy najczęściej pomijają, a regulatorzy najczęściej sprawdzają. Prawidłowo zintegrowane wdrożenie Amplitude powinno przejść cztery kontrole. Po pierwsze, przeglądarka z wyświetlonym banerem zgody, ale bez dokonanego wyboru, powinna generować zero żądań do api.amplitude.com lub api.eu.amplitude.com i zero plików cookie AMP_ w document.cookie. Po drugie, odrzucenie kategorii analityki powinno utrzymywać ten stan — brak zdarzeń, brak plików cookie, brak wpisów w pamięci lokalnej z prefiksem AMP_. Po trzecie, zaakceptowanie analityki powinno generować jeden identify, po którym następuje ruch zdarzeń, a plik cookie AMP_ powinien pojawić się z atrybutem SameSite zgodnym z polityką CMP wydawcy. Po czwarte, cofnięcie zgody po fakcie powinno natychmiast zatrzymać dalsze zdarzenia i wyczyścić przechowywane identyfikatory — opóźnione czyszczenie jest ustaleniem.

Ślad audytu jest ważny niezależnie. Zgodnie z wytycznymi EDPB dotyczącymi banerów cookie z 2023 r. i odnowionymi priorytetami grupy roboczej na 2026 r., regulatorzy oczekują, że wydawca będzie w stanie udowodnić, dla dowolnego zdarzenia w projekcie Amplitude, że użytkownik, który je wygenerował, udzielił ważnej zgody w momencie przechwycenia. Wymaga to, aby dziennik zgód CMP był możliwy do odpytania według identyfikatora urządzenia lub sesji, a ładunek zdarzenia Amplitude zawierał pole wersji zgody powiązane z tym dziennikiem. Przechowywanie ciągu zgody jako właściwości niestandardowej użytkownika w każdym zdarzeniu to najprostszy sposób na uczynienie tego powiązania możliwym do audytu.

Wybór właściwego regionu i miejsca przechowywania danych

Amplitude obsługuje dwa regiony produkcyjne: USA (api.amplitude.com) i UE (api.eu.amplitude.com). Dla ruchu z EOG i Zjednoczonego Królestwa region UE jest właściwym domyślnym — przechowuje dane wewnątrz EOG i zmniejsza powierzchnię ryzyka transferu, którą wyrok Schrems II i Ramy Prywatności Danych UE-USA uczyniły centralną dla każdego przeglądu analitycznego. Zmiana regionów nie jest retroaktywna: istniejące dane pozostają tam, gdzie zostały po raz pierwszy pozyskane. Dla wydawców planujących wdrożenie CMP warto zatem potwierdzić region przed skalowaniem i udokumentować wybór w informacji o prywatności, aby łańcuch podstaw prawnych był przejrzysty od zbierania do przechowywania. Właściwie wybrany region, połączony z prawidłowo bramkowanym SDK i możliwym do odpytania dziennikiem zgód, to to, co przekształca wdrożenie Amplitude z ryzyka regulacyjnego w dającą się obronić część stosu analitycznego.