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.
W kampaniach generujących leady mam od lat ten sam problem: Google Ads widzi tylko wysłany formularz. Nie widzi rozmowy, którą handlowiec odbył trzy dni później, nie widzi oferty, nie widzi podpisanej umowy. Optymalizuje więc pod coś, co jest zaledwie zapowiedzią sprzedaży.
Skutek jest przewidywalny i widuję go regularnie. Algorytm dowiaduje się, że formularze z pewnej grupy zapytań są tanie, więc dosypuje tam budżetu. Po miesiącu okazuje się, że to najtańsze leady na koncie i jednocześnie najgorsze — ludzie pytają o coś, czego firma nie robi, albo szukają najtańszej oferty na rynku.
Śledzenie konwersji offline jest odpowiedzią na dokładnie tę sytuację. Polega na tym, żeby po zamknięciu transakcji wrócić do Google Ads i powiedzieć: ten konkretny lead, z tego konkretnego kliknięcia, okazał się wart tyle. Konfiguracja nie jest trudna technicznie, ale wymaga współpracy z osobami, które na co dzień nie zaglądają do panelu reklamowego.
Bo liczba formularzy nie jest celem biznesowym. Celem jest przychód, a między jednym a drugim potrafi być przepaść.
Kiedy przekazuję do Google Ads informację o zamkniętych transakcjach, dzieją się dwie rzeczy. Pierwsza jest oczywista: widzę w raportach, które kampanie, grupy i zapytania faktycznie dowożą klientów, a nie tylko zgłoszenia. To zmienia decyzje o budżecie w sposób, którego żadna analiza samych leadów nie zastąpi.
Druga jest ważniejsza. Strategie automatyczne uczą się na tym, co im podasz jako konwersję. Jeśli podasz formularz, będą optymalizować pod formularze. Jeśli podasz zamkniętą sprzedaż z jej wartością, zaczną szukać ludzi podobnych do tych, którzy kupili. To ten sam mechanizm, który w e-commerce działa od dawna dzięki wartości transakcji — tylko w usługach trzeba go zbudować ręcznie.
Uczciwie: przy bardzo małej liczbie domkniętych transakcji miesięcznie efekt uczenia będzie ograniczony. Wartość raportowa pozostaje jednak nawet wtedy, a to zwykle wystarcza, żeby wdrożenie się opłaciło.
Cały mechanizm opiera się na jednym identyfikatorze.
Kiedy ktoś klika reklamę, Google dokleja do adresu docelowego parametr GCLID — unikalny identyfikator tego kliknięcia. Zadaniem strony jest ten parametr przechwycić i zapisać razem z danymi z formularza. Potem, gdy lead zamieni się w klienta, wysyłasz do Google Ads plik albo żądanie API mówiące: GCLID taki a taki, konwersja o nazwie „Umowa podpisana”, data, wartość.
Google dopasowuje GCLID do oryginalnego kliknięcia i przypisuje konwersję wstecz — do właściwej kampanii, grupy reklam i zapytania. Z punktu widzenia raportów wygląda to tak, jakby konwersja nastąpiła w momencie kliknięcia, mimo że wydarzyła się tygodnie później.
Warto od razu wiedzieć o dwóch ograniczeniach. Po pierwsze, GCLID trzeba złapać i przechować — jeśli formularz go nie zapisuje, nie ma czego wysyłać i nie da się tego odzyskać wstecz. Po drugie, istnieje maksymalne okno czasowe między kliknięciem a zaimportowaną konwersją; przy bardzo długich procesach sprzedażowych część transakcji z niego wypadnie. Warto sprawdzić aktualny limit w dokumentacji, zanim obiecasz zarządowi pełne domknięcie pętli.
Kolejność ma znaczenie, bo pierwszy krok jest nieodwracalny w tym sensie, że dane niezłapane dziś przepadają na zawsze.
Pierwszy import zwykle się nie udaje i to normalne. Najczęstsze przyczyny to zły format daty, nazwa akcji konwersji niezgodna co do znaku z tą w panelu oraz GCLID-y starsze niż dopuszczalne okno.
Bywa, że przechwycenie GCLID jest niewykonalne: formularz obsługuje zewnętrzny system, strona jest poza kontrolą działu marketingu albo lead przychodzi telefonicznie.
Wtedy sięgam po konwersje rozszerzone dla leadów. Zamiast identyfikatora kliknięcia przesyłasz zahaszowane dane kontaktowe — najczęściej adres e-mail — które użytkownik sam podał w formularzu. Google dopasowuje je do zalogowanego konta, które kliknęło reklamę, i przypisuje konwersję.
Różnica praktyczna jest taka, że nie musisz nic przechowywać na etapie kliknięcia — wystarczy, że masz adres e-mail klienta w CRM i wiesz, kiedy transakcja została zamknięta. Wymogiem jest natomiast poprawne przygotowanie danych po Twojej stronie: haszowanie zgodne ze specyfikacją i normalizacja zapisu adresu.
Dopasowanie z natury rzeczy nie obejmie wszystkich transakcji, bo nie każdy użytkownik jest rozpoznawalny. Traktuję to jako uzupełnienie, nie jako zamiennik pełnego wdrożenia z GCLID tam, gdzie jest ono możliwe.
Sam import to dopiero połowa roboty. Druga połowa to decyzja, co właściwie importujesz.
Najważniejsze ustalenie dotyczy wartości. Wysyłanie samego faktu podpisania umowy bez kwoty sprawia, że system traktuje kontrakt na tysiąc złotych i na sto tysięcy identycznie. Jeśli w Twojej firmie transakcje różnią się wartością — a zwykle różnią się bardzo — przekazuj kwotę i optymalizuj pod wartość, nie pod liczbę.
Drugie ustalenie dotyczy tego, które akcje oznaczasz jako konwersje główne. Zwykle zostawiam w tej roli jeden etap, ten najbliższy pieniądzom, a wcześniejsze etapy śledzę jako pomocnicze. Kilka konwersji głównych naraz oznacza, że algorytm dostaje kilka sprzecznych celów.
Trzecie to regularność. Import raz na kwartał jest niemal bezużyteczny — dane docierają tak późno, że przestają opisywać rzeczywistość. Import codzienny albo przynajmniej tygodniowy daje systemowi szansę na naukę.
I rzecz z pogranicza organizacji, nie techniki: ktoś w firmie musi rzetelnie oznaczać w CRM, co się z leadem stało. Jeśli handlowcy nie domykają statusów, cały mechanizm karmi się fikcją.
Brak przechwytywania GCLID od pierwszego dnia. To jedyny błąd w tej układance, którego nie da się naprawić wstecz. Nawet jeśli import wdrożysz dopiero za pół roku, zacznij zapisywać identyfikator już teraz.
Podwójne liczenie. Jeśli formularz nadal jest konwersją główną i dokładasz do tego zamkniętą sprzedaż jako drugą konwersję główną, konto raportuje dwa razy tę samą ścieżkę i optymalizuje pod mieszankę obu.
Import bez wartości. Opisany wyżej, ale powtórzę, bo to najczęstsza przyczyna rozczarowania efektami.
Zbyt długi łańcuch decyzyjny. Jeśli między zamknięciem transakcji a importem mija więcej czasu niż dopuszczalne okno, dane po prostu nie wejdą. Warto sprawdzić to zawczasu, zwłaszcza w branżach, gdzie proces sprzedaży trwa miesiącami.
Traktowanie tego jako projektu marketingu. To projekt na styku marketingu, sprzedaży i IT. Jeśli wchodzisz w niego bez zgody i zaangażowania działu handlowego, skończy się na jednym pliku wgranym testowo i zapomnianym.
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 |