Co to jest feed produktowy i jak działa?

Sklep internetowy może posiadać tysiące produktów, wariantów, zdjęć, cen i stanów magazynowych. Wszystkie te informacje są czytelne dla użytkownika odwiedzającego stronę, ale zewnętrzne systemy potrzebują ich w uporządkowanej formie.

Google Merchant Center, porównywarka cen, platforma reklamowa albo system partnerski nie powinny samodzielnie przeszukiwać każdej karty produktu i próbować odgadywać, która liczba jest ceną, które zdjęcie jest główne, a który wariant jest aktualnie dostępny.

Takie dane przekazuje feed produktowy.

Feed może zawierać informacje o całej ofercie sklepu albo tylko o wybranych produktach. Może być aktualizowany raz dziennie, kilka razy na godzinę albo niemal na bieżąco. Może działać jako plik XML, CSV, arkusz albo integracja przez API.

Samo utworzenie pliku nie oznacza jednak, że katalog jest prawidłowy.

Feed może technicznie się otwierać, ale jednocześnie przekazywać:

• nieaktualne ceny,
• produkty bez zdjęć,
• nieprawidłowe warianty,
• błędne identyfikatory,
• brakujące marki,
• nieistniejące adresy,
• produkty niedostępne,
• opisy pełne kodu i pozostałości po kreatorze strony.

Z punktu widzenia automatycznego systemu każde pole ma znaczenie. Jedna nieprawidłowa wartość może spowodować odrzucenie produktu, błędne przypisanie reklamy albo skierowanie klienta do oferty, której nie może kupić.

W swojej pracy regularnie spotykam sklepy, w których feed został uruchomiony kilka lat wcześniej i od tego czasu nikt go nie kontrolował. Wtyczka nadal generuje plik, ale struktura produktów, sposób przechowywania marek, pola EAN i ceny zdążyły się zmienić.

Feed produktowy nie jest dodatkiem działającym niezależnie od sklepu. Jest technicznym odwzorowaniem jego danych. Jeżeli dane źródłowe są nieuporządkowane, problemy pojawią się również w feedzie.

Co to jest feed produktowy?

Feed produktowy to uporządkowany zestaw danych opisujących produkty oferowane przez sklep.

Każdy produkt jest przedstawiony za pomocą określonych atrybutów, takich jak:

• unikalny identyfikator,
• nazwa,
• opis,
• adres strony produktu,
• adres głównego zdjęcia,
• cena,
• waluta,
• dostępność,
• marka,
• GTIN,
• MPN,
• kategoria,
• stan produktu,
• dane wariantu.

Feed pozwala automatycznie przekazywać katalog do innych usług bez ręcznego dodawania każdego produktu.

Może być wykorzystywany między innymi przez:

• Google Merchant Center,
• Google Ads,
• Meta Ads,
• porównywarki cen,
• marketplace’y,
• systemy afiliacyjne,
• partnerów handlowych,
• narzędzia remarketingowe,
• zewnętrzne katalogi produktów.

Czy feed produktowy jest tym samym co katalog produktów?

Pojęcia te są często używane zamiennie, ale mogą oznaczać różne elementy procesu.

Katalog produktów jest zbiorem ofert znajdujących się w konkretnym systemie, na przykład w Google Merchant Center albo na platformie reklamowej.

Feed produktowy jest jednym ze sposobów dostarczenia danych do tego katalogu.

Można więc powiedzieć, że:

• sklep generuje feed,
• zewnętrzny system pobiera feed,
• na podstawie feedu tworzy lub aktualizuje katalog.

Katalog może być również zasilany przez API, integrację platformy albo ręczne dodawanie produktów. Wtedy tradycyjny plik może nie występować, ale nadal przekazywany jest ten sam rodzaj danych.

Feed a źródło danych

Współczesne platformy coraz częściej używają określenia źródło danych.

Jest to pojęcie szersze niż sam plik.

Źródłem danych może być:

• plik XML,
• plik CSV,
• plik tekstowy,
• arkusz internetowy,
• automatyczne pobieranie informacji ze sklepu,
• integracja WooCommerce,
• połączenie przez API,
• ręcznie wprowadzany katalog.

W praktyce nadal bardzo często mówi się o feedzie, nawet gdy dane nie są przekazywane przez klasyczny plik.

Jak wygląda feed produktowy?

Feed nie jest stroną przeznaczoną do czytania przez klienta.

Jest zbiorem rekordów, w którym każdy rekord odpowiada produktowi lub jego wariantowi.

Można wyobrazić go sobie jak rozbudowany arkusz:

• jeden wiersz opisuje jeden produkt,
• każda kolumna odpowiada określonemu atrybutowi,
• wartości muszą mieć właściwy format,
• nagłówki muszą odpowiadać wymaganiom systemu docelowego.

W pliku XML te same informacje zapisane są za pomocą uporządkowanych elementów, a nie zwykłych kolumn.

Format techniczny jest mniej ważny niż poprawność i kompletność przekazywanych danych.

W jakich formatach może działać feed?

XML

XML jest jednym z najczęściej wykorzystywanych formatów feedów produktowych.

Dobrze obsługuje:

• duże katalogi,
• zagnieżdżone dane,
• listy produktów,
• automatyczne generowanie,
• cykliczne pobieranie przez zewnętrzne systemy.

Plik XML może być dostępny pod stałym adresem, z którego platforma regularnie pobiera najnowszą wersję.

CSV

CSV przedstawia dane w postaci tabeli rozdzielanej określonym znakiem.

Jest wygodny do:

• ręcznej analizy,
• otwierania w arkuszu kalkulacyjnym,
• edycji mniejszych katalogów,
• importu do różnych systemów.

Problemy mogą pojawiać się przy:

• przecinkach w opisach,
• znakach nowej linii,
• kodowaniu znaków,
• nieprawidłowym separatorze,
• bardzo długich treściach.

TSV i pliki tekstowe

Wartości mogą być rozdzielane tabulatorami albo innym ustalonym separatorem.

Format jest prosty, ale nadal wymaga poprawnego kodowania i konsekwentnej struktury.

Arkusz internetowy

Arkusz może być wygodny dla małego katalogu albo dodatkowego źródła danych.

Pozwala ręcznie poprawiać:

• tytuły,
• etykiety,
• kategorie,
• dodatkowe informacje marketingowe.

Przy dużym i szybko zmieniającym się sklepie ręczne utrzymywanie arkusza staje się jednak ryzykowne.

API

API pozwala przesyłać dane programistycznie bez tworzenia klasycznego pliku do cyklicznego pobierania.

Może umożliwiać:

• szybkie aktualizacje cen,
• aktualizacje stanów magazynowych,
• dodawanie i usuwanie produktów,
• odbieranie informacji o błędach,
• automatyczne zarządzanie dużymi katalogami.

Integracja API daje większą kontrolę, ale wymaga uwierzytelnienia, obsługi błędów, monitoringu i utrzymania kodu.

Jaki format feedu jest najlepszy?

Nie istnieje jeden najlepszy format dla każdego sklepu.

Wybór zależy od:

• liczby produktów,
• liczby wariantów,
• częstotliwości zmian,
• wymagań kanału docelowego,
• możliwości platformy sklepowej,
• potrzeby ręcznych korekt,
• posiadanych zasobów technicznych.

Dla niewielkiego katalogu wystarczający może być automatyczny plik XML.

Dla dużego sklepu synchronizującego stany z ERP lepsze może być połączenie głównego katalogu z częstymi aktualizacjami wybranych danych przez API.

Format powinien rozwiązywać konkretny problem, a nie być wybierany dlatego, że wygląda bardziej zaawansowanie.

Jakie dane powinien zawierać feed?

Dokładny zakres zależy od platformy, kraju, rodzaju produktu i sposobu prezentacji.

Najczęściej potrzebne są:

• ID produktu,
• tytuł,
• opis,
• link,
• link do zdjęcia,
• cena,
• dostępność,
• stan produktu,
• marka,
• GTIN lub MPN,
• kategoria,
• dane wariantu.

Dodatkowo można przekazywać:

• cenę promocyjną,
• dodatkowe zdjęcia,
• kolor,
• rozmiar,
• materiał,
• wzór,
• płeć i grupę wiekową,
• etykiety kampanii,
• koszty dostawy,
• informacje o pakietach,
• jednostkową miarę ceny.

Dlaczego identyfikator produktu jest tak ważny?

Identyfikator łączy kolejne aktualizacje tej samej oferty.

Powinien być:

• unikalny,
• stabilny,
• niezmienny bez potrzeby,
• przypisany zawsze do tego samego produktu lub wariantu.

Jeżeli przy każdej aktualizacji produkt otrzymuje nowe ID, zewnętrzny system może traktować go jako nową ofertę.

Może to powodować:

• utratę historii wyników,
• ponowne sprawdzanie produktu,
• duplikowanie ofert,
• problemy z kampaniami,
• brak zgodności z analityką.

Identyfikatorem może być ID WooCommerce, SKU, ID wariantu albo inny stabilny kod.

Najważniejsze jest to, aby wybrana metoda była stosowana konsekwentnie.

ID produktu a ID wariantu

Produkt wariantowy posiada zwykle produkt główny oraz osobne warianty.

Każdy wariant może różnić się:

• kolorem,
• rozmiarem,
• ceną,
• stanem,
• zdjęciem,
• kodem GTIN,
• SKU.

Jeżeli wariant jest osobną możliwą do kupienia ofertą, powinien posiadać własny identyfikator.

Produkt główny może służyć do połączenia wariantów w jedną grupę.

Nie należy przesyłać wszystkich wariantów z tym samym ID, ponieważ kolejne rekordy będą nadpisywać się albo zostaną uznane za duplikaty.

SKU w feedzie produktowym

SKU jest wewnętrznym kodem używanym przez sklep do identyfikacji produktu.

Może być bardzo dobrym identyfikatorem feedu, jeżeli:

• jest unikalne,
• nie zmienia się po każdej aktualizacji,
• każdy wariant ma własne SKU,
• jest zgodne z systemem magazynowym.

Problem pojawia się, gdy:

• wiele produktów posiada to samo SKU,
• SKU jest puste,
• produkt główny i wariant używają tego samego kodu,
• kod zmienia się podczas migracji,
• system zewnętrzny wykorzystuje inny identyfikator.

GTIN, EAN i UPC

GTIN jest globalnym identyfikatorem produktu handlowego.

W zależności od rynku może występować jako:

• EAN,
• UPC,
• ISBN,
• inny obsługiwany standard.

Jeżeli producent nadał produktowi taki numer, powinien zostać prawidłowo przekazany.

GTIN pomaga systemom:

• rozpoznać konkretny produkt,
• połączyć oferty różnych sprzedawców,
• porównać dane,
• lepiej dopasować produkt do zapytania.

Nie należy wymyślać numeru tylko po to, aby pole nie było puste.

Fałszywy GTIN może przypisać ofertę do zupełnie innego produktu.

Co zrobić, gdy produkt nie ma EAN-u?

Nie każdy produkt posiada EAN.

Może to dotyczyć:

• rękodzieła,
• produktów wykonywanych na zamówienie,
• towarów marki własnej,
• unikalnych zestawów,
• części bez globalnego oznaczenia,
• produktów zabytkowych lub kolekcjonerskich.

W takiej sytuacji feed powinien prawidłowo informować o braku standardowego identyfikatora i przekazywać inne rzeczywiste dane, na przykład markę oraz MPN, jeśli istnieje.

Brak EAN-u jest lepszy niż nieprawdziwy EAN.

Czym jest MPN?

MPN jest numerem katalogowym nadanym przez producenta.

Nie powinien być automatycznie zastępowany wewnętrznym SKU sklepu.

Jeżeli producent posiada oficjalny numer produktu, warto przekazać go w odpowiednim polu.

MPN wraz z marką może pomagać w identyfikacji produktu, szczególnie gdy nie posiada on GTIN-u.

Marka produktu

Feed powinien wskazywać rzeczywistą markę produktu.

Nie należy automatycznie wpisywać nazwy sklepu jako marki wszystkich ofert.

Nazwa sklepu jest marką produktu tylko wtedy, gdy sprzedawany towar rzeczywiście został wprowadzony pod tą marką.

W WooCommerce marka może być przechowywana jako:

• atrybut,
• taksonomia wtyczki,
• pole niestandardowe,
• kategoria,
• dane z zewnętrznego systemu.

Generator feedu musi wiedzieć, z którego miejsca pobrać prawidłową wartość.

Jak przygotować dobry tytuł produktu?

Tytuł powinien jednoznacznie opisywać produkt.

W zależności od rodzaju oferty może zawierać:

• markę,
• typ produktu,
• model,
• najważniejszą cechę,
• kolor,
• rozmiar,
• pojemność,
• liczbę elementów.

Przykładowa kolejność może wyglądać tak:

Marka – rodzaj produktu – model – cecha – wariant.

Tytuł nie powinien być przepełniony:

• wykrzyknikami,
• samymi wielkimi literami,
• informacjami o dostawie,
• kodami rabatowymi,
• powtarzanymi słowami,
• obietnicami niezwiązanymi z produktem.

Czy tytuł w feedzie musi być identyczny jak w sklepie?

Nie zawsze musi być zapisany w identyczny sposób, ale musi opisywać tę samą ofertę.

Nazwa w sklepie może być krótka, ponieważ użytkownik widzi kategorię, markę i kontekst strony.

W reklamie lub porównywarce produkt może być prezentowany bez tego kontekstu.

Feed może więc rozszerzyć tytuł o:

• rodzaj produktu,
• markę,
• model,
• wariant.

Nie wolno jednak dodawać cech, których produkt nie posiada.

Opis produktu w feedzie

Opis powinien przedstawiać rzeczywiste cechy i zastosowanie produktu.

Może zawierać:

• najważniejsze funkcje,
• materiał,
• wymiary,
• kompatybilność,
• zawartość zestawu,
• parametry techniczne,
• informację o przeznaczeniu.

Nie powinien być:

• zbiorem słów kluczowych,
• kopią stopki sklepu,
• tekstem o wszystkich usługach firmy,
• pełen kodu HTML i shortcode’ów,
• zawierać nieaktualnych promocji,
• opisywać innego wariantu.

Problem kodu i pozostałości po kreatorach

Opisy produktów mogą zawierać elementy techniczne pozostawione przez:

• WPBakery,
• Elementor,
• krótkie kody,
• import z innej platformy,
• edytor wizualny,
• niestandardowe pola.

Jeżeli generator feedu pobiera surową treść, w opisie mogą pojawić się fragmenty takie jak nazwy kontenerów, shortcode’y i ustawienia układu.

Feed powinien:

• usunąć elementy techniczne,
• zachować czytelny tekst,
• nie sklejać przypadkowo słów,
• nie usuwać ważnych parametrów.

Link do produktu

Każdy rekord powinien prowadzić do właściwej strony produktu lub konkretnego wariantu.

Adres powinien:

• działać,
• korzystać z HTTPS,
• prowadzić do tego samego produktu,
• nie wymagać logowania,
• nie przekierowywać do strony głównej,
• umożliwiać zakup.

Nieprawidłowe są sytuacje, w których:

• produkt prowadzi do kategorii,
• wariant prowadzi do innego koloru,
• adres zwraca błąd,
• produkt został usunięty,
• strona działa tylko dla administratora.

Link do zdjęcia

Feed powinien przekazywać stabilny adres głównego zdjęcia.

Zdjęcie powinno:

• pokazywać właściwy produkt,
• odpowiadać wariantowi,
• mieć dobrą jakość,
• być dostępne dla zewnętrznego systemu,
• nie zwracać błędu,
• nie być przypadkową miniaturą.

Adres zdjęcia nie powinien wygasać po kilku godzinach ani wymagać zalogowania.

Dodatkowe zdjęcia

Feed może przekazywać więcej niż jedno zdjęcie produktu.

Dodatkowe materiały mogą pokazywać:

• produkt z innej strony,
• detale,
• zastosowanie,
• skalę,
• opakowanie,
• elementy zestawu.

Nie należy jednak dodawać zdjęć produktów, które nie są częścią oferty, bez jasnego kontekstu.

Cena produktu

Cena w feedzie musi odpowiadać cenie widocznej na stronie i możliwej do zapłacenia przez użytkownika.

Niezgodności mogą wynikać z:

• ceny netto zamiast brutto,
• innej waluty,
• opóźnionej aktualizacji,
• cache,
• błędnego wariantu,
• dynamicznego rabatu,
• ceny zależnej od ilości,
• integracji z ERP.

Nie należy przesyłać najniższej możliwej ceny, jeżeli dotyczy ona innego wariantu albo wymaga dodatkowych warunków niewidocznych dla użytkownika.

Cena promocyjna

Feed może rozróżniać cenę regularną i promocyjną.

Promocja powinna:

• rzeczywiście działać,
• dotyczyć właściwego produktu,
• być widoczna na stronie,
• mieć aktualny termin,
• nie wymagać ukrytego kodu, jeśli nie został odpowiednio przekazany.

Po zakończeniu promocji feed powinien szybko wrócić do aktualnych danych.

Dostępność produktu

Dostępność powinna odpowiadać możliwości zakupu.

Produkt może być:

• dostępny,
• niedostępny,
• w przedsprzedaży,
• oczekujący na określony termin,
• dostępny na zamówienie, jeżeli system docelowy obsługuje taki model.

Nie należy oznaczać produktu jako dostępnego, jeżeli:

• nie można dodać go do koszyka,
• wszystkie warianty są wyprzedane,
• sprzedaż została wyłączona,
• produkt wymaga kontaktu zamiast zakupu,
• stan magazynowy nie pozwala na realizację.

Jak często aktualizować ceny i stany?

Częstotliwość aktualizacji powinna odpowiadać szybkości zmian w sklepie.

Inne potrzeby ma katalog stu produktów o stałych cenach, a inne sklep synchronizujący tysiące pozycji z hurtownią.

Częstsze aktualizacje są szczególnie ważne, gdy:

• stan zmienia się wiele razy dziennie,
• ceny pochodzą z ERP,
• produkty sprzedają się w kilku kanałach,
• często uruchamiane są promocje,
• oferta zależy od kursu waluty,
• katalog jest bardzo duży.

Feed aktualizowany raz na dobę może przez wiele godzin reklamować produkt, który został już wyprzedany.

Feed pełny i aktualizacje przyrostowe

Pełny feed zawiera cały katalog przeznaczony dla danego kanału.

Aktualizacja przyrostowa może przekazywać tylko zmienione informacje, na przykład:

• cenę,
• dostępność,
• stan magazynowy.

Takie połączenie bywa użyteczne w dużych sklepach:

• pełny katalog jest przetwarzany okresowo,
• najbardziej dynamiczne dane są aktualizowane częściej.

Rozwiązanie wymaga jednak prawidłowego dopasowania produktów przez stabilne identyfikatory.

Produkty wariantowe w feedzie

Każdy możliwy do kupienia wariant powinien być opisany zgodnie ze swoją rzeczywistą konfiguracją.

Wariant może posiadać własne:

• ID,
• SKU,
• GTIN,
• cenę,
• dostępność,
• zdjęcie,
• kolor,
• rozmiar,
• link.

Warianty jednej rodziny powinny być połączone wspólnym identyfikatorem grupy.

Pozwala to systemowi rozpoznać, że są wersjami tego samego produktu.

Najczęstsze błędy wariantów

Problemy pojawiają się, gdy:

• wszystkie warianty mają to samo ID,
• każdy wariant korzysta z jednego zdjęcia,
• link nie wybiera właściwego wariantu,
• cena pochodzi z najtańszej wersji,
• GTIN jednego wariantu jest kopiowany do pozostałych,
• niedostępny rozmiar jest oznaczony jako dostępny,
• produkt główny jest przesyłany razem z wariantami jako dodatkowa oferta.

Kategorie produktów w feedzie

Feed może zawierać kilka różnych rodzajów klasyfikacji.

Kategoria sklepu

Odpowiada strukturze używanej w WooCommerce.

Może wyglądać tak:

Dom i ogród > Kuchnia > Akcesoria kuchenne.

Typ produktu

Może przedstawiać własną ścieżkę logiczną przygotowaną dla kampanii i raportów.

Kategoria systemu docelowego

Niektóre platformy posiadają własną oficjalną klasyfikację produktów.

Produkt trzeba wtedy przypisać do najlepiej odpowiadającej kategorii zewnętrznego systemu.

Jedna kategoria WooCommerce nie zawsze odpowiada bezpośrednio jednej kategorii platformy.

Dlaczego automatyczne mapowanie kategorii bywa błędne?

Nazwa kategorii w sklepie może być zbyt ogólna.

Przykładowo kategoria „Akcesoria” może zawierać:

• akcesoria kuchenne,
• akcesoria samochodowe,
• akcesoria elektroniczne,
• dodatki do odzieży.

Automatyczne przypisanie wyłącznie na podstawie ostatniej nazwy może prowadzić do niewłaściwej klasyfikacji.

Lepsze mapowanie uwzględnia pełną ścieżkę kategorii, typ produktu i jego cechy.

Czym są etykiety niestandardowe?

Etykiety niestandardowe służą do wewnętrznego dzielenia produktów na potrzeby kampanii.

Mogą opisywać:

• marżę,
• sezon,
• popularność,
• przedział cenowy,
• bestsellery,
• nowości,
• produkty strategiczne,
• poziom zwrotów,
• priorytet reklamowy.

Nie są zwykle wyświetlane klientowi.

Pomagają natomiast podzielić katalog według kryteriów biznesowych, których nie widać w zwykłych kategoriach.

Dlaczego marża powinna znaleźć odzwierciedlenie w feedzie?

System reklamowy zna cenę produktu, ale nie zna automatycznie jego rentowności.

Dwa produkty sprzedawane za 500 zł mogą generować zupełnie inną marżę.

Jeżeli cały katalog jest reklamowany jednakowo, budżet może trafiać do produktów:

• o minimalnym zysku,
• drogich w wysyłce,
• często zwracanych,
• trudnych w obsłudze,
• mało dostępnych.

Etykieta marżowa pozwala tworzyć osobne kampanie lub różne priorytety.

Czy jeden feed wystarczy do wszystkich kanałów?

Nie zawsze.

Różne platformy mogą wymagać:

• innych nazw pól,
• innego formatu kategorii,
• innych identyfikatorów,
• odmiennych długości opisów,
• innych zasad dotyczących zdjęć,
• dodatkowych atrybutów,
• innej struktury wariantów.

Jeden wspólny zestaw danych źródłowych może zasilać kilka feedów, ale każdy eksport powinien być dopasowany do odbiorcy.

Nie warto wymuszać jednego pliku, który jest tylko częściowo zgodny z każdą platformą.

Feed dla Google a feed dla porównywarki cen

Google może wymagać określonych identyfikatorów, klasyfikacji i zasad dotyczących oferty.

Porównywarka może oczekiwać dodatkowo:

• kosztu dostawy,
• czasu wysyłki,
• numeru kategorii porównywarki,
• informacji o gwarancji,
• specyficznego formatu wariantów.

Ten sam produkt może więc wymagać innego mapowania pól.

Feed dla Meta Ads

Katalog używany w reklamach Meta może posiadać własne wymagania i nazwy atrybutów.

Może być wykorzystywany do:

• reklam dynamicznych,
• prezentowania produktów,
• remarketingu,
• kampanii katalogowych.

Identyfikatory produktów przekazywane przez piksel lub inne zdarzenia muszą odpowiadać identyfikatorom znajdującym się w katalogu.

Problem spójności jest taki sam jak w przypadku Google: produkt oglądany na stronie musi dać się powiązać z rekordem w feedzie.

Feed dla marketplace’u

Marketplace może wymagać znacznie większej liczby atrybutów niż system reklamowy.

Może potrzebować:

• parametrów technicznych,
• informacji o producencie,
• danych bezpieczeństwa,
• warunków dostawy,
• kategorii marketplace’u,
• danych potrzebnych do utworzenia pełnej oferty.

Feed reklamowy nie zawsze wystarczy do automatycznego wystawienia produktu na marketplace.

Feed a dane strukturalne

Feed i dane strukturalne opisują produkty w uporządkowany sposób, ale działają inaczej.

Feed jest aktywnie przekazywany lub pobierany przez konkretną platformę.

Dane strukturalne znajdują się w kodzie strony produktu i pomagają robotom rozpoznać widoczne informacje.

Oba źródła powinny być zgodne w zakresie:

• ceny,
• waluty,
• dostępności,
• marki,
• identyfikatorów,
• wariantu.

Rozbieżność pomiędzy feedem, kodem strony i widokiem klienta zwiększa ryzyko błędów.

Feed produktowy a SEO

Feed nie zastępuje indeksowania strony ani działań SEO.

Może pomóc w prezentowaniu produktów w określonych systemach, ale nie naprawi:

• braku indeksowania produktów,
• duplikacji treści,
• nieprawidłowych adresów kanonicznych,
• słabej struktury kategorii,
• problemów technicznych strony,
• braku linkowania wewnętrznego.

Dobry feed może natomiast ujawnić problemy danych, które wpływają również na jakość sklepu i SEO.

Jeżeli produkt nie posiada jasnej nazwy, marki, kategorii i opisu, problem nie ogranicza się wyłącznie do reklamy.

Feed a remarketing dynamiczny

Remarketing dynamiczny łączy aktywność użytkownika z katalogiem produktów.

Proces może wyglądać następująco:

1. Użytkownik ogląda konkretny produkt.
2. Strona przekazuje jego identyfikator.
3. System odnajduje ten sam identyfikator w feedzie.
4. Reklama może później pokazać oglądany produkt.

Jeżeli identyfikatory są niespójne, reklama może:

• nie wyświetlić produktu,
• pokazać produkt główny zamiast wariantu,
• wyświetlić inną ofertę,
• nie utworzyć prawidłowej grupy odbiorców.

Feed a Google Analytics 4

Google Analytics 4 może otrzymywać informacje o produktach oglądanych i kupowanych przez użytkownika.

Warto zachować spójność takich danych jak:

• ID produktu,
• nazwa,
• marka,
• kategoria,
• wariant,
• cena.

Jeżeli feed wykorzystuje SKU, a GA4 wewnętrzne ID WordPressa, raporty mogą być trudne do porównania.

Nie zawsze wszystkie systemy muszą używać identycznego kodu, ale potrzebne jest znane i stabilne mapowanie.

Feed w WooCommerce

WooCommerce przechowuje podstawowe dane produktów, ale nie wszystkie informacje potrzebne do feedu muszą znajdować się w standardowych polach.

Źródłami mogą być:

• tytuł produktu,
• opis krótki i pełny,
• cena regularna,
• cena promocyjna,
• stan magazynowy,
• SKU,
• atrybuty,
• kategorie,
• obrazy,
• pola niestandardowe,
• taksonomie marek,
• dane integracji ERP.

Generator feedu musi prawidłowo połączyć te informacje.

Gotowa wtyczka czy dedykowany generator?

Gotowa wtyczka może być wystarczająca, gdy sklep korzysta ze standardowej struktury WooCommerce.

Powinna jednak obsługiwać:

• produkty proste,
• produkty wariantowe,
• marki,
• GTIN i MPN,
• niestandardowe pola,
• wykluczanie kategorii,
• etykiety,
• automatyczne aktualizacje,
• duży katalog.

Dedykowany generator może być potrzebny, gdy:

• dane pochodzą z nietypowych pól,
• opis jest składany z kilku sekcji,
• sklep posiada niestandardowe warianty,
• ceny są obliczane dynamicznie,
• potrzebne jest zaawansowane filtrowanie,
• różne kanały wymagają osobnego mapowania,
• gotowe wtyczki generują błędne dane.

Czy feed powinien obejmować wszystkie produkty?

Nie zawsze.

Można wykluczyć produkty:

• niedostępne,
• bez zdjęcia,
• bez ceny,
• nierentowne,
• przeznaczone wyłącznie dla wybranych klientów,
• ukryte,
• techniczne,
• tworzone tylko jako element zestawu,
• niespełniające wymagań kanału.

Feed może również obejmować tylko określone kategorie lub marki.

Jest to przydatne, gdy kampania ma rozpocząć się od najlepiej przygotowanej części katalogu.

Filtrowanie feedu po kategorii

Możliwość wyboru kategorii pozwala:

• ograniczyć katalog,
• utworzyć osobne źródła dla różnych kampanii,
• wykluczyć produkty o małej marży,
• testować wybraną część oferty,
• tworzyć feedy dla różnych partnerów.

Filtrowanie powinno uwzględniać również podkategorie.

Jeżeli wybrana zostaje kategoria główna, trzeba świadomie zdecydować, czy feed ma zawierać produkty przypisane do jej potomków.

Filtrowanie po marce, stanie i cenie

Zaawansowany generator może pozwalać wybierać produkty według:

• marki,
• stanu magazynowego,
• ceny,
• statusu publikacji,
• typu produktu,
• daty dodania,
• atrybutów,
• pól niestandardowych.

Takie reguły powinny być udokumentowane. Inaczej produkt może zniknąć z feedu, a nikt nie będzie wiedział, który warunek go wykluczył.

Główne i dodatkowe źródła danych

Główne źródło dostarcza podstawowy katalog i może dodawać lub usuwać produkty.

Dodatkowe źródło może uzupełniać wybrane dane istniejących rekordów.

Może poprawiać na przykład:

• tytuły,
• opisy,
• kategorie,
• etykiety niestandardowe,
• wartości wykorzystywane w kampanii.

Połączenie wymaga zgodnego ID produktu.

Dodatkowe źródło nie naprawi katalogu, jeżeli identyfikatory są niestabilne.

Reguły przekształcania danych

Niektóre platformy pozwalają modyfikować dane już po ich pobraniu.

Reguły mogą:

• dodać markę do tytułu,
• przypisać kategorię,
• utworzyć etykietę,
• zastąpić pustą wartość,
• połączyć kilka pól,
• zmienić format danych.

Reguły są przydatne, ale nie powinny tworzyć skomplikowanego systemu ukrywającego problemy sklepu.

Jeżeli każda cena, marka i kategoria musi być poprawiana poza WooCommerce, warto uporządkować źródło danych.

Walidacja feedu

Przed podłączeniem feedu warto sprawdzić:

• czy plik się otwiera,
• czy ma prawidłowe kodowanie,
• czy zawiera wszystkie wymagane pola,
• czy produkty mają unikalne ID,
• czy linki działają,
• czy zdjęcia są dostępne,
• czy ceny mają właściwy format,
• czy warianty są poprawnie pogrupowane,
• czy dane nie zawierają kodu i błędnych znaków.

Walidacja techniczna nie zastępuje kontroli merytorycznej.

Plik może być poprawnym XML-em, ale przekazywać całkowicie błędne ceny.

Jak diagnozować odrzucone produkty?

Proces diagnostyczny powinien obejmować:

1. Sprawdzenie komunikatu systemu docelowego.
2. Odczytanie wartości wysłanej w feedzie.
3. Porównanie jej z wartością przetworzoną.
4. Sprawdzenie strony produktu.
5. Sprawdzenie danych strukturalnych.
6. Kontrolę konkretnego wariantu.
7. Sprawdzenie czasu ostatniej aktualizacji.

Nie należy poprawiać wyłącznie objawu.

Jeżeli sto produktów posiada błędną markę, problem prawdopodobnie znajduje się w mapowaniu pola, a nie w każdym rekordzie osobno.

Monitoring feedu

Automatyczny feed powinien być monitorowany.

Trzeba kontrolować:

• datę ostatniego wygenerowania,
• datę ostatniego pobrania,
• liczbę produktów,
• liczbę błędów,
• nagłe spadki katalogu,
• problemy z adresem pliku,
• czas generowania,
• wygaśnięcie autoryzacji.

Jeżeli feed zwykle zawiera 10 000 produktów, a nagle ma 500, powinno to zostać wykryte przed rozpoczęciem kolejnej kampanii.

Czy feed może obciążać sklep?

Tak, szczególnie gdy generowany jest dynamicznie przy każdym pobraniu.

Duży katalog może wymagać:

• pobrania tysięcy produktów,
• odczytania wielu pól,
• przetworzenia wariantów,
• wygenerowania opisów,
• sprawdzenia stanów i zdjęć.

Jeżeli zewnętrzny system pobiera plik kilka razy dziennie, każde żądanie może obciążać bazę.

Lepszym rozwiązaniem bywa:

• generowanie pliku według harmonogramu,
• zapisywanie gotowej wersji,
• aktualizowanie tylko zmienionych danych,
• dzielenie katalogu,
• wykorzystanie kolejki zadań.

Bezpieczeństwo feedu

Feed produktowy zwykle zawiera dane publiczne, ale nadal wymaga kontroli.

Nie powinien przypadkowo ujawniać:

• cen hurtowych,
• wewnętrznych marż,
• danych klientów,
• kluczy API,
• technicznych notatek,
• produktów przeznaczonych dla zamkniętej grupy,
• tajnych rabatów.

Jeżeli plik posiada ograniczony dostęp, trzeba sprawdzić, czy platforma docelowa może go pobrać.

Adres feedu nie powinien również zawierać klucza dającego szersze uprawnienia niż odczyt katalogu.

Najczęstsze błędy w feedach produktowych

Brak stabilnych identyfikatorów

Produkty otrzymują nowe ID po każdej aktualizacji.

Duplikaty

Ten sam produkt pojawia się kilka razy z różnymi oznaczeniami.

Nieaktualne ceny

Feed jest odświeżany rzadziej niż sklep.

Nieaktualne stany

Reklamowany produkt został już wyprzedany.

Błędna waluta

Wartość liczbowa odpowiada jednej walucie, a oznaczenie innej.

Cena netto zamiast brutto

Użytkownik widzi inną kwotę po wejściu na stronę.

Fałszywe identyfikatory GTIN

Numery zostały wymyślone albo przypisane do innego wariantu.

Brak marek

Generator nie odczytuje taksonomii używanej w sklepie.

Marka sklepu zamiast producenta

Każdy produkt otrzymuje tę samą nieprawidłową markę.

Złe warianty

Warianty mają wspólne ID, zdjęcie albo kod produktu.

Nieprawidłowe zdjęcia

Feed przekazuje miniaturę, placeholder albo inny kolor.

Uszkodzone opisy

W treści znajdują się shortcode’y, kod kreatora i nieczytelne znaczniki.

Adresy prowadzące do kategorii

Użytkownik nie trafia bezpośrednio do reklamowanego produktu.

Brak filtrowania katalogu

Feed obejmuje produkty techniczne, ukryte i nierentowne.

Jeden feed dla wszystkich platform

Plik nie spełnia w pełni wymagań żadnego kanału.

Brak monitoringu

Generator przestaje działać, ale kampanie nadal korzystają ze starego katalogu.

Generowanie przy każdym wejściu

Zewnętrzne pobranie obciąża całą bazę produktów.

Brak kontroli po zmianie sklepu

Nowy motyw, wtyczka marek albo integracja magazynowa zmienia dane, ale feed nie zostaje sprawdzony.

Jak samodzielnie sprawdzić feed produktowy?

Podstawową kontrolę można rozpocząć od odpowiedzi na kilka pytań:

1. Jaki system generuje feed?
2. Jak często jest aktualizowany?
3. Kiedy ostatnio został wygenerowany bez błędu?
4. Ile produktów powinien zawierać?
5. Ile produktów rzeczywiście zawiera?
6. Czy każdy rekord ma unikalne ID?
7. Czy warianty posiadają osobne identyfikatory?
8. Czy ceny odpowiadają stronie?
9. Czy dostępność jest aktualna?
10. Czy marka pochodzi z właściwego pola?
11. Czy GTIN-y są prawdziwe?
12. Czy zdjęcia odpowiadają produktom i wariantom?
13. Czy linki działają?
14. Czy opis nie zawiera kodu i shortcode’ów?
15. Czy wykluczone są produkty, których nie należy promować?
16. Czy kategorie zostały prawidłowo zmapowane?
17. Czy identyfikatory są zgodne z analityką i remarketingiem?
18. Czy feed nie ujawnia danych wewnętrznych?
19. Czy generator nie obciąża serwera?
20. Czy ktoś analizuje komunikaty platformy docelowej?

Jak wygląda prawidłowy proces tworzenia feedu?

1. Określam kanał docelowy – sprawdzam jego format i wymagane atrybuty.
2. Analizuję dane sklepu – ustalam, gdzie znajdują się ceny, marki, GTIN-y, warianty i kategorie.
3. Porządkuję identyfikatory – wybieram stabilny sposób oznaczania produktów.
4. Ustalam zakres katalogu – wybieram produkty, kategorie i warianty przeznaczone do eksportu.
5. Mapuję pola – łączę dane WooCommerce z atrybutami platformy.
6. Przygotowuję reguły czyszczenia – usuwam kod, błędne znaki i niepotrzebne elementy opisów.
7. Obsługuję warianty – przekazuję właściwe ceny, stany, zdjęcia i identyfikatory.
8. Dodaję dane marketingowe – tworzę typy produktów i etykiety kampanii.
9. Wybieram sposób aktualizacji – dopasowuję harmonogram do tempa zmian.
10. Generuję wersję testową – sprawdzam format i przykładowe produkty.
11. Porównuję dane ze sklepem – kontroluję ceny, dostępność, zdjęcia i linki.
12. Podłączam źródło – przekazuję je do właściwego systemu.
13. Naprawiam błędy grupowo – szukam przyczyny w mapowaniu zamiast poprawiać każdy produkt ręcznie.
14. Wdrażam monitoring – kontroluję liczbę rekordów, aktualność i błędy.
15. Analizuję wyniki – sprawdzam nie tylko zatwierdzenie produktów, ale również sprzedaż i rentowność.

Czy każdy sklep potrzebuje dedykowanego feedu?

Nie.

Standardowy sklep WooCommerce może poprawnie działać z dobrze skonfigurowaną gotową integracją.

Dedykowany generator ma większe uzasadnienie, gdy:

• gotowa wtyczka pomija ważne dane,
• sklep posiada własne pola i taksonomie,
• produkty mają nietypową strukturę,
• opisy są składane z kilku źródeł,
• potrzebne są różne feedy dla kilku platform,
• katalog wymaga zaawansowanych filtrów,
• aktualizacja musi być bardzo częsta,
• gotowe rozwiązanie nadmiernie obciąża serwer.

Nie buduję własnego systemu tylko dlatego, że technicznie jest to możliwe. Najpierw sprawdzam, czy problemu nie rozwiąże prawidłowa konfiguracja istniejącego narzędzia.

Najważniejsze wnioski

• Feed produktowy jest uporządkowanym źródłem informacji o ofercie sklepu.
• Może działać jako XML, CSV, arkusz, integracja platformy albo API.
• Każdy produkt lub wariant powinien posiadać unikalny i stabilny identyfikator.
• SKU może być identyfikatorem, jeżeli jest unikalne i niezmienne.
• GTIN-u nie należy wymyślać ani kopiować z innego produktu.
• Marka powinna odpowiadać rzeczywistemu producentowi lub marce produktu.
• Tytuł powinien jednoznacznie opisywać produkt bez sztucznego upychania fraz.
• Opis powinien być czysty i pozbawiony shortcode’ów oraz kodu kreatorów.
• Cena i dostępność muszą odpowiadać aktualnym informacjom widocznym w sklepie.
• Każdy wariant powinien posiadać właściwe ID, zdjęcie, cenę, stan i identyfikatory.
• Kategorie sklepu i klasyfikacje zewnętrznych platform wymagają świadomego mapowania.
• Etykiety niestandardowe pomagają dzielić produkty według marży, sezonu i priorytetu.
• Nie każdy produkt powinien automatycznie trafiać do każdego kanału reklamowego.
• Jeden wspólny katalog źródłowy może zasilać kilka feedów dopasowanych do różnych platform.
• Feed powinien być aktualizowany z częstotliwością odpowiadającą zmianom cen i stanów.
• Duże katalogi mogą wymagać osobnych aktualizacji przyrostowych albo API.
• Feed, dane strukturalne i strona produktu powinny przedstawiać spójne informacje.
• Spójne identyfikatory są potrzebne do analityki i remarketingu dynamicznego.
• Automatyczny generator wymaga monitoringu daty aktualizacji, liczby produktów i błędów.
• Poprawny format pliku nie gwarantuje prawidłowych danych biznesowych.
• Feed nie zastępuje SEO, sprawnego sklepu ani prawidłowego procesu zakupowego.
• Najlepszy feed jest dokładnym i aktualnym odwzorowaniem rzeczywistej oferty.

Nie wiesz, czy feed prawidłowo odwzorowuje ofertę sklepu?

Podczas audytu sprawdzam nie tylko to, czy plik istnieje i można go otworzyć. Analizuję identyfikatory, warianty, marki, GTIN-y, ceny, dostępność, zdjęcia, opisy, kategorie i sposób aktualizacji danych.

Mogę wskazać produkty pomijane przez błędne filtry, warianty nadpisujące się z powodu wspólnego ID oraz rozbieżności pomiędzy WooCommerce, feedem, analityką i katalogiem reklamowym.

Nie zakładam automatycznie, że potrzebny jest nowy generator. Najpierw ustalam, czy problem znajduje się w danych sklepu, mapowaniu pól, harmonogramie, integracji czy wymaganiach konkretnego kanału. Dopiero później porządkuję feed i przygotowuję go do stabilnej automatycznej pracy.