Server-side tagging

Jak się tego używa

Kontener uruchamia się w chmurze albo u dostawcy takich środowisk i wskazuje na niego subdomenę sklepu, żeby ruch szedł we własnej domenie. Konfiguracja obejmuje odbiór zdarzeń, tagi wysyłkowe do platform oraz reguły decydujące, które pola opuszczają serwer.

Dlaczego warto to znać

Rozwiązanie odpowiada na trzy różne problemy naraz. Identyfikator zapisany w cookie ustawionym przez serwer we własnej domenie żyje dłużej niż ustawiony skryptem w przeglądarce, więc powracający klient rzadziej liczy się jako nowy. Zdarzenia z serwera docierają także wtedy, gdy przeglądarka blokuje skrypty platform reklamowych. Sklep zyskuje też kontrolę nad tym, jakie pola wychodzą na zewnątrz. Kosztem jest utrzymanie serwera i wyższa złożoność wdrożenia.

Na co uważać

To nie jest obejście zgód. Dane przechodzące przez własny serwer podlegają tym samym przepisom, a status zgody trzeba przekazać dalej; wysyłka zdarzeń po odmowie jest naruszeniem niezależnie od tego, skąd wychodzą. Rozwiązanie nie pomaga, jeśli identyfikator nadal nadaje skrypt w przeglądarce. Błąd w regule filtrującej ucina konwersje albo wypuszcza zbędne pola i nie zostawia komunikatu w interfejsie. Krążąca liczba o odzyskaniu 19% utraconych danych po takim wdrożeniu pochodzi z opisu jednego wdrożenia agencyjnego, nie z badania, i była przypisywana instytucji, która tego nie badała.

Mit: „Firmy wdrażające sGTM odzyskują 19% utraconych danych (IAB Polska)”. To wynik jednego wdrożenia u jednego klienta z case study agencji (15.07.2025) i dotyczy sesji GA4, nie „danych”; IAB Polska niczego takiego nie badało. Skala odzysku w konkretnym sklepie zależy od udziału Safari, blokerów i odmów zgody, więc trzeba ją zmierzyć u siebie.