Gdzie kończy się panel, a zaczyna skrypt

Podział, który stosuję, jest prosty i oparty na tym, gdzie leży przyczyna problemu.

Jeśli błąd wynika z tego, że dane w systemie sklepowym są niepoprawne, poprawiam je w systemie sklepowym. Każde inne rozwiązanie jest łataniem, które trzeba będzie utrzymywać.

Jeśli błąd wynika z tego, że dane są poprawne, ale niezgodne z wymaganiami Google — na przykład dostępność zapisana po polsku albo cena z przecinkiem — poprawiam to w warstwie między sklepem a Google. Tu wchodzą reguły i skrypty.

A jeśli problem polega na tym, że danych po prostu nie ma, żadna automatyzacja go nie rozwiąże. Można wtedy tylko zdecydować, czy produkt ma jechać do Google bez tego atrybutu, czy nie jechać wcale.

Ten trzeci przypadek jest wart podkreślenia, bo widzę wiele wdrożeń, w których skrypt wypełnia brakujące pola wartościami zmyślonymi. Kończy się to zawsze tak samo, tylko później i gorzej.

Reguły źródła danych — pierwsza linia

Zanim napiszę jakikolwiek kod, sprawdzam, czy sprawy nie da się załatwić regułami wbudowanymi w panel. W nowej wersji są one na poziomie źródła danych i potrafią więcej, niż większość osób sprawdza.

• Podmiana i mapowanie wartości — zamiana „dostępny” na wartość wymaganą przez Google, ujednolicenie nazw kolorów, przypisanie kategorii Google do własnych typów produktu. Najczęstsze zastosowanie i zwykle wystarczające.

• Ustawianie wartości domyślnych — jeden kraj wysyłki, jedna marka dla całego katalogu producenta, stała grupa wiekowa w sklepie dla dorosłych.

• Budowanie atrybutu z kilku innych — sklejanie tytułu z marki, modelu i wariantu według stałego wzorca. Robi więcej dla dopasowania niż jakakolwiek inna zmiana w pliku.

• Warunkowe stosowanie zmian — poprawka tylko dla wybranej kategorii albo dla ofert spełniających warunek.

• Wykluczanie ofert — usuwanie z wysyłki produktów, których nie chcemy pokazywać w Google, bez ingerencji w eksport ze sklepu.

Reguły mają dwie zalety, dla których zawsze próbuję ich pierwsze: nie wymagają utrzymania kodu i są widoczne dla każdego, kto zajrzy do konta. Skrypt, o którym wie jedna osoba, jest ryzykiem operacyjnym.

Ich ograniczenie jest równie wyraźne. Nie zrobią transformacji wymagającej danych z zewnątrz i nie ogarną logiki bardziej skomplikowanej niż kilka warunków.

Dodatkowe źródła danych jako łatka

Drugi mechanizm dostępny bez programowania to dodatkowe źródło danych, czyli osobny plik nadpisujący wybrane atrybuty w ofertach z pliku głównego.

Używam go w dwóch sytuacjach. Pierwsza: uzupełnienie danych, których w sklepie nie ma i szybko nie będzie — na przykład kodów towaru wpisanych ręcznie przez zespół zakupów w arkuszu. Druga: krótkoterminowe działania marketingowe, w tym etykiety niestandardowe pod kampanie sezonowe.

Warunkiem jest zgodność identyfikatorów. Dodatkowe źródło łączy się z głównym po identyfikatorze produktu i jeżeli sklep zmienia identyfikatory przy przebudowie katalogu, cała łatka odpada w ciszy.

Bardzo praktyczna kombinacja to arkusz jako dodatkowe źródło danych, uzupełniany skryptem. Zespół widzi dane w arkuszu, skrypt pilnuje poprawności formatu, Google pobiera arkusz według harmonogramu. Rozwiązanie brzydkie architektonicznie, a w praktyce działa dobrze i nie wymaga pracy programisty przy każdej zmianie.

Pilnuję tylko jednego: dodatkowe źródło musi mieć właściciela i datę przeglądu. Łatki bez przeglądu zostają na lata i nikt nie wie, dlaczego produkt ma dziwną kategorię.

Interfejsy programistyczne — co jest dziś stabilne

Tu trzeba uważać, bo trwa zmiana i wybór interfejsu ma konsekwencje na kilka lat.

Interfejsem produkcyjnym pozostaje Content API for Shopping w wersji 2.1. To on obsługuje dziś zdecydowaną większość integracji: wgrywanie i aktualizowanie ofert, pobieranie statusów akceptacji, zarządzanie źródłami danych i cenami. Jeżeli buduję coś, co ma działać niezawodnie w tym kwartale, korzystam z niego.

Równolegle Google rozwija nowy interfejs pod nazwą Merchant API, udostępniony w wersji beta w połowie poprzedniego roku. Jest zorganizowany modułowo i ma z czasem zastąpić poprzedni. Na dziś jest to jednak wersja beta, w której zakres funkcji i sygnatury wywołań mogą się jeszcze zmienić — traktuję go więc jako coś do przetestowania na środowisku pobocznym, a nie jako fundament wdrożenia dla klienta.

Praktyczna rekomendacja, którą daję zespołom technicznym: pisać warstwę integracji tak, żeby wywołania interfejsu były odizolowane w jednym miejscu. Migracja i tak kiedyś nastąpi, a różnica w koszcie między dobrze i źle odizolowaną integracją jest ogromna.

Do tego dochodzi rzecz nudna, ale kluczowa: limity wywołań i obsługa błędów. Skrypt, który przy odrzuceniu części ofert po prostu przerywa działanie, zostawia katalog w stanie częściowo zaktualizowanym, a to gorszy stan niż brak aktualizacji.

Skrypty w Google Ads i w arkuszach

Nie każda automatyzacja wymaga zaplecza programistycznego. Dwa środowiska, z których korzystam najczęściej, są dostępne od razu.

Skrypty w Google Ads nadają się do zadań na granicy kampanii i danych produktowych: raport ofert bez wyświetleń, lista produktów odrzuconych zestawiona z wydatkami, powiadomienie e-mailem, gdy liczba niezaakceptowanych ofert przekroczy próg. To pierwsza rzecz, jaką wdrażam u klienta z dużym katalogiem, bo zamienia zaglądanie do panelu w powiadomienie.

Skrypty w arkuszach nadają się do walidacji i przygotowania danych. Sprawdzenie długości tytułów, wykrycie duplikatów kodów towaru, wyłapanie cen zerowych, kontrola zgodności listy kategorii ze słownikiem Google. Napisanie takiego zestawu zajmuje jeden dzień i zwraca się przy pierwszym dużym eksporcie.

Trzecia kategoria to własny skrypt na serwerze, uruchamiany harmonogramem przed wysyłką pliku. Tu warto zbudować prostą zasadę: skrypt nie wysyła pliku, jeśli walidacja wykryła błąd krytyczny w więcej niż ustalonym odsetku ofert. Lepiej wysłać wczorajszy plik niż dzisiejszy zepsuty.

Co warto walidować u siebie, przed wysyłką

Lista kontrolna, którą zwykle wdrażam. Wszystkie te rzeczy da się sprawdzić bez pytania Google.

Kompletność atrybutów wymaganych dla danej kategorii — nie ogólnie, ale w rozbiciu na kategorie, bo wymagania się różnią. Poprawność formatu ceny i waluty, w tym separator dziesiętny. Zgodność wartości dostępności z zamkniętą listą dopuszczalnych. Unikalność identyfikatorów oraz poprawność sumy kontrolnej w kodach towaru. Długość i struktura tytułów. Dostępność adresów zdjęć, sprawdzona zapytaniem, a nie założeniem. I obecność identyfikatora grupy wariantów tam, gdzie warianty istnieją.

Osobno warto sprawdzać rzecz, o której się zapomina: liczbę ofert w pliku względem poprzedniego przebiegu. Nagły spadek o kilkadziesiąt procent prawie nigdy nie jest zamierzony, a wysłanie takiego pliku wygasza część katalogu.

Wszystkie te kontrole zapisuję do dziennika z datą i liczbą wykrytych przypadków. Bez historii nie da się stwierdzić, czy jakość danych rośnie, czy tylko dziś było lepiej.

Czego nie automatyzuję

Na koniec granica, którą uważam za ważniejszą niż cała reszta tekstu.

Nie automatyzuję uzupełniania brakujących kodów towaru wartościami wygenerowanymi. Nieprawdziwy identyfikator jest gorszy niż jego brak i prowadzi do dopasowania oferty do zupełnie innego produktu.

Nie automatyzuję zmian ceny w pliku w oderwaniu od strony. Skrypt, który koryguje cenę w pliku, żeby zgadzała się z komunikatem Google, przy nieaktualnej cenie na stronie tworzy rozbieżność, która wraca ze zdwojoną siłą.

Nie automatyzuję ponownych zgłoszeń do weryfikacji w pętli. Wysyłanie żądania sprawdzenia co kilka godzin nie przyspiesza procesu, a przy naruszeniach zasad wygląda dokładnie na to, czym jest.

I nie automatyzuję decyzji o wykluczaniu produktów z pliku na podstawie samej rentowności bez rozmowy z klientem. To decyzja handlowa, nie techniczna, choć wykonuje się ją jedną regułą.