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.
Zalecenie Google w tej sprawie jest jednoznaczne od dawna: dopasowanie przybliżone stosuj razem ze Smart Biddingiem. Powtarza się w dokumentacji, w materiałach szkoleniowych i w rekomendacjach w panelu. I mimo tego regularnie widzę konta, gdzie szerokie dopasowanie pracuje na ręcznym CPC.
Bywa to świadoma decyzja, bywa zaniedbanie. Warto rozumieć różnicę, bo konsekwencje są wymierne — i bywa, że akurat w Twojej sytuacji to zalecenie nie ma zastosowania.
Chcę więc wyjaśnić, dlaczego te dwa elementy zostały zaprojektowane razem, co konkretnie tracisz, rozdzielając je, i w jakich okolicznościach mimo wszystko wybieram ten wariant.
Dopasowanie przybliżone nie oznacza dziś „zapytania zawierające moje słowa”. Oznacza zapytania tematycznie powiązane — bez wymogu obecności konkretnych wyrazów i bez wymogu kolejności. Zakres jest ogromny i celowo taki jest.
Problem polega na tym, że w tym zakresie wartość poszczególnych zapytań różni się drastycznie. Ktoś wpisujący nazwę konkretnego produktu z dopiskiem „cena” jest wart wielokrotnie więcej niż ktoś szukający definicji kategorii. Jedno słowo kluczowe w dopasowaniu przybliżonym obsługuje oba te zapytania.
I tu jest sedno. Przy ręcznej stawce ustawiasz jedną liczbę na całe to spektrum. Płacisz tyle samo za zapytanie zakupowe i za informacyjne. Przy Smart Biddingu system ocenia każdą aukcję osobno i licytuje wysoko tam, gdzie prawdopodobieństwo konwersji jest wysokie, a nisko albo wcale tam, gdzie jest niskie.
Szerokie dopasowanie zostało więc rozszerzone w założeniu, że po drugiej stronie stoi mechanizm potrafiący rozróżnić wartość poszczególnych zapytań. Bez niego dostajesz zasięg bez selekcji.
Skutki są przewidywalne i widuję je w powtarzalnym układzie.
Rozjazd między liczbą kliknięć a liczbą konwersji. Kampania szybko zbiera ruch, bo szeroki zakres zapewnia wyświetlenia, ale współczynnik konwersji jest niski, bo znaczna część tego ruchu nie miała intencji zakupowej.
Budżet wyczerpywany przez zapytania ogólne. Zapytania informacyjne mają zwykle niższą konkurencję i tańsze kliknięcia, więc przy jednej stałej stawce system chętnie je kupuje. Efekt: najwięcej kliknięć pochodzi z najmniej wartościowej części spektrum.
Konieczność ciągłego dopisywania wykluczeń. To główny koszt pracy w tym modelu. Raport wyszukiwanych haseł staje się listą zadań, którą trzeba obsługiwać co kilka dni, bo każda nieobsłużona pozycja to wydatek.
Mylące dane o jakości. Wskaźnik jakości takiego słowa kluczowego jest uśrednieniem po bardzo różnych zapytaniach, więc mówi niewiele. Trudno na jego podstawie zdecydować, czy problem jest w reklamie, czy w doborze fraz.
Nie twierdzę, że kampania w tym układzie nie działa. Twierdzę, że przenosi pracę selekcji z algorytmu na człowieka — i jeśli ten człowiek jej nie wykonuje, pieniądze wyciekają.
Są sytuacje, w których zalecenie o łączeniu obu elementów nie ma zastosowania, bo brakuje warunku wstępnego dla Smart Biddingu.
W pierwszych dwóch przypadkach traktuję ten stan jako etap przejściowy z określonym warunkiem wyjścia: gdy pomiar będzie uporządkowany albo gdy zapytania zostaną potwierdzone, przechodzę dalej.
Jeśli decydujesz się na ten model, warto obwarować go dyscypliną, bo sam z siebie się nie obroni.
Osobna kampania z własnym, ograniczonym budżetem. Nigdy nie mieszam szerokiego dopasowania z frazami ścisłymi w jednej kampanii — szerokie zawsze zje budżet przeznaczony na to, co pewne.
Stawka wyraźnie niższa niż na frazach potwierdzonych. To ruch o nieznanej wartości, więc nie może kosztować tyle samo co ruch o znanej.
Rytm przeglądu raportu wyszukiwanych haseł. Co kilka dni w pierwszych tygodniach, potem co tydzień. Każda pozycja dostaje jedną z dwóch decyzji: awans do struktury ścisłej albo wykluczenie. Pozostawianie bez decyzji jest trzecią, najkosztowniejszą opcją.
Rozbudowane listy wykluczeń współdzielone między kampaniami, żeby jedna praca chroniła całe konto.
Ustalony warunek zamknięcia. Jeśli po ustalonym okresie kampania nie znalazła fraz wartych awansu, wyłączam ją. Kampania badawcza, która nie dostarcza wiedzy, nie ma innego uzasadnienia.
Moment jest dość jasny do rozpoznania.
Przechodzę, gdy pomiar konwersji jest uporządkowany — bez duplikatów, z jasno wskazanymi konwersjami głównymi, z wartością, jeśli transakcje różnią się kwotą. I gdy konwersji jest dość, żeby decyzje opierały się na danych, a nie na przypadku.
Wtedy zaczynam od jednej kampanii, ustawiam cel bardzo blisko wyniku, który ta kampania faktycznie osiągała, i zostawiam ją w spokoju na okres nauki. Przy okazji robię porządek w korektach stawek — większość tych z czasów ręcznego zarządzania traci przy automacie zastosowanie.
Rzecz, o której warto pamiętać przy tej zmianie: wykluczenia zbudowane przez miesiące pracy zostają przydatne. Automat lepiej rozdziela stawki, ale nie wie, że pewna kategoria zapytań jest dla Twojej firmy bezwartościowa mimo pozornego podobieństwa tematycznego. Ta wiedza jest Twoja i nie warto jej wyrzucać przy okazji przełączania strategii.
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 |