Co dokładnie ma być sprawdzane

Zanim cokolwiek wkleję do panelu, ustalam listę miejsc, w których w koncie siedzą adresy URL. Jest ich więcej, niż większość osób pamięta.

• Końcowe adresy URL reklam — najbardziej oczywiste i zwykle jedyne, które ktoś kiedykolwiek sprawdzał ręcznie.

• Adresy na poziomie słów kluczowych — pojedyncze słowa kluczowe mogą mieć własny adres nadpisujący ten z reklamy. To ulubione miejsce zapomnianych linków.

• Rozszerzenia — linki do podstron mają swoje adresy, a przy nich osobne adresy mobilne. Rozszerzenia dodane na poziomie konta łatwo przeoczyć, bo nie widać ich w kampanii.

• Osobne adresy mobilne — pozostałość po czasach oddzielnych serwisów mobilnych, wciąż spotykana na starszych kontach i praktycznie nigdy nie testowana.

• Szablony śledzenia — jeśli końcowy adres jest poprawny, a szablon dokleja parametry, które serwer odrzuca, użytkownik zobaczy błąd, choć sam adres docelowy działa.

Osobno traktuję adresy produktów z pliku dla Merchant Center. Skrypt w Google Ads ich nie obejmie — tam błędy zgłasza sam Merchant Center i to inna procedura.

Dlaczego skrypt, a nie ręczne klikanie

Ręcznie sprawdzam adresy przy audycie i przy wdrożeniu, ale to jednorazowa czynność. Problem z martwymi linkami polega na tym, że pojawiają się między audytami, w losowym momencie, zwykle po wdrożeniu na stronie, o którym nikt reklamodawcy nie uprzedził.

Google Ads scripts to narzędzie wbudowane w panel: kod w JavaScripcie, który uruchamia się według harmonogramu i ma dostęp do struktury konta oraz do możliwości pobierania stron internetowych. Nie trzeba serwera, nie trzeba dostępu do API, nie trzeba niczego instalować. Dla tego zadania jest to najprostsze narzędzie, jakie znam.

Druga zaleta jest organizacyjna. Skrypt zostawia po sobie zapis: arkusz z listą adresów, kodów odpowiedzi i dat sprawdzenia. Kiedy klient pyta, od kiedy reklama prowadziła w pustkę, mam odpowiedź, a nie domysł. Przy rozliczaniu odpowiedzialności między agencją a działem IT klienta ten arkusz bywa ważniejszy niż samo powiadomienie.

Jak taki skrypt jest zbudowany

Nie piszę tego od zera i nikomu nie radzę — Google udostępnia gotowe rozwiązanie do sprawdzania linków w bibliotece skryptów i to jest właściwy punkt startu. Warto natomiast rozumieć, z czego się składa, bo prawie zawsze trzeba je dopasować.

Logika ma cztery elementy. Pierwszy to zebranie adresów — selektory typu AdsApp.ads() i AdsApp.keywords() z filtrem na aktywne elementy w aktywnych kampaniach, plus rozszerzenia. Filtr na status jest istotny, bo w koncie leżą setki wstrzymanych elementów, których nikt nie zamierza włączać.

Drugi to odpytanie każdego adresu przez UrlFetchApp.fetch(). Trzy ustawienia mają tu znaczenie: wyciszenie wyjątków HTTP, żeby błąd 404 nie przerywał całego przebiegu, decyzja o tym, czy podążać za przekierowaniami, oraz nagłówek identyfikujący zapytanie. Jeśli chcę widzieć łańcuchy przekierowań, wyłączam automatyczne podążanie i sprawdzam nagłówek z nowym adresem samodzielnie.

Trzeci to klasyfikacja odpowiedzi. Kody z rodziny 4xx i 5xx to alarm. Przekierowania nie są błędem, ale warto je logować, bo łańcuch trzech przeskoków oznacza, że ktoś przebudował serwis i zapomniał zaktualizować reklamy. Przekroczenie czasu odpowiedzi zapisuję osobno, bo to często problem z wydajnością strony, nie z adresem.

Czwarty to raportowanie: zapis do arkusza przez SpreadsheetApp i wiadomość przez MailApp, wysyłana wyłącznie wtedy, gdy coś się znalazło. Skrypt, który codziennie przysyła maila „wszystko w porządku”, po tygodniu zaczyna wpadać do folderu, którego nikt nie czyta.

Ograniczenia, które trzeba obejść

To jest część, na której najczęściej wykłada się pierwsze wdrożenie.

Skrypt ma limit czasu jednego uruchomienia. Przy koncie z kilkoma tysiącami unikalnych adresów jeden przebieg nie zdąży sprawdzić wszystkiego. Rozwiązanie jest w gotowym skrypcie Google: zapisujemy w arkuszu, dokąd doszliśmy, i przy następnym uruchomieniu ruszamy od tego miejsca. Skrypt planuję wtedy co godzinę, a nie raz na dobę.

Adresy trzeba odfiltrować z duplikatów. Setki słów kluczowych prowadzą zwykle na kilkadziesiąt różnych stron, więc zbieranie unikalnych adresów przed odpytywaniem skraca przebieg wielokrotnie i zmniejsza liczbę zapytań do serwera klienta.

Trzeba też uprzedzić dział techniczny po stronie klienta. Serwer z zabezpieczeniem przed botami potrafi odpowiadać na takie zapytania kodem 403 albo stroną weryfikacyjną, a wtedy skrypt raportuje awarię, której nie ma. Rozwiązaniem jest dopisanie adresu skryptu do wyjątków albo umówienie się na rozpoznawalny nagłówek. Warto to ustalić przed pierwszym uruchomieniem, żeby nie zaczynać wdrożenia od fałszywego alarmu.

Przy koncie menedżera nie uruchamiam osobnego skryptu w każdym koncie. Skrypt na poziomie menedżera przechodzi po wybranych kontach i pozwala wykonywać przebiegi równolegle, a raport zbiera w jednym miejscu. Przy kilkunastu klientach to różnica między pięcioma minutami dziennie a niczym.

Wdrożenie krok po kroku

Robię to w tej kolejności i nie skracam żadnego etapu.

Zaczynam od skopiowania gotowego rozwiązania do konta i autoryzacji dostępu — skrypt musi mieć zgodę na pobieranie stron zewnętrznych oraz na arkusze i pocztę. Potem tworzę pusty arkusz na raport i wklejam jego adres do konfiguracji.

Pierwsze uruchomienie robię na ograniczonym zakresie: jedna kampania, tryb podglądu, wynik czytam z logu. Chodzi o sprawdzenie dwóch rzeczy — czy adresy w ogóle się zbierają i czy serwer klienta odpowiada normalnie na te zapytania. Dopiero potem rozszerzam zakres na całe konto.

Harmonogram ustawiam co godzinę przy dużych kontach i raz dziennie przy małych, zawsze wcześnie rano. Powiadomienia kieruję na skrzynkę, którą naprawdę czytam, i dodaję do treści maila numer konta, bo przy skrypcie z poziomu menedżera bez tego nie wiadomo, o którego klienta chodzi.

Na koniec dopisuję do arkusza kolumnę na status obsługi. Bez tego przy trzeciej awarii nie wiadomo, które adresy zostały już naprawione, a które czekają, i raport zamienia się w listę, do której nikt nie zagląda.

Czego skrypt nie wyłapie

Traktuję go jako czujnik dymu, nie jako kontrolę jakości.

Nie wyłapie miękkiego błędu 404 — strony, która zwraca poprawny kod 200 i wyświetla komunikat „produktu nie ma w ofercie”. Dla skryptu wszystko jest w porządku, dla użytkownika strona jest bezużyteczna. To trzeba sprawdzać ręcznie albo dodatkowo szukać w treści charakterystycznej frazy, jeśli sklep jej używa.

Nie wyłapie też adresu, który działa, ale prowadzi nie tam, gdzie powinien: reklama konkretnego modelu kierująca po przebudowie na kategorię ogólną albo na stronę główną. Kod odpowiedzi jest poprawny, sens reklamy zniknął.

Nie oceni wreszcie, czy strona ładuje się sensownie na telefonie i czy formularz na niej działa. Skrypt widzi surową odpowiedź serwera, a nie stronę po wykonaniu skryptów przeglądarki.

Dlatego u siebie łączę dwie rzeczy: automat pilnuje kodów odpowiedzi codziennie, a ja raz w miesiącu klikam ręcznie w reklamy najważniejszych kampanii i patrzę, gdzie faktycznie trafiam. Automat wyłapuje awarie, człowiek wyłapuje nonsensy. Jedno drugiego nie zastąpi, ale razem zamykają tę kategorię problemów praktycznie do zera.