Konwersje rozszerzone dołączają do konwersji Google Ads zahaszowany e-mail albo telefon klienta, który Google dopasowuje do zalogowanych kont. Wdrożenie ma 4 kroki, a o wyniku decyduje to, czy dane klienta są dostępne w chwili wysłania konwersji:
- włączenie konwersji rozszerzonych w ustawieniach konta Google Ads,
- przekazanie danych użytkownika do tagu konwersji, najczęściej przez Google Tag Manager,
- uzależnienie wysyłki danych od zgody
ad_user_dataw Consent Mode v2, - sprawdzenie parametru
emw żądaniu konwersji i diagnostyki w Google Ads.
Zwykły tag konwersji łączy konwersję z kliknięciem reklamy przez plik cookie. Gdy pliku nie ma, bo klient kliknął reklamę na telefonie, a kupił na komputerze, albo usunął ciasteczka, Google może odzyskać część takich konwersji po zahaszowanym e-mailu. Dopasowanie działa tylko dla osób, które były zalogowane na konto Google podczas kontaktu z reklamą.
Czego potrzeba przed wdrożeniem konwersji rozszerzonych?
Wdrożenie wymaga 4 warunków:
- działania powodującego konwersję z tagu Google albo z Google Tag Managera, bo konwersje importowane z celów Google Analytics według instrukcji Google nie obsługują konwersji rozszerzonych,
- danych klienta w chwili konwersji, czyli e-maila (Google wskazuje go jako preferowany klucz), telefonu albo kompletu adresowego z imieniem, nazwiskiem, kodem pocztowym i krajem,
- strony konwersji w HTTPS, bo na stronie HTTP tag nie haszuje danych i zamiast skrótu wysyła kod błędu
e3, - banera zgód, który przekazuje stan zgody do Consent Mode v2, w tym parametr
ad_user_data.
1. Włącz konwersje rozszerzone na koncie Google Ads
W Google Ads otwierasz Cele > Ustawienia, rozwijasz panel „Wykorzystanie danych klientów” i zaznaczasz „Włącz konwersje rozszerzone”. Obok stoi opcja „Włącz listy klientów oparte na konwersjach”, czyli osobna zgoda na budowanie z tych samych danych list klientów na koncie. Na końcu akceptujesz warunki dotyczące danych klientów. Ustawienie obejmuje całe konto, a pojedyncze działanie powodujące konwersję da się z niego wyłączyć.
Od kwietnia 2026 r. Google Ads przyjmuje dane użytkownika jednocześnie z tagów witryny, Menedżera danych i API, więc wybór jednej metody wdrożenia przestał być potrzebny. Konta, które korzystały z funkcji wcześniej, Google przenosi na nowe ustawienie automatycznie. Część instrukcji Google nadal opisuje krok wyboru metody z listy i ostrzega, że dane wysłane inną drogą mogą nie zostać przetworzone. Jeśli Twoje konto wciąż pokazuje tę listę, wybierasz na niej metodę, którą faktycznie wysyłasz dane.
Przed akceptacją warunków tag nie dołącza danych użytkownika do konwersji, nawet gdy są skonfigurowane. W teście na koncie bez zaakceptowanych warunków tag Google wysłał konwersję z ustawionym obiektem user_data, ale bez parametru em, zarówno przy zgodzie, jak i bez niej. Brak em na tym etapie jest więc oczekiwany i nie oznacza błędu tagu.
2. Przekaż dane użytkownika do tagu konwersji
Tag odczytuje dane klienta w chwili wysłania konwersji. Jeśli e-mail zniknął już ze strony albo z warstwy danych, konwersja idzie bez niego, a podgląd Google Tag Managera i tak pokazuje tag jako uruchomiony. Wdrożenie może więc wyglądać na poprawne i nie przekazywać żadnych danych. Dlatego wybór sposobu przekazania zaczyna się od pytania, gdzie e-mail jest w momencie konwersji.
Który sposób przekazania danych wybrać?
| Sposób | Skąd tag bierze dane | Kiedy działa | Ryzyko |
|---|---|---|---|
| automatyczne wykrywanie | przeszukuje stronę w poszukiwaniu ciągów, które wyglądają jak e-mail, telefon albo adres | strona potwierdzenia wyświetla dane klienta | łapie też e-mail i telefon firmy z nagłówka albo stopki; wykluczasz je selektorami |
| selektory CSS albo zmienne JavaScript | wskazany element strony | stały układ strony, pole z atrybutem id | przebudowa szablonu zmienia selektor |
| warstwa danych (dataLayer) | wartości, które strona przekazuje w zdarzeniu | formularze wysyłane bez przeładowania, przekierowanie na stronę podziękowania, sklepy | wymaga pracy programisty |
| kod | obiekt user_data przekazany w kodzie strony albo w zmiennej GTM |
dane pochodzą z systemu, na przykład z konta zalogowanego klienta | wymaga pracy programisty; Google traktuje dane z kodu priorytetowo |
Warstwa danych ma sens, gdy formularz wysyła się bez przeładowania strony albo przekierowuje na stronę podziękowania, bo dane nie zależą wtedy od wyglądu strony. Automatyczne wykrywanie ma sens na stronie potwierdzenia, która pokazuje e-mail klienta.
Formularz osadzony w ramce iframe z innej domeny, na przykład z HubSpota albo Marketo, jest poza zasięgiem automatu i selektorów. Zasada tego samego pochodzenia (same-origin policy) nie pozwala skryptom strony czytać pól dokumentu z innej domeny. Dane z takiego formularza trafią do tagu tylko wtedy, gdy formularz sam przekaże je do strony, na przykład zdarzeniem w warstwie danych.
Jak skonfigurować konwersje rozszerzone w Google Tag Manager?
Konfiguracja w Google Tag Managerze ma 5 czynności:
- W kontenerze masz tag Google z kontem Google Ads jako miejscem docelowym. W jego ustawieniach (Zarządzaj) włączasz „Zezwalaj na zbieranie danych przekazywanych przez użytkowników” i wybierasz sposób zbierania.
- Przy konfiguracji ręcznej tworzysz zmienną „Dane przekazywane przez użytkowników” i przypisujesz do pól e-mail, telefon i adres zmienne warstwy danych albo elementy DOM, najlepiej wskazane przez atrybut id.
- Zmienną dołączasz jako parametr zdarzenia
user_datado tagu, który wysyła konwersję. - Pola, których formularz nie zbiera, usuwasz ze zmiennej zamiast zostawiać je puste.
- Publikujesz kontener dopiero po testowej konwersji w trybie podglądu i po sprawdzeniu żądania (krok 4).
Bez Google Tag Managera ten sam obiekt ustawia w kodzie strony polecenie gtag('set', 'user_data', {...}), wywołane przed zdarzeniem konwersji.
Co zrobić, gdy e-mail jest na innej stronie niż konwersja?
Google przewiduje na ten przypadek osobny tag „Zdarzenie Google Ads dotyczące danych przekazywanych przez użytkowników” z regułą „Przesłanie formularza”. Tag zbiera dane na stronie formularza, a Google łączy je z konwersją w tej samej sesji przez plik cookie reklamowy. Ten plik podlega zgodzie ad_storage, więc bez niej połączenie nie działa.
Druga droga to zapis danych w pamięci sesji przeglądarki (sessionStorage) na stronie formularza i odczyt na stronie podziękowania. Zapisane tam wartości odczyta każdy skrypt działający w tej domenie, dlatego bezpieczniej przechowywać skrót SHA-256 niż e-mail jawnym tekstem. Skrót musi wtedy powstać według zasad normalizacji Google.
Haszować dane samemu czy zostawić to tagowi?
Tag, który dostaje dane jawne, sam je normalizuje i haszuje funkcją SHA-256, a do Google wysyła skrót. Własne haszowanie ma sens, gdy przechowujesz dane między stronami albo wysyłasz je z serwera. Przed SHA-256 wykonujesz wtedy 4 czynności normalizacji opisane przez Google:
- usunięcie spacji na początku i na końcu,
- zamianę liter na małe,
- zapis telefonu w formacie E.164, czyli z prefiksem kraju i bez spacji, myślników i nawiasów (+48600100200),
- usunięcie kropek przed znakiem @ w adresach gmail.com i googlemail.com.
Skrót zapisujesz szesnastkowo (64 znaki) i przekazujesz w polach sha256_email_address albo sha256_phone_number. Każda różnica w zapisie daje inny skrót. „Jan.Kowalski@Gmail.com” i „jan.kowalski@gmail.com” dają dwa różne ciągi SHA-256, więc skrót z niepoprawnie znormalizowanego adresu nie dopasuje się do konta Google.
Dokumentacja Google nie jest tu spójna. Specyfikacja Google Ads API każe przy adresach Gmail usuwać też część po znaku „+”, a instrukcje tagu i przykładowy kod w tej samej specyfikacji tego nie robią. Przy danych wysyłanych jawnie ten problem nie występuje, bo normalizację wykonuje tag.
3. Uzależnij wysyłkę danych od zgody
Wysyłką danych użytkownika do Google steruje parametr ad_user_data trybu uzyskiwania zgody, czyli Consent Mode v2. Google deklaruje, że tag dołącza dane przekazywane przez użytkowników tylko wtedy, gdy konto zaakceptowało warunki i gdy wymagane parametry zgody mają stan „granted”.
Bez zgody tag nie milknie. W teście z odmową wszystkich zgód tag wysłał konwersję do innej domeny Google (pagead2.googlesyndication.com), bez identyfikatora reklamowego i z oznaczeniem odmowy w parametrze gcs=G100. Tak działa zaawansowany tryb Consent Mode, a Google deklaruje, że na podstawie takich sygnałów modeluje część konwersji. Danych klienta te sygnały nie zawierają. Jeśli baner zgód nie aktualizuje stanu po kliknięciu „Akceptuj”, konwersje rozszerzone nie dostają danych od nikogo, więc test zgody idzie przed testem samych konwersji rozszerzonych.
Zahaszowany e-mail to nadal dana osobowa. RODO w motywie 26 uznaje dane spseudonimizowane, które da się przypisać osobie przy użyciu dodatkowych informacji, za informacje o możliwej do zidentyfikowania osobie. Google porównuje skrót ze skrótami adresów swoich użytkowników, czyli dysponuje taką dodatkową informacją. Polityka prywatności strony informuje więc o przekazywaniu danych do Google w celu pomiaru skuteczności reklam, a podstawę prawną przekazania wskazuje administrator danych.
4. Sprawdź, czy dane dochodzą i czy pasują
Pierwszy test robisz od razu po publikacji, bez czekania na raporty Google Ads. W narzędziach deweloperskich Chrome, na karcie Sieć, wykonujesz testową konwersję i szukasz żądania do googleadservices.com/pagead/conversion/ albo google.com/pagead/1p-conversion/. Parametr em z wartością, która zaczyna się od tv.1~em i ma po sobie długi ciąg znaków, oznacza, że tag odczytał i zahaszował dane.
Co oznacza pusty parametr em albo kod błędu?
| Co widzisz w żądaniu | Znaczenie według Google | Co sprawdzić |
|---|---|---|
| brak parametru em | dane nie trafiły do tagu albo konto nie zaakceptowało warunków | krok 1 i zgodę ad_user_data |
| samo tv.1~em | parametr jest pusty, danych nie było w chwili konwersji | moment odczytu i wartość zmiennej w podglądzie GTM |
| kod e0 | dane nie przechodzą walidacji formatu, na przykład e-mail bez @ | źródło zmiennej |
| kod e1 | stara, nieobsługiwana przeglądarka | test w aktualnym Chrome |
| kod e2 | haszowanie SHA-256 nie powiodło się | nietypowe znaki w danych |
| kod e3 | strona nie działa w HTTPS | adres strony konwersji |
Jak czytać diagnostykę konwersji rozszerzonych w Google Ads?
Raport diagnostyki pojawia się po około 72 godzinach w Cele > Podsumowanie, w działaniu powodującym konwersję, na karcie Diagnostyka. Raport pokazuje 2 wskaźniki:
- pokrycie, czyli odsetek konwersji, które przyszły z wystarczającymi danymi użytkownika; niski wynik wskazuje na problem z odczytem danych z kroku 2,
- współczynnik dopasowania, czyli część tych danych, która pasuje do zalogowanych kont Google; Google oznacza wynik od 0 do 15% jako niski, a powyżej 15% jako wysoki.
Niski współczynnik dopasowania przy wysokim pokryciu Google tłumaczy złym formatem danych albo klientami, którzy nie mają kont Google lub podają inne dane niż w koncie. Google zaleca przekazywanie wszystkich 3 kluczy dopasowania, czyli e-maila, telefonu i adresu. Alerty diagnostyki nie pojawiają się, gdy działanie ma mniej niż 20 konwersji w 7 dniach.
Kilka dni po wdrożeniu działanie dostaje w kolumnie „Stan” komunikat „Rejestruję (przetwarzam konwersje rozszerzone)”. Według Google system uczy się do 30 dni, zanim wpływ konwersji rozszerzonych pojawi się w raportach. Potem stan zmienia się na „Rejestruję (konwersje rozszerzone)”, a karta przy nim przez 30 dni pokazuje, o ile wzrosła liczba raportowanych konwersji.
Jak wdrożyć wariant dla potencjalnych klientów z CRM?
Wariant dla potencjalnych klientów służy firmom, w których sprzedaż kończy się poza stroną, czyli przez telefon, na spotkaniu albo umową w CRM. Wdrożenie ma 2 części:
- na stronie tag konwersji formularza wysyła dane użytkownika tak samo jak w krokach 1-4,
- w CRM po zamknięciu sprzedaży importujesz konwersję offline z tym samym e-mailem albo telefonem, a Google dopasowuje ją do danych zebranych na stronie po tych samych skrótach.
Ten sam e-mail w formularzu i w CRM jest warunkiem dopasowania. Adres poprawiony ręcznie przez handlowca daje inny skrót i zrywa połączenie z kliknięciem reklamy.
Od 15 czerwca 2026 r. Google Ads API nie przyjmuje nowych wdrożeń importu konwersji offline, w tym konwersji rozszerzonych dla potencjalnych klientów. Nową integrację z CRM budujesz przez Menedżera danych w Google Ads albo przez Data Manager API. Integracje, które już wcześniej wysyłały dane przez Google Ads API, działają dalej w czasie migracji.
Potrzebujesz wsparcia w SEO lub AI Search?
Przeanalizuję sytuację Twojej strony i wskażę, które działania realnie zwiększą jej widoczność.