Migracja na server-side: jak przenieść tracking bez utraty danych

Migracja na tagowanie server-side to nie jest przełącznik, który się pstryka. To przebieg równoległy: stawiasz serwer, wysyłasz zdarzenia jednocześnie do starej i nowej konfiguracji, uzgadniasz liczby, aż zaczną się zgadzać, i dopiero wtedy wyłączasz starą.

Zrób to inaczej, a dowiesz się, co się zepsuło, patrząc na wykres przychodów trzy tygodnie za późno.

Najczęstsza awaria, jaką widuję, to przełączenie wszystkiego naraz w piątek. W podglądzie GTM wygląda dobrze, tagi się odpalają, serwer odpowiada 200, zespół idzie do domu. W poniedziałek zakupy w GA4 są niższe o 40% i nikt nie potrafi powiedzieć, czy spadła sprzedaż, czy tracking. Obie wersje są prawdopodobne. I to ta niejednoznaczność jest kosztowna, nie sam błąd.

Ten artykuł to playbook migracji: co naprawić przed startem, jak puścić oba systemy równolegle, lista uzgodnień, pięć rzeczy, które się psują, i jak się wycofać.

Zanim zaczniesz: napraw to, co już jest zepsute

Tagowanie server-side przenosi Twój tracking. Nie naprawia go.

Jeśli Twoje zdarzenie purchase odpala się dziś dwa razy, będzie odpalać się dwa razy również na serwerze. Jeśli Twoje wdrożenie zgód jest błędne, przeniesienie go na server-side sprawi, że będzie błędne w miejscu, którego nikt nie zobaczy w konsoli przeglądarki. Wydasz €2000 i trzy tygodnie, żeby odtworzyć swoje dotychczasowe błędy w droższej architekturze.

Najpierw przeprowadź kontrolę:

1. Czy coś jest podwójnie otagowane? Wyświetl źródło, poszukaj gtag(. Jeśli tam jest, a GTM ma też tag konfiguracyjny GA4, napraw to, zanim tkniesz cokolwiek innego.
2. Czy GA4 zgadza się z backendem? Weź wczorajsze zamówienia z bazy. Porównaj z zakupami w GA4. Jeśli różnica przekracza 5%, dowiedz się dlaczego teraz, a nie w trakcie migracji, kiedy każda rozbieżność zostanie zrzucona na serwer.
3. Czy zgody faktycznie działają? Odmów zgody, przeładuj, potwierdź, że nic się nie odpala. Jeśli mimo to się odpala, masz problem z compliance, który server-side ukryje, zamiast rozwiązać.

Ten krok jest nudny i wszyscy go pomijają. Jest też różnicą między migracją, która trwa trzy tygodnie, a taką, która trwa trzy miesiące.

Nie wiesz, w jakim stanie jest Twój tracking? Darmowy audyt GTM robi te kontrole automatycznie. Podajesz adres, dostajesz raport w około 10 minut. Bez rejestracji.

Faza 1: Postaw serwer i nie ruszaj niczego

Wdróż serwer tagujący, wskaż na niego subdomenę i zatrzymaj się.

Potrzebujesz analytics.twojastrona.pl (albo podobnej) wskazującej na Twój kontener serwerowy, na Twojej własnej domenie, z ważnym certyfikatem. Nie na domenie od Google: jeśli ciasteczko nie jest ustawiane na Twojej domenie, tracisz całą korzyść z jego żywotności, która uzasadniała ten projekt.

Na tym etapie zero ruchu produkcyjnego z niego korzysta. I tak ma być. Powstrzymaj się przed przeniesieniem jednego taga "tylko na próbę".

Kontrola kosztów: dla większości średnich stron wychodzi między €50 a €200/miesiąc. Dwie rzeczy potrafią wysadzić tę liczbę: źle ustawione minimum autoskalowania i domyślne logowanie każdego żądania do Cloud Logging. Wyłącz logowanie żądań, chyba że akurat debugujesz, bo inaczej rachunek za logi przewyższy rachunek za moc obliczeniową.

Faza 2: Przebieg równoległy

To rdzeń migracji i część, którą ludzie pomijają.

Utwórz drugą usługę GA4. Nie drugi strumień danych, tylko całą drugą usługę. Skieruj na nią swój tag GA4 po stronie serwera. Twoja usługa produkcyjna dalej odbiera dane client-side, dokładnie jak wcześniej.

Teraz działa jedno i drugie. Client-side do Usługi A (produkcja, nietknięta). Server-side do Usługi B (cień). Ci sami użytkownicy, te same zdarzenia, dwa rurociągi.

Pozwól temu działać przez co najmniej dwa tygodnie. Potrzebujesz wolumenu do porównania i co najmniej jednego pełnego cyklu tygodniowego, bo ruch w tygodniu i w weekend zachowuje się inaczej, a trzydniowa próbka Cię okłamie.

Na produkcji nic się nie zmienia. Jeśli serwer stanie w płomieniach, Twoje dane się tym nie przejmą.

Co porównywać

Uzgadniaj to w tej kolejności:

Metryka	Oczekiwana różnica	Jeśli mocno odstaje
Odsłony	Server-side 2-8% wyżej	Wyższy server-side jest poprawny: adblocki już go nie blokują
Zakupy	W granicach 1-2%	Duża różnica oznacza, że payload e-commerce nie przeżywa podróży
Przychód z zakupów	W granicach 1-2%	Sprawdź walutę i format wartości, nie liczbę zdarzeń
Użytkownicy	Server-side niżej	Tak ma być. Ciasteczka server-side żyją dłużej, więc ta sama osoba liczy się raz, a nie trzy razy
Sesje z odmową zgody	Powinny zachowywać się identycznie	Jeśli serwer zapisuje zdarzenia dla odmawiających, natychmiast przerwij

Ten pierwszy wiersz najbardziej ludzi dziwi. Wyższy ruch po stronie serwera to nie błąd. To odzysk z adblocków, za który zapłaciłeś. Wzrost 2-8% jest normalny. Wzrost o 40% oznacza, że coś odpala się dwa razy.

Faza 3: Pięć rzeczy, które się psują

W kolejności, w jakiej je znajduję.

1. Podwójne liczenie w Meta Conversions API

Ta duża. Jeśli wysyłasz zakupy zarówno z piksela w przeglądarce, jak i z serwera, Meta musi wiedzieć, że to to samo zdarzenie. Dopasowuje je po event_id (przeglądarka) i event_id (serwer), plus event_name i znacznik czasu.

Pomyl to, a każdy zakup policzy się dwa razy. Twój ROAS podwaja się z dnia na dzień, wszyscy świętują, a potem budżet skaluje się względem liczby, która jest błędna dokładnie o 100%.

Wygeneruj identyfikator zdarzenia raz, w warstwie danych, i przekaż tę samą wartość do obu. Nie dwa losowe ID. Nie znacznik czasu. Ten sam ciąg znaków.

2. Stan zgody nie podróżuje

Serwer nie wie, na co użytkownik wyraził zgodę, dopóki mu tego nie powiesz. Zgoda mieszka w przeglądarce i musi być jawnie przekazywana z każdym zdarzeniem.

Serwer, który nigdy nie dostanie odmowy, przetworzy zdarzenie, bo z jego punktu widzenia nic nie powiedziało nie. Twój obowiązek wynikający z RODO nie przeniósł się na serwer. Przeniósł się tylko Twój kod. To dokładnie ta pułapka, którą opisałem w artykule o śledzeniu bez ciasteczek: server-side nie jest obejściem zgody, a regulatorzy nie dali się do tego przekonać.

3. Ciągłość identyfikatora klienta

Kiedy przełączasz się na serwer, to on zaczyna ustawiać ciasteczko. Jeśli wygeneruje nowy identyfikator klienta, zamiast odczytać istniejące ciasteczko _ga, każdy powracający użytkownik staje się nowy w dniu przełączenia.

Zobaczysz gigantyczny skok nowych użytkowników, zapaść powracających i zepsutą atrybucję dla każdego, kto był w trakcie ścieżki. Odczytaj istniejące ciasteczko. Nie generuj nowego.

4. Tablica items w e-commerce zostaje spłaszczona

Tablica items to najbardziej krucha część każdego payloadu e-commerce. Przeżywa przeglądarkę bez problemu, a potem dociera do serwera jako string albo ze złym zagnieżdżeniem, i GA4 po cichu ją odrzuca.

Objaw: zdarzenia zakupu docierają, przychód dociera, a raportowanie na poziomie produktów jest puste. Wszystko wygląda dobrze na dashboardzie, który wszyscy oglądają, a raporty merchandisingowe po cichu robią się puste.

5. Cross-domain i łańcuchy przekierowań

Jeśli Twój koszyk stoi na innej domenie, parametry linkera muszą przetrwać przeskok. Server-side zmienia miejsce zapisu ciasteczka, a konfiguracja międzydomenowa, która działała wcześniej, może przestać działać po migracji.

Faza 4: Przełączanie, jeden tag naraz

Kiedy liczby się uzgodnią, migruj po jednym tagu, w tej kolejności:

1. GA4 pierwszy. Największy wolumen, najbardziej wybaczający błędy, najłatwiejszy do porównania.
2. Meta CAPI drugi. Największe ryzyko, przez opisany wyżej problem z deduplikacją. Obserwuj przez tydzień.
3. Google Ads trzeci.
4. Cała reszta na końcu.

Po każdym tagu: obserwuj przez 48 godzin, zanim ruszysz następny. Jeśli zmigrujesz cztery tagi jednego popołudnia i konwersje spadną, masz czterech podejrzanych i żadnej możliwości wskazania winnego. Zmigruj jeden, a masz jednego.

Utrzymuj usługę-cień jeszcze przez miesiąc po pełnym przełączeniu. Nic nie kosztuje, a jest Twoim jedynym punktem odniesienia, gdy ktoś za trzy tygodnie zapyta, czy liczby się zmieniły.

Plan wycofania

Zapisz go przed startem, bo nie będziesz miał ochoty go pisać o 18:00 w dniu, w którym coś się posypie.

Wycofanie migracji w GTM jest naprawdę proste i to jest niedoceniana zaleta robienia tego w GTM: cofnij kontener do poprzednio opublikowanej wersji. Dwa kliknięcia. Tagi wracają do client-side, a dane płyną dokładnie tak jak wcześniej.

To prawda tylko wtedy, gdy nie wyrwałeś jednocześnie tagów client-side. Zostaw je na miejscu, wstrzymane, przez miesiąc. Skasowanie ich w dniu przełączenia to ta jedna decyzja, która zamienia dwuklikowe wycofanie w awarię.

Ile to naprawdę trwa

Dla średniej wielkości sklepu z GA4, Meta CAPI i Google Ads:

• Kontrole i naprawy przed startem: 2-5 dni, dłużej jeśli audyt znajdzie realne problemy.
• Postawienie serwera i subdomeny: 1-2 dni.
• Przebieg równoległy: minimum 2 tygodnie i to nie jest część do skracania.
• Uzgodnienia i łatanie różnic: 3-7 dni.
• Etapowe przełączanie: 2 tygodnie, po jednym tagu na 48 godzin plus zapas.

Razem 6 do 8 tygodni, z czego większość to czekanie i obserwowanie, a nie budowanie. Kto obiecuje Ci migrację server-side w tydzień, albo pomija przebieg równoległy, albo nigdy nie musiał tłumaczyć dyrektorowi finansowemu 40-procentowego spadku przychodu.

Najczęstsze pytania

Ile trwa migracja na tagowanie server-side? Od sześciu do ośmiu tygodni dla typowego średniego e-commerce. Większość tego czasu to dwutygodniowy przebieg równoległy i etapowe przełączanie, a oba istnieją po to, żeby wyłapać problemy, zanim dotrą do danych produkcyjnych.

Czy muszę migrować wszystko naraz? Nie i nie powinieneś. Migruj po jednym tagu, zaczynając od GA4, i czekaj 48 godzin między kolejnymi. Jeśli coś się zepsuje po migracji jednego taga, wiesz dokładnie, co to spowodowało.

Dlaczego dane server-side są wyższe niż client-side? Bo adblocki już ich nie blokują. Wzrost liczby zdarzeń o 2-8% jest oczekiwany i pożądany. Znacznie większy skok zwykle oznacza, że jakieś zdarzenie odpala się dwa razy.

Czy tagowanie server-side zepsuje mój piksel Meta? Podwoi Twoje konwersje, jeśli nie wdrożysz poprawnie deduplikacji. Zdarzenie z przeglądarki i zdarzenie z serwera muszą nieść ten sam event_id, wygenerowany raz i przekazany do obu. To najczęstszy i najdroższy błąd migracji.

Czy tagowanie server-side znosi wymóg zgody? Nie. Zgoda musi być jawnie przekazana z przeglądarki na serwer. Serwer, który nie dostanie sygnału zgody, i tak przetworzy zdarzenia, a to naruszenie RODO, nie funkcja.

Jak się wycofać, jeśli migracja pójdzie źle? Cofnij kontener GTM do poprzednio opublikowanej wersji. Zadziała to tylko wtedy, gdy zostawiłeś tagi client-side na miejscu (wstrzymane, nie skasowane). Trzymaj je przez miesiąc po przełączeniu.

Co dalej

Sama migracja nie jest technicznie trudna. Trudna jest dyscyplina: postawić serwer i nie skierować od razu na niego ruchu produkcyjnego, puścić dwa systemy równolegle przez dwa tygodnie, kiedy wszyscy chcą mieć to zrobione do piątku, i przełączać po jednym tagu, kiedy cztery poszłyby szybciej.

Zacznij od kontroli przed startem, bo to one decydują, czy to będzie projekt na trzy tygodnie, czy na trzy miesiące. Jeśli Twój tracking client-side już teraz nie zgadza się z backendem, napraw to najpierw. Migracja zepsutej konfiguracji produkuje zepsutą konfigurację, tylko trudniejszą w debugowaniu i droższą w utrzymaniu.

Potem zbuduj usługę-cień i uzbrój się w cierpliwość. Przebieg równoległy jest całą metodą. Reszta to hydraulika.

Jeśli chcesz, żeby ktoś porządnie przeprowadził kontrole przed startem, darmowy audyt GTM obejmuje stronę kontenera. A jeśli chcesz, żeby migracja została wyceniona i wdrożona, to jest praca deweloperska: €80/godzinę albo stała cena po 30-minutowej rozmowie zakresowej. Robiłem to na WordPressie, WooCommerce, Shoperze, PrestaShop i na własnych stackach. Pełny cennik tutaj.

---

Źródła

• Dokumentacja tagowania server-side (Google)
• Deduplikacja w Meta Conversions API (Meta)
• Consent Mode przy tagowaniu server-side (Google)