Zacznij od warstwy danych, nie od tagów

Warstwa danych to obiekt na stronie, w którym sklep publikuje informacje o tym, co się właśnie stało: jaki produkt został wyświetlony, co wpadło do koszyka, jaka transakcja się zakończyła i za ile. Menedżer tagów tylko to czyta.

To rozróżnienie jest fundamentem. Jeśli sklep nie publikuje danych, żadna konfiguracja tagów tego nie naprawi — można próbować wyciągać wartości ze wzorców w kodzie strony, ale to rozwiązanie, które psuje się przy każdym wdrożeniu nowego szablonu i nie da się na nim oprzeć raportowania.

Minimalny zakres, o który proszę przy sklepie, to identyfikator transakcji, wartość netto lub brutto (świadomie wybrana i konsekwentnie stosowana), waluta, lista pozycji z identyfikatorami produktów i kwota kosztów dostawy. Identyfikatory produktów muszą być dokładnie te same, które trafiają do pliku danych w Merchant Center — inaczej remarketing dynamiczny nie połączy zdarzeń z produktami.

Osobna rzecz, o której warto pomyśleć na tym etapie: czy wartość transakcji ma zawierać podatek i dostawę. To decyzja biznesowa, nie techniczna, i musi zostać podjęta raz, bo przekłada się na każdy późniejszy cel ROAS.

Struktura kontenera, która nie zamienia się w chaos

Kontener po roku pracy powinien być czytelny dla kogoś, kto nie brał udziału we wdrożeniu. Wymaga to dwóch nawyków.

Pierwszy to konwencja nazw. Używam prefiksów mówiących o typie elementu i systemie docelowym, żeby lista tagów sortowała się sensownie sama z siebie. Nazwa powinna od razu odpowiadać na pytanie, do jakiego narzędzia idą dane i jakie zdarzenie obsługuje tag.

Drugi to zdarzenia własne jako podstawa reguł. Reguły oparte na wyświetleniu konkretnego adresu URL są kruche — wystarczy, że sklep zmieni ścieżkę strony podziękowania. Reguła oparta na zdarzeniu publikowanym przez sklep w momencie zakończenia zamówienia przetrwa taką zmianę.

Nie zapominam też o środowisku testowym. Kontener powinien mieć osobną wersję podłączoną do środowiska deweloperskiego, bo alternatywą jest testowanie na żywym sklepie i zaśmiecanie danych sprzedażowych zamówieniami testowymi. To brzmi oczywiście, a bywa pomijane.

Konwersje Google Ads krok po kroku

Kolejność ma znaczenie i jest następująca.

• Najpierw w Google Ads definiuję akcję konwersji: zakup, z wartością zmienną, z ustalonym oknem konwersji i oznaczoną jako konwersja główna.

• Potem w menedżerze tagów wstawiam tag zdarzenia konwersji, wypełniając wartość i identyfikator transakcji zmiennymi z warstwy danych, nigdy wartościami wpisanymi na sztywno.

• Identyfikator transakcji uzupełniam obowiązkowo — to on odpowiada za to, że odświeżenie strony podziękowania nie policzy drugiego zakupu.

• Sprawdzam, czy na stronie działa też tag odpowiadający za powiązanie kliknięcia z konwersją, bo bez niego zdarzenie nie przypisze się do kampanii.

• Na końcu testuję w trybie podglądu i weryfikuję w Google Ads, czy konwersja rzeczywiście się zaraportowała i z jaką wartością.

Uwaga praktyczna: konwersja pokazuje się w interfejsie z opóźnieniem. Zanim ogłosisz, że nie działa, daj temu kilka godzin i sprawdź stan tagu w kolumnie statusu.

Remarketing dynamiczny i tagi produktowe

Dla sklepu drugi zestaw tagów jest równie ważny jak konwersje, bo bez niego nie ma dynamicznych reklam produktowych.

Tag remarketingu potrzebuje trzech parametrów przekazywanych na każdym istotnym etapie: identyfikatora produktu, typu strony i wartości. Typ strony musi być zgodny z wartościami, których oczekuje Google — inaczej listy odbiorców będą się budować, ale reklamy nie będą wiedziały, co pokazać.

Najczęstszy błąd, jaki tu spotykam, to rozjazd identyfikatorów. W pliku danych produkt ma identyfikator z systemu magazynowego, a na stronie skrypt przekazuje identyfikator z bazy sklepu. Oba są poprawne, żaden nie jest ten sam, i remarketing dynamiczny nie działa. Sprawdzenie tego zajmuje pięć minut i jest pierwszą rzeczą, którą robię przy diagnozie.

Warto też zdecydować, gdzie tag ma się uruchamiać. Na stronie kategorii, karcie produktu, w koszyku i po zakupie — tak, na stronie regulaminu i w panelu klienta — nie.

Zgody użytkowników i to, co z nich wynika dla pomiaru

Tagi marketingowe nie mogą uruchamiać się przed uzyskaniem zgody i to nie jest kwestia dobrej praktyki, a wymogu. Wdrożenie musi więc zawierać mechanizm, który wstrzymuje część tagów do momentu decyzji użytkownika.

W menedżerze tagów realizuje się to zwykle przez zdarzenie publikowane przez narzędzie do zbierania zgód i reguły uwzględniające jego stan. Warto to zaprojektować świadomie, bo dwa skrajne rozwiązania są jednakowo złe: uruchamianie wszystkiego od razu jest niedopuszczalne, a blokowanie absolutnie wszystkiego do kliknięcia w banner oznacza, że tracisz również dane, które wolno zbierać.

Konsekwencja dla raportowania jest istotna i trzeba ją komunikować klientowi z góry: część konwersji nie zostanie zmierzona bezpośrednio. Liczby w panelu będą niższe od liczby zamówień w sklepie i to nie jest błąd wdrożenia. Google udostępnia mechanizm pozwalający modelować brakujące dane w oparciu o zachowanie użytkowników, którzy zgodę wyrazili, ale nadal mówimy o szacunku, nie o pomiarze pełnym.

Weryfikacja i najczęstsze rozjazdy liczb

Wdrożenie kończę porównaniem trzech źródeł: liczby zamówień w panelu sklepu, liczby transakcji w Analytics i liczby konwersji w Google Ads. Te liczby nigdy nie będą identyczne i to jest normalne, ale różnice muszą mieć wyjaśnienie.

Typowe przyczyny rozjazdów:

• Podwójne liczenie — konwersja z tagu i jednocześnie zaimportowany cel z Analytics oznaczone jako konwersje główne. Klasyk, który zawyża wyniki dwukrotnie.

• Różny moment przypisania — Google Ads przypisuje konwersję do dnia kliknięcia, narzędzia analityczne zwykle do dnia transakcji. Przy dłuższym procesie decyzyjnym daje to widoczną różnicę w raportach dziennych.

• Zamówienia anulowane i zwroty, które w sklepie zniknęły, a w pomiarze zostały.

• Zamówienia telefoniczne i przez marketplace, których żaden tag na stronie nie zobaczy.

Ostatnia rada, bardziej higieniczna niż techniczna: opisuj wersje kontenera przy publikacji. Jedno zdanie o tym, co i dlaczego zostało zmienione, oszczędza godziny w momencie, gdy trzeba ustalić, od kiedy dane wyglądają dziwnie.