Zamrożone, nie wyłączone

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

  dostęp: obecnie przez listę dopuszczeń

Co przemawia przeciw natychmiastowej zmianie

Dostęp do Data Manager API biegnie przez listę dopuszczeń. Dla części użytkowników 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.