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.
Najbardziej niedoceniana część panelu Google Ads leży w menu narzędzi i większość osób nigdy tam nie zagląda. Skrypty pozwalają uruchamiać własny kod, który czyta dane z konta, sprawdza warunki i — jeśli sobie na to pozwolisz — wprowadza zmiany. Wszystko bez żadnej infrastruktury po Twojej stronie i bez dostępu do interfejsu programistycznego.
Powiem od razu, czym to nie jest, bo tu rodzą się największe nieporozumienia. Skrypty nie zastępują myślenia i nie optymalizują kampanii lepiej niż człowiek. Ich prawdziwa wartość leży w czymś nudniejszym: pilnują rzeczy, o których zapominamy, i sprawdzają je codziennie o tej samej godzinie. Człowiek tego nie robi, bo człowiek ma inne rzeczy do zrobienia.
Poniżej opisuję, jak to działa, do czego używam skryptów najczęściej i jak zacząć, jeśli nigdy nie pisałeś kodu.
Skrypty pisze się w języku opartym na JavaScripcie, w edytorze wbudowanym w panel. Kod uruchamia się po stronie Google, nie na Twoim serwerze — nie potrzebujesz więc niczego oprócz dostępu do konta.
Skrypt ma dostęp do struktury konta poprzez zestaw obiektów: kampanii, grup reklam, słów kluczowych, reklam, a także do statystyk za wybrane okresy. Może również czytać i zapisywać dane w arkuszach kalkulacyjnych oraz wysyłać wiadomości e-mail. Ta ostatnia możliwość jest w praktyce najważniejsza, bo pozwala zamienić skrypt w system alertów.
Uruchamianie odbywa się według harmonogramu, który sam ustawiasz: raz na godzinę, raz dziennie, raz w tygodniu. Obowiązują limity czasu wykonania i liczby operacji, więc bardzo duże konta wymagają dzielenia pracy na etapy — ale przy typowym koncie nie ma to znaczenia.
Ważna rzecz na start: skrypt ma dokładnie takie uprawnienia jak użytkownik, który go stworzył. Może wyłączyć kampanię, zmienić stawki, wstrzymać słowo kluczowe. Dlatego pierwsze skrypty, jakie polecam uruchomić, tylko czytają dane i nic nie zmieniają.
Kolejność odpowiada temu, jak często faktycznie z nich korzystam.
Zwróć uwagę, że w tej całej liście nie ma ani jednego skryptu zmieniającego stawki. To nie przypadek.
Jest to najczęstszy pomysł osób, które dowiadują się o skryptach, i jednocześnie ten, od którego odradzam zaczynanie.
Powód pierwszy: automatyczne strategie ustalania stawek robią to lepiej, bo mają dostęp do sygnałów na poziomie pojedynczej aukcji, których skrypt nie zobaczy nigdy. Skrypt operuje na zagregowanych statystykach z ostatnich dni. Konkurowanie z mechanizmem, który decyduje w czasie licytacji, nie ma sensu.
Powód drugi: skrypt zmieniający stawki w koncie z włączoną strategią automatyczną wchodzi z nią w konflikt. Widziałem konta, w których stary skrypt z czasów ręcznego zarządzania działał latami po przejściu na automat i nikt nie wiedział, dlaczego dzieją się dziwne rzeczy.
Powód trzeci, najważniejszy: błąd w skrypcie modyfikującym konto działa szybciej niż Twoja reakcja. Pomyłka w warunku może w ciągu jednego uruchomienia wyłączyć wszystkie kampanie albo dziesięciokrotnie podnieść stawki. Skrypt czytający dane w najgorszym przypadku wyśle nieprawdziwy e-mail.
Jeśli już automatyzuję zmiany, to rzeczy jednoznaczne i odwracalne: wstrzymanie reklamy prowadzącej na adres zwracający błąd, wstrzymanie kampanii produktowej dla towaru niedostępnego. Zawsze z ograniczeniem liczby zmian w jednym uruchomieniu i zawsze z powiadomieniem o tym, co zostało zrobione.
Nie trzeba pisać kodu od zera i nie polecam tej drogi na początek.
Google publikuje bibliotekę gotowych rozwiązań z opisem, co robią i jak je skonfigurować. Wiele z nich wymaga zmiany kilku linii na początku pliku: adresu e-mail do powiadomień, progów, identyfikatora arkusza. To poziom trudności zbliżony do konfigurowania wtyczki.
Kolejność, którą polecam:
Ten ostatni punkt jest zdradliwy i wart podkreślenia. Skrypt alertowy, który się zepsuł, wygląda dokładnie tak samo jak skrypt alertowy, który nie ma o czym alarmować.
Skrypty mają nieprzyjemną cechę wspólną z regułami automatycznymi: zostają w koncie znacznie dłużej niż powód, dla którego powstały.
Prowadzę więc krótką listę: co robi każdy skrypt, kto go dodał, kiedy i po co. Przy przejmowaniu konta jest to jedna z pierwszych rzeczy, których szukam, i prawie nigdy jej nie znajduję. Wtedy trzeba czytać kod, żeby ustalić, czy coś działa celowo, czy jest reliktem.
Raz na kwartał przeglądam listę i wyłączam to, co przestało być potrzebne. Skrypt związany z akcją promocyjną z zeszłego roku nie ma prawa nadal się uruchamiać.
Sprawdzam też uprawnienia. Skrypt utworzony przez osobę, która odeszła z firmy i której dostęp odebrano, przestanie działać — i lepiej się o tym dowiedzieć w trakcie przeglądu niż w środku sezonu.
Na koniec rzecz, którą uważam za najważniejszą przy myśleniu o automatyzacji w ogóle: skrypty warto traktować jako system wczesnego ostrzegania, nie jako kierowcę. Ich zadaniem jest zwrócić moją uwagę na to, co wymaga decyzji. Decyzję nadal podejmuję sam i to się w najbliższych latach nie zmieni tak szybko, jak sugerują to niektóre zapowiedzi.
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 |