Strona internetowa jest centrum działań marketingowych. Twoje treści na WWW i to, jak użytkownicy z nich korzystają, to źródło najcenniejszych informacji do optymalizacji strategii. Analityka tych danych opiera się na założeniu, że śledzenie i zaciągane zdarzenia są właściwie wdrożone. Google Tag Manager pozwala na zarządzanie wszystkimi skryptami śledzącymi (tzw. tagami) w scentralizowany sposób i weryfikację ich działania.
Porządek i dokumentacja wdrożeń w Google Tag Manager
Wdrażając analitykę z GTM, niezbędne jest dokumentowanie tych działań. Dlaczego? Plik w Excelu z podstawowymi danymi pozwoli na uporządkowanie wszystkich śledzonych zdarzeń. Tworząc dokumentację, musimy uwzględnić:
- co mierzymy? (np. „formularz kontaktowy”);
- gdzie wysyłamy dane? (GA4, Google Ads, Meta Pixel);
- czy to konwersja? (Tak/Nie);
- etykietę i ID konwersji (szczególnie istotne dla Google Ads);
- komentarze i statusy (czy wszystko działa, testowane, wymaga poprawy).
Dobrze przygotowany plik w Excelu pozwoli uniknąć chaosu i eliminacji wielu błędów już na starcie. To również ułatwienie podczas wprowadzenia jakichkolwiek zmian w tagach, czy testowania tych rozwiązań, zwłaszcza gdy analityka jest rozwijana przez kilka osób. Taki dokument może też służyć jako brief dla zespołu developerskiego czy też marketingowego.
Może Cię zainteresować: Optymalizacja konwersji (CRO) – jak poprawić wyniki strony internetowej?
Najczęstsze błędy w śledzeniu formularzy
Źle podpięte tagi, czy błędna konfiguracja w Google Tag Managerze to prosta droga do zbierania fałszywych danych. Inne czarne scenariusze to też brak opcji rozróżniania formularzy ze strony lub nawet duplikowanie informacji. A to skutkuje zaburzonymi wynikami twoich kampanii – automatyczne optymalizacje będą bazować na błędnych wnioskach a ty nie będziesz w stanie ocenić skuteczności poszczególnych działań.
Jakie błędy psują twoje śledzenie formularzy na stronie? Przykładowo, okienko wyszukiwania na stronie internetowej może się zliczać jako formularz, bo bazuje na bardzo podobnym kodzie HTML. To samo może dotyczyć np. dodania do koszyka – dlatego zawsze trzeba sprawdzić, czy formularz, który chcemy śledzić, rzeczywiście jest tym, którego dotyczą nasze cele.
Formularze bez unikalnego ID (form ID)
Jeśli na stronie funkcjonuje kilka formularzy o tej samej strukturze i wszystkie mają identyczne ID (albo nie mają go wcale), GTM nie ma możliwości ich rozróżnienia. To częsty problem w przypadku globalnych widgetów, np. formularzy osadzanych w stopce, które pojawiają się na wszystkich podstronach. W efekcie każde przesłanie dowolnego formularza uruchamia to samo zdarzenie, niezależnie od tego, który formularz został wypełniony.
Ten sam formularz w wielu miejscach strony
Brak rozróżnienia pomiędzy formularzami kontaktowymi, ofertowymi czy zapisami na newsletter powoduje, że każde przesłanie formularza może być potraktowane jako konwersja. Jeżeli formularz kontaktowy występuje zarówno na stronie „Kontakt”, jak i w stopce na każdej podstronie i nie ma dodatkowych warunków w regule GTM – nie będzie wiadomo, z którego miejsca pochodzi zdarzenie.
Wiele formularzy tego samego typu bez rozróżnienia między sobą
Często na stronie występuje kilka podobnych formularzy, ale znajdujących się na różnych podstronach. Jeśli dla wszystkich tych akcji, używany jest ten sam typ zdarzenia (np. Form Submit) bez dodatkowych warunków, analityka nie odróżni, która z interakcji była skuteczna. To problem szczególnie w przypadku kampanii, które mają różne cele, ale wykorzystują podobne formularze.
Trudności z testowaniem i debugowaniem
Brak jednoznacznego rozdzielenia formularzy, za pomocą różnych ID i wartości w dataLayer, utrudnia również testowanie działania zdarzeń. Jeżeli wszystkie formularze zwracają te same wartości, w trybie podglądu GTM i DebugView w GA4 nie widać wtedy, który formularz faktycznie został przesłany.
Jak uniknąć tych problemów i poprawnie wdrożyć śledzenie formularzy?
Unikalne ID formularza (Form ID)
Najpewniejszym sposobem na poprawne śledzenie formularzy (i innych zdarzeń) jest nadanie każdemu z nich unikalnego identyfikatora (Form ID). Dzięki temu Google Tag Manager będzie je rozpoznawać i uruchamiać odpowiednią regułę tylko w tej konkretnej sytuacji.
W tym miejscu warto wspomnieć o kilku dobrych praktykach:
- W popularnych systemach CMS, takich jak WordPress z Elementorem, jest możliwość ręcznego ustawienia ID formularza bez konieczności ingerencji w kod.
- Warto wprowadzać czytelne i jednoznaczne nazwy, np. “form_kontakt”, “form_oferta”, “form_newsletter”. Ułatwia to konfigurację, późniejsze testowanie i analizę danych.
Filtrowanie po adresie URL (Page Path)
W przypadku, gdy nie ma możliwości nadania ID formularzowi (np. w starszych szablonach, przy ograniczeniach technicznych), można skorzystać z filtrowania po adresie URL. Reguła w GTM będzie sprawdzać, czy aktualna podstrona zawiera w adresie konkretne frazy, takie jak „/kontakt/” lub „/oferta/”.
To rozwiązanie działa dobrze, jeśli formularz znajduje się tylko na tej jednej podstronie. Jeśli formularz jest osadzony globalnie (np. w stopce), samo filtrowanie po URL może nie wystarczyć. Warto łączyć tę metodę z innymi, np. z widocznością elementu.
Wykorzystanie klasy CSS formularza
Jeżeli formularze posiadają klasy CSS, również ich można użyć do zbudowania reguł w Google Tag Managerze. W takim przypadku warunek w regule sprawdza, czy element zawiera określoną klasę, np. “form-kontakt”.
Uwaga! Klasy CSS mogą być przypadkowo powielane lub zmieniane przez edytor strony. Warto każdorazowo sprawdzić w inspektorze przeglądarki (Inspect Element), czy klasa faktycznie rozróżnia poszczególne formularze i nie jest wykorzystywana w innych elementach strony.
Reguła oparta o widoczność elementu (Element Visibility Trigger)
Dla dynamicznych układów stron, gdzie formularze mogą być ładowane warunkowo (np. w module, który otwiera się po kliknięciu), warto wykorzystać wyzwalacz oparty o widoczność tego elementu. Reguła w GTM będzie sprawdzać, czy formularz jest widoczny na ekranie użytkownika, zanim wyzwoli zdarzenie. To rozwiązanie wymaga jednak starannego przetestowania różnych sposobów korzystania ze strony.
Dodatkowe parametry w dataLayer
W bardziej zaawansowanych wdrożeniach, do śledzenia można wykorzystać dodatkowe informacje przesyłane w “dataLayer”. Jeśli formularz generuje dodatkowe zmienne, takie jak “eventCategory”, “eventAction”, “formName” lub inne niestandardowe atrybuty, możesz je wykorzystać w warunkach reguł w GTM.
To umożliwia rozróżnianie formularzy nie tylko po ich umiejscowieniu na stronie, ale też po typie działania użytkownika (np. różne warianty formularzy w zależności od wybranych opcji).
Testowanie wdrożeń śledzenia formularzy i debugowanie zdarzeń
Testowanie wdrożonych tagów i reguł to ważny etap, którego nie można pomijać! Regularne testy, przed przesłaniem danych do Google Analytics, pozwolą na uniknięcie zbierania błędnych informacji
Wykorzystaj narzędzia takie jak tryb podglądu w GTM, DebugView w GA4 czy konsola przeglądarki. Umożliwiają one sprawdzenie, czy zdarzenia uruchamiają się prawidłowo i przesyłają właściwe informacje.
I na koniec – konfiguracja GTM powinna być zgodna z UX
Kiedy testujemy poprawność działania zdarzeń, powinniśmy też sprawdzać, czy śledzone interakcje są zrozumiałe dla użytkownika.
Jeżeli użytkownik nie dostaje jasnego komunikatu po wysłaniu formularza, może wysłać go kilka razy w takiej samej formie. To zaburza dane konwersyjne, dlatego trzeba sprawdzać nie tylko technikalia, ale też to, czy użytkownik wie, że formularz został wysłany.”
Warto ustawić wyraźny komunikat dla użytkownika o sukcesie – np. tekst po przesłaniu formularza, czy przekierowanie na stronę z podziękowaniem. Niezależnie od formy, informacja ta powinna być czytelna i jednoznaczna.
Przeczytaj także: Jak zacząć myśleć o zabezpieczeniu swojego Facebooka?
