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

Refund w sklepie, konwersja z CRM, zamówienie złożone telefonicznie, odnowienie abonamentu w B2B. Każde z tych zdarzeń wchodzi do GA4 z backendu, bez przeglądarki i bez kontenera GTM. Przez lata prowadziła do nich jedna droga: Measurement Protocol. Google nie zamknął tej drogi, ale przestał ją rozwijać i wskazał następcę.

Wpis z 7 maja 2026 w changelogu GA4 zapowiada wsparcie Data Manager API dla zdarzeń serwerowych. Google opisuje je jako alternatywę dla Measurement Protocol przy wysyłce zdarzeń rekomendowanych i niestandardowych bezpośrednio do usługi GA4, dla strumieni internetowych i aplikacyjnych, z wyjątkiem zdarzeń zarezerwowanych. Dla agencji to zmiana dla nowych integracji.

Co dziś pisze Google na stronie Measurement Protocol

Nagłówek na stronie deweloperskiej Measurement Protocol brzmi jednoznacznie: protokół osiągnął dojrzały, finalny stan produktu i pozostanie dostępny, bez planów wycofania. Google dodaje jednak zdanie, które rozstrzyga kierunek: żeby zabezpieczyć konfigurację na przyszłość, nowe integracje serwerowe warto budować na Data Manager API, które jest centralną infrastrukturą Google dla przyszłych usprawnień w pozyskiwaniu danych.

W praktyce: istniejące skrypty nie przestaną działać i nie ma daty granicznej, ale nie ma też podstaw, żeby spodziewać się nowych funkcji.

Pięć różnic, które Google podaje wprost

Oficjalny przewodnik migracyjny zawiera tabelę porównawczą.

• Model danych. Data Manager API ma jeden model współdzielony ze wszystkimi produktami reklamowymi Google. Measurement Protocol zna tylko model GA4.
• Szyfrowanie. Data Manager API je obsługuje. Measurement Protocol nie.
• Destynacje. Jedno żądanie może trafić do wielu miejsc jednocześnie. Measurement Protocol obsługuje jeden strumień danych na żądanie, czyli jeden measurement ID albo jeden Firebase App ID.
• Klucz API. W Data Manager API nie istnieje, bo uwierzytelnianie idzie przez OAuth. W Measurement Protocol api_secret jest wymagane.
• Obsługa błędów. Data Manager API działa w modelu fast-fail. Measurement Protocol raportuje błędy wyłącznie dla żądań testowych wysłanych na serwer walidacji.

Uwierzytelnianie wychodzi z adresu URL

To zmiana, którą docenią osoby odpowiedzialne za bezpieczeństwo. W Measurement Protocol api_secret siedzi w query stringu, czyli w adresie żądania. Adresy trafiają do logów serwera, do historii narzędzi diagnostycznych i do kopii zapasowych. Wyciek takiego sekretu pozwala wstrzykiwać fałszywe zdarzenia do usługi, bez śladu w przeglądarce.

Data Manager API używa poświadczeń OAuth z właściwym zakresem. Klucz nie wędruje w adresie, a dostęp można rotować po stronie projektu. Przy wspólnym koncie serwisowym to różnica w skali szkody.

Destination opisuje, dokąd idzie zdarzenie

W Measurement Protocol adres żądania zawierał measurement_id albo firebase_app_id i to wystarczało. W Data Manager API najpierw opisujesz cel, czyli destination, a dopiero potem samo zdarzenie. Destination ma trzy elementy: operatingAccount, czyli konto odbierające dane, loginAccount, czyli konto, na którym dostęp ma osoba z poświadczeniami, oraz productDestinationId, czyli identyfikator strumienia danych.

Warto zapamiętać dwa warunki z dokumentacji. Przy typie konta GOOGLE_ANALYTICS_PROPERTY pole account_id przyjmuje identyfikator usługi GA4, a productDestinationId to measurement ID strumienia internetowego lub Firebase App ID dla aplikacji. Druga sprawa jest organizacyjna: poświadczenia muszą należeć do użytkownika GA4 z rolą Edytujący albo Administrator w tej usłudze. Konto serwisowe, które dziś wysyła zdarzenia przez api_secret, często nie ma dostępu do usługi GA4. To pierwsza rzecz do ustalenia z klientem, zanim ktokolwiek napisze kod.

Do tego dochodzi możliwość wysłania jednego żądania do wielu celów. Każde zdarzenie może mieć listę destinationReferences, a jeśli jej nie ustawisz, trafi do wszystkich celów w żądaniu. Google rozdziela pola według typu celu: do GA4 pójdą clientId, appInstanceId i eventName, do Google Ads pola własne. Dla e-commerce oznacza to, że ten sam zakup można zgłosić do usługi GA4 i do konwersji offline w Google Ads jednym wywołaniem.

Fast-fail zmienia sposób monitorowania

Model fast-fail jest surowszy niż w innych API Google. Jeśli żądanie zawiera błąd struktury albo którykolwiek rekord nie przejdzie walidacji pola wymaganego, całe żądanie pada i żadne dane z niego nie zostaną przetworzone. Nie ma częściowego sukcesu, do którego przyzwyczaiło choćby Google Ads API.

To brzmi groźnie, ale ma drugą stronę. Pole nieobowiązkowe nie wywala żądania. Przy odpowiedzi HTTP 200 możesz dostać listę fieldWarnings, na przykład o brakującym identyfikatorze produktu w pozycji koszyka. Żądanie przejdzie, ale pole zostanie puste.

Wniosek jest praktyczny. Kod, który loguje tylko status HTTP, zamieni błąd w ciszę, a ty dowiesz się o nim, gdy klient zapyta o spadek konwersji. Loguj całą odpowiedź: kod, listę ostrzeżeń i requestId. Ten ostatni identyfikator Google wymaga przy zgłoszeniu do wsparcia i bez niego trudno cokolwiek odtworzyć. Przy wysyłce wsadowej rozważ mniejsze paczki, bo jeden wadliwy rekord blokuje całe żądanie.

Co zostaje bez zmian

Measurement Protocol nadal działa i nie ma zapowiedzi wyłączenia, więc migracja nie jest gaszeniem pożaru. Zdarzenia zarezerwowane są nadal odrzucane, z błędem INVALID_EVENT_NAME. Identyfikatory pozostają te same: client_id dla zdarzeń internetowych, app_instance_id dla aplikacji, user_id opcjonalnie. Weryfikacja też się nie zmienia, bo dalej sprawdzasz dane w raporcie Czas rzeczywisty albo w DebugView. Nowością jest flaga validate_only, która zastępuje serwer walidacji.

RODO, zgody i wysyłka z backendu

Wysyłka serwerowa omija przeglądarkę, a razem z nią banner i sygnały zgody. To wygodne technicznie i ryzykowne prawnie, jeśli traktujesz backend jako miejsce bez przepisów. Dane, które wysyłasz, muszą mieć podstawę w rejestrze czynności przetwarzania.

Osobna kategoria to dane kontaktowe. Wysyłka zahashowanego adresu e-mail czy telefonu do Customer Match albo przez pole user_data to inne przetwarzanie niż pomiar ruchu. Data Manager API wspiera szyfrowanie, czego Measurement Protocol nie potrafi, ale szyfrowanie nie zastępuje podstawy prawnej ani informacji w polityce prywatności. Przy zdarzeniach transakcyjnych zwykle wystarczy identyfikator transakcji i client_id. Dane kontaktowe dodawaj tylko wtedy, gdy klient ma na to zgodę i wpis w dokumentacji. Podstawy zgód po stronie przeglądarki opisaliśmy w liście kontrolnej RODO i Consent Mode.

Od czego zacząć migrację

1. Zrób inwentarz. Wypisz skrypty i zadania, które dziś wołają Measurement Protocol: kto jest właścicielem, jakie zdarzenia i pola wysyła.
2. Zdecyduj per integracja, nie hurtem. Skrypt wysyłający jedno zdarzenie dziennie nie wymaga przepisania w tym tygodniu. Nowy projekt buduj od razu na Data Manager API.
3. Przygotuj dostęp. Włącz API w projekcie, wygeneruj poświadczenia z właściwym zakresem i nadaj użytkownikowi GA4 rolę Edytującego albo Administratora w usłudze klienta. To zwykle najdłuższy krok, bo wymaga zgody po stronie klienta.
4. Przenieś pola według mapowań z dokumentacji i przetestuj na validate_only. Zwróć uwagę na timestamp, który w Data Manager API jest polem zdarzenia, a nie żądania, oraz na pole eventSource.
5. Ustaw monitorowanie odpowiedzi, zanim wdrożysz wysyłkę na produkcji. Kod HTTP, ostrzeżenia i requestId w jednym miejscu, z alertem przy błędzie. Sama wysyłka bez obserwacji to najczęstszy sposób na cichy brak danych.

Kiedy nie ruszać tematu

Jeśli wysyłasz jeden typ zdarzenia raz na dobę, bez danych osobowych, a skrypt działa od dwóch lat, migracja nie wnosi nic poza ryzykiem regresji. Minimum to notatka w dokumentacji i decyzja, że nowe integracje powstaną już na tym API. Wyjątkiem jest sytuacja, gdy i tak łączysz wysyłkę do GA4 z wgraniem konwersji do Google Ads. Wtedy jedno API zamiast dwóch zaczyna się liczyć.