Skąd skrypt bierze wiedzę o dostępności

To pierwsza i najważniejsza decyzja, bo od niej zależy niezawodność całej konstrukcji. Widzę cztery sensowne warianty.

• Arkusz z listą dostępności. Sklep raz na godzinę albo raz na dobę zapisuje do arkusza dwie kolumny: identyfikator produktu i status dostępności. Skrypt czyta arkusz. Wariant najprostszy, najłatwiejszy do podglądu przez człowieka i mój domyślny wybór w mniejszych sklepach.

• Własny punkt dostępowy po stronie sklepu. Adres zwracający listę produktów ze statusem w formacie do maszynowego odczytu. Rozwiązanie właściwe, gdy asortyment jest duży i zmienia się w ciągu dnia — wymaga jednak pracy programisty i zabezpieczenia adresu.

• Plik z ofertą produktową. Skoro sklep i tak generuje plik dla usługi zakupowej, można czytać dostępność wprost z niego. Zaleta: jedno źródło prawdy dla wszystkich kanałów. Wada: plik odświeża się rzadziej niż stan w magazynie.

• Odczyt ze strony produktu. Skrypt pobiera stronę i szuka w niej frazy oznaczającej niedostępność. Wariant ostatniej szansy, gdy nie ma dostępu do zaplecza sklepu. Kruchy — każda zmiana w szablonie strony go psuje.

Niezależnie od wariantu wymagam jednej rzeczy: informacji o dacie ostatniego odświeżenia. Bez niej skrypt nie potrafi odróżnić „wszystko dostępne” od „źródło danych stanęło trzy dni temu”.

Co dokładnie pauzować

Rozumowanie odruchowe brzmi: skoro produktu nie ma, pauzujemy reklamę. W praktyce rzadko jest to właściwy poziom.

Wstrzymanie samej reklamy zostawia aktywne słowa kluczowe. Grupa reklam z jedną wstrzymaną reklamą przestanie wyświetlać cokolwiek — jeśli była jedyna — albo zacznie pokazywać reklamę ogólną, która niekoniecznie pasuje do zapytania o konkretny model.

Dlatego zwykle działam na poziomie grupy reklam, przy założeniu, że konto ma strukturę, w której grupa odpowiada produktowi albo wąskiej rodzinie produktów. Wtedy pauza grupy zdejmuje z aukcji i reklamy, i frazy, i wszystko wraca jednym ruchem.

W kontach o innej budowie wybieram inne punkty zaczepienia. Jeśli produkt jest reprezentowany przez pojedyncze słowa kluczowe rozproszone po grupach — pauzuję słowa kluczowe. Jeśli chodzi o całą kategorię, w której nie ma już nic — pauzuję kampanię, ale to decyzja, którą wolę zostawić człowiekowi.

Powiązanie między produktem a elementem konta buduję na etykietach. Każda grupa reklam dotycząca produktu dostaje etykietę z jego identyfikatorem w ustalonym formacie. Skrypt nie zgaduje wtedy niczego z nazw, a nazwy w koncie zmieniają się częściej, niż ktokolwiek pamięta.

Jak działa taki skrypt

Skrypty w Google Ads to kod w JavaScripcie uruchamiany po stronie Google, z dostępem do obiektów konta i do zewnętrznych adresów. Nie trzeba mieć serwera — wystarczy zapisać skrypt w koncie, autoryzować dostęp i ustawić harmonogram.

Logika, którą stosuję, ma cztery kroki. Najpierw wczytanie danych o dostępności i sprawdzenie ich świeżości. Potem zebranie z konta wszystkich elementów oznaczonych etykietą produktową i zbudowanie mapy: identyfikator produktu do elementu konta. Następnie porównanie stanu pożądanego ze stanem faktycznym i wyliczenie listy zmian. I na końcu — wykonanie zmian oraz zapis raportu.

Rozdzielenie wyliczania od wykonywania jest tu celowe. Dzięki temu ten sam skrypt można uruchomić w trybie samego raportowania, bez ruszania konta. Każde wdrożenie zaczynam od kilku dni w takim trybie i porównuję, czy lista proponowanych zmian pokrywa się z tym, co o sklepie wiem.

Harmonogram dopasowuję do tempa zmian w magazynie. Dla większości sklepów wystarcza uruchomienie co godzinę; przy asortymencie schodzącym w minutach żaden skrypt nie będzie dość szybki i trzeba szukać rozwiązania po stronie kampanii produktowych.

Warto pamiętać o technicznych ograniczeniach środowiska: pojedyncze uruchomienie ma limit czasu wykonania i limit liczby operacji. Przy dużym koncie oznacza to konieczność podziału pracy na partie albo przeniesienia logiki na poziom konta menedżera.

Zabezpieczenia przed masową pauzą

To najważniejsza część i jedyna, której nie odpuszczam. Awarie, które widziałem, nie polegały na tym, że skrypt czegoś nie zapauzował. Polegały na tym, że zapauzował wszystko.

• Kontrola świeżości danych. Jeśli źródło nie zostało odświeżone w założonym czasie, skrypt nie robi nic i wysyła powiadomienie. Milczenie źródła nigdy nie może znaczyć „brak towaru”.

• Limit skali zmiany. Jeśli w jednym przebiegu miałoby zostać wstrzymanych więcej elementów niż ustalony próg — na przykład więcej niż kilka procent aktywnych grup — skrypt przerywa pracę i pyta człowieka. Ten jeden warunek uratował mi już dwa wdrożenia, w których sklep wygenerował uszkodzony plik.

• Lista wyjątków. Kampanie brandowe, kampanie wizerunkowe i wszystko, co nie jest przypisane do konkretnego produktu, trafia na listę pomijaną bezwarunkowo.

• Weryfikacja liczby wpisów. Jeżeli źródło zwraca wyraźnie mniej pozycji niż poprzednio, traktuję to jako awarię, nie jako wyprzedanie asortymentu.

• Powiadomienie po każdym przebiegu ze zmianami i raz dziennie podsumowanie, także wtedy, gdy nic się nie stało. Skrypt, który milczy, jest nieodróżnialny od skryptu, który przestał działać.

Powrót towaru i porządek w koncie

Automatyczne wstrzymanie jest łatwe. Trudniejsze jest wznowienie, bo tu skrypt może włączyć coś, co człowiek wyłączył świadomie.

Rozwiązuję to jedną zasadą: skrypt wznawia wyłącznie to, co sam wstrzymał. Przy pauzowaniu dokłada elementowi drugą etykietę oznaczającą „wstrzymane automatycznie, z datą”. Przy wznawianiu bierze pod uwagę tylko elementy z tą etykietą i po włączeniu ją usuwa. Grupa wyłączona ręcznie przez specjalistę pozostaje wyłączona.

Drugi element porządku to okres wyczekiwania. Nie wznawiam natychmiast po pojawieniu się stanu, bo w sklepach zdarza się migotanie dostępności przy pojedynczych sztukach. Kilkadziesiąt minut potwierdzonej dostępności wystarcza, żeby nie włączać i nie wyłączać tej samej grupy dziesięć razy dziennie.

Trzeci: co zrobić z produktem, którego nie ma od dawna. Element wstrzymany dłużej niż ustalony czas raportuję osobno, do decyzji człowieka. Zwykle znaczy to, że produkt zszedł z oferty, a wraz z nim powinny zniknąć reklamy, frazy i strona docelowa — a to już nie jest praca dla automatu.

Kampanie produktowe i alternatywy

Na koniec granice tego rozwiązania, bo skrypt nie jest odpowiedzią na wszystko.

W kampaniach produktowych i tych, które opierają się na pliku z ofertą, sterowanie odbywa się przez sam plik. Produkt oznaczony jako niedostępny przestaje być wyświetlany bez żadnej ingerencji w koncie — pisanie skryptu do tego samego celu jest dublowaniem mechanizmu i psuciem danych do nauki algorytmu. Praca leży wtedy po stronie częstotliwości odświeżania pliku i poprawności pola z dostępnością, a nie w koncie reklamowym.

Dla kampanii w sieci wyszukiwania są też prostsze narzędzia niż skrypt. Reklamy z elementami wstawianymi z pliku danych potrafią wygasać razem z pozycją w tym pliku. Reguły automatyczne obsłużą prosty warunek bez pisania kodu, choć nie odczytają zewnętrznego źródła. Jeśli sklep ma zaplecze techniczne, tę samą logikę da się zbudować po stronie własnego systemu i interfejsu programistycznego Google Ads — pełniej, ale drożej w utrzymaniu.

Skrypt wybieram, gdy potrzebuję czegoś pośredniego: własnej logiki i zewnętrznych danych, bez własnego serwera i bez większego projektu. To zwykle najlepszy stosunek efektu do nakładu w sklepie średniej wielkości.

Jedna rzecz na deser, o której łatwo zapomnieć: wdrożenie trzeba dopisać do dokumentacji konta. Po pół roku ktoś zapyta, dlaczego połowa grup jest wstrzymana, i musi istnieć miejsce, w którym stoi odpowiedź.