Dlaczego strona z podziękowaniem to za mało
Klasyczna konfiguracja śledzenia formularza wygląda tak: użytkownik wysyła formularz, przegląda trafia na adres w stylu /dziekujemy, a Ty ustawiasz w Google Ads i GA4 konwersję opartą na odwiedzeniu tej strony. Przez lata to wystarczało. Dziś, przy nowoczesnych formularzach, ten model ma kilka poważnych dziur.
Po pierwsze: coraz więcej formularzy wysyła dane przez AJAX, bez przeładowania strony i bez zmiany adresu URL. Komunikat „dziękujemy" pojawia się w tym samym miejscu co formularz, więc adres w pasku przeglądarki się nie zmienia — a to oznacza, że konwersja oparta na URL po prostu się nie odpali.
Po drugie: nawet jeśli strona z podziękowaniem istnieje, odświeżenie jej przez użytkownika (albo powrót przez przycisk „wstecz") podbija licznik konwersji bez żadnego nowego zgłoszenia. Po trzecie — i to najważniejsze z perspektywy biznesowej — sama informacja „formularz wysłany" nic nie mówi o tym, czy to był wartościowy lead, czy przypadkowe zgłoszenie.
Śledzenie oparte wyłącznie na stronie z podziękowaniem traktuje każdy formularz identycznie. Nie widzisz, na którym polu ludzie się poddają, ani które zgłoszenia mają realną wartość biznesową. Dla algorytmów Google Ads to ten sam sygnał — a przecież nie każdy lead jest tak samo wart.
Jak GTM właściwie widzi formularz na stronie
Google Tag Manager oferuje wbudowany trigger „Form Submission", który nasłuchuje zdarzenia submit na elemencie <form>. Dla prostych, statycznych formularzy HTML to działa nieźle. Problem pojawia się, gdy formularz jest zbudowany na frameworku JS (React, Vue) albo wtyczce (Contact Form 7, Gravity Forms, HubSpot Forms) — bo tam zdarzenie submit może zostać przechwycone przez skrypt strony, zanim GTM zdąży je zobaczyć.
Bezpieczniejsze podejście: nie polegać na natywnym zdarzeniu przeglądarki, tylko na zdarzeniu, które sam wypycha formularz po udanej walidacji i wysyłce. Większość popularnych wtyczek formularzy ma własne zdarzenia JS (np. wpcf7mailsent dla Contact Form 7) albo callbacki po stronie API. Zadanie polega na tym, żeby przy tym zdarzeniu wykonać dataLayer.push() z informacją o sukcesie.
To rozróżnienie jest kluczowe: „kliknięcie przycisku wyślij" to nie to samo co „formularz został poprawnie wysłany". Jeśli walidacja formularza odrzuci zgłoszenie (błędny e-mail, brakujące pole), a Ty mierzysz kliknięcie przycisku, zaliczasz konwersje, które nigdy nie dotarły do Twojej skrzynki.
Śledzenie kroków wypełniania formularza
Formularze wieloetapowe (np. dane kontaktowe → opis potrzeby → preferowany budżet → potwierdzenie) dają dużo więcej informacji, jeśli mierzysz każdy krok osobno, a nie tylko finalne wysłanie.
form_step_view z numerem kroku. Pozwala policzyć, ile osób w ogóle dotarło do danego etapu.form_step_complete — dopiero to potwierdza, że krok został realnie ukończony, nie tylko obejrzany.form_submit_success odpala się dopiero po odpowiedzi serwera potwierdzającej przyjęcie zgłoszenia — nie po samym kliknięciu.W GTM te zdarzenia łapię triggerem „Custom Event" osobno dla każdej nazwy zdarzenia, a numer kroku odczytuję ze zmiennej warstwy danych (Data Layer Variable). Dzięki temu w GA4 mogę zbudować lejek: ile osób zobaczyło krok 1, ile przeszło do kroku 2, i tak dalej — i dokładnie zobaczyć, gdzie następuje największy spadek.
Które pole powoduje porzucenie
Sam lejek kroków mówi, na którym etapie ludzie rezygnują. Żeby dowiedzieć się, które konkretnie pole jest problemem, potrzebne jest bardziej granularne śledzenie na poziomie pojedynczych inputów.
Metoda, której używam: do każdego pola formularza podpinam nasłuchiwanie zdarzenia blur (czyli moment opuszczenia pola po interakcji). Przy pierwszym dotknięciu danego pola wypycham do warstwy danych zdarzenie field_touch z nazwą pola — nie z jego wartością. To ważne z punktu widzenia ochrony danych: interesuje mnie fakt interakcji, nie treść wpisana przez użytkownika.
Do warstwy danych i do Google Ads/GA4 nigdy nie przekazuję wartości pól takich jak imię, e-mail czy telefon — tylko nazwę pola i fakt interakcji. To wystarcza do analizy porzuceń, a jednocześnie nie naraża na przetwarzanie danych osobowych w narzędziach analitycznych.
Mając zestaw zdarzeń field_touch dla każdego pola oraz zdarzenie form_abandon (np. odpalane, gdy użytkownik zamyka kartę lub jest nieaktywny dłużej niż określony czas po interakcji z formularzem, a formularz nie został wysłany), mogę w GA4 zestawić: jakie było ostatnie dotknięte pole przed porzuceniem. Jeśli większość porzuceń kończy się na polu „budżet" albo „numer telefonu" — to konkretna wskazówka, że warto zmienić sposób proszenia o tę informację, np. uczynić ją opcjonalną albo przesunąć na koniec formularza.
Przekazywanie wartości leada na podstawie wybranych opcji
Wiele formularzy kontaktowych ma pole wyboru, które pośrednio mówi o wartości zapytania — np. zakres budżetu, wielkość firmy, rodzaj potrzebnej usługi. Zamiast traktować każde zgłoszenie jako identyczne, można tę informację wykorzystać do przekazania zróżnicowanej wartości konwersji do Google Ads.
| Wybrana opcja w formularzu | Kategoria | Przykładowa wartość konwersji |
|---|---|---|
| Budżet powyżej progu X | Wysoka | Wyższa wartość przypisana w tagu konwersji |
| Budżet w środkowym przedziale | Średnia | Wartość pośrednia |
| Budżet poniżej progu wejścia | Niska | Niższa wartość lub brak przypisania wartości |
Technicznie wygląda to tak: przy wysyłce formularza wypycham do warstwy danych wybraną opcję (np. lead_budget_range: 'srodkowy'), a w GTM tworzę zmienną typu „Lookup Table", która mapuje tę wartość na konkretną liczbę. Tę liczbę podstawiam jako parametr value w tagu konwersji Google Ads i jako parametr zdarzenia w GA4. Efekt: algorytm optymalizujący pod wartość konwersji (a nie tylko ich liczbę) dostaje dokładniejszy sygnał o tym, które źródła ruchu przynoszą bardziej obiecujące zapytania.
Konfiguracja w GTM krok po kroku
- Zdarzenie sukcesu w kodzie strony — formularz (lub jego wtyczka) musi wypychać
dataLayer.push()dopiero po potwierdzeniu przyjęcia zgłoszenia przez serwer, nie po kliknięciu przycisku. - Trigger „Custom Event" w GTM — nasłuchujący na nazwę zdarzenia zdefiniowaną w kroku pierwszym, np.
form_submit_success. - Zmienne warstwy danych — osobne zmienne do odczytu numeru kroku, nazwy formularza i wybranej kategorii/wartości.
- Tag konwersji Google Ads — z dynamiczną wartością pobieraną ze zmiennej, zamiast stałej liczby wpisanej na sztywno.
- Zdarzenie GA4 — równolegle wysyłane z tymi samymi parametrami, żeby dane w obu narzędziach się zgadzały.
- Test w trybie podglądu GTM — sprawdzenie, czy zdarzenie faktycznie odpala się raz na jedno prawdziwe zgłoszenie, a nie przy każdym kliknięciu przycisku.
Śledzenie bez strony z podziękowaniem
Dla formularzy AJAX, które nie przekierowują na osobny adres, cała logika opiera się na zdarzeniu JS, a nie na URL. Większość popularnych wtyczek udostępnia własne zdarzenie po udanej wysyłce — trzeba je znaleźć w dokumentacji wtyczki albo podejrzeć w kodzie źródłowym strony. Jeśli formularz jest pisany od zera, najprościej jest poprosić dewelopera o dodanie jednej linijki dataLayer.push() w miejscu, gdzie kod obsługuje odpowiedź serwera potwierdzającą sukces.
Nie mierzę konwersji na podstawie samego zniknięcia formularza z widoku ani zmiany jego stylu na „ukryty" — te elementy bywają manipulowane przez błędy JS niezwiązane z faktyczną wysyłką. Zawsze szukam zdarzenia powiązanego z odpowiedzią serwera, a nie ze zmianą wizualną na stronie.
Testowanie na środowisku deweloperskim przed wdrożeniem
Zanim uznam konfigurację za gotową, testuję ją w kilku scenariuszach: udana wysyłka, wysyłka odrzucona przez walidację, podwójne kliknięcie przycisku „wyślij" (częsty błąd użytkownika przy wolniejszym łączu) oraz wysyłka na urządzeniu mobilnym z inną przeglądarką niż domyślna. Każdy z tych scenariuszy potrafi ujawnić inny problem — np. podwójne kliknięcie bywa liczone jako dwie konwersje, jeśli zdarzenie nie jest odpowiednio zabezpieczone przed wielokrotnym odpaleniem w krótkim czasie.
Dobrą praktyką jest też dodanie prostego zabezpieczenia po stronie kodu formularza: blokady ponownego wysłania tego samego zgłoszenia w ciągu kilku sekund od pierwszej próby. To nie tylko porządkuje dane analityczne, ale też chroni przed przypadkowym zdublowaniem zgłoszenia w systemie CRM.
Narzędzia, które ułatwiają pracę z formularzami w GTM
Poza wbudowanymi triggerami GTM, przy bardziej złożonych formularzach korzystam z kilku dodatkowych mechanizmów. Zmienne typu „Custom JavaScript" pozwalają np. odczytać wartość konkretnego pola formularza w momencie wysyłki, bez konieczności modyfikowania kodu strony — pod warunkiem, że pole ma unikalny identyfikator lub nazwę, po której można je jednoznacznie wskazać.
Przy formularzach osadzonych w ramkach iframe (częste w przypadku niektórych systemów rezerwacji czy kalkulatorów wycen) sytuacja jest trudniejsza — komunikacja między iframe a stroną nadrzędną wymaga zwykle mechanizmu postMessage, a GTM musi nasłuchiwać na wiadomości przekazywane tą drogą. To bardziej zaawansowana konfiguracja, ale bez niej formularze w iframe są praktycznie niemożliwe do precyzyjnego zmierzenia.
Checklist — zanim uznasz formularz za dobrze śledzony
- Czy konwersja odpala się po realnym potwierdzeniu wysyłki, a nie po kliknięciu przycisku?
- Czy formularz wieloetapowy ma osobne zdarzenia dla każdego kroku?
- Czy wiesz, na którym polu najczęściej dochodzi do porzucenia?
- Czy do warstwy danych trafiają tylko nazwy pól i kategorie, a nie wpisane przez użytkownika dane osobowe?
- Czy wartość konwersji w Google Ads różni się w zależności od wybranych opcji w formularzu?
- Czy przetestowałeś konfigurację w trybie podglądu GTM na realnym, poprawnym zgłoszeniu?
- Czy dane w GA4 i Google Ads się ze sobą zgadzają liczbowo?
„Strona z podziękowaniem mówi, że ktoś kliknął wyślij. Śledzenie na poziomie pól i kroków mówi, dlaczego reszta tego nie zrobiła."
— Zasada, którą stosuję przy każdym audycie formularza