Od czego zaczynam, a od czego nie

Nie zaczynam od menedżera tagów. Zaczynam od rozmowy z osobą, która w firmie faktycznie odbiera telefony od potencjalnych klientów.

Pytam o cztery rzeczy: jakie sygnały poprzedzają dobre zapytanie, co takie osoby czytają przed kontaktem, jak długo trwa decyzja i po czym w firmie rozpoznaje się, że temat jest poważny. Odpowiedzi bywają nieoczywiste — bardzo często okazuje się, że o jakości zgłoszenia najlepiej mówi coś prozaicznego, na przykład pobranie cennika albo wejście na podstronę o wdrożeniu.

Dopiero z tej rozmowy powstaje lista kandydatów na zdarzenia. Odwracam tu typową kolejność, bo wdrożenia zaczynane od strony technicznej kończą się zestawem zdarzeń mierzących to, co dało się łatwo zmierzyć, a nie to, co ma znaczenie.

Ostatni krok przygotowania to brutalne skrócenie listy. Trzydzieści zdarzeń nikt nigdy nie przeanalizuje. Wybieram takie, które da się jednoznacznie zinterpretować i które ktoś w firmie będzie umiał wykorzystać w decyzji.

Projekt zdarzeń: nazwy i parametry

Ten etap wykonuję w arkuszu, nie w interfejsie. Kolumny: nazwa zdarzenia, warunek wystąpienia, parametry, docelowy wymiar, właściciel decyzji.

Nazwy trzymam w jednym schemacie — czasownik plus obiekt, małymi literami, z podkreśleniami, po angielsku. Kluczowa zasada: jedno zdarzenie na typ akcji, szczegóły w parametrach. Zamiast osobnych zdarzeń dla każdego pliku do pobrania robię jedno pobranie materiału z parametrem mówiącym, co to za materiał i z której podstrony.

Ma to praktyczny powód. GA4 pozwala zarejestrować ograniczoną liczbę zdarzeń o unikalnych nazwach oraz ograniczoną liczbę wymiarów niestandardowych, a każdy parametr trzeba osobno zarejestrować jako wymiar, żeby dał się użyć w raporcie. Rozdrobniony zestaw nazw wyczerpuje te limity szybciej niż ktokolwiek się spodziewa, a potem trzeba go rozplątywać w działającym koncie.

W parametrach unikam czegokolwiek, co identyfikuje osobę. Adresy e-mail, numery telefonów i treści z pól formularza nie mają prawa wejść do GA4 — poza regulaminem chodzi też o to, że taki incydent bywa trudny do odkręcenia. Zamiast tego przekazuję kategorie: typ materiału, wielkość firmy z listy wyboru, źródło zapytania.

Wdrożenie w menedżerze tagów

Warstwa techniczna jest prostsza niż projekt, pod warunkiem że projekt istnieje.

Preferuję zdarzenia wypychane przez aplikację do warstwy danych, a nie łapane nasłuchami po selektorach CSS. Selektory przeżywają dokładnie do następnej zmiany szablonu, po czym pomiar przestaje działać cicho, bez żadnego komunikatu. Jeśli deweloper nie ma czasu, ustalam minimum: warstwa danych dla formularzy i dla kroków konfiguratora, reszta na nasłuchach.

Rzeczy, które sprawdzam zawsze, bo psują dane bezszelestnie:

• Podwójne zliczanie — formularz wysyłany przez skrypt, do którego dodatkowo doklejono nasłuch kliknięcia przycisku. Jedno zgłoszenie, dwa zdarzenia.

• Potwierdzenie po stronie serwera — zdarzenie powinno lecieć po udanym wysłaniu, nie po kliknięciu. Inaczej mierzysz też próby zablokowane walidacją.

• Zgody — przy trybie uzyskiwania zgody część zdarzeń nie wyjdzie od użytkowników bez akceptacji. Trzeba wiedzieć, którą część danych to dotyczy, zanim ktoś zacznie porównywać miesiąc do miesiąca.

• Formularze w ramkach i na zewnętrznych narzędziach — kalendarze do rezerwacji spotkań i systemy webinarowe najczęściej nie przekazują nic same z siebie.

Każde zdarzenie weryfikuję w podglądzie debugowania i dopiero potem w raporcie czasu rzeczywistego. Wdrożenie bez tego kroku uważam za niewdrożone.

Które zdarzenia awansują na kluczowe

W GA4 to, co dawniej nazywano konwersją, jest oznaczeniem zdarzenia jako kluczowego. Oznaczenie ma konsekwencje, więc rozdaję je oszczędnie.

Dzielę zdarzenia na trzy poziomy. Poziom pierwszy to sygnały zainteresowania — obejrzenie materiału, przewinięcie strony wdrożeniowej, wejście na cennik. Mierzę je, ale nie oznaczam. Poziom drugi to działania wymagające wysiłku: pobranie dokumentu z podaniem danych, uruchomienie kalkulatora, rozpoczęcie rezerwacji spotkania. Tu oznaczenie ma sens, bo są to zdarzenia policzalne i związane z intencją. Poziom trzeci to zgłoszenia i umówione spotkania.

Do Google Ads importuję zwykle poziom trzeci jako główne, a wybrane zdarzenia z poziomu drugiego jako pomocnicze. Ta druga grupa daje algorytmowi wolumen, którego brakuje przy dziesięciu zgłoszeniach miesięcznie, ale nie może stać się celem — o tym, dlaczego różnym krokom przypisuję różne wartości, piszę osobno.

Jedno zastrzeżenie z doświadczenia: gdy tylko jakieś zdarzenie zostanie oznaczone jako kluczowe, ktoś w firmie zacznie je raportować zarządowi jako „lead”. Warto uzgodnić nazwy w raportach, zanim to się stanie.

Sklejenie z systemem sprzedaży

Bez tego kroku całość zostaje ćwiczeniem z pomiaru ruchu, bo o wyniku procesu B2B decyduje to, co dzieje się po zgłoszeniu.

Potrzebne są dwie rzeczy. Pierwsza to identyfikator zapisywany razem ze zgłoszeniem — identyfikator kliknięcia z reklamy oraz własny identyfikator zgłoszenia w ukrytym polu formularza. Druga to zwrotny import statusu z systemu sprzedaży: temat zakwalifikowany, oferta wysłana, umowa. Google Ads pozwala takie zdarzenia offline dosyłać, a przy zgłoszeniach z danymi kontaktowymi można zamiast identyfikatora użyć konwersji rozszerzonych dla leadów.

Uwaga na okno czasowe. Jeśli decyzja u klienta trwa pół roku, a maksymalne okno konwersji jest krótsze, część domknięć nigdy nie przypisze się do kampanii. Nie da się tego obejść ustawieniem — trzeba wybrać wcześniejszy etap procesu jako punkt pomiaru i pilnować, żeby korelował z domknięciami.

Przy dłuższych cyklach i sensownym wolumenie eksportuję dane surowe do hurtowni i tam łączę je ze statusami z systemu sprzedaży. Interfejs GA4 do takich analiz jest po prostu za ciasny.

Utrzymanie, o którym wszyscy zapominają

Pomiar zdarzeń psuje się cicho i to jest jego najgorsza cecha.

Raz w miesiącu przechodzę krótką listę: czy każde zdarzenie z arkusza nadal spływa, czy nie pojawiły się nazwy, których nikt nie zgłaszał, czy liczba zgłoszeń w analityce zgadza się z liczbą w skrzynce i w systemie sprzedaży. Ta trzecia kontrola wyłapuje najwięcej — rozjazd rzędu kilkudziesięciu procent oznacza zwykle albo blokadę skryptów, albo zdarzenie odpalane w złym momencie.

Dokumentację trzymam poza narzędziem, w tym samym arkuszu co projekt. Po roku nikt nie pamięta, dlaczego zdarzenie nazywa się tak, a nie inaczej, i co dokładnie liczy jego parametr.

I rzecz najbardziej banalna: zmiana strony bez informacji dla osoby odpowiedzialnej za pomiar oznacza, że przez kilka tygodni optymalizujesz kampanie pod dane, których nie ma. Umówienie się z zespołem, że przebudowa formularza to również temat analityczny, kosztuje jedną rozmowę i oszczędza kwartał zmarnowanych danych.