Jak wygląda pomiar bez serwera i z serwerem

W klasycznym modelu wszystko dzieje się w przeglądarce użytkownika. Strona ładuje kontener menedżera tagów, ten uruchamia po kolei skrypty poszczególnych narzędzi, a każdy z nich wysyła żądanie bezpośrednio do swojego dostawcy. Przy typowym sklepie to kilka do kilkunastu osobnych połączeń z domenami zewnętrznymi.

W modelu z kontenerem serwerowym przeglądarka wysyła dane w jedno miejsce — na Twój serwer, dostępny pod Twoją subdomeną. Ten serwer odbiera zdarzenie, przetwarza je i sam wysyła dalej do narzędzi docelowych. Przeglądarka nie musi wiedzieć, ile systemów jest po drugiej stronie.

Konsekwencje są trzy. Strona ładuje mniej kodu zewnętrznego, bo część logiki przeniosła się na serwer. Ruch pomiarowy idzie na Twoją własną domenę, co ma znaczenie przy mechanizmach ograniczających skrypty zewnętrzne. I najważniejsze dla wielu firm: kontrolujesz, co wychodzi na zewnątrz, bo możesz dane przed wysłaniem zmodyfikować albo część z nich zatrzymać.

Z czego składa się kontener serwerowy

Struktura jest podobna do znanej z kontenera na stronie, ale dochodzi jeden element, który bywa niezrozumiały na początku.

• Klient — element, którego nie ma w kontenerze przeglądarkowym. Jego zadaniem jest odebrać przychodzące żądanie i zamienić je na zdarzenie zrozumiałe dla kontenera. Osobne klienty obsługują różne formaty danych przychodzących.

• Zdarzenie — ustandaryzowany zapis tego, co się stało, wraz z parametrami.

• Tagi — wysyłają dane do systemów docelowych. Działają podobnie jak w kontenerze na stronie, tylko wykonują się na serwerze.

• Zmienne i reguły — tu bez zaskoczeń, logika jest ta sama.

• Infrastruktura — kontener musi gdzieś działać. Standardowo uruchamia się go w chmurze Google, ale mechanizm jest kontenerem aplikacyjnym i można go umieścić także u innego dostawcy.

Do tego dochodzi konfiguracja własnej subdomeny wskazującej na ten serwer. To element obowiązkowy, jeśli chcesz uzyskać cokolwiek poza samą centralizacją — bez własnej domeny ruch pomiarowy nadal jest ruchem do domeny zewnętrznej.

Co to realnie rozwiązuje

Tu trzeba oddzielić rzeczywiste korzyści od obietnic, które słyszę w rozmowach.

Trwałość identyfikatorów. Przeglądarki ograniczają czas życia plików cookie zapisywanych przez skrypty działające w przeglądarce — w niektórych z nich to kwestia dni. Cookie ustawiane w odpowiedzi z Twojego serwera podlega innym zasadom i żyje dłużej. Dla pomiaru powracających użytkowników to najbardziej wymierna zmiana z całej listy.

Mniej kodu na stronie. Kilka skryptów zewnętrznych mniej to realna różnica w czasie ładowania, zwłaszcza na urządzeniach mobilnych. Nie jest to jednak cudowna kuracja — jeśli strona jest wolna z powodu nieskompresowanych zdjęć, przeniesienie tagów nie pomoże.

Kontrola nad danymi. Możesz usunąć z ładunku parametry, których nie chcesz wysyłać na zewnątrz, albo wzbogacić zdarzenie danymi ze swojego systemu, których nie ma w przeglądarce. To argument, który najczęściej przekonuje działy prawne.

Odporność na blokowanie skryptów. Częściowa i warto to powiedzieć wprost. Rozszerzenia blokujące reklamy radzą sobie także z domenami własnymi, jeśli rozpoznają wzorzec. To nie jest sposób na obejście decyzji użytkownika i nie należy tak tego sprzedawać.

Czego to nie rozwiązuje: zgody użytkownika. Jeśli ktoś nie zgodził się na pomiar marketingowy, kontener serwerowy tego nie zmienia i nie może być traktowany jako obejście. Wymogi prawne dotyczą przetwarzania danych, nie miejsca, w którym uruchamia się kod.

Ile to kosztuje i czego wymaga

To jest część rozmowy, którą warto przeprowadzić przed decyzją, a nie po pierwszej fakturze.

Serwer działa nieprzerwanie i jest opłacany za czas pracy instancji, nie za liczbę zdarzeń. Oznacza to koszt stały, niezależny od tego, czy w danej godzinie na stronie jest sto osób czy zero. Dla poprawnej pracy zaleca się utrzymywanie kilku instancji jednocześnie, żeby ruch nie trafiał na zimny start. Rachunek jest więc przewidywalny, ale nie jest zerowy i przy małym sklepie bywa nieproporcjonalny do korzyści.

Drugi koszt jest mniej widoczny: kompetencje. Konfiguracja wymaga dostępu do DNS, rozumienia certyfikatów, umiejętności debugowania żądań HTTP i znajomości formatów danych. To nie jest zadanie do wykonania w panelu przez osobę zajmującą się kampaniami. Utrzymanie też — jeśli kontener przestanie działać, dane przestają płynąć w całości, a nie częściowo.

Trzeci to złożoność diagnozy. W modelu klasycznym problem widać w narzędziach przeglądarki. Tutaj trzeba sprawdzić, co dotarło do serwera, co serwer z tym zrobił i co wysłał dalej — trzy miejsca zamiast jednego.

Dla kogo to ma sens

Moje kryterium jest proste i dotyczy skali oraz konkretnej potrzeby.

Ma sens, jeśli prowadzisz duży sklep, w którym różnica w jakości pomiaru przelicza się na zauważalne pieniądze, albo jeśli masz wymóg wynikający z polityki firmy: dane muszą przechodzić przez infrastrukturę, którą kontrolujesz. Ma też sens, jeśli potrzebujesz wzbogacać zdarzenia danymi z systemów wewnętrznych — na przykład marżą, której nie chcesz publikować w kodzie strony.

Nie ma sensu, jeśli podstawowy pomiar w kontenerze przeglądarkowym nie jest u Ciebie poprawnie wdrożony. To najczęstsza sytuacja, z jaką się spotykam: ktoś chce przenosić pomiar na serwer, a jednocześnie ma zdublowane konwersje i wartość transakcji wpisaną na sztywno. Kolejność jest odwrotna — najpierw porządek w danych, potem architektura.

Nie ma też sensu, jeśli nikt w firmie nie potrafi utrzymać tego rozwiązania i nie ma budżetu na zewnętrzne wsparcie. Kontener serwerowy, którym nikt się nie opiekuje, to pojedynczy punkt awarii dla całego pomiaru.

Jak podejść do wdrożenia

Jeśli po tym wszystkim uważasz, że to rozwiązanie dla Ciebie, kilka praktycznych uwag z wdrożeń, które prowadziłem.

Nie wyłączam starego pomiaru w dniu uruchomienia nowego. Przez kilka tygodni działają oba i porównuję liczby. Rozjazdy zawsze są i lepiej je zobaczyć, mając punkt odniesienia.

Zaczynam od jednego narzędzia, nie od wszystkich naraz. Najpierw pomiar analityczny, dopiero potem konwersje reklamowe. Przeniesienie konwersji jako pierwsze oznacza, że ewentualny błąd uderza od razu w optymalizację kampanii.

Subdomenę konfiguruję na samym początku, bo bez niej testowanie nie ma sensu — zachowanie plików cookie będzie inne niż docelowe.

I rzecz, której nauczyłem się nie pomijać: zapisuję dokumentację konfiguracji poza samym narzędziem. Kto ma dostęp, jak nazywa się projekt w chmurze, kto płaci rachunek, gdzie są ustawienia DNS. Za rok, kiedy coś przestanie działać, to będzie pierwsze pytanie, na które nikt nie będzie znał odpowiedzi.