Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Pomiar konwersji w Google Ads od kilku lat robi się coraz mniej szczelny i nie jest to niczyja wina — tak działają kolejne ograniczenia przeglądarek i wymogi dotyczące zgód. Efekt widzę na kontach regularnie: kampania sprzedaje, sprzedaż jest w systemie klienta, a w Google Ads brakuje części konwersji i nikt nie wie, których.
Konwersje rozszerzone to odpowiedź Google na ten problem. Mechanizm jest dostępny dla wszystkich reklamodawców od kilku miesięcy i uważam go dziś za jedno z niewielu wdrożeń, które przy niedużym nakładzie pracy poprawiają jakość danych w całym koncie — a więc też jakość decyzji automatycznych strategii stawek.
Poniżej opisuję, co dokładnie się dzieje z danymi, jakie warunki trzeba spełnić i czego po tym nie należy oczekiwać. Bez obietnic co do skali efektu, bo ta zależy od struktury ruchu i od tego, jak dużo danych klient w ogóle zbiera.
Klasyczne mierzenie konwersji opiera się na tym, że przeglądarka pamięta kliknięcie reklamy i przy zakupie potrafi je przypomnieć. Kiedy ta pamięć zostaje skrócona albo wyczyszczona, konwersja fizycznie nastąpiła, ale nie ma jej czym połączyć z kliknięciem.
Konwersje rozszerzone dokładają do zdarzenia konwersji zahaszowane dane kontaktowe, które klient sam podał w formularzu — najczęściej adres e-mail, czasem też numer telefonu, imię, nazwisko i adres. Google porównuje te skróty z danymi zalogowanych kont użytkowników i jeśli znajdzie dopasowanie, przypisuje konwersję do wcześniejszego kliknięcia reklamy.
Dwie rzeczy warto tu podkreślić. Pierwsza: to nie jest nowe źródło konwersji, a domknięcie tych, które i tak się wydarzyły. Liczba raportowanych konwersji rośnie, bo część z nich wcześniej po prostu wypadała z pomiaru. Druga: mechanizm działa tylko dla użytkowników zalogowanych do konta Google, więc nigdy nie odzyska wszystkiego.
Odzyskane konwersje trafiają do tej samej akcji konwersji co pozostałe. Nie ma osobnej kolumny „z konwersji rozszerzonych” — to jednocześnie zaleta, bo dane od razu zasilają strategie stawek, i utrudnienie, bo trudno rozdzielić efekt wdrożenia od zmian w kampanii.
To pytanie zadaje mi każdy klient, który słyszy „przekazujemy adres e-mail do Google”, i zadaje je słusznie.
Dane nie opuszczają przeglądarki w postaci jawnej. Przed wysłaniem są przekształcane funkcją skrótu SHA-256, czyli zamieniane w ciąg znaków, z którego nie da się odtworzyć oryginału. Google po swojej stronie liczy skrót z danych, które już ma, i porównuje jeden ciąg z drugim. Dopasowanie albo jest, albo go nie ma — sam adres nigdzie nie jedzie.
Przed haszowaniem dane muszą być znormalizowane: bez spacji na początku i końcu, małymi literami, numer telefonu w formacie międzynarodowym. Jeśli formularz przepuszcza adresy z wielką literą albo telefony bez prefiksu kraju, skróty nie będą się zgadzać i dopasowań będzie mniej, choć technicznie wszystko „działa”. Standardowe wdrożenia robią tę normalizację za nas, ale przy własnej implementacji trzeba o niej pamiętać.
Osobno: żeby włączyć tę funkcję, w koncie Google Ads trzeba zaakceptować warunki dotyczące danych klientów. To formalność w interfejsie, ale w praktyce oświadczenie, że masz podstawę do przekazania tych danych i poinformowałeś o tym użytkowników. Politykę prywatności trzeba zaktualizować przed wdrożeniem, nie po.
Sprawdzam cztery rzeczy, zanim cokolwiek konfiguruję.
Pierwsza, najprostsza, to wdrożenie oparte na tagu Google Ads już obecnym na stronie. Wskazujesz, w których elementach strony podziękowania znajdują się dane — przez selektory pól albo automatyczne wykrywanie — a haszowanie dzieje się po stronie przeglądarki. Zaleta: nie trzeba ruszać kodu. Wada: łamie się przy każdej przebudowie szablonu, bo selektory przestają pasować.
Druga to menedżer tagów. Dane przekazuję z warstwy danych do dedykowanego tagu, co daje kontrolę nad tym, co dokładnie jest wysyłane i pod jakim warunkiem. Wybieram ten sposób wszędzie, gdzie mam dostęp do warstwy danych, bo jest odporny na zmiany wyglądu strony i łatwiej go debugować.
Trzecia to przekazywanie danych po stronie serwera, przez interfejs programistyczny. Najtrwalsze rozwiązanie i jedyne, które nie zależy od tego, co zrobi przeglądarka. Wymaga pracy programisty, więc proponuję je sklepom, które i tak mają zespół techniczny.
Niezależnie od drogi: wdrożenie testuję na środowisku testowym albo na jednej akcji konwersji, a nie od razu na wszystkich. Błąd w selektorze potrafi wysłać do Google zawartość zupełnie innego pola i to jest ostatnia rzecz, którą chcesz odkryć po miesiącu.
Osobno wspomnę o kierunku, który jest obecnie w becie i pojawia się na części kont: rozszerzeniu tego samego pomysłu na sprzedaż, która domyka się poza witryną.
Logika jest taka: formularz zbiera adres e-mail, sprzedaż zamyka się w rozmowie telefonicznej kilka tygodni później, a informację o wygranej transakcji trzeba jakoś odesłać do Google Ads. Dotychczas robiło się to przez import konwersji offline z identyfikatorem kliknięcia, co wymagało przechowywania tego identyfikatora w systemie klienta. Testowany mechanizm pozwala dopasować transakcję po zahaszowanym adresie e-mail, czyli po polu, które w bazie i tak jest.
Podkreślam: to jeszcze nie jest funkcja powszechnie dostępna i nie planowałbym dziś wokół niej wdrożenia u klienta. Warto o niej wiedzieć, bo jeśli wejdzie szerzej, uprości pomiar w firmach usługowych bardziej niż cokolwiek innego w ostatnim czasie. Do tego momentu import konwersji offline z identyfikatorem kliknięcia pozostaje właściwym rozwiązaniem.
Pierwszym miejscem jest zakładka diagnostyki przy akcji konwersji. Pokazuje status wdrożenia i najczęstsze problemy: brak danych w zdarzeniach, dane w złym formacie, brak akceptacji warunków. Zaglądam tam po wdrożeniu i jeszcze raz po tygodniu, bo część problemów ujawnia się dopiero na większym ruchu.
Drugim jest podgląd tagów. Chcę zobaczyć, że w zdarzeniu konwersji faktycznie lecą pola z danymi i że są to skróty, a nie tekst jawny. To pięć minut pracy, które oszczędza bardzo nieprzyjemną rozmowę.
Czego nie robię: nie porównuję liczby konwersji z dnia przed wdrożeniem i z dnia po. Efekt nie pojawia się natychmiast, dopasowania przetwarzane są z opóźnieniem, a dzienne wahania są większe niż różnica, której szukasz. Patrzę na dłuższe okresy i pamiętam, że jednocześnie mogły zmienić się budżety, sezon i konkurencja.
I rzecz, o której warto powiedzieć klientowi z góry: nie obiecuję, ile konwersji wróci. Zależy to od tego, jaka część klientów jest zalogowana do konta Google, ile danych zbiera formularz i jak wygląda ścieżka zakupowa. Obiecuję natomiast, że dane będą bliżej rzeczywistości niż były — a to jest warunek sensownego działania automatycznych strategii, które uczą się dokładnie z tych liczb.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |