Checklista wdrożenia enhanced conversions
62 punkty kontrolne w ośmiu obszarach - od warunków wstępnych, przez wybór metody, GTM, hashowanie i zgody, po diagnostykę, która udowadnia, że dopasowania faktycznie zachodzą. Przy każdym punkcie: gdzie tego szukać, dlaczego to ma znaczenie i kiedy reagować.
Ostatnia aktualizacja:
Dlaczego „wdrożone” nie znaczy „działające”
Ulepszone konwersje to jedna z niewielu rzeczy w Google Ads, które realnie dokładają dane zamiast je przestawiać. Nie zmieniają licytacji, nie przebudowują kampanii, nie wymagają nowego budżetu - po prostu odzyskują część konwersji, które przepadały przez blokady ciasteczek, przeglądarki chroniące prywatność i ścieżki prowadzące przez kilka urządzeń.
Problem w tym, że „wdrożone” i „działające” to w tym przypadku dwie zupełnie różne rzeczy. Panel pokazuje status, który brzmi optymistycznie, tag odpala się bez błędu, a diagnostyka po tygodniu pokazuje zero dopasowań - bo e-mail leciał ze spacją na końcu albo dane docierały wyłącznie dla zalogowanych klientów. Nic nie krzyczy. Po prostu nic się nie dzieje.
Ta checklista prowadzi przez 62 punkty w ośmiu obszarach: od sprawdzenia, czy w ogóle masz z czego korzystać, przez wybór metody i wdrożenie, aż po diagnostykę, która udowadnia, że dopasowania faktycznie zachodzą. Osobno opisuję wariant dla leadów, bo przy sprzedaży domykanej poza stroną rządzi się on inną logiką.
Zakładam, że klasyczny pomiar konwersji już działa - ulepszone konwersje są nadbudową, nie fundamentem. Jeśli nie masz tej pewności, zacznij od checklisty pomiaru konwersji w Google Ads.
Jak korzystać z tej checklisty
Odhaczaj punkty w trakcie audytu - postęp zapisuje się w Twojej przeglądarce, więc możesz zamknąć kartę i wrócić do niej jutro. Nie ma logowania ani wysyłania czegokolwiek na serwer; dane siedzą wyłącznie na Twoim urządzeniu, a przycisk „Wyczyść postęp” kasuje je natychmiast.
Nie traktuj tego jako wyścigu do 100%. Odhaczony punkt oznacza „sprawdziłem i wiem, jak jest”, a nie „jest dobrze”. Audyt, który kończy się kompletem zielonych checkboxów i listą dwudziestu znalezisk, jest wart więcej niż taki, po którym nie zapisałeś nic.
Idź po kolei. Sekcje są ułożone tak, że wcześniejsze rozstrzygają, czy późniejsze mają w ogóle sens - nie ma po co analizować stawek, jeśli za chwilę okaże się, że konwersje liczą się podwójnie.
Warunki wstępne: czy w ogóle masz z czego korzystać
0/8Ulepszone konwersje nie są przełącznikiem - są nadbudową nad pomiarem, który musi już działać. Wdrożone na zepsutym fundamencie nie naprawią niczego, tylko dołożą warstwę, w której trudniej szukać błędu. Ta sekcja zajmuje kwadrans i regularnie kończy się wnioskiem „najpierw napraw tag”.
Gdzie:Cele → Akcje powodujące konwersję → kolumna Ostatnia rejestracja
Ulepszone konwersje uzupełniają istniejące zdarzenie, nie tworzą nowego. Jeśli akcja nie rejestruje nic, nie ma czego uzupełniać. Zacznij od checklisty pomiaru konwersji, jeśli tu coś nie gra.
Próg alarmowy:Akcja konwersji bez rejestracji przy aktywnym ruchu - wdrożenie EC nic nie da.
To warunek, o który rozbija się większość wdrożeń. Ulepszone konwersje potrzebują e-maila, telefonu albo adresu - jeśli strona podziękowania jest anonimowa, bo dane siedzą wyłącznie w backendzie, żadne ustawienie tego nie obejdzie. Zostaje wtedy wariant przez API.
Sklepy pozwalające kupić bez podania e-maila (na przykład przy odbiorze osobistym z płatnością na miejscu) będą miały niskie pokrycie z powodów, których nie da się naprawić technicznie. Warto to wiedzieć zawczasu, żeby nie ścigać nieosiągalnego wskaźnika.
E-mail i telefon to dane osobowe, także po zahashowaniu. Podstawą jest zgoda marketingowa użytkownika, a nie sam fakt, że posiadasz te dane w systemie. Ta decyzja zapada przed wdrożeniem, nie po nim.
Gdzie:Cele → Ustawienia → Ulepszone konwersje → warunki
Bez tego funkcja nie ruszy, a komunikat łatwo przeoczyć w gąszczu ustawień. To dosłownie jeden checkbox, przez który wdrożenia potrafią stać tygodniami, podczas gdy wszyscy szukają błędu w kodzie.
Próg alarmowy:Warunki niezaakceptowane - dane będą przychodzić i nie będą przetwarzane.
Dopasowanie działa na skali. Przy kilku konwersjach miesięcznie efekt będzie niemierzalny, bo nawet duży procentowy przyrost oznacza pojedyncze zdarzenia. To nie znaczy, że nie warto wdrażać - znaczy, że nie oczekuj efektu widocznego w raporcie.
Bez zapisanej liczby sprzed wdrożenia nie udowodnisz, że cokolwiek się zmieniło. Zanotuj konwersje z ostatnich 30 dni per kampania - to Twój punkt odniesienia i jedyna obrona przed pytaniem „czy to w ogóle coś dało”.
Wdrożenie wymaga zmian po stronie strony albo GTM-a. Jeśli okaże się, że nikt w firmie nie ma dostępu do szablonu checkoutu, to jest to problem organizacyjny, który trzeba rozwiązać przed, a nie w trakcie.
Wybór metody i przygotowanie danych
0/8Trzy drogi prowadzą do celu i różnią się nie tyle skutecznością, co tym, kto musi je utrzymać. Wybór metody jest decyzją na lata - zmiana później oznacza wdrożenie od nowa, bo nie da się płynnie przejść z jednej na drugą bez okresu, w którym dane lecą podwójnie albo wcale.
Najczęściej najrozsądniejszy wybór: nie wymaga dewelopera przy każdej korekcie, a zmiany widać w trybie podglądu. Warunek: dane użytkownika muszą być dostępne na stronie, w dataLayer albo w polach formularza.
Sensowne, gdy strona nie używa GTM-a albo gdy dział IT woli mieć wszystko w repozytorium. Minus: każda zmiana to wdrożenie kodu, czyli kolejka, testy i czekanie.
Jedyna droga, gdy dane nie istnieją na stronie w momencie konwersji - na przykład przy sprzedaży domykanej przez telefon. Daje największą kontrolę i wymaga dewelopera oraz utrzymania integracji.
Część platform e-commerce ma wbudowaną obsługę ulepszonych konwersji albo wtyczkę, która robi to poprawnie. Zanim zlecisz wdrożenie od zera, sprawdź, czy nie wystarczy włączyć opcji - to godzina zamiast tygodnia.
E-mail w polu formularza, telefon w podsumowaniu zamówienia, dane w dataLayer. Wypisz konkretne selektory albo nazwy zmiennych, zanim zaczniesz konfigurować - ta lista jest planem wdrożenia.
Wyciąganie e-maila przez selektor CSS ze strony działa do pierwszej zmiany szablonu. dataLayer jest kontraktem, który przetrwa redesign - warto o niego walczyć na etapie wdrożenia, bo później nikt do tego nie wróci.
Próg alarmowy:Dane pobierane wyłącznie selektorem CSS z widocznego tekstu strony.
E-mail daje najwyższą skuteczność dopasowania i zwykle wystarcza. Telefon i adres podnoszą pokrycie tam, gdzie e-mail bywa niedostępny. Nie przekazuj wszystkiego „na wszelki wypadek” - każde pole to dane osobowe, które musisz uzasadnić.
Przy wdrożeniu przez GTM z pól strony Google hashuje dane w przeglądarce przed wysłaniem. Przy własnej implementacji odpowiedzialność jest po Twojej stronie - i to tam powstaje większość błędów. Jeśli nie masz powodu, żeby hashować samodzielnie, nie rób tego.
Wdrożenie w Google Tag Managerze
0/12Ścieżka domyślna dla większości wdrożeń. Całość sprowadza się do tego, żeby tag konwersji dostał dane użytkownika w momencie odpalenia - ale diabeł siedzi w kolejności i w tym, czy zmienne mają wartość wtedy, kiedy są potrzebne, a nie ułamek sekundy później.
Gdzie:GTM → Tagi → tag konwersji → Podaj dane podane przez użytkownika
Starsze tagi nie mają tej sekcji w ogóle. Jeśli jej nie widzisz, tag pochodzi sprzed wprowadzenia funkcji i trzeba go odtworzyć - próba dopisania parametrów na siłę skończy się cichym ignorowaniem danych.
Gdzie:GTM → Zmienne → Nowa → Dane podane przez użytkownika
To dedykowany typ zmiennej, który zbiera pola i przygotowuje je do wysyłki. Nie próbuj składać tego ręcznie z osobnych zmiennych - ten typ obsługuje normalizację i hashowanie za Ciebie.
Tryb automatyczny sam szuka pól na stronie i bywa zaskakująco skuteczny przy typowych checkoutach. Ręczny wymaga wskazania każdego pola i jest przewidywalny. Zacznij od automatycznego, ale zweryfikuj wynik - automat potrafi znaleźć pole newslettera zamiast pola zamówienia.
Dla każdego pola podaj zmienną z dataLayer albo selektor CSS. Zmienna z dataLayer jest zawsze lepszym wyborem - selektor jest zakładnikiem szablonu i zmieni się przy pierwszym redesignie.
Gdzie:GTM → Podgląd → wybierz zdarzenie konwersji → zakładka Variables
Najczęstszy błąd całego wdrożenia: tag odpala się szybciej, niż dane trafiają na stronę, i zmienna zwraca undefined. Wszystko wygląda poprawnie w konfiguracji i nie działa w praktyce.
Próg alarmowy:Zmienna z danymi zwracająca undefined przy zdarzeniu konwersji.
Jeśli używasz osobnego tagu ustawiającego dane użytkownika, musi odpalić się przed tagiem konwersji. GTM pozwala wymusić kolejność w ustawieniach zaawansowanych tagu - skorzystaj z tego zamiast liczyć na szczęście.
Gdzie:GTM → tag → Ustawienia zaawansowane → Ustawienia zgody
Tag przekazujący dane osobowe musi respektować sygnały z CMP tak samo jak reszta pomiaru - a właściwie bardziej, bo tu stawka jest wyższa. Ustaw wymaganą zgodę jawnie, nie polegaj na domyślnych.
Gdzie:GTM → Podgląd → przejdź pełną ścieżkę zakupu
Nie testuj przez wpisanie adresu strony podziękowania z palca - wtedy dataLayer jest pusty i test niczego nie dowodzi. Przejdź całą ścieżkę tak, jak zrobi to klient.
Gdzie:DevTools → Network → filtr „google” → parametry żądania konwersji
Ostateczny dowód. Jeśli w żądaniu nie ma zahashowanych danych, tag ich nie wysłał - niezależnie od tego, co pokazuje podgląd GTM. To rozstrzyga spór „przecież skonfigurowałem”.
Opis typu „EC: dane użytkownika w tagu konwersji zakupu, źródło dataLayer” zajmuje dziesięć sekund i jest jedyną rzeczą, która za pół roku wyjaśni, co i po co zrobiono.
Checkout mobilny bywa innym kodem, innym szablonem i innymi selektorami. Wdrożenie działające na komputerze i milczące na telefonie to sytuacja spotykana regularnie - a mobile to zwykle większość ruchu.
Odwrotny problem: tag odpalający się na każdej próbie wysyłki, także nieudanej, przekazuje śmieci. Upewnij się, że wyzwalacz reaguje na potwierdzone zdarzenie, a nie na kliknięcie przycisku.
Warianty: gtag i API
0/6Dwie pozostałe drogi. Sekcja jest krótsza, bo większość wdrożeń kończy się na GTM - ale jeśli Twoja sytuacja wymaga kodu albo integracji serwerowej, tu są punkty, które trzeba domknąć. Jeśli wdrażasz przez GTM, możesz tę sekcję odhaczyć jako nieaktualną.
Dane użytkownika muszą być ustawione zanim odpali się zdarzenie konwersji. Odwrotna kolejność oznacza, że konwersja poleci bez nich - i nie dostaniesz żadnego ostrzeżenia, tylko zerowe dopasowanie.
Na kontach z wieloma akcjami łatwo podpiąć dane pod inną niż zamierzona. Efekt: jedna akcja ma świetne pokrycie, druga zero, a nikt nie wie dlaczego.
Wdrożenie serwerowe wymaga powiązania konwersji z kliknięciem - przez GCLID albo przez dopasowanie po danych. Ta decyzja determinuje całą architekturę integracji i zapada na początku.
Serwer nie ma pomocy Google w normalizacji, więc cała odpowiedzialność jest po Twojej stronie: małe litery, obcięte spacje, SHA-256. Błąd na tym etapie daje zerowe dopasowanie przy pozornie działającej integracji.
Próg alarmowy:Hashowanie po stronie serwera bez wcześniejszej normalizacji.
Integracja serwerowa działa w tle, więc nikt nie zauważy, że przestała. Potrzebujesz logowania błędów i alertu - inaczej dowiesz się o awarii z raportu za miesiąc.
Za rok ktoś zapyta, czemu dane lecą przez API, skoro jest GTM. Jedno zdanie z uzasadnieniem oszczędza wtedy dzień archeologii - albo, co gorsza, „uproszczenia”, które zepsuje działające wdrożenie.
Hashowanie i normalizacja danych
0/8Sekcja dla tych, którzy hashują samodzielnie. Google nie powie Ci, że hash jest zły - powie, że dopasowań jest mało, a to zupełnie inny komunikat, prowadzący w zupełnie inną stronę. Jeśli wdrażasz przez GTM z pól strony, ta sekcja jest tylko wiedzą kontrolną.
Hash rozróżnia wielkość liter, a Google normalizuje dane po swojej stronie przed porównaniem. Jeśli zahashujesz adres z wielkiej litery, hash nie zgodzi się z niczym - przy zerowym komunikacie o błędzie.
Próg alarmowy:E-mail hashowany bez sprowadzenia do małych liter.
Spacja skopiowana razem z adresem z formularza zmienia hash całkowicie. To najbardziej banalny i najczęstszy powód zerowego dopasowania w samodzielnych wdrożeniach.
Google normalizuje część adresów w specyficzny sposób. Jeśli Twoja implementacja tego nie odwzorowuje, dopasowanie spadnie dokładnie dla tej grupy użytkowników, która jest największa.
Numer musi mieć prefiks kraju i żadnych spacji ani myślników. Polski numer zapisany jako „500 100 200” nie zostanie dopasowany do niczego - potrzebny jest zapis z prefiksem, bez separatorów.
Próg alarmowy:Numery telefonów wysyłane w formacie lokalnym, ze spacjami.
To jedyny akceptowany algorytm. MD5 czy SHA-1 zostaną przyjęte jako ciąg znaków i po prostu nie dopasują się do niczego - bez błędu, bez ostrzeżenia.
Część pól adresowych, jak kraj czy kod pocztowy, jest przekazywana bez hashowania. Zahashowanie ich sprawia, że są bezużyteczne, a Ty tracisz sygnał, który mógł podnieść pokrycie.
Hash pustego ciągu jest poprawnym hashem i zostanie wysłany jak każdy inny - dopasowując się do niczego. Jeśli pole jest puste, po prostu go nie przekazuj zamiast wysyłać hash pustki.
Próg alarmowy:Ten sam hash powtarzający się przy wielu konwersjach - to hash pustego pola.
Weź adres testowy, policz hash w swojej implementacji i porównaj z wynikiem niezależnego narzędzia. Jeśli się różnią, wiesz to teraz - a nie za miesiąc, patrząc na niewyjaśnione zero w diagnostyce.
Zgody i wymogi prawne
0/7Ulepszone konwersje to przetwarzanie danych osobowych w celu marketingowym - nawet jeśli technicznie wysyłasz ciąg znaków. Zahashowanie nie jest anonimizacją: to pseudonimizacja, bo cały sens polega na tym, że po drugiej stronie ktoś potrafi te dane dopasować do konkretnej osoby.
Dla celów marketingowych to praktycznie zawsze zgoda. Fakt, że użytkownik podał e-mail przy zakupie, nie jest zgodą na wysłanie go do Google w celu dopasowania reklam - to dwie różne rzeczy.
Techniczne wdrożenie musi odzwierciedlać decyzję prawną. Tag ma nie wysyłać danych, gdy zgody nie ma - i to trzeba sprawdzić w praktyce, a nie założyć.
Próg alarmowy:Dane użytkownika wysyłane mimo odrzuconej zgody marketingowej.
Gdzie:Odrzuć zgodę w banerze i przejdź transakcję z otwartą zakładką Network
Jedyny sposób, żeby udowodnić, że mechanizm działa. Sprawdź, czy w żądaniu nie ma zahashowanych danych. To test, o który zapyta każdy audyt RODO.
Przekazywanie danych do Google w celu pomiaru skuteczności reklam musi być opisane. To nie jest formalność - to jedyny dokument, w którym użytkownik może się o tym dowiedzieć.
Relacja z Google przy przetwarzaniu danych klientów wymaga uregulowania. W większości przypadków obowiązują warunki zaakceptowane w panelu, ale warto wiedzieć, co dokładnie zaakceptowałeś i mieć to udokumentowane.
Jeśli e-mail wystarcza do przyzwoitego pokrycia, nie wysyłaj przy okazji adresu i telefonu. Minimalizacja danych to nie tylko wymóg prawny - to też mniejsze pole do błędu i mniejsza szkoda przy incydencie.
Przy pierwszym pytaniu o RODO albo pierwszej kontroli data i zakres wdrożenia są pierwszą rzeczą, której będziesz szukać. Zapisz je razem z tym, jakie pola są przekazywane.
Diagnostyka i pokrycie dopasowań
0/7Wdrożenie kończy się nie w momencie publikacji, tylko wtedy, gdy diagnostyka pokaże, że dane przychodzą i są dopasowywane. Status „aktywne” nie znaczy nic - liczy się procent dopasowanych zdarzeń, bo to on decyduje, czy funkcja realnie coś odzyskuje.
Gdzie:Cele → Ustawienia → Ulepszone konwersje → Diagnostyka
Status inny niż „Rejestrowanie” oznacza, że mimo pozornie poprawnego wdrożenia nic się nie dzieje. Diagnostyka pokazuje też konkretny powód - to pierwsze miejsce, do którego zaglądasz po wdrożeniu.
Próg alarmowy:Status inny niż „Rejestrowanie” po 48 h od publikacji.
Jedyna metryka, która mówi, czy wdrożenie ma sens. Niskie pokrycie zwykle nie oznacza błędu w tagu - oznacza, że dane docierają tylko dla części transakcji, na przykład wyłącznie dla zalogowanych klientów.
Trzy najczęstsze: dane niedostępne dla części ścieżek (goście vs zalogowani), zgoda odrzucana przez dużą część ruchu, błąd normalizacji. Każda wymaga innego działania - a rozróżnisz je, patrząc na to, dla jakiej grupy transakcji dane docierają.
Diagnostyka potrzebuje danych, a dopasowania pojawiają się z opóźnieniem. Ocenianie wdrożenia po dwóch dniach to najprostszy sposób, żeby wyłączyć coś, co działa.
Tu przydaje się poziom bazowy z pierwszej sekcji. Wzrost liczby raportowanych konwersji przy niezmienionym ruchu i sprzedaży to dokładnie to, po co wdrażałeś ulepszone konwersje.
Jeśli konto zaczyna raportować więcej konwersji przy tej samej sprzedaży, historyczne CPA przestaje być punktem odniesienia. Cel zostawiony bez zmian stanie się nagle zbyt luźny i algorytm zacznie licytować agresywniej, niż zakładałeś.
Próg alarmowy:Cel tCPA nietknięty po wdrożeniu, które podniosło liczbę konwersji.
Ulepszone konwersje psują się po cichu przy każdej zmianie szablonu checkoutu. Nic nie krzyczy - pokrycie po prostu spada. Kwartalny rzut oka na diagnostykę wyłapuje to, zanim zrobi to spadek wyników.
Enhanced conversions for leads
0/6Osobny wariant dla firm, które sprzedają przez formularz i domykają sprzedaż poza stroną. Pozwala domknąć pętlę bez GCLID - dopasowanie idzie po zahashowanym e-mailu z formularza, więc przeżywa CRM, który gubi identyfikatory, i handlowca, który wpisuje leada ręcznie.
Ma sens, gdy sprzedaż domyka się poza stroną, a między formularzem a umową mijają tygodnie. Jeśli sprzedajesz w sklepie i konwersja dzieje się na stronie, potrzebujesz zwykłych ulepszonych konwersji, nie tego wariantu.
To ten sam mechanizm co przy klasycznym wdrożeniu, tylko zdarzeniem jest wysłanie formularza, a nie zakup. E-mail musi trafić do tagu w chwili, gdy lead powstaje.
Cała konstrukcja opiera się na tym, że e-mail z formularza i e-mail z późniejszego importu to ten sam ciąg. Jeśli handlowiec poprawi literówkę w CRM, dopasowanie przepadnie - warto o tym wiedzieć i uprzedzić zespół.
Próg alarmowy:CRM pozwalający ręcznie edytować adres e-mail leada bez śladu.
Gdzie:Cele → Przesyłanie danych → import z danymi użytkownika
Zamiast GCLID przesyłasz zahashowany e-mail i moment konwersji. Google dopasowuje to do kliknięcia po swojej stronie - i to jest cała przewaga tego wariantu nad klasycznym importem offline.
Lead zakwalifikowany i podpisana umowa to dwa różne zdarzenia o różnej wartości. Import wszystkiego jako jednej konwersji marnuje najcenniejszą informację, jaką masz - tę o jakości leada.
Gdzie:Cele → Przesyłanie danych → historia przesłanych plików
Google raportuje liczbę zaakceptowanych i odrzuconych wierszy razem z powodem. Pierwszy import prawie nigdy nie przechodzi w stu procentach - zwykle przez format daty albo strefę czasową.
Przeszedłeś całą checklistę. I co teraz?
Masz listę znalezisk. Najtrudniejsze dopiero przed Tobą: ustalić, które z nich realnie kosztuje Cię pieniądze, a które jest kosmetyką - i w jakiej kolejności to naprawiać. Jeśli chcesz drugą parę oczu do tej rozmowy, odezwij się.
Porozmawiajmy o wynikach audytuWdrożone. Co teraz
Nie oceniaj wdrożenia przez tydzień. Diagnostyka potrzebuje danych, a dopasowania pojawiają się z opóźnieniem. Ocena po dwóch dniach to najprostszy sposób, żeby wyłączyć coś, co właśnie zaczęło działać.
Patrz na pokrycie, nie na status. „Rejestrowanie” znaczy tylko tyle, że dane przychodzą. Dopiero procent dopasowanych zdarzeń mówi, czy funkcja cokolwiek odzyskuje - i czy problem, jeśli jest, siedzi w tagu, czy w tym, że Twój checkout po prostu nie zna e-maila klienta.
Przelicz cele stawek. Jeśli konto zaczęło raportować więcej konwersji przy niezmienionej sprzedaży, Twoje historyczne CPA przestało być punktem odniesienia. To nie jest kosmetyka - cel zostawiony bez zmian sprawi, że algorytm zacznie licytować agresywniej, niż zakładałeś.
Wpisz kontrolę diagnostyki do kalendarza. Raz na kwartał i po każdej zmianie w checkoucie. Ulepszone konwersje nie psują się z hukiem - pokrycie po prostu cicho spada po aktualizacji szablonu, o której nikt Ci nie powiedział.
Jeśli pokrycie jest niskie i nie wiesz dlaczego, albo nie masz pewności, czy wdrożenie jest zgodne z RODO - zobacz, jak wygląda audyt Google Ads u mnie, albo po prostu napisz.
Mogą być, ale nie są z automatu. To przetwarzanie danych osobowych w celu marketingowym, więc potrzebujesz podstawy prawnej - praktycznie zawsze zgody - i opisu w polityce prywatności. Zahashowanie nie jest anonimizacją, tylko pseudonimizacją: cały sens polega na tym, że po drugiej stronie ktoś potrafi dopasować te dane do konkretnej osoby. Wysyłka mimo odrzuconej zgody jest problemem prawnym, nie technicznym.
Zależy od tego, ile Ci dziś ucieka, a to zależy od przeglądarek Twoich klientów, długości ścieżki i poziomu zgód. Nie podam Ci procentu, bo każda taka liczba byłaby zmyślona - dlatego pierwsza sekcja tej listy każe zapisać poziom bazowy. Bez niego nie udowodnisz efektu ani sobie, ani klientowi.
Sprawdź trzy rzeczy w tej kolejności: czy warunki korzystania z danych klientów są zaakceptowane w panelu (jeden checkbox, przez który wdrożenia stoją tygodniami), czy zmienna z danymi nie zwraca undefined w momencie odpalenia tagu, i czy dane faktycznie wychodzą w żądaniu do Google w zakładce Network. To pokrywa większość przypadków.
Niekoniecznie i to ważne rozróżnienie. Niskie pokrycie zwykle oznacza, że dane docierają tylko dla części transakcji - na przykład wyłącznie dla zalogowanych klientów, a goście kupują anonimowo. To problem na stronie, nie w Google Ads, i żadne ustawienie go nie obejdzie. Błąd normalizacji daje raczej zero niż mało.
GTM w większości przypadków: nie wymaga dewelopera przy każdej korekcie i pozwala testować w podglądzie. Kod bezpośrednio - gdy strona nie używa GTM-a. API tylko wtedy, gdy dane nie istnieją na stronie w momencie konwersji, na przykład przy sprzedaży domykanej telefonicznie. Wybór jest na lata, bo zmiana metody oznacza wdrożenie od nowa.
Nie, i zwykle nie powinieneś. Przy wdrożeniu przez GTM z pól strony Google normalizuje i hashuje dane w przeglądarce przed wysłaniem. Samodzielne hashowanie ma sens tylko przy API i jest miejscem, w którym powstaje większość błędów: spacja na końcu adresu albo brak sprowadzenia do małych liter dają zero dopasowań bez jakiegokolwiek komunikatu.
Zakresem i mechaniką dopasowania. Klasyczne uzupełniają konwersję, która dzieje się na stronie. Wariant dla leadów pozwala domknąć pętlę bez GCLID: dopasowanie idzie po zahashowanym e-mailu z formularza, więc przeżywa CRM gubiący identyfikatory. Jeśli sprzedajesz w sklepie, potrzebujesz tych pierwszych. Jeśli domykasz sprzedaż telefonem po tygodniach - tych drugich.
Tak i to jest cały sens. Więcej poprawnie przypisanych konwersji to lepszy sygnał treningowy. Ale uwaga na skutek uboczny: jeśli liczba raportowanych konwersji rośnie przy niezmienionej sprzedaży, Twoje historyczne CPA przestaje być punktem odniesienia i cel tCPA trzeba przeliczyć. Inaczej algorytm dostanie nagle dużo luźniejszy cel, niż zakładałeś.
Zero dopasowań i nie wiesz dlaczego?
Wdrażam i naprawiam pomiar w kontach Google Ads od kilkunastu lat. Sprawdzę, gdzie urywa się łańcuch - i czy problem siedzi w tagu, w zgodach, czy po prostu w tym, że checkout nie zna e-maila klienta.
Porozmawiajmy o Twoim wdrożeniuKontekst do tej checklisty
Lista kontrolna mówi, co odhaczyć. Wpisy poniżej tłumaczą, dlaczego dany punkt jest na liście i co zrobić, gdy odpowiedź brzmi „nie”.
Całość ułożyłem w bazie wiedzy Google Ads - osiem obszarów, od pierwszej kampanii po pomiar konwersji.