Kanał Google & YouTube czy własny feed?
Wybór zaczynamy od potrzeb katalogu. Standardowa integracja może wystarczyć, jeżeli obsługuje wymagane rynki i pola. Własny feed XML lub inna forma eksportu ma sens, gdy potrzebujesz osobnych reguł, dodatkowych odbiorców albo kontroli nad źródłem wybranych wartości. Nie zmieniamy narzędzia tylko dlatego, że produkt został odrzucony: najpierw sprawdzamy przyczynę w diagnostyce.
Opisujemy, który system wysyła produkt i jakie identyfikatory wykorzystuje. Kilka równoległych źródeł bez uzgodnionej odpowiedzialności może utrudnić znalezienie miejsca nadpisania. Weryfikujemy połączenia, harmonogramy i historię przetwarzania. Zakres obejmuje dane katalogowe i ich przesyłanie. Prowadzenie Google Ads, budżet kampanii oraz kreacje reklamowe ustalamy osobno. Dobrze zbudowany feed nie gwarantuje akceptacji całego konta ani sprzedaży konkretnego produktu.
Tytuły i opisy z właściwego pola
Tytuł produktu w sklepie, SEO title i nazwa przekazywana do reklamy mogą pełnić różne funkcje. Zapisujemy, które pole jest źródłem każdej wartości. Jeżeli integracja wysyła meta title zamiast oczekiwanego tytułu, sprawdzamy dostępne ustawienia i reguły transformacji. Nie edytujemy całego katalogu SEO tylko po to, aby skompensować niewłaściwe mapowanie feedu.
Warianty i język
Nazwa powinna pozwalać rozpoznać oferowany wariant, a treść zgadzać się ze stroną docelową. Dla odrębnych rynków weryfikujemy język, adres produktu i walutę. Reguły budowy tytułów testujemy na różnych typach produktów, zamiast przykładać jeden wzór do całego katalogu. Metapola mogą porządkować dane, jeśli integracja rzeczywiście je odczytuje. Ich nazwy, formaty i odpowiedzialność za uzupełnianie zapisujemy w dokumentacji przekazywanej zespołowi.
GTIN, marka, kategorie i grupowanie
Kontrola identyfikatorów rozpoczyna się w katalogu źródłowym. Sprawdzamy przypisanie GTIN do konkretnego wariantu, poprawność marki i spójność kategorii. Nie generujemy przypadkowych kodów dla produktów, które ich nie mają. Google opisuje wymagania w specyfikacji; sposób postępowania zależy od rodzaju produktu i rzeczywistej dostępności identyfikatora. Brak danych trzeba wyjaśnić, a nie ukryć przez fikcyjną wartość.
Ustalamy stabilne identyfikatory ofert i grupowanie wariantów. Zmiana ID podczas zwykłej aktualizacji może utrudnić analizę historii. Przy migracji źródła przygotowujemy mapę starych i nowych kluczy, aby uniknąć przypadkowych duplikatów. Kontrolujemy próbkę obejmującą produkt prosty, wiele kolorów lub rozmiarów, brakujący identyfikator i produkt wycofany. Reguły walidacji dopasowujemy do kanału: wymagania Ceneo i Google nie są automatycznie identyczne.
Odrzucone produkty: dane czy zasady?
Rozdzielamy błędy formatu, niezgodność ceny, problem ze zdjęciem i ograniczenia wynikające z zasad platformy. Poprawny plik nie usuwa blokady związanej z rodzajem towaru lub wiarygodnością konta. Przy produktach regulowanych sprawdzamy polityki Google i wymagane dokumenty. Nie proponujemy obchodzenia weryfikacji, zmiany nazwy w celu ukrycia produktu ani gwarancji odblokowania.
Gdy błąd wraca po dwóch dniach
Porównujemy wartość w sklepie, wysłanym źródle i po przetworzeniu przez odbiorcę. Zapisujemy czas ostatniej synchronizacji oraz informację o dodatkowych regułach. W ten sposób można ustalić, czy poprawkę nadpisuje aplikacja, system magazynowy, inne źródło lub mechanizm aktualizacji odbiorcy. Dokumentujemy kod błędu, objęte nim produkty i wynik następnego cyklu. Samo zniknięcie komunikatu po ręcznej edycji nie jest wystarczającym kryterium zakończenia prac.
Próbka do diagnozy powracającego odrzucenia
Wybieramy produkty z tym samym komunikatem oraz jeden porównywalny produkt bez błędu. Zapisujemy wartość źródłową, wynik eksportu i odczyt po przetworzeniu. Różnica między nimi wskazuje etap, który trzeba sprawdzić. Jeśli oba produkty przechodzą przez tę samą regułę, szukamy cechy rozdzielającej przypadki, na przykład innej waluty, pustego pola albo nadpisania z dodatkowego systemu.
Następnie zmieniamy jedną uzgodnioną regułę i czekamy na zwykły cykl aktualizacji odbiorcy. Takie podejście pozwala odróżnić trwałą naprawę od jednorazowego ręcznego obejścia. W raporcie pozostaje zapis, dlaczego wybrano konkretny punkt mapowania i jaka próbka potwierdziła rezultat. Nie wnioskujemy o całym katalogu po jednym produkcie, jeśli różne grupy używają innych źródeł lub reguł.
Właściciel danych po wdrożeniu
Zespół powinien wiedzieć, gdzie poprawiać tytuł reklamowy, kto uzupełnia brakujący identyfikator i kto reaguje na błąd pobierania. Te zadania mogą należeć do różnych osób. Bez takiego podziału poprawka trafia do niewłaściwego panelu i znika przy następnej synchronizacji. Instrukcja obejmuje też kontrolę po dodaniu nowego rynku lub kategorii, żeby stary zestaw reguł nie był stosowany bez oceny do całkiem innego asortymentu.
Zdjęcia, cena, dostępność i koszt dostawy
Weryfikujemy, czy zdjęcia są dostępne dla odbiorcy i przedstawiają właściwy wariant. Sprawdzamy adresy po zmianie domeny, reguły dostępu i jakość plików. W przypadku cen porównujemy rabaty, walutę oraz stan widoczny po wejściu na stronę produktu. Wysłanie ceny bazowej zamiast ceny obowiązującej na danym rynku może tworzyć rozbieżność, nawet gdy eksport jest technicznie poprawny.
Dostępność musi wynikać z ustalonego źródła stanów i zasad sprzedaży przy braku towaru. Osobno analizujemy dostawę, jeżeli diagnostyka wskazuje jej koszt lub obszar obsługi. Nie ustawiamy fikcyjnej darmowej wysyłki dla zamknięcia błędu. Po zmianach wykonujemy kontrolę na przykładach z odpowiednich rynków. Jeżeli problem leży w cenach lub stanach nadpisywanych przez ERP, łączymy prace z integracją systemów, zamiast ograniczać naprawę do końcowego pliku.
Aktualizacje oraz feed dla Ceneo
Uzgadniamy, jak szybko zmiana w sklepie powinna pojawić się w kanale. Harmonogram eksportu i pobrania przez odbiorcę to dwa różne momenty, a dodatkowy czas zajmuje przetwarzanie. Nie obiecujemy natychmiastowej aktualizacji, jeżeli źródło i odbiorca działają w cyklach. Dla produktów szybko rotujących kontrola świeżości danych jest częścią oceny ryzyka.
Feed dla Ceneo lub innej porównywarki projektujemy według aktualnej specyfikacji odbiorcy. Sprawdzamy strukturę, kategorie, linki i wymagane atrybuty. Osobny eksport może korzystać ze wspólnego katalogu, ale nie powinien bezrefleksyjnie kopiować wszystkich pól Google. Ustalamy właściciela dostępu do pliku i sposób monitorowania błędów pobierania. W odbiorze potrzebna jest poprawna próbka i potwierdzenie przetworzenia, a nie wyłącznie plik otwierający się w przeglądarce.
DataEase i utrzymanie jakości katalogu
DataEase to nasze narzędzie do masowej pracy z danymi Shopify. W projekcie sprawdzamy, czy jego aktualne funkcje odpowiadają wymaganej operacji, typom zasobów i formatowi eksportu. Jeśli potrzebny wariant feedu wymaga rozszerzenia lub innego konektora, zapisujemy to przed wyceną. Nie przedstawiamy planowanej funkcji jako dostępnej bez weryfikacji w aplikacji.
Przy większym katalogu warto połączyć integrację z porządkowaniem danych: ujednolicić markę, jednostki, identyfikatory i metapola. Import i eksport Shopify może być wtedy osobnym etapem. Do briefu podaj liczbę wariantów, rynki, obecne źródło i przykładowe kody odrzucenia. Wynikiem jest mapowanie, konfiguracja, raport testów oraz instrukcja reagowania na powracające błędy. Skuteczność reklamy analizujemy oddzielnie od poprawności feedu, korzystając z analityki Shopify.
Źródła i aktualność informacji
Sprawdzono: . Dostępność funkcji i warunki dostawców mogą się zmieniać.
Google: specyfikacja danych produktówGoogle: aktualizacje specyfikacji w 2026DataEase w Shopify App Store