English
Deutsch
PolskiSystemy Tag Management: od kodowania na sztywno po Server-Side i wybór dostawcy
Spis treści
Kto pracuje dziś w marketingu cyfrowym lub analityce, prawdopodobnie codziennie korzysta z systemu zarządzania tagami (TMS – Tag Management System). Ale nie zawsze było to tak proste. Aby zrozumieć potęgę współczesnych platform takich jak Google Tag Manager, Tealium czy Jentis, musimy cofnąć się do początków zbierania danych.
Wczesne lata: Era „Hardcodingu”
Na początku lat 2000., za każdym razem, gdy zespół marketingu chciał dodać piksel śledzący (np. Google Analytics lub skrypt afiliacyjny) na stronę, musiał zgłosić to do działu IT. Programiści musieli ręcznie wdrażać („hardcode’ować”) te fragmenty JavaScript bezpośrednio w kodzie źródłowym witryny.
Proces ten był powolny, podatny na błędy i całkowicie zależny od cykli wydawniczych IT. Wraz z eksplozją marketingu cyfrowego, strony internetowe stawały się ociężałe od dziesiątek zewnętrznych skryptów, co drastycznie spowalniało ich ładowanie i tworzyło koszmar w zarządzaniu danymi.
Ewolucja: Narodziny TMS
W latach 2008-2012 pojawiły się pierwsze systemy TMS (Tealium powstało w 2008 r., GTM wystartował w 2012 r.). TMS dostarczał jeden kod „kontenera”, który umieszczało się na stronie tylko raz. Od tego momentu marketerzy mogli wdrażać, modyfikować i zarządzać tagami przez przyjazny interfejs webowy, bez dotykania kodu strony.
Obecnie branża przechodzi kolejną ogromną zmianę: Server-Side Tracking (SST – Śledzenie po stronie serwera). Z powodu adblockerów, przepisów o prywatności (RODO) oraz systemów ITP w przeglądarkach, tradycyjne śledzenie traci dane. Platformy TMS ewoluują, aby kierować dane przez własny serwer (first-party) przed wysłaniem ich do zewnętrznych narzędzi.
Oto zestawienie największych graczy na rynku.
Najwięksi gracze w zarządzaniu tagami
1. Google Tag Manager (GTM)
Niekwestionowany król udziałów w rynku, głównie dlatego, że jego standardowa wersja jest darmowa i płynnie integruje się z ekosystemem Google.
- PROsy: Darmowy, ogromna społeczność, mnóstwo poradników, bardzo przyjazny dla początkujących.
- CONsy: Darmowa wersja nie ma wsparcia SLA na poziomie enterprise. Wszystkie dane przechodzą przez infrastrukturę Google, co dla niektórych korporacji rodzi obawy o prywatność.
- Server-Side Tracking: Dostępny (sGTM). Wdrożenie jest stosunkowo proste w chmurze Google Cloud, ale wymaga wiedzy technicznej, aby zmapować dane z przeglądarki na serwer.
- Kiedy wybrać: Gdy stack marketingowy opiera się głównie na Google (GA4, Google Ads) i potrzebne jest szybkie, darmowe rozwiązanie.
2. Tealium (Tealium iQ)
Pionier i waga ciężka w segmencie Enterprise. Tealium zostało stworzone dla ogromnych korporacji z wieloma markami i skomplikowaną architekturą danych.
- PROsy: Potężny rynek tagów (ponad 1000 natywnych integracji), doskonałe zarządzanie danymi (Data Governance) i bardzo stabilne środowisko.
- CONsy: Bardzo drogie rozwiązanie. Interfejs jest techniczny, a próg wejścia (nauki) jest wysoki.
- Server-Side Tracking: Wybitny. Narzędzie Tealium EventStream zarządza ruchem serwerowym bezbłędnie, ale wymaga zaawansowanych umiejętności deweloperskich.
- Kiedy wybrać: Dla dużej korporacji z ogromnym budżetem, która musi wysyłać dane do setek narzędzi innych niż Google.
3. Adobe Experience Platform (Tags / dawniej Adobe Launch)
Odpowiedź Adobe na zarządzanie tagami, głęboko zintegrowana z Adobe Experience Cloud.
- PROsy: Głęboka, natywna integracja z Adobe Analytics i Adobe Target.
- CONsy: Interfejs jest mniej intuicyjny niż w GTM. Całkowity „overkill” (przerost formy nad treścią) bez innych produktów Adobe w użyciu.
- Server-Side Tracking: Realizowany przez Adobe Edge Network (Event Forwarding). Niezwykle potężny, ale bardzo skomplikowany we wdrożeniu.
- Kiedy wybrać: Wyłącznie wtedy, gdy cyfrowy ekosystem firmy jest w 100% zbudowany na produktach Adobe.
4. Commanders Act (dawniej TagCommander)
Europejski gracz, silnie skoncentrowany na zgodności z RODO i zarządzaniu zgodami.
- PROsy: Zbudowany z myślą o europejskim prawie. Płynnie łączy platformę do zarządzania zgodami (CMP) z systemem TMS.
- CONsy: Mniejsza popularność na świecie, co oznacza mniejszą społeczność i brak łatwo dostępnych tutoriali.
- Server-Side Tracking: Solidne natywne opcje serwerowe zaprojektowane wokół wymogów prywatności. Wdrożenie o średnim poziomie trudności.
- Kiedy wybrać: Dla firmy działającej w UE, dla której RODO i suwerenność danych to absolutny priorytet.
5. Jentis (Innowator)
Jentis to austriacka firma technologiczna, która podeszła do tematu zupełnie inaczej. Zamiast brać tradycyjny (przeglądarkowy) TMS i dodawać do niego opcje serwerowe, Jentis został od podstaw zbudowany jako natywna platforma do Server-Side Trackingu.
- PROsy: Niesamowita jakość danych, wbudowana zgodność z prawem i ekstremalne korzyści wydajnościowe dla strony (w przeglądarce nie odpala się prawie żaden JavaScript).
- CONsy: Wymaga całkowitej zmiany myślenia o analityce. Jest to produkt premium (wyższy koszt) dla dojrzałych organizacji.
- Server-Side Tracking: Jest rdzeniem produktu. Wdrożenie jest znacznie bardziej zoptymalizowane i prostsze niż budowanie własnych serwerów pod GTM.
Funkcja „Synthetic Users” (Syntetyczni Użytkownicy) w Jentis: To tutaj Jentis deklasuje konkurencję. Gdy użytkownik odrzuca cookies na banerze (Consent Mode), tradycyjne systemy przestają śledzić, pozostawiając ogromne luki w analityce (utrata nawet 30-40% ruchu). Jentis rozwiązuje to dzięki Syntetycznym Użytkownikom. Zamiast zapisywać ciasteczko w przeglądarce, serwer Jentis wykorzystuje zaawansowane modelowanie statystyczne i anonimowe dane serwerowe do wygenerowania „syntetycznego” identyfikatora sesji. Pozwala to firmom zachować kluczowe dane o wolumenie ruchu i konwersjach w sposób w pełni zanonimizowany i w 100% zgodny z RODO.
- Kiedy wybrać: Gdy jakość danych jest priorytetem, brak zgód na cookies pochłania ogromną część ruchu, a potrzebne jest zaawansowane rozwiązanie serwerowe prosto z pudełka.
Podsumowanie: Jak wybrać?
Nie ma „najlepszego” TMS-a – jest tylko najlepszy TMS dla danego ekosystemu. Stack oparty na Google woła o GTM, oparty na Adobe – o Adobe Tags. Elastyczność na poziomie enterprise przemawia za Tealium. Gdy jednak w grze są prywatność i odzyskanie utraconych danych, Jentis jest technologią przyszłości.
Pytania i odpowiedzi
Czy różnica między Synthetic Users w Jentis a modelowaniem konwersji Google jest techniczna, czy dotyczy tylko miejsca, w którym działają?
Różnica jest techniczna: oba rozwiązania działają na osobnych etapach, a zamieszanie bierze się z traktowania tych etapów jako jednego.
Pierwszym etapem jest identyfikacja: czy cokolwiek jest zapisywane na urządzeniu odwiedzającego lub z niego odczytywane. Drugim jest szacowanie: uzupełnianie luk w raportach na podstawie zagregowanych wzorców. Modelowanie konwersji to wyłącznie drugi etap; nie powstaje żaden identyfikator, a brakujące konwersje są szacowane na podstawie zaobserwowanych. Syntetyczny identyfikator sesji należy do pierwszego: serwer nadaje coś, co zastępuje sesję, nie prosząc przeglądarki o przechowanie tego. Modelowanie statystyczne, które Jentis stosuje na tej podstawie, należy do drugiego.
Do tego rozróżnienia należą też pytania. Dokładność jest cechą etapu szacowania i rozstrzyga ją porównanie z grupą kontrolną (holdout), a nie deklaracja dostawcy. To, czy według przepisów ePrivacy potrzebna jest zgoda, jest cechą etapu przechowywania, bo przepisy te dotyczą zapisywania lub odczytywania informacji na urządzeniu, a nie wniosków wyciąganych później na serwerze; przetwarzanie na serwerze nadal wymaga własnej podstawy prawnej według RODO. Ocena, która trzyma te dwa pytania osobno, da użyteczne odpowiedzi; ocena pytająca o całą funkcję „czy to jest zgodne z prawem”, nie da.
Co konkretnie oznacza „Data Governance” w systemach enterprise w porównaniu z porządnie prowadzonym darmowym kontenerem?
W gruncie rzeczy trzy sprawdzalne rzeczy, a różnica polega na tym, czy są wymuszone, czy tylko umówione.
Po pierwsze zatwierdzanie: kto może publikować i czy musi to zatwierdzić druga osoba? Darmowy kontener zna role i wersje, ale nie ma wymuszonej ścieżki zatwierdzania. Umowa „nikt nie publikuje sam” obowiązuje, dopóki wszyscy o niej pamiętają. Po drugie dostęp do danych: jakie wartości tag w ogóle może odczytać? W darmowym kontenerze niestandardowy tag HTML może odczytać każdą zmienną i każdy element strony; taki typ tagu blokuje się listą w kodzie strony, a nie w interfejsie kontenera. Po trzecie cele: dokąd wolno wysyłać dane? Utrzymywana lista dozwolonych odbiorców to coś innego niż możliwość wstawienia własnego skryptu.
Czy to jest warte swojej ceny, zależy od jednej liczby: ile osób ma dostęp. Przy trzech osobach w zespole uzgodnienia niezawodnie zastępują technikę. Przy trzydziestu osobach z pięciu agencji żadne uzgodnienie nie zastąpi technicznej granicy i właśnie tam te systemy się sprzedają.
Czy wyeksportowany kontener w formacie JSON da się w praktyce przenieść do systemu innego dostawcy?
W praktyce nie. Lepiej założyć to od początku niż liczyć na konwerter. Eksport opisuje tagi, wyzwalacze i zmienne w formacie jednego dostawcy; odpowiedniki w innym systemie mają inne pojęcia i inne granice.
Przenośna jest natomiast warstwa danych i to ona decyduje o koszcie migracji. Jeżeli zdarzenia i ich parametry są opisane w dokumencie, a strona wypycha je niezależnie od tego, kto je odbiera, wymiana systemu sprowadza się do odtworzenia reguł na tych samych danych. Jeżeli logika siedzi w kilkudziesięciu zmiennych czytających DOM, migracja jest przepisaniem od zera.
Stąd praktyczny wniosek na dziś, niezależnie od tego, czy zmiana kiedykolwiek nastąpi: warstwa danych jest tym elementem, który przede wszystkim warto specyfikować pisemnie. Reszta jest konfiguracją narzędzia, a narzędzia zmieniają się częściej niż sklepy internetowe.
Powiązane artykuły
