Przenoszenie identyfikatorów użytkowników GA4 na serwer: opcja migracji w Tag Managerze

Klient GA4 w serwerowym Google Tag Managerze odbiera żądania pomiarowe i przygotowuje zdarzenia dla tagów serwerowych. Sposób identyfikacji określa identyfikator przeglądarki w danych wysyłanych do GA4. Zmiana identyfikatora może wpłynąć na liczbę użytkowników, przypisanie sesji i analizy długoterminowe.

Dwa różne ustawienia

JavaScript Managed wykorzystuje Client ID przekazany przez przeglądarkę. Typowy plik _ga zawiera identyfikator wraz z elementami formatu: GA1.1.123456789.1680000000 to wartość cookie, a 123456789.1680000000 to zawarty w wartości Client ID. Client ID nie stanowi wiarygodnej tożsamości osoby.

Server Managed wykorzystuje identyfikator zarządzany przez serwer, zwykle zapisany w cookie FPID. Cookie ustawia odpowiedź HTTP, ale dane nadal są przechowywane w przeglądarce. Dodatkowa opcja Migrate from JavaScript Managed Client ID dotyczy przejścia z istniejących identyfikatorów przeglądarkowych; sam checkbox nie wybiera trybu zarządzania.

Co ma zachować migracja

W istniejącym pomiarze migracja ma ograniczać nagłą zmianę dotychczasowych Client ID. Nie oznacza to wstecznego połączenia wszystkich identyfikatorów ani gwarancji niezmienionej atrybucji, czyli przypisania konwersji do źródła marketingowego. Ustawienie nie odzyskuje identyfikatorów wcześniej usuniętych lub wygasłych.

Opis „zamiana starego cookie na FPID z zachowaniem tej samej tożsamości GA4 na zawsze” jest niewystarczający. Znaczenie ma przekazywany dalej client_id. Przed zmianą produkcyjną porównanie identyfikatorów wejściowych i wyjściowych w używanej wersji klienta musi ustalić obsługę istniejących ID, nowych profili i wcześniej ustawionych cookies FPID.

HttpOnly zapewnia określoną ochronę

HttpOnly uniemożliwia bezpośredni dostęp do cookie z JavaScript strony, na przykład przez document.cookie. Cross-site scripting (XSS) oznacza uruchomienie wstrzykniętego złośliwego kodu w kontekście witryny. HttpOnly ogranicza prostą kradzież cookies w części takich ataków. Witryna nie staje się jednak odporna na XSS: złośliwy kod nadal może zmieniać zawartość strony lub inicjować żądania. Identyfikator analityczny różni się także od cookie sesji logowania.

Dwa lata w Safari nie są gwarantowane

Skonfigurowana data wygaśnięcia nie gwarantuje rzeczywistego okresu przechowywania. WebKit ogranicza w określonych sytuacjach także cookies ustawiane w odpowiedziach HTTP: wykrycie maskowania strony trzeciej przez CNAME lub adres IP oznacza limit siedmiu dni. Sesje prywatne, usuwanie cookies i ustawienia przeglądarki mogą dodatkowo ograniczyć dostępność. ITP, czyli Intelligent Tracking Prevention w WebKit, to zestaw mechanizmów przeglądarki ograniczających śledzenie. FPID nie omija tych mechanizmów w każdej sytuacji.

Testy muszą obejmować własny punkt odbioru, domenę i ścieżkę cookie, HTTPS oraz rzeczywiste odpowiedzi przeglądarki. Wymogi dotyczące zgody nadal odnoszą się do zapisu i wykorzystania identyfikatora.

Kontrolowany test przejścia

1. Zapis aktualnej wersji kontenera i ustawień. Początkowo osobna konfiguracja pomiaru testowego.
2. Profil z istniejącym Client ID oraz nowy profil. Porównanie identyfikatorów wejściowych, cookies odpowiedzi i identyfikatorów wysyłanych do GA4.
3. Osobne testy kolejnych stron, istniejącego FPID, wygasłych lub usuniętych identyfikatorów, odmowy i wycofania zgody.
4. Uwzględnienie wszystkich ścieżek zdarzeń: przeglądarki, zakupów serwerowych, ewentualnego Measurement Protocol i wielu domen. Różne ID mogą podzielić tę samą ścieżkę.
5. Po kontrolowanej publikacji obserwacja użytkowników, sesji i przypisania kampanii według przeglądarki w odniesieniu do faktycznej daty wdrożenia.

Zmiana identyfikatora może osłabić ciągłość historii. Nie oznacza to jednak, że każda wizyta musi zostać uznana za nowego użytkownika albo każda konwersja trafi do „Direct / None”. Wynik zależy także od innych sygnałów tożsamości, parametrów kampanii i ustawień raportów.