W skrócie
- Feed jest procesem, nie jednorazowym plikiem.
- Cena i dostępność muszą odpowiadać stronie.
- Zmiany wdraża się według wpływu i dowodu.
Merchant Center i feed produktowy łączą katalog sklepu z systemami Google, ale ich jakość zależy od danych źródłowych, strony, integracji i regularnej kontroli. Odrzucony produkt nie zawsze ma problem w samym pliku. Cena może być poprawna w eksporcie, lecz inna na stronie po rabacie; dostępność może zmieniać się szybciej niż harmonogram aktualizacji; identyfikator może być tworzony od nowa przy każdym imporcie.
Naprawa powinna więc zaczynać się od własności kont, mapy źródeł i reprodukcji błędu. Dopiero później zmienia się atrybuty, reguły albo integrację. Losowe poprawianie komunikatów bez rozpoznania przyczyny może usunąć objaw dla kilku produktów, a jednocześnie pogorszyć cały katalog.
Zabezpiecz własność konta i narysuj drogę danych
Spisz identyfikator Merchant Center, konto Google Ads, usługę analityczną, domenę oraz integracje sklepu. Ustal, które zasoby należą do firmy i kto ma dostęp administracyjny. Sklep nie powinien być zależny od prywatnego konta jednej osoby albo dostawcy, który jako jedyny może zmienić źródło danych.
Narysuj przepływ od systemu produktowego do strony i Merchant Center. Dane mogą pochodzić z platformy sklepowej, pliku XML lub TSV, arkusza, automatycznego pobierania ze strony, interfejsu API albo kombinacji źródeł. Trzeba wiedzieć, które pole jest nadrzędne oraz gdzie powstają reguły modyfikujące tytuł, cenę, dostępność i kategorię.
Zapisz częstotliwość każdego etapu. Jeśli magazyn aktualizuje się co kilka minut, sklep co godzinę, a feed raz dziennie, powstaje okno niespójności. Nie zawsze da się je wyeliminować, ale można je uwzględnić w harmonogramie i monitoringu. Aktualizacja częstsza od źródła nie poprawi danych, których źródło jeszcze nie otrzymało.
Sprawdź historię zmian w panelu, integracji i platformie. Ustal, czy wzrost odrzuceń nastąpił po zmianie szablonu, migracji, wdrożeniu promocji, modyfikacji wariantów lub dodaniu aplikacji. Zbieżność czasu jest wskazówką, nie dowodem, ale pozwala ograniczyć obszar badania.
Jeżeli sklep korzysta z kilku narzędzi marketingowych, zasada własności jest podobna jak przy audycie Google Ads, dostępu i historii zmian. Firma powinna móc kontynuować pracę po zmianie wykonawcy i rozumieć, które systemy wymieniają dane.
Pakiet danych do diagnostyki
0/12
Uporządkuj identyfikatory i atrybuty w źródle, nie tylko w regule
Identyfikator produktu powinien być stabilny w czasie i jednoznaczny dla oferty. Nie zmieniaj go tylko dlatego, że poprawiono tytuł albo zdjęcie. Nowy identyfikator może przerwać historię i utrudnić porównanie. Warianty wymagają własnych rekordów oraz wspólnego powiązania zgodnego z rzeczywistą strukturą produktu.
Tytuł ma rozróżniać ofertę i odpowiadać stronie. Powinien wykorzystywać realne cechy, takie jak typ, marka, model, rozmiar czy kolor, jeśli mają zastosowanie. Nie wypełniaj go powtórzeniami słów ani komunikatem promocyjnym oderwanym od produktu. Kolejność informacji może zależeć od kategorii i sposobu wyszukiwania.
Opis powinien mówić o produkcie, nie o polityce sklepu. Usuń kod HTML, teksty o darmowej dostawie, przypadkowe fragmenty regulaminu i dane wspólne dla całej witryny, jeśli nie należą do pola. Zadbaj, by źródło nie ucinało treści w środku zdania albo nie kopiowało nazwy bez żadnej informacji.
GTIN, marka i numer producenta powinny odpowiadać faktycznym oznaczeniom. Nie twórz sztucznego kodu, by wypełnić wymagane pole. Jeśli produkt nie ma identyfikatora producenta, trzeba zastosować właściwy sposób opisu zgodny z aktualną specyfikacją, a nie wpisywać losową wartość.
Kolor, rozmiar, materiał, płeć, grupa wiekowa i inne atrybuty zależą od rodzaju produktu. Wartości powinny być spójne między wariantami i stroną. Zanim dodasz skomplikowane reguły mapowania, popraw słownik w systemie źródłowym. Reguła może ukryć bałagan, ale kolejne kanały sprzedaży odziedziczą ten sam problem.
Synchronizuj cenę i dostępność z tym, co widzi klient
Porównaj rekord feedu z właściwym wariantem na stronie. Cena, waluta, dostępność i stan produktu muszą dotyczyć tego samego identyfikatora. Jeśli adres otwiera domyślnie inny rozmiar albo kolor, system może odczytać wartość różną od przesłanej. Link powinien prowadzić do konkretnej oferty, o ile platforma na to pozwala.
Promocje wymagają dat, ceny bazowej i prawidłowego działania w koszyku. Nie wysyłaj obniżonej ceny, której klient nie widzi bez kodu albo dodatkowego warunku, jeśli sposób prezentacji nie odpowiada wymaganiom kanału. W czasie rozpoczęcia i zakończenia promocji zwiększ częstotliwość kontroli.
Dostępność musi wynikać z realnej możliwości realizacji. Stan „dostępny” nie powinien oznaczać produktu, którego sklep nie może sprzedać, a „brak” nie powinien być ustawiany tylko dlatego, że dany wariant czeka na synchronizację. Ustal jedno źródło prawdy dla stanu magazynowego i kolejność obsługi rezerwacji.
Sprawdź stronę bez zalogowania, na telefonie i po zaakceptowaniu lub odrzuceniu zgód. Cena oraz produkt nie mogą być widoczne tylko po wykonaniu skryptu blokowanego dla części użytkowników. Dane strukturalne powinny zgadzać się z widoczną ofertą. Po zmianie szablonu wykonaj test reprezentatywnych kategorii, nie jednej najprostszej karty.
Problemy sieciowe sklepu lub biura mogą utrudniać panel, lecz większym ryzykiem jest niedostępność samej witryny dla systemów zewnętrznych. Organizację łączności operacyjnej opisują poradniki o internecie w lokalu usługowym oraz zapasowym łączu w biurze. Monitoring strony i feedu powinien jednak działać niezależnie od komputera właściciela.
Diagnozuj błąd na konkretnej próbce i szukaj wspólnej przyczyny
Podziel problemy na poziom konta, źródła, grupy produktów i pojedynczej oferty. Blokada konta wymaga innego postępowania niż brak atrybutu dla kilku rekordów. Nie zaczynaj od masowej zmiany feedu, jeśli komunikat dotyczy ograniczonej kategorii albo strony docelowej.
Dla produktu wybierz jeden identyfikator i prześledź go od bazy sklepu przez surowy eksport, reguły, dane widoczne w Merchant Center aż do strony. Zapisz wartości oraz czas każdego etapu. Dzięki temu można wskazać, gdzie powstała rozbieżność, zamiast naprawiać ostatni system w łańcuchu.
Następnie sprawdź, co łączy wadliwe rekordy: kategorię, markę, wariant, brak zdjęcia, źródło magazynu, szablon adresu albo moment importu. Próbka powinna zawierać też produkt poprawny z tej samej grupy. Różnica między nimi często daje lepszą wskazówkę niż sam tekst błędu.
Przy zdjęciach kontroluj adres, dostępność pliku, jakość, kadrowanie i zgodność z wariantem. Nie dodawaj znaków lub elementów promocyjnych sprzecznych z wymaganiami. Jeśli generujesz wiele rozmiarów, upewnij się, że system przekazuje wersję możliwą do pobrania i nie blokuje jej zabezpieczeniem witryny.
Jeżeli potrzebna jest zewnętrzna diagnostyka, zakres usługi może obejmować konto, źródła, atrybuty, błędy i plan napraw. Przykład takiego zakresu opisuje oferta audytu Merchant Center i feedu produktowego. Sklep powinien zachować dostęp, kopię konfiguracji i listę zmian z uzasadnieniem.
Wdrażaj plan naprawczy według wpływu i kontroluj nawroty
Najpierw usuń problemy blokujące konto, domenę, pobieranie źródła lub znaczną część katalogu. Następnie zajmij się ceną, dostępnością, identyfikatorami i innymi danymi wpływającymi na możliwość publikacji. Optymalizacja tytułów ma sens po odzyskaniu wiarygodnego, stabilnego przepływu.
Każde zadanie powinno mieć komunikat wyjściowy, rozpoznaną przyczynę, zakres produktów, właściciela, zmianę, termin ponownego sprawdzenia i kryterium powodzenia. Zachowaj próbkę sprzed poprawki. Jeśli problem wróci, historia pokaże, czy przyczyna była błędnie rozpoznana, czy inny proces nadpisał dane.
Nie wdrażaj wielu globalnych reguł bez testu. Zastosuj zmianę do małej grupy, sprawdź stronę i przetworzone dane, a dopiero potem rozszerz. Reguły powinny mieć nazwę oraz opis celu. Po kilku miesiącach łatwo zapomnieć, dlaczego usuwają fragment tytułu albo zastępują kategorię.
Po naprawie kontroluj liczbę aktywnych, ograniczonych i odrzuconych produktów, świeżość źródła, różnice ceny oraz dostępności i awarie pobierania. Wskaźniki marketingowe oceniaj osobno od poprawności danych. Produkt może być aktywny, lecz nieatrakcyjny; może też sprzedawać się dobrze mimo niepełnego atrybutu, który ogranicza przyszły zasięg.
Połącz dane katalogowe z jakością pomiaru i obsługi zamówień. Metodę testowania zdarzeń i znaczenia konwersji opisuje poradnik o pomiarze konwersji oraz jakości danych. Poprawny feed nie dowodzi rentowności kampanii, tak jak dobry wynik kampanii nie usprawiedliwia błędnej informacji dla klienta.
Kontroluj źródło, reguły, harmonogram i stronę. Jednorazowe usunięcie błędów nie wystarczy, jeśli następna aktualizacja ponownie wysyła wadliwe dane.
Najczęstsze pytania
Czy feed musi być plikiem XML?
Nie. Dane mogą trafiać do Merchant Center różnymi obsługiwanymi metodami, między innymi przez platformę, plik, arkusz, automatyczne pobieranie lub API. Wybór powinien odpowiadać systemowi sklepu i potrzebnej częstotliwości.
Dlaczego cena w feedzie różni się od strony?
Przyczyną może być opóźnienie aktualizacji, inny wariant, promocja, waluta, reguła, pamięć podręczna albo błędne dane strukturalne. Trzeba prześledzić ten sam produkt i czas w każdym etapie.
Czy można zmienić identyfikator produktu, aby usunąć błąd?
Nie powinno się tego robić jako skrótu. Identyfikator ma być stabilny. Należy naprawić przyczynę błędu; zmiana identyfikatora może przerwać historię i stworzyć duplikaty.
Jak często aktualizować dane?
Częstotliwość zależy od tempa zmian ceny, dostępności i możliwości źródła. Harmonogram powinien ograniczać okres niespójności, ale częstszy import nie pomoże, jeśli sklep lub magazyn aktualizuje się wolniej.
Czy aktywny produkt oznacza, że dane są dobre?
Nie w pełni. Aktywny produkt przeszedł określone kontrole, ale nadal może mieć słaby tytuł, niepełne atrybuty, niewłaściwy wariant strony lub dane pogarszające jakość ruchu. Potrzebna jest także kontrola biznesowa.
