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.
Tydzień temu Google poinformowało, że nie zdąży ograniczyć ciasteczek stron trzecich w Chrome w drugiej połowie tego roku i przesuwa start na początek 2025. To trzecie przesunięcie tego terminu. Reakcja w branży była taka, jakiej można się było spodziewać: część osób odetchnęła z ulgą i wróciła do tego, co robiła.
Uważam to za błąd, i to nie z powodów ideowych. Przez ostatnie dwa lata zmieniło się dość rzeczy niezależnych od Chrome, żeby konta oparte wyłącznie na danych zbieranych przez skrypty firm trzecich już dziś działały słabiej: obowiązkowy tryb zgody w Europie od marca, ograniczenia w przeglądarkach Safari i Firefox działające od lat, krótsze okna atrybucji, coraz większa część pomiaru wyliczana modelowo. Przesunięcie o rok nie odwraca żadnej z tych rzeczy.
Poniżej opisuję, jak podchodzę do budowy strategii Google Ads dla firmy, która chce oprzeć kampanie na danych własnych. Nie jako do projektu technologicznego, a jako do zwykłej kolejności działań na koncie.
Zacznę od rozwiania nieporozumienia, które słyszę najczęściej: „skoro nie będzie ciasteczek, to nie będzie remarketingu”. Nieprawda i warto rozumieć dlaczego.
Ciasteczka stron trzecich obsługują rozpoznawanie tego samego użytkownika między różnymi domenami. Na tym stoi klasyczny remarketing w sieci reklamowej i część pomiaru między witrynami. Nie znikają natomiast ciasteczka własne, czyli te zapisywane przez domenę, na której użytkownik faktycznie jest — a to na nich opiera się pomiar konwersji na naszej stronie, listy odbiorców zbierane z naszego serwisu i identyfikacja sesji.
To, co realnie się kurczy, to zasięg mierzony poza naszą domeną: rozpoznawanie użytkownika na cudzych stronach, pomiar wyświetleń w sieci reklamowej, dokładność atrybucji ścieżek prowadzących przez wiele witryn. Kampanie w wyszukiwarce i kampanie produktowe, w których użytkownik trafia do nas i tu konwertuje, tracą najmniej.
Wniosek praktyczny jest nudny, ale konsekwentny: im więcej sygnałów pochodzi z relacji między nami a klientem, tym mniej zależymy od tego, co Google zrobi z Chrome w przyszłym roku.
Od 6 marca tryb uzyskiwania zgody w wersji 2 jest wymogiem dla reklamodawców kierujących reklamy do Europejskiego Obszaru Gospodarczego i Wielkiej Brytanii. Bez niego przestaje działać dokładnie to, o czym mówi ten tekst: listy klientów, remarketing i przekazywanie sygnałów użytkownika do Google Ads.
W praktyce oznacza to dwa dodatkowe parametry przekazywane z banera zgody — jeden dotyczący reklam, drugi personalizacji — i konieczność sprawdzenia, czy narzędzie zgody faktycznie je wysyła. Na kontach, które przeglądałem w marcu i kwietniu, najczęstszym problemem nie był brak banera, a baner, który zgody zbierał i nigdzie ich nie przekazywał. Diagnostyka jest prosta: podgląd w Tag Managerze plus komunikaty w panelu Google Ads.
Druga decyzja, którą trzeba przy tym podjąć, dotyczy trybu podstawowego albo zaawansowanego. W podstawowym tagi nie uruchamiają się w ogóle do momentu zgody. W zaawansowanym uruchamiają się, ale bez identyfikatorów, przekazując anonimowe sygnały, z których Google modeluje brakujące konwersje. Dla większości sklepów, z którymi pracuję, wariant zaawansowany daje wyraźnie pełniejszy obraz — ale to decyzja, którą powinien zaakceptować prawnik klienta, nie ja.
Zanim zacznę cokolwiek wdrażać, robię listę tego, co w firmie leży w szufladzie. Prawie zawsze jest tego więcej, niż klient sądzi, i prawie nigdy nie jest to używane w reklamie.
Z tej listy powstaje plan, w jakiej kolejności podłączać dane do konta. Wszystkiego naraz nie da się zrobić i nie warto próbować.
Jeśli miałbym wskazać jedną rzecz do wdrożenia w pierwszej kolejności, są to konwersje rozszerzone. Działają od 2021 roku, są dostępne na każdym koncie i mimo to spotykam je rzadko.
Mechanizm polega na tym, że przy konwersji przekazujemy do Google zahaszowany adres e-mail albo numer telefonu z formularza lub zamówienia. Google porównuje ten skrót ze swoimi zalogowanymi użytkownikami i domyka konwersje, które przy samym ciasteczku byłyby nieprzypisane. Dane wychodzą z przeglądarki w postaci skrótu, nie w postaci jawnej.
Efekt jest podwójny. Po pierwsze, pełniejszy pomiar — a więc lepsze dane dla strategii automatycznych, które przecież uczą się na konwersjach. Po drugie, mniej rozbieżności między liczbą zamówień w systemie klienta a liczbą w panelu, co ratuje niejedną rozmowę o wynikach.
Wariant dla leadów, przekazujący dane z CRM już po fakcie, jest osobną rzeczą i wymaga więcej pracy po stronie klienta, ale na kontach B2B to on daje największą różnicę: system zaczyna optymalizować pod leada, który zamienił się w rozmowę handlową, a nie pod każdy wypełniony formularz.
Lista klientów to najbardziej dosłowne użycie danych własnych — wgrywamy zahaszowane kontakty i Google dopasowuje je do swoich użytkowników. Dopasowuje część, nie wszystkie, więc pierwsza rzecz, którą sprawdzam, to rozmiar listy po dopasowaniu. Zbyt małe segmenty po prostu nie zaczną działać.
Zastosowania, które mają sens w tej kolejności:
Higiena jest tu ważniejsza niż pomysłowość: lista wgrana raz i nieodświeżana przez rok jest gorsza niż brak listy, bo podpowiada systemowi wczorajszy obraz klienta.
To zmiana, która na kontach e-commerce daje najwięcej, a wymaga głównie decyzji, nie technologii.
Dopóki do Google Ads leci samo zdarzenie „zakup”, każda transakcja jest dla systemu równa. Kiedy leci wartość, algorytm zaczyna widzieć różnicę między koszykiem za sto i za trzy tysiące złotych. Krok dalej to przekazywanie wartości skorygowanej o marżę albo o prawdopodobieństwo zwrotu — wtedy optymalizacja przestaje gonić przychód i zaczyna gonić zysk.
Na kontach usługowych odpowiednikiem jest przypisanie leadom różnych wartości w zależności od tego, czym się kończą. Nie trzeba do tego integracji z CRM od pierwszego dnia; można zacząć od stałych wartości opartych na historycznej skuteczności poszczególnych typów zgłoszeń, a integrację dołożyć później.
Jedno ostrzeżenie: zmiana sposobu liczenia wartości psuje porównywalność danych w czasie. Robię to na początku miesiąca, notuję datę i przez pierwsze dwa tygodnie nie wyciągam wniosków z wykresów.
Kolejność, którą stosuję, wynika z zależności między krokami, nie z ich trudności. Najpierw zgoda i poprawny pomiar konwersji, bo bez tego wszystko dalsze mierzy fikcję. Potem konwersje rozszerzone. Potem wartości konwersji. Potem listy klientów i wykluczenia. Na końcu segmenty i sygnały w kampaniach automatycznych.
Błędy, które widzę najczęściej, są zawsze te same. Wgrywanie list bez podstawy prawnej i bez informacji w polityce prywatności. Traktowanie sygnałów odbiorców jako twardego kierowania. Optymalizacja pod wartość, która nie uwzględnia zwrotów. I najkosztowniejszy: odkładanie wszystkiego do czasu, gdy Chrome faktycznie ograniczy ciasteczka — mimo że listy odbiorców i historia konwersji nie budują się wstecz, a każdy miesiąc zwłoki to dane, których potem nie da się odzyskać.
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 |