Naprawa Google Merchant Center
Przywrócić odrzucone produkty do Zakupów.
Diagnoza odrzuceń i problemów konta, poprawki w danych źródłowych zamiast w eksporcie feedu i ponowne zgłoszenie z dowodami, których wymaga Google. Zbudowaliśmy aplikację monitorującą dokładnie na tym problemie.
Cena stała
Od 850 €
To obejmuje diagnozę i poprawki danych na jednym koncie. Zawieszenie, kilka feedów albo zepsuta synchronizacja dochodzą do 3750 €. Kwota jest ustalona przed startem, a nie liczona za godziny.
Wyślij opis, a dostaniesz liczbę w odpowiedzi.
Opisz projektProdukty przestały się wyświetlać, a powodem jest kod
Wyświetlenia w Zakupach spadają, na koncie wisi czerwony baner, a wyjaśnieniem jest sformułowanie w rodzaju wprowadzanie w błąd albo nieprawidłowa wartość, bez wskazania, która część sklepu je wywołała. W tym czasie kampanie dalej wydają budżet na to, co przetrwało, więc strata jest częściowa i łatwo ją odczytać jako słabszy tydzień. Odruchem jest otworzyć plik z ofertami i poprawiać atrybuty, i właśnie tam ucieka najwięcej pracy: spora część tych odrzuceń wcale nie siedzi w pliku, tylko w sklepie, który Google odwiedził zaraz potem.
Co obejmuje praca
Diagnoza, a nie lista kodów błędów
Problemy na poziomie produktu i konta pobiera się przez Merchant API, grupuje według przyczyny zamiast według produktu i dzieli na dwa rodzaje, które zachowują się inaczej: problemy danych, które po poprawce znikają same przy kolejnym indeksowaniu, i problemy zasad, które wymagają ponownej weryfikacji przez człowieka. To, który rodzaj masz, przesądza o wszystkim dalej.
Naprawione u źródła, nie w eksporcie
Poprawki idą w dane produktów w twoim sklepie, w konfigurację wysyłki i podatków albo na samą stronę. Łatanie wartości w eksporcie rozjeżdża plik z ofertami i stronę docelową, a właśnie ta rozbieżność jest osobnym powodem odrzucenia. Szybkie rozwiązanie tworzy więc kolejne zgłoszenie.
Jedna prośba o weryfikację, złożona porządnie
Przy sprawach zasad i konta kolejność brzmi: napraw, udokumentuj, dopiero potem jedna prośba. Prób i okresów karencji jest ograniczona liczba, a prośba wysłana przed faktycznym usunięciem przyczyny spala jedną z nich. Zgłoszenie mówi, co było nie tak, co się zmieniło i gdzie to sprawdzić.
Dlaczego akurat tak
Wprowadzanie w błąd ocenia się na twojej stronie
Google nie czyta wyłącznie pliku z ofertami. Wchodzi do sklepu i sprawdza, czy wyglądasz na firmę, do której można wysłać kupującego: osiągalne dane kontaktowe, możliwa do znalezienia polityka zwrotów, ceny i dostępność zgodne z tym, co deklaruje plik, oraz twierdzenia, które da się zweryfikować. Uczciwe sklepy wpadają na tym bez przerwy i dalej szukają przyczyny w pliku, w którym jej nie ma.
Silnik jest nasz, więc diagnoza to nie zgadywanie
Feed Guard, nasza własna aplikacja, działa na Merchant API i powstał dokładnie pod ten problem: czytać problemy konta i produktów, tłumaczyć je zwykłym językiem i pilnować następnego. Od tego samego odczytu zaczyna się tutaj diagnoza. Czego nikt nie może dać, to obietnica: zatwierdzenie i przywrócenie konta to decyzja Google, więc wynik nie jest gwarantowany, a kto go gwarantuje, sprzedaje coś innego.
Jak to przebiega
Dostęp do odczytu Merchant Center i sklepu, albo eksport, jeśli dostęp jest niemożliwy. Dostajesz listę problemów pogrupowaną według przyczyn, z liczbą produktów przy każdej.
Pisemna diagnoza: co jest problemem danych i zniknie przy indeksowaniu, co jest sprawą zasad i wymaga weryfikacji, co jest strukturalne i będzie kosztować realną pracę, a czego nie da się naprawić w ogóle.
Poprawki lądują w danych produktów, w ustawieniach wysyłki i podatków albo na samej stronie, a potem czekają na indeksowanie, które je potwierdzi, zamiast zostać ogłoszone jako zrobione.
Przy sprawach zasad i konta prośba o weryfikację idzie raz, po potwierdzeniu, że przyczyna została usunięta, razem z dowodami.
Kontrola po ponownym indeksowaniu i krótka lista tego, co obserwować co miesiąc, żeby ta sama klasa awarii nie wróciła niezauważona.
Tło
Jak naprawdę działają awarie w Merchant Center
Odrzucenie, obniżenie i zawieszenie to trzy różne problemy
Odrzucenie ukrywa pojedyncze produkty, podczas gdy reszta katalogu dalej sprzedaje. Obniżenie jest cichsze: oferta nadal się wyświetla, ale stoi za konkurencją, bo brakuje atrybutu albo jest słaby, i nic na koncie nie nazywa tego błędem. Zawieszenie działa na poziomie konta i ukrywa wszystko, zwykle po ostrzeżeniu. Wszystkie trzy traktuje się jako jedno, jako problem z plikiem ofert, i dlatego sprzedawcy przez tydzień poprawiają atrybuty, podczas gdy prawdziwa przyczyna siedzi w sklepie. Pierwsze użyteczne pytanie nie brzmi, co jest nie tak z plikiem, tylko który z tych trzech przypadków się wydarzył.
Dlaczego naprawa zwykle nie leży w pliku
Plik z ofertami to twierdzenie o twoich produktach. Google sprawdza to twierdzenie względem strony, do której prowadzi. Dlatego wracają dokładnie te błędy, w których jedno i drugie się rozjeżdża: cena zmieniająca się po wyrenderowaniu aplikacji rabatowej, dostępność w magazynie przy wyprzedanym wariancie, strona docelowa z przekierowaniem, waluta zmieniająca się między plikiem a rynkiem prezentacji. Edytowanie eksportu tak, żeby walidator zamilkł, powiększa rozbieżność, zamiast ją zamykać. Trwale pomaga tylko baza danych produktów, z której generuje się cała reszta.
Wydaj pierwszą prośbę o weryfikację z głową
Próśb o weryfikację nie ma bez ograniczeń i każda uruchamia okres karencji. Typowym błędem jest wysłać jedną natychmiast, bo baner uwiera, a przycisk jest tuż obok, zanim przyczyna została faktycznie usunięta. Wtedy prośba zostaje odrzucona, zaczyna się karencja, a druga próba idzie już pod presją czasu. Problemy na poziomie danych nie wymagają prośby w ogóle: napraw je, a kolejne indeksowanie je zdejmie. Zachowaj prośbę na to, co naprawdę wymaga człowieka, i wyślij ją, gdy poprawkę da się już sprawdzić.
Skąd ta wiedza
Feed Guard, nasza własna aplikacja dla Shopify, jest zbudowana na Merchant API i czyta dokładnie te problemy konta i produktów. Dlatego na blogu leży tu dziesięć artykułów rozbierających te awarie po kolei: zawieszenia, wprowadzanie w błąd, odrzucone zdjęcia, brakujące GTIN i marka, rozbieżności ceny i dostępności, wymagania redakcyjne, prośby o ponowną weryfikację i migracja na Merchant API. Usługa to ten sam odczyt zastosowany do twojego konta, z wykonanymi, a nie opisanymi poprawkami.
Powiązane usługi
Opisz projekt
Napisz, co masz i co ma się zmienić. W ciągu dwóch dni roboczych dostajesz pisemną wycenę: zakres rozbity na części z ceną przy każdej, albo pytania, których do niej brakuje. Bez rozmowy wstępnej po drodze.
Pytania
Kłopoty w Merchant Center: pytania i odpowiedzi
Problemy danych zwykle znikają w ciągu kilku dni od poprawki, przy kolejnym indeksowaniu, bez żadnej prośby. Sprawy zasad i konta trwają dłużej i zależą od weryfikacji, której nie kontrolujesz. Kto podaje ci datę przywrócenia konta, podaje datę, której Google mu nie dał.
Nie. Decyzja należy do Google i ta praca tego nie zmienia. W naszych rękach jest to, żeby przyczyna została poprawnie rozpoznana, faktycznie usunięta i przedstawiona z dowodami, i właśnie to sprawia, że prośbę warto w ogóle składać. Jeśli uczciwa ocena brzmi, że konto nie wróci, usłyszysz to, zamiast dostać rachunek za próby.
To najczęstsza wersja tej sprawy. Wprowadzanie w błąd rzadko jest zarzutem oszustwa. Zwykle znaczy, że Google nie zdołał potwierdzić czegoś, czego się spodziewa: danych kontaktowych, jasnej polityki zwrotów, cen zgodnych ze stroną docelową albo możliwej do potwierdzenia tożsamości firmy. Praca polega na tym, żeby to dało się sprawdzić, a nie na sporze o intencje.
Rzadko. Aplikacje różnią się tym, jak mapują atrybuty, i złe mapowanie faktycznie powoduje odrzucenia. Ale awarie na poziomie konta i większość powtarzalnych awarii produktowych biorą się z danych produktów i ze sklepu pod spodem. Zmiana aplikacji przy niezmienionych danych źródłowych zwykle odtwarza te same problemy pod nowymi nazwami.
Tylko jeśli twoje produkty synchronizuje coś własnego: samodzielnie napisany skrypt, starsza integracja albo aplikacja, która nie przeszła migracji. Standardowe ścieżki Shopify i WooCommerce przestawili sami dostawcy. Jeśli w łańcuchu wisi własne zadanie, po dacie wyłączenia przestaje dostawać dane, a to lepiej sprawdzić przed awarią niż po niej.