Co warto mierzyć poza wysłaniem

Cztery zdarzenia, które w mojej praktyce dają najwięcej.

• Wyświetlenie formularza — nie samo wejście na stronę, a moment, w którym formularz faktycznie pojawił się w widoku użytkownika. Bez tego nie wiesz, ilu ludzi w ogóle go zobaczyło, a przy formularzu na dole długiej strony różnica jest ogromna.

• Rozpoczęcie wypełniania — pierwsze kliknięcie w dowolne pole. Zestawienie tego z wyświetleniem daje najczystszą miarę tego, czy formularz zachęca.

• Błąd walidacji wraz z informacją, które pole go wywołało. To najbardziej niedoceniane zdarzenie z całej listy i zwykle najszybsze źródło konkretnej poprawki.

• Porzucenie — użytkownik rozpoczął wypełnianie i opuścił stronę bez wysłania. Najlepiej z informacją o ostatnim dotkniętym polu.

Do tego oczywiście wysłanie, ale z zastrzeżeniem: wysłanie formularza to nie to samo co potwierdzenie jego przyjęcia przez serwer. O tym rozróżnieniu będzie osobno, bo to najczęstsze źródło zawyżonych statystyk.

Który mechanizm wykrywania wybrać

GTM daje kilka dróg i wybór zależy od tego, jak formularz jest zbudowany.

Wbudowany detektor przesłania formularza jest najprostszy i warto zacząć od niego. Problem polega na tym, że opiera się na standardowym zdarzeniu przeglądarki, a większość nowoczesnych formularzy — zwłaszcza wysyłanych asynchronicznie, bez przeładowania strony — tego zdarzenia nie generuje albo przerywa jego domyślne działanie. Zdarza się też, że reguła uruchamia się przy nieudanej walidacji, czyli liczy wysłania, których nie było.

Nasłuch zdarzeń w warstwie danych to rozwiązanie najlepsze i wymagające współpracy z programistą. Formularz sam ogłasza, co się stało — rozpoczęcie, błąd z nazwą pola, potwierdzone przyjęcie — a GTM tylko na to reaguje. Jeśli masz taką możliwość, wybierz ją; wszystkie pozostałe metody są obejściami.

Detektor widoczności elementu obsługuje wyświetlenie formularza i podziękowanie po wysłaniu. Prosty, niezawodny, nie wymaga zmian w kodzie.

Detektor kliknięcia na pola i na przycisk — przydatny do rozpoczęcia wypełniania i jako awaryjne przybliżenie wysłania, ale kliknięcie w przycisk to nie to samo co udane wysłanie.

Wyświetlenie strony podziękowania jest najpewniejszą metodą pomiaru realnego wysłania, o ile taka strona istnieje. Formularze pokazujące komunikat bez zmiany adresu tej możliwości nie dają.

Konfiguracja krok po kroku

Kolejność, która oszczędza najwięcej czasu na debugowaniu.

Włącz potrzebne zmienne wbudowane — identyfikator i klasy formularza, tekst i identyfikator klikniętego elementu, adres strony. Bez nich reguły nie mają na czym się oprzeć.

Zbuduj reguły od najpewniejszego zdarzenia. Zaczynam od strony podziękowania albo widoczności komunikatu o sukcesie, bo to zdarzenie, które chcę mieć poprawne przede wszystkim.

Nazwij zdarzenia konsekwentnie, na przykład według wzorca obszar–akcja, i trzymaj się tego schematu. Po roku pracy nazwy nadawane doraźnie zamieniają kontener w archeologię.

Przekaż kontekst w parametrach: identyfikator formularza, jego położenie na stronie, nazwę pola przy błędzie walidacji. Zdarzenie bez parametrów mówi, że coś się stało, ale nie pozwala tego naprawić.

Testuj w trybie podglądu, wypełniając formularz na kilka sposobów: poprawnie, z błędem, z porzuceniem w połowie, na telefonie. Ten etap wyłapuje większość problemów.

Najczęstsze błędy

Liczenie kliknięcia w przycisk jako wysłania. Najczęstsza przyczyna zawyżonych statystyk konwersji. Użytkownik, który kliknął, zobaczył błąd walidacji i wyszedł, zostaje policzony jako lead. Przy trudnym formularzu różnica bywa dramatyczna.

Podwójne zdarzenia. Dwie reguły łapiące tę samą akcję — na przykład wbudowany detektor i własna reguła kliknięcia — dają dwa zdarzenia z jednego wysłania. Warto to sprawdzić w podglądzie, zanim ktoś zacznie raportować te liczby.

Brak reguły blokującej dla środowiska testowego. Formularze wypełniane przez zespół podczas testów trafiają do tych samych statystyk co ruch klientów.

Zdarzenie bez informacji, o który formularz chodzi. Przy serwisie z formularzem kontaktowym, zapisem na newsletter i zapytaniem ofertowym jedno wspólne zdarzenie „wysłanie formularza” jest praktycznie bezużyteczne.

Przesyłanie treści pól do systemu analitycznego. To błąd poważniejszy niż pozostałe, bo dotyczy danych osobowych. Do analityki trafiają nazwy pól i informacja o zdarzeniu, nigdy wpisane przez użytkownika wartości.

Zgody i dane osobowe

Wątek, który przy formularzach jest szczególnie wrażliwy i którego nie da się dopisać po wdrożeniu.

Tagi analityczne i reklamowe powinny uruchamiać się zgodnie ze stanem zgody użytkownika. GTM ma do tego wbudowaną obsługę — tag można ustawić tak, żeby czekał na odpowiednią zgodę, zamiast wystrzelić natychmiast. Warto to skonfigurować, a nie polegać wyłącznie na tym, że banner „blokuje skrypty”, bo takie blokowanie bywa nieszczelne.

Druga rzecz to zakres przesyłanych danych. Do pomiaru interakcji z formularzem nie potrzebujesz ani jednej wartości wpisanej przez użytkownika. Jeśli natomiast planujesz przekazywać dane kontaktowe do systemu reklamowego w ramach mechanizmów dopasowania konwersji, to osobny temat z własnymi wymogami — haszowanie po stronie klienta i ustalona podstawa prawna. Nie mieszam tych dwóch spraw w jednym wdrożeniu.

Na koniec praktyczna uwaga: udokumentuj, co i kiedy wysyłasz. Kontener bez opisu po roku staje się nieczytelny dla wszystkich, w tym dla osoby, która go zbudowała — a przy formularzach dokumentacja jest też odpowiedzią na pytanie, jakie dane przetwarzasz i po co.