Measurement Protocol GA4 w trybie utrzymania: co się zmienia i kiedy warto przejść na Data Manager API

Spis treści
Na stronie Google poświęconej Measurement Protocol widnieje od czerwca 2026 wzmianka opisująca niecodzienny stan: interfejs osiągnął dojrzały, zamknięty stan produktu i pozostaje w działaniu, a wycofanie nie jest planowane. Dla integracji serwer-serwer zalecane jest w zamian Data Manager API, określone jako centralna infrastruktura przyszłych nowości w przyjmowaniu danych.
W tłumaczeniu znaczy to: nic nie zostaje wyłączone i nic nie dochodzi. To nie termin, lecz rozjazd – a rozjazdy wymagają decyzji w chwili, której nikt nie wyznacza.

Co tryb utrzymania znaczy w praktyce
Istniejąca integracja działa dalej. Kto dziś dosyła do GA4 zamówienia z systemu magazynowego albo zamknięte transakcje z systemu obsługi klienta, nie musi niczego ruszać, i nie ma daty, w której cokolwiek przestaje działać.
Przestaje rozwój. Każda przyszła możliwość w przyjmowaniu danych po stronie serwera powstaje w nowym interfejsie. Konfiguracja stojąca na Measurement Protocol starzeje się więc nie przez to, że się psuje, lecz przez to, że otoczenie wokół niej zyskuje zdolności, po które ona nie potrafi sięgnąć.
Trzy różnice, które się liczą
Pierwsza to uwierzytelnienie. Measurement Protocol pracuje z api_secret wysyłanym w zapytaniu – długowieczną tajemnicą w ciągu znaków, która ląduje w dziennikach i rzadko bywa wymieniana. Data Manager API wymaga OAuth 2.0 z zakresem datamanager. Wspólna tajemnica znika, a uprawnienie da się związać z kontem usługi i odebrać pojedynczo.
Druga to zasięg jednego żądania. Measurement Protocol rozmawia z Google Analytics. Google Ads albo Display & Video 360 wymagają innego interfejsu z własnym schematem, własnym uwierzytelnieniem i własną obsługą błędów. Data Manager API sprowadza te cele pod jeden model danych; jedno zdarzenie może w jednym żądaniu trafić do kilku z nich.
Trzecia dotyczy identyfikatorów. Nowy interfejs obsługuje do dziesięciu identyfikatorów na rekord oraz szyfrowanie XChaCha20-Poly1305, którego zarządzanie kluczami może leżeć w Google Cloud albo w AWS. Dla danych dopasowywanych znaczy to, że identyfikator opuszcza firmę zaszyfrowany, a nie jedynie zahaszowany.
To samo zadanie, dwie drogi
Measurement Protocol
POST /mp/collect?measurement_id=G-…&api_secret=…
jeden punkt końcowy, jeden cel, tajemnica w zapytaniu
identyfikatory jawnie albo zahaszowane
Data Manager API
REST albo gRPC, OAuth 2.0, zakres "datamanager"
jedno wywołanie, kilka celów Google
do 10 identyfikatorów na rekord, XChaCha20-Poly1305
lista dopuszczeń: tylko zdarzenia GA z identyfikatorem transakcji jako dodatkowe źródło
Co przemawia przeciw natychmiastowej zmianie
Przesyłanie do GA4 zdarzeń z identyfikatorem transakcji jako dodatkowego źródła danych biegnie w Data Manager API przez listę dopuszczeń. Dla użytkowników, którzy potrzebują właśnie tego, migracja nie jest zatem w ogóle decyzją, lecz kolejką, a plan zbudowany na dostępie jeszcze nieprzyznanym nie jest planem.
Dochodzi do tego nakład niedoceniany przy każdej zmianie interfejsu: OAuth wymaga konta usługi, zarządzania kluczami i sposobu na zauważenie wygasłego uprawnienia, zanim zabraknie trzech dni transakcji. api_secret w zmiennej środowiskowej nie ma żadnego z tych wymagań – i to jest jednocześnie jego słabością i powodem, dla którego istniejąca integracja potrzebuje tak mało opieki.
Kiedy zmiana się opłaca
Trzy przypadki przemawiają za nią wyraźnie. Pierwszy to planowana druga integracja: kto i tak zamierza dostarczać transakcje również do Google Ads, zbuduje inaczej drugą integrację obok pierwszej i będzie potem utrzymywał dwie. Drugi to obchodzenie się z danymi osobowymi – tam, gdzie identyfikatory opuszczają firmę, szyfrowanie z własnym zarządzaniem kluczami to inna rozmowa z działem ochrony danych niż wartość skrótu. Trzeci to budowa od nowa, bo zaczynanie nieistniejącej jeszcze integracji na zamrożonym interfejsie kosztuje tę samą pracę dwa razy.
Tam, gdzie żaden z tych przypadków nie zachodzi, czekanie jest do obrony, a nawet nasuwa się samo. Wzmianka na stronie Google nie jest odliczaniem. Jest informacją, że jeden interfejs jest gotowy, a drugi jest budowany dalej, i ta informacja nie zmienia się przez to, że ktoś przeczyta ją pół roku później.
Pytania i odpowiedzi
Dlaczego api_secret w zapytaniu to coś więcej niż defekt kosmetyczny?
Ponieważ adres wraz z zapytaniem trafia do wielu miejsc, których nikt nie traktuje jak schowka na tajemnice: do dzienników dostępu serwerów proxy i load balancerów, do komunikatów o błędach, do narzędzi monitorujących i do dzienników samej aplikacji. Każde z tych miejsc przechowuje wtedy tajemnicę tak długo, jak długo przechowuje swoje wpisy, często dłużej, niż powinna ona obowiązywać.
Kto zna tajemnicę, nie odczyta za jej pomocą danych z GA4, ale może zapisywać dowolne zdarzenia w strumieniu danych. Szkodą nie jest więc wyciek danych, lecz zafałszowane raporty, a wychodzi ona na jaw późno, bo podrzucone zdarzenia wyglądają jak prawdziwe.
Dopóki istniejąca integracja działa dalej, środkiem zaradczym pozostaje wymiana tajemnicy. GA4 pozwala utworzyć kilka takich tajemnic na strumień danych, widocznych w ustawieniach strumienia jako „Measurement Protocol API secrets”, więc wymiana polega na utworzeniu i wdrożeniu nowej, a na usunięciu starej dopiero potem. OAuth 2.0 w Data Manager API rozwiązuje ten sam problem u podstaw, bo tokeny dostępu są krótkotrwałe i nie są umieszczane w adresie.
Czy oba interfejsy mogą działać równolegle w trakcie przejścia?
Tak, o ile to samo zdarzenie nie trafia obiema drogami do tego samego celu, bo inaczej transakcje pojawią się w GA4 podwójnie. Czystym rozwiązaniem jest podział według celów, na przykład GA4 dalej przez Measurement Protocol, a Google Ads już przez Data Manager API, albo twarde przełączenie każdego celu w ustalonym momencie.
Jak wychodzi na jaw błędna albo wygasła integracja, zanim zabraknie transakcji?
W obu interfejsach w różny sposób. Measurement Protocol odpowiada na każde otrzymane żądanie statusem powodzenia, nawet gdy zdarzenie jest błędne albo zostaje odrzucone. Sprawdzenie w punkcie walidacyjnym /debug/mp/collect pokazuje błędy, ale należy do etapu tworzenia, a nie do każdego żądania. W działaniu pozostaje tylko uzgadnianie: liczba wysłanych zdarzeń wobec liczby tych, które docierają do GA4.
W Data Manager API brak albo wygaśnięcie uprawnienia objawia się natomiast odpowiedzią z błędem. Alarm na odpowiedzi spoza zakresu powodzenia wystarcza wtedy, by zauważyć problem przy pierwszym niepowodzeniu, a nie dopiero po brakujących transakcjach, o ile integracja w ogóle analizuje odpowiedzi.