Data Manager API zamiast Measurement Protocol: co zmienia się w wysyłce zdarzeń

Zdarzenia z backendu, takie jak zwroty w sklepie, konwersje z CRM czy odnowienia abonamentów B2B, trafiają do GA4 z pominięciem przeglądarki i kontenera GTM. Przez lata jedynym sposobem na taką integrację był Measurement Protocol. Google nie zamknął jeszcze tej drogi, ale przestał ją rozwijać. Zamiast tego mamy nowego następcę.

Wpis w changelogu GA4 z maja 2026 roku zapowiada wsparcie Data Manager API dla zdarzeń serwerowych. Google opisuje to jako bezpośrednią alternatywę dla Measurement Protocol przy wysyłce zdarzeń rekomendowanych i niestandardowych do usługi GA4. Obejmuje to strumienie internetowe i aplikacyjne, omijając jedynie zdarzenia zarezerwowane. My w agencji traktujemy to po prostu jako nowy standard dla wszystkich przyszłych integracji.

Co aktualnie mówi dokumentacja Measurement Protocol

Komunikat na stronie deweloperskiej Measurement Protocol brzmi dość jednoznacznie. Protokół osiągnął finalny stan produktu. Pozostanie dostępny i nie ma planów jego wyłączenia. Google dodaje tam jednak jedno zdanie, które całkowicie zmienia optykę. Dokumentacja wprost zaleca budowanie nowych integracji serwerowych na Data Manager API, nazywając je centralną infrastrukturą dla przyszłych usprawnień.

W praktyce oznacza to tyle, że twoje istniejące skrypty nie przestaną nagle działać. Nie goni nas żadna data graniczna. Z drugiej strony nie ma też żadnych powodów, aby spodziewać się w starym protokole jakichkolwiek nowości.

Pięć różnic z oficjalnego przewodnika

Oficjalny przewodnik migracyjny zawiera tabelę porównawczą. Wynikają z niej konkrety.

• Model danych. Data Manager API ma jeden wspólny model dla wszystkich produktów reklamowych Google. Measurement Protocol rozumie wyłącznie model GA4.
• Szyfrowanie. Data Manager API natywnie je obsługuje. Measurement Protocol nie ma takiej opcji.
• Destynacje. Jedno żądanie w nowym API może trafić do wielu miejsc jednocześnie. Measurement Protocol obsługuje zawsze tylko jeden strumień danych na żądanie.
• Klucz API. W Data Manager API w ogóle nie istnieje, ponieważ uwierzytelnianie odbywa się przez OAuth. W Measurement Protocol pole api_secret było i jest wymagane.
• Obsługa błędów. Data Manager API działa w modelu fast-fail. Measurement Protocol raportuje błędy wyłącznie podczas żądań testowych wysyłanych na dedykowany serwer walidacji.

Uwierzytelnianie znika z adresu URL

Tę zmianę doceni każdy, kto realnie dba o bezpieczeństwo infrastruktury. W Measurement Protocol klucz api_secret przesiaduje bezpośrednio w adresie żądania. To oznacza, że ląduje w logach serwera, w historii narzędzi diagnostycznych i w kopiach zapasowych. Wyciek takiego klucza pozwala komukolwiek wstrzykiwać fałszywe zdarzenia do twojej usługi, nie zostawiając absolutnie żadnego śladu w przeglądarce.

Data Manager API używa poświadczeń OAuth z odpowiednio dobranym zakresem. Sekret nie podróżuje w adresie, a dostępy można rotować po stronie projektu chmurowego. Przy współdzielonym koncie serwisowym to kolosalna różnica w skali potencjalnych szkód.

Destination jasno określa cel żądania

W starym protokole adres żądania zawierał po prostu identyfikator measurement_id i to wystarczało. W Data Manager API najpierw musisz zdefiniować cel, czyli destination, a dopiero potem pakujesz samo zdarzenie. Destination składa się z konta odbierającego dane (operatingAccount), konta z poświadczeniami (loginAccount) oraz identyfikatora strumienia danych (productDestinationId).

Dokumentacja wymusza tutaj dwa konkretne warunki. Przy typie konta GOOGLE_ANALYTICS_PROPERTY podajesz identyfikator usługi GA4, a jako productDestinationId wstawiasz measurement ID dla strony lub Firebase App ID dla aplikacji mobilnej. Druga kwestia bywa bardziej problematyczna. Poświadczenia muszą należeć do użytkownika GA4, który posiada rolę Edytującego albo Administratora w docelowej usłudze. Konto serwisowe, które dzisiaj pcha ci zdarzenia przez api_secret, zazwyczaj takiego dostępu po prostu nie ma. To absolutnie pierwsza rzecz, którą musimy ustalać z klientem przed rozpoczęciem prac deweloperskich.

Zupełną nowością jest opcja wysłania jednego żądania do wielu celów. Każde zdarzenie przyjmuje listę destinationReferences. Jeśli jej nie zdefiniujesz, zdarzenie poleci do wszystkich celów określonych w żądaniu. Google odpowiednio rozdziela pola pod spodem. Do GA4 trafią identyfikatory clientId i appInstanceId, a do Google Ads odpowiednie pola własne. Sklepy internetowe mogą w ten sposób zgłosić zakup do GA4 i do konwersji offline w Google Ads za pomocą pojedynczego żądania HTTP.

Fast-fail uczy pokory w monitorowaniu

Model fast-fail jest znacznie surowszy od tego, co znamy z innych API Google. Jeśli twoje żądanie posiada błąd w strukturze albo którykolwiek z rekordów oblał walidację pola wymaganego, całe żądanie natychmiast upada. Żadne dane nie zostaną przetworzone. Nie doświadczysz tutaj częściowego sukcesu, znanego chociażby z Google Ads API.

Brzmi groźnie, ale to ma też swoje pozytywne strony. Brak wypełnionego pola opcjonalnego nie niszczy całego żądania. Przy poprawnej odpowiedzi HTTP 200 możesz otrzymać listę fieldWarnings, która zasygnalizuje ci na przykład brak identyfikatora produktu w jednym z elementów koszyka. Zdarzenie przejdzie. To konkretne pole po prostu pozostanie puste.

Płynie z tego bardzo konkretny wniosek techniczny. Kod, który loguje wyłącznie status HTTP, po cichu zamieni błędy walidacji w milczenie. Dowiesz się o problemie dopiero wtedy, gdy sfrustrowany klient zapyta o niezrozumiały spadek konwersji w panelu. Loguj całą odpowiedź z serwera: kod, listę ostrzeżeń oraz requestId. Ten ostatni identyfikator jest obligatoryjny przy zgłaszaniu spraw do wsparcia Google, a bez niego namierzenie błędu graniczy z cudem. Przy wysyłkach wsadowych warto rozważyć mniejsze paczki, ponieważ jeden felerny rekord zablokuje tu całe żądanie.

Co pozostaje bez zmian

Measurement Protocol działa i nigdzie się nie wybiera. Migracja nie ma charakteru natychmiastowego pożaru do ugaszenia. Zdarzenia zarezerwowane wciąż odbijają się z błędem INVALID_EVENT_NAME. Główne identyfikatory się nie zmieniają. Nadal używamy client_id dla ruchu webowego, app_instance_id dla aplikacji mobilnych oraz opcjonalnego user_id. Sam proces weryfikacji również wygląda znajomo. Dane przeglądasz w raporcie Czas rzeczywisty albo bezpośrednio w narzędziu DebugView. Nowa jest jedynie flaga validate_only, która skutecznie zastępuje stary serwer testowy.

Kwestie RODO i zbiórka z backendu

Wysyłka zdarzeń z poziomu serwera całkowicie omija przeglądarkę, a co za tym idzie, omija bannery cookies i sygnały zgody użytkownika. To niesamowicie wygodne z technicznego punktu widzenia. Niesie jednak ze sobą potężne ryzyko prawne, jeśli traktujemy backend jako strefę z wyłączonymi przepisami. Dane przesyłane w ten sposób muszą posiadać jednoznaczną podstawę w rejestrze czynności przetwarzania.

Zupełnie inną kategorią ryzyk są dane kontaktowe. Przesyłanie zahashowanych adresów e-mail czy numerów telefonów do Customer Match to twarde przetwarzanie danych osobowych, a nie zwykły pomiar ruchu anonimowego. Data Manager API natywnie wspiera szyfrowanie. Sam proces szyfrowania nie zastąpi jednak legalnej podstawy prawnej ani wpisów w polityce prywatności. Przy zdarzeniach transakcyjnych najczęściej wystarcza sam numer transakcji powiązany z client_id. Dane kontaktowe dorzucamy wyłącznie w sytuacjach, gdy klient dysponuje zebraną zgodą. Szerzej analizujemy ten temat w liście kontrolnej RODO i Consent Mode.

Od czego zacząć migrację

1. Przygotuj inwentarz. Wypisz wszystkie systemy i zadania, które komunikują się przez stary protokół. Ustal właścicieli skryptów oraz pełną listę wysyłanych zdarzeń i parametrów.
2. Podejmuj decyzje dla każdej integracji osobno. Skrypt przesyłający jedno zliczenie dziennie nie wymaga przepisywania na wczoraj. Nowe projekty budujmy od teraz już wyłącznie na nowym API.
3. Ogarnij dostępy na chłodno. Włącz API w projekcie Cloud, wygeneruj poświadczenia i nadaj użytkownikowi GA4 rolę Edytującego w usłudze. To zazwyczaj trwa najdłużej ze względów biurokratycznych po stronie klienta.
4. Zmapuj pola zgodnie z dokumentacją i mocno przetestuj wywołania z użyciem flagi validate_only. Zwróć uwagę na timestamp, który stał się polem samego zdarzenia, a także na nowe pole eventSource.
5. Wdróż twarde monitorowanie. Zanim wypuścisz cokolwiek na produkcję, upewnij się, że zbierasz kody HTTP, ostrzeżenia i requestId w jednym dostępnym logu. Wysyłanie danych w ciemno to najczęstsza przyczyna dramatycznych dziur w raportach.

Kiedy lepiej odpuścić

Jeśli nadzorujesz skrypt, który wysyła prosty ping raz na dobę, nie dotyka danych osobowych klientów i działa absolutnie bezawaryjnie od dwóch lat, przesiadka na nowe API nie przyniesie ci niczego poza kosztami wdrożenia i ryzykiem regresji. Wystarczy dodać notatkę w dokumentacji technicznej i zamknąć temat. Wyjątek robimy w przypadku, gdy i tak przymierzamy się do połączenia wysyłki do GA4 z transferem konwersji offline do Google Ads. Wtedy użycie jednego wspólnego interfejsu staje się uzasadnione.