Co musisz mieć, zanim wybierzesz metodę

Niezależnie od sposobu przesyłania, w CRM muszą znaleźć się trzy rzeczy.

Identyfikator kliknięcia. Najczęściej GCLID, przechwycony przy pierwszej wizycie i zapisany razem z rekordem leada. Jeśli prowadzisz też kampanie w innych systemach reklamowych, każdy ma własny parametr i warto przechowywać je w osobnych polach, a nie w jednym „źródło”.

Znacznik czasu zmiany statusu. Nie data utworzenia leada, a data zdarzenia, które importujesz — moment podpisania umowy albo wpłaty. Google przypisze konwersję do kliknięcia, ale w raportach potrzebuje wiedzieć, kiedy nastąpiła.

Wartość. Kwota transakcji, najlepiej netto i w jednej, stałej walucie. Bez niej optymalizacja pod wartość jest niemożliwa, a to zwykle główny powód, dla którego cały projekt się robi.

Do tego dochodzi ustalenie organizacyjne, które jest ważniejsze niż technika: ktoś musi odpowiadać za rzetelność statusów w CRM. Jeśli handlowcy zamykają szanse sprzedaży wybiórczo albo z opóźnieniem tygodni, żadna integracja tego nie naprawi.

Wariant 1 — ręczny plik

Najprostsza droga: eksportujesz z CRM arkusz z kolumnami GCLID, nazwa konwersji, data i godzina, wartość, waluta, a potem wgrywasz go w Google Ads jako import konwersji offline.

Zalety są realne. Uruchamiasz to w godzinę, bez udziału programistów, i od razu widzisz, czy dane w ogóle się dopasowują. Do walidacji całego pomysłu nie ma lepszej metody — zanim zbudujesz integrację, warto sprawdzić na jednym pliku, jaki odsetek GCLID-ów faktycznie się przypisuje.

Wada jest jedna, ale zabójcza: to proces, który ktoś musi wykonywać ręcznie w nieskończoność. Z mojego doświadczenia takie rozwiązania żyją do pierwszego urlopu osoby odpowiedzialnej. Traktuję je więc wyłącznie jako etap testowy, nie docelowy, i mówię to klientowi od początku, żeby nie było złudzeń.

Wariant 2 — arkusz w chmurze z harmonogramem

Wariant, który polecam najczęściej, bo daje najlepszy stosunek trwałości do kosztu.

Google Ads potrafi pobierać plik z konwersjami z arkusza w chmurze albo z adresu HTTPS według harmonogramu — codziennie albo co tydzień. Twoim zadaniem jest zadbać, żeby ten arkusz sam się aktualizował: eksportem z CRM, prostym skryptem albo narzędziem do automatyzacji przepływów, jeśli CRM ma gotowy konektor.

W praktyce oznacza to, że raz konfigurujesz źródło i harmonogram, a potem proces działa bez ludzkiej ręki. Nie potrzebujesz zespołu programistów, a mimo to nie masz zadania powtarzalnego na czyjejś liście obowiązków.

Warto pamiętać o dwóch rzeczach. Arkusz powinien zawierać tylko nowe rekordy albo mieć mechanizm odporny na powtórki, bo ponowne wysłanie tej samej konwersji może ją zdublować. I trzeba gdzieś zaglądać po błędy — Google raportuje odrzucone wiersze, ale nikt Cię o tym nie poinformuje, jeśli sam nie sprawdzisz.

Wariant 3 — integracja przez API

Rozwiązanie docelowe dla firm, które traktują ten kanał poważnie i mają zaplecze techniczne.

CRM wysyła konwersję do Google Ads w momencie zmiany statusu, przez interfejs programistyczny. Dane docierają natychmiast, nie ma pliku, nie ma harmonogramu, nie ma ryzyka, że ktoś zapomni. Do tego dostajesz w odpowiedzi konkretną informację o błędzie dla każdego rekordu, co bardzo skraca diagnostykę.

Koszt to praca programistyczna: uwierzytelnianie, obsługa limitów, ponawianie nieudanych żądań, logowanie. Do tego dochodzi utrzymanie, bo interfejsy programistyczne mają wersje i starsze są z czasem wyłączane — trzeba mieć kogoś, kto raz w roku to podniesie.

Wybieram tę drogę, gdy liczba transakcji jest duża, proces sprzedaży szybki albo gdy firma i tak ma dział rozwoju, dla którego to zadanie na kilka dni.

Wariant 4 — konwersje rozszerzone dla leadów

Osobna ścieżka, przydatna, gdy nie da się przechwycić GCLID.

Zamiast identyfikatora kliknięcia przesyłasz zahaszowany adres e-mail, który klient sam podał w formularzu. Dopasowanie następuje po stronie Google. Zaletą jest to, że nie musisz nic zmieniać na etapie wejścia na stronę — wystarczy, że masz kontakt w CRM.

Ograniczenie jest wbudowane w metodę: dopasuje się tylko część rekordów, bo nie każdy użytkownik jest rozpoznawalny. Nie traktuję tego jako słabości rozwiązania, a jako jego charakterystykę — i uprzedzam o tym, zanim ktoś porówna liczby z CRM z liczbami w panelu i uzna, że coś jest zepsute.

Dane osobowe wymagają tu szczególnej uwagi: haszowanie musi być zgodne ze specyfikacją, a podstawa prawna przekazywania takich danych powinna być ustalona przed wdrożeniem, nie po.

Jak sprawdzić, że import faktycznie działa

Pierwsza rzecz, na którą patrzę po wdrożeniu, to odsetek dopasowanych rekordów. Jeśli z pliku ze stu konwersjami przypisało się pięć, problem prawie zawsze siedzi w przechwytywaniu GCLID — najczęściej ginie on przy przejściu przez podstronę albo przy przekierowaniu.

Druga to rozkład konwersji w czasie. Zaimportowane konwersje pojawiają się w raportach z datą kliknięcia, więc dane z ostatnich tygodni będą przez pewien czas wyglądać na niepełne. To normalne i trzeba to uwzględnić przy ocenie kampanii — porównywanie ostatnich siedmiu dni z okresem sprzed dwóch miesięcy zawsze wypadnie na niekorzyść bieżącego okresu.

Trzecia to zgodność z CRM. Raz w miesiącu zestawiam liczbę zamkniętych transakcji w CRM z liczbą zaimportowanych konwersji. Rozjazd, który rośnie, oznacza zwykle albo zmianę w formularzu, albo cichą awarię harmonogramu.

Na koniec rzecz, o której łatwo zapomnieć w euforii po wdrożeniu: dopóki nowe akcje konwersji nie zbiorą sensownej historii, nie przełączam na nie strategii automatycznej. Najpierw obserwuję dane, potem zmieniam sposób licytowania — nie odwrotnie.