Feed z ERP do reklam - jak zautomatyzować aktualizacje cen i stanów

Feed z ERP do reklam oznacza, że ceny i stany magazynowe w Google Merchant Center i katalogu Meta pochodzą bezpośrednio z systemu ERP, a nie z ręcznie aktualizowanego pliku. Automatyczna aktualizacja feedu działa najlepiej w dwóch warstwach: pełny plik produktowy pobierany według harmonogramu oraz szybkie aktualizacje cen i dostępności przez API, uruchamiane przy każdej zmianie w ERP. Dzięki temu reklamy nie promują produktów, których nie ma w magazynie, ani nie pokazują nieaktualnych cen.

W tym wpisie wyjaśniamy, dlaczego feed generowany ze sklepu bywa spóźniony wobec ERP, jak zaprojektować eksport danych z ERP, kiedy wystarczy plik pobierany według harmonogramu, a kiedy potrzebne jest API Merchant Center i katalogu Meta oraz jak kontrolować, że ceny w reklamach zgadzają się ze stroną. Tekst jest dla sklepów i hurtowni, które prowadzą kampanie produktowe i mają stany w ERP.

[#wazne] W skrócie: feed z ERP do reklam to eksport produktów, cen i stanów prosto z systemu ERP do Google Merchant Center i katalogu Meta. Pełny feed może być pobierany według harmonogramu, a zmiany cen i dostępności warto wysyłać na bieżąco przez API (w Google przez Merchant API, w Meta przez Catalog Batch API). Kluczowa jest zgodność danych z ceną i dostępnością na stronie sklepu. Programiści Vinson wdrażają takie integracje.

Czym jest feed z ERP i dlaczego ceny w reklamach się rozjeżdżają

Feed produktowy to plik lub strumień danych z listą produktów i ich atrybutami - identyfikatorem, tytułem, ceną, dostępnością, zdjęciem i linkiem - który zasila reklamy produktowe. Feed z ERP to taki, którego dane cenowe i magazynowe pochodzą bezpośrednio z systemu ERP, bo to tam firma prowadzi magazyn i cenniki.

W wielu firmach droga danych jest dłuższa: ERP synchronizuje się ze sklepem co jakiś czas, sklep generuje feed co kilka godzin, a Merchant Center pobiera go raz dziennie. Każde ogniwo dodaje opóźnienie. Gdy produkt sprzeda się w hurcie albo na marketplace, reklama może go promować jeszcze przez wiele godzin. Klient klika, płacisz za kliknięcie, a na stronie widzi brak towaru albo inną cenę.

Google wymaga, aby dostępność w danych produktowych odpowiadała dostępności na stronie docelowej i w procesie zakupu, a niezgodność może prowadzić do odrzucenia produktu. Atrybut availability przyjmuje wartości in_stock, out_of_stock, preorder i backorder (stan na marzec 2026 - sprawdź aktualną specyfikację Google Merchant Center). Ta sama zasada zgodności dotyczy ceny.

Problem rośnie razem z liczbą kanałów sprzedaży. Sklep, który sprzedaje tylko przez własną stronę, ma stan zmieniany przez jeden proces. Gdy dochodzą marketplace, sprzedaż hurtowa i sklep stacjonarny, stan w ERP zmienia się wielokrotnie w ciągu dnia z wielu stron, a feed generowany raz na dobę staje się nieaktualny już po kilku godzinach. Wtedy automatyczna aktualizacja feedu przestaje być udogodnieniem i staje się warunkiem opłacalności kampanii produktowych.

Automatyczna aktualizacja feedu z ERP skraca tę drogę. Przepływ, który stosujemy, wygląda tak:

[#chart:wpr42a]

Jak przygotować eksport danych z ERP do feedu produktowego

ERP rzadko ma wszystkie pola potrzebne w reklamach. Zwykle trzyma kod, nazwę handlową, cenę, stan i EAN, ale tytuł marketingowy, opis, zdjęcia i link do strony są w sklepie. Dlatego eksport z ERP zwykle łączy się z danymi sklepu po wspólnym identyfikatorze, najczęściej SKU. Jak ustawić pełny feed dla Google i jakie atrybuty są w nim obowiązkowe, opisujemy we wpisie feed produktowy dla Google Merchant Center - jak go wygenerować i utrzymać.

Przy projektowaniu eksportu z ERP trzeba podjąć kilka decyzji, które później trudno zmienić:

Decyzja	Dlaczego ważna	Typowe rozwiązanie
Identyfikator produktu	Musi być taki sam w feedzie, kodzie śledzenia i sklepie	SKU wariantu, niezmienne w czasie
Który stan pokazać	ERP ma stan fizyczny, rezerwacje i kilka magazynów	Stan dostępny do sprzedaży minus bufor bezpieczeństwa
Która cena	ERP może mieć kilka cenników i ceny netto	Cena detaliczna brutto zgodna z ceną w sklepie
Promocje	Cena promocyjna musi zgadzać się ze stroną	Osobne pole ceny promocyjnej z datami obowiązywania
Produkty wycofane	Nie mogą wisieć w feedzie z dostępnością in_stock	Oznaczenie out_of_stock lub usunięcie z feedu

[#tip] Ustal bufor bezpieczeństwa dla stanów. Jeśli w ERP zostały 2 sztuki, a sprzedajesz też na marketplace, lepiej pokazać produkt w reklamach jako niedostępny niż płacić za kliknięcia klientów, dla których towaru zabraknie. Próg dobierz do rotacji i liczby kanałów.

Feed z ERP do reklam oznacza, że ceny i stany magazynowe w Google Merchant Center i katalogu Meta pochodzą bezpośrednio z systemu ERP, a nie z ręcznie aktualizowanego pliku. Automatyczna aktualizacja feedu działa najlepiej w dwóch warstwach: pełny plik produktowy pobierany według harmonogramu oraz szybkie aktualizacje cen i dostępności przez API, uruchamiane przy każdej zmianie w ERP. Dzięki temu reklamy nie promują produktów, których nie ma w magazynie, ani nie pokazują nieaktualnych cen.

W tym wpisie wyjaśniamy, dlaczego feed generowany ze sklepu bywa spóźniony wobec ERP, jak zaprojektować eksport danych z ERP, kiedy wystarczy plik pobierany według harmonogramu, a kiedy potrzebne jest API Merchant Center i katalogu Meta oraz jak kontrolować, że ceny w reklamach zgadzają się ze stroną. Tekst jest dla sklepów i hurtowni, które prowadzą kampanie produktowe i mają stany w ERP.

[#wazne] W skrócie: feed z ERP do reklam to eksport produktów, cen i stanów prosto z systemu ERP do Google Merchant Center i katalogu Meta. Pełny feed może być pobierany według harmonogramu, a zmiany cen i dostępności warto wysyłać na bieżąco przez API (w Google przez Merchant API, w Meta przez Catalog Batch API). Kluczowa jest zgodność danych z ceną i dostępnością na stronie sklepu. Programiści Vinson wdrażają takie integracje.

Czym jest feed z ERP i dlaczego ceny w reklamach się rozjeżdżają

Feed produktowy to plik lub strumień danych z listą produktów i ich atrybutami - identyfikatorem, tytułem, ceną, dostępnością, zdjęciem i linkiem - który zasila reklamy produktowe. Feed z ERP to taki, którego dane cenowe i magazynowe pochodzą bezpośrednio z systemu ERP, bo to tam firma prowadzi magazyn i cenniki.

W wielu firmach droga danych jest dłuższa: ERP synchronizuje się ze sklepem co jakiś czas, sklep generuje feed co kilka godzin, a Merchant Center pobiera go raz dziennie. Każde ogniwo dodaje opóźnienie. Gdy produkt sprzeda się w hurcie albo na marketplace, reklama może go promować jeszcze przez wiele godzin. Klient klika, płacisz za kliknięcie, a na stronie widzi brak towaru albo inną cenę.

Google wymaga, aby dostępność w danych produktowych odpowiadała dostępności na stronie docelowej i w procesie zakupu, a niezgodność może prowadzić do odrzucenia produktu. Atrybut availability przyjmuje wartości in_stock, out_of_stock, preorder i backorder (stan na marzec 2026 - sprawdź aktualną specyfikację Google Merchant Center). Ta sama zasada zgodności dotyczy ceny.

Problem rośnie razem z liczbą kanałów sprzedaży. Sklep, który sprzedaje tylko przez własną stronę, ma stan zmieniany przez jeden proces. Gdy dochodzą marketplace, sprzedaż hurtowa i sklep stacjonarny, stan w ERP zmienia się wielokrotnie w ciągu dnia z wielu stron, a feed generowany raz na dobę staje się nieaktualny już po kilku godzinach. Wtedy automatyczna aktualizacja feedu przestaje być udogodnieniem i staje się warunkiem opłacalności kampanii produktowych.

Automatyczna aktualizacja feedu z ERP skraca tę drogę. Przepływ, który stosujemy, wygląda tak:

[#chart:wpr42a]

Jak przygotować eksport danych z ERP do feedu produktowego

ERP rzadko ma wszystkie pola potrzebne w reklamach. Zwykle trzyma kod, nazwę handlową, cenę, stan i EAN, ale tytuł marketingowy, opis, zdjęcia i link do strony są w sklepie. Dlatego eksport z ERP zwykle łączy się z danymi sklepu po wspólnym identyfikatorze, najczęściej SKU. Jak ustawić pełny feed dla Google i jakie atrybuty są w nim obowiązkowe, opisujemy we wpisie feed produktowy dla Google Merchant Center - jak go wygenerować i utrzymać.

Przy projektowaniu eksportu z ERP trzeba podjąć kilka decyzji, które później trudno zmienić:

Decyzja	Dlaczego ważna	Typowe rozwiązanie
Identyfikator produktu	Musi być taki sam w feedzie, kodzie śledzenia i sklepie	SKU wariantu, niezmienne w czasie
Który stan pokazać	ERP ma stan fizyczny, rezerwacje i kilka magazynów	Stan dostępny do sprzedaży minus bufor bezpieczeństwa
Która cena	ERP może mieć kilka cenników i ceny netto	Cena detaliczna brutto zgodna z ceną w sklepie
Promocje	Cena promocyjna musi zgadzać się ze stroną	Osobne pole ceny promocyjnej z datami obowiązywania
Produkty wycofane	Nie mogą wisieć w feedzie z dostępnością in_stock	Oznaczenie out_of_stock lub usunięcie z feedu

[#tip] Ustal bufor bezpieczeństwa dla stanów. Jeśli w ERP zostały 2 sztuki, a sprzedajesz też na marketplace, lepiej pokazać produkt w reklamach jako niedostępny niż płacić za kliknięcia klientów, dla których towaru zabraknie. Próg dobierz do rotacji i liczby kanałów.

Automatyczna aktualizacja feedu - harmonogram pliku czy API

Merchant Center może pobierać plik z produktami z Twojego serwera według harmonogramu. Dokumentacja Merchant API opisuje harmonogram dzienny, tygodniowy lub miesięczny oraz możliwość natychmiastowego pobrania pliku poza harmonogramem; jednocześnie zaleca, by przy potrzebie częstszej aktualizacji niż raz dziennie używać usługi produktów zamiast wielokrotnego pobierania pliku (stan na marzec 2026 - sprawdź aktualną dokumentację Google).

W Merchant API zapisy produktów wykonuje się na zasobie productInputs (wstawianie, częściowa aktualizacja, usuwanie), a przetworzony wynik odczytuje się z zasobu products. Dokumentacja zaleca częściowe aktualizacje (patch) dla atrybutów, które często się zmieniają, takich jak cena i dostępność, i wymaga wcześniejszego utworzenia źródła danych typu API w Merchant Center. Google zapowiedział wycofanie starszego Content API for Shopping na 18 sierpnia 2026 r. i przejście na Merchant API, więc nowe integracje warto od razu budować na Merchant API (stan na marzec 2026 - sprawdź aktualną dokumentację Google).

W Meta katalog produktów można zasilać plikiem pobieranym według harmonogramu albo przez Catalog Batch API. Zapytanie POST /{catalog_id}/items_batch pozwala w jednym wywołaniu tworzyć, aktualizować i usuwać produkty, a stan przetwarzania sprawdza się przez GET /{catalog_id}/check_batch_request_status z otrzymanym identyfikatorem (stan na marzec 2026 - sprawdź aktualną dokumentację Meta). Który sposób wybrać, zależy głównie od tempa zmian:

[#chart:wpr42b]

W praktyce najlepiej sprawdza się połączenie obu metod. Pełny plik z ERP i sklepu pobierany raz na dobę porządkuje cały katalog - nowe produkty, opisy, zdjęcia. Zmiany cen i stanów, które w ERP pojawiają się w ciągu dnia, wysyła osobny proces przez API. Gdy ERP nie potrafi wysyłać zdarzeń o zmianach, skrypt co kilkanaście minut porównuje bieżące stany z ostatnio wysłanymi i przekazuje tylko różnice.

Przy aktualizacjach przez API trzeba pamiętać o kilku zasadach technicznych. Integracja potrzebuje bazy, w której zapisuje ostatnio wysłane wartości i czas wysyłki dla każdego SKU - bez niej nie da się wysyłać tylko różnic ani wyjaśnić, skąd w reklamie wzięła się dana cena. Błędy API trzeba odkładać do ponowienia, a nie pomijać, bo pominięta zmiana dostępności oznacza produkt, który w reklamach będzie dostępny aż do następnego pełnego pliku. Ważne jest też, żeby pełny feed i aktualizacje przez API nie nadpisywały się nawzajem starszymi danymi: pełny plik powinien być generowany z tych samych, aktualnych danych co aktualizacje różnicowe. Dokumentacja Merchant API wymaga, by produkty aktualizowane przez API znajdowały się w źródle danych typu API - sposób połączenia pliku i API trzeba więc zaplanować na początku, a nie dopiero przy pierwszych problemach.

[#przyklad] Uproszczona logika aktualizacji różnicowej: pobierz z ERP SKU, cenę i stan dostępny; porównaj z ostatnio wysłanymi wartościami zapisanymi w bazie integracji; dla zmienionych SKU wyślij częściową aktualizację ceny lub dostępności do Merchant API i katalogu Meta; zapisz nowe wartości i czas wysyłki; błędy odłóż do ponowienia.

Integracja ERP z feedem - na co uważać przy polskich systemach

Polskie systemy ERP różnią się dostępem do danych: część ma API lub mechanizmy eksportu, część wymaga odczytu z bazy danych albo dodatkowego modułu. Wpływa to na to, jak często da się pobierać stany i czy da się reagować na zmiany na bieżąco. Typowe pułapki przy integracji Comarch ERP opisujemy we wpisie integracja Comarch ERP XL i Optima ze sklepem - na co uważać.

Obciążenie ERP - częste zapytania o pełny katalog mogą spowalniać pracę działów, dlatego lepiej pobierać tylko zmiany,
Ceny netto i brutto - ERP często trzyma ceny netto, a reklama musi pokazać cenę brutto taką jak w sklepie,
Kilka magazynów - stan dostępny dla reklam to zwykle suma wybranych magazynów minus rezerwacje,
Warianty - każdy rozmiar i kolor to osobny produkt w feedzie z własnym stanem,
Okna serwisowe - aktualizacje ERP i kopie zapasowe nie mogą zatrzymać feedu bez alertu.

Jak kontrolować, czy feed z ERP jest aktualny

Nawet dobrze zbudowana integracja wymaga kontroli. Najważniejsze sygnały to ostrzeżenia i odrzucenia w diagnostyce Merchant Center oraz w menedżerze katalogu Meta, rozbieżności cen między feedem a stroną i produkty z dostępnością in_stock, które w ERP mają zerowy stan. Gdy do stanów dochodzą marketplace, warto spiąć feed z tą samą logiką co synchronizacja stanów magazynowych między sklepem a marketplace, żeby wszystkie kanały widziały ten sam stan. Typowe objawy i poprawki:

[#chart:wpr42c]

Codziennie - alert, gdy pełny feed nie został pobrany lub wysyłka różnic się zatrzymała.
Co tydzień - przegląd diagnostyki Merchant Center i katalogu Meta pod kątem ceny i dostępności.
Co miesiąc - porównanie losowej próbki produktów: ERP, strona sklepu, dane w Merchant Center.
Po każdej zmianie w ERP lub sklepie - test eksportu na kilku produktach przed wdrożeniem.

Od czego zacząć automatyzację feedu z ERP

Nie trzeba od razu budować pełnej integracji w czasie rzeczywistym. Pierwszym krokiem jest pomiar problemu: ile produktów w Merchant Center ma dostępność in_stock, a w ERP zerowy stan, ile ma inną cenę niż na stronie i jak długo trwa droga zmiany z ERP do reklamy. Wystarczy kilka dni porównań na próbce produktów, żeby zobaczyć, czy opóźnienie liczy się w minutach, czy w godzinach, i które kategorie są najbardziej narażone.

Drugi krok to skrócenie łańcucha. Często największą poprawę daje częstsze generowanie istniejącego feedu i częstsze pobieranie go przez Merchant Center albo przełączenie feedu z danych sklepu na dane prosto z ERP. Dopiero gdy to nie wystarcza, warto dodać aktualizacje różnicowe przez API, zaczynając od dostępności, bo to ona najczęściej marnuje budżet. Ceny promocyjne można dołączyć w kolejnym etapie.

Trzeci krok to utrzymanie. Integracja feedu z ERP powinna mieć właściciela, dokumentację mapowania pól i procedurę na wypadek awarii, np. możliwość szybkiego wstrzymania kampanii produktowych, jeśli feed przestanie się aktualizować przed dużą promocją. Takie przygotowanie jest tańsze niż jeden dzień kampanii, która kieruje ruch na puste karty produktów. Warto też co jakiś czas sprawdzić, czy feed nie zawiera produktów, których sklep w ogóle już nie sprzedaje, bo takie pozycje potrafią latami wisieć w katalogu reklamowym z nieaktualnymi danymi.

[#checklista] Feed z ERP gotowy do reklam: wspólny identyfikator SKU w ERP, sklepie i feedzie; cena brutto zgodna ze stroną; stan dostępny z buforem; produkty wycofane oznaczone jako niedostępne; pełny feed pobierany według harmonogramu; zmiany cen i stanów wysyłane przez API; alert o zatrzymaniu synchronizacji; okresowy przegląd diagnostyki.

Jak Vinson pomaga z feedem z ERP do reklam

Zapewniamy wsparcie programistyczne dla sklepów i sprzedawców: integracje, automatyzacje, poprawki i rozwój sklepów oraz narzędzi. Przy feedach z ERP analizujemy, gdzie powstaje opóźnienie, projektujemy eksport z ERP połączony z danymi sklepu, wdrażamy aktualizacje cen i stanów przez Merchant API i Catalog Batch API Meta oraz ustawiamy alerty. Jako Google Partner i Meta Business Partner wiemy, jak dane produktowe przekładają się na wyniki kampanii. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Jak często aktualizować feed produktowy z ERP?

Pełny feed z opisami i zdjęciami zwykle wystarczy aktualizować raz dziennie. Ceny i stany warto aktualizować częściej - przy szybkiej rotacji nawet co kilkanaście minut lub przy każdej zmianie w ERP. Google zaleca, aby przy aktualizacjach częstszych niż raz dziennie korzystać z API zamiast wielokrotnego pobierania pliku.

Czy można wysłać feed bezpośrednio z ERP do Google Merchant Center?

Tak, ale ERP zwykle nie ma wszystkich pól wymaganych w reklamach, np. tytułów marketingowych, zdjęć i linków. Najczęściej dane z ERP łączy się z danymi sklepu po SKU, a dopiero wynik trafia do Merchant Center. Częste zmiany cen i stanów można wysyłać osobno przez Merchant API.

Co się stanie, gdy dostępność w feedzie nie zgadza się ze stroną?

Google wymaga zgodności dostępności w danych produktowych z dostępnością na stronie i w procesie zakupu, a niezgodność może skutkować odrzuceniem produktu. Dodatkowo płacisz za kliknięcia klientów, którzy nie mogą kupić towaru. Dlatego stany z ERP powinny trafiać do feedu jak najszybciej.

Czym jest Merchant API i czy zastępuje Content API?

Merchant API to interfejs Google do zarządzania danymi w Merchant Center, w tym produktami i źródłami danych. Google zapowiedział wycofanie Content API for Shopping na 18 sierpnia 2026 r., więc nowe integracje warto budować na Merchant API. Aktualny harmonogram sprawdź w dokumentacji Google.

Czy feed z ERP wymaga programisty?

Zwykle tak, bo trzeba połączyć dane z ERP i sklepu, wybrać właściwą cenę i stan, obsłużyć autoryzację w API Google i Meta oraz zbudować alerty. Gotowe narzędzia feedowe pomagają, jeśli potrafią odczytać dane z Twojego ERP. Przy nietypowych systemach lub wielu magazynach potrzebna jest integracja dedykowana.

Feed z ERP z automatyczną aktualizacją cen i stanów chroni budżet reklamowy przed kliknięciami w produkty, których nie ma. Jeśli chcesz połączyć swój ERP z Google Merchant Center i katalogiem Meta, sprawdź wsparcie programistyczne Vinson.

Automatyczna aktualizacja feedu - harmonogram pliku czy API

Merchant Center może pobierać plik z produktami z Twojego serwera według harmonogramu. Dokumentacja Merchant API opisuje harmonogram dzienny, tygodniowy lub miesięczny oraz możliwość natychmiastowego pobrania pliku poza harmonogramem; jednocześnie zaleca, by przy potrzebie częstszej aktualizacji niż raz dziennie używać usługi produktów zamiast wielokrotnego pobierania pliku (stan na marzec 2026 - sprawdź aktualną dokumentację Google).

W Merchant API zapisy produktów wykonuje się na zasobie productInputs (wstawianie, częściowa aktualizacja, usuwanie), a przetworzony wynik odczytuje się z zasobu products. Dokumentacja zaleca częściowe aktualizacje (patch) dla atrybutów, które często się zmieniają, takich jak cena i dostępność, i wymaga wcześniejszego utworzenia źródła danych typu API w Merchant Center. Google zapowiedział wycofanie starszego Content API for Shopping na 18 sierpnia 2026 r. i przejście na Merchant API, więc nowe integracje warto od razu budować na Merchant API (stan na marzec 2026 - sprawdź aktualną dokumentację Google).

W Meta katalog produktów można zasilać plikiem pobieranym według harmonogramu albo przez Catalog Batch API. Zapytanie POST /{catalog_id}/items_batch pozwala w jednym wywołaniu tworzyć, aktualizować i usuwać produkty, a stan przetwarzania sprawdza się przez GET /{catalog_id}/check_batch_request_status z otrzymanym identyfikatorem (stan na marzec 2026 - sprawdź aktualną dokumentację Meta). Który sposób wybrać, zależy głównie od tempa zmian:

[#chart:wpr42b]

W praktyce najlepiej sprawdza się połączenie obu metod. Pełny plik z ERP i sklepu pobierany raz na dobę porządkuje cały katalog - nowe produkty, opisy, zdjęcia. Zmiany cen i stanów, które w ERP pojawiają się w ciągu dnia, wysyła osobny proces przez API. Gdy ERP nie potrafi wysyłać zdarzeń o zmianach, skrypt co kilkanaście minut porównuje bieżące stany z ostatnio wysłanymi i przekazuje tylko różnice.

Przy aktualizacjach przez API trzeba pamiętać o kilku zasadach technicznych. Integracja potrzebuje bazy, w której zapisuje ostatnio wysłane wartości i czas wysyłki dla każdego SKU - bez niej nie da się wysyłać tylko różnic ani wyjaśnić, skąd w reklamie wzięła się dana cena. Błędy API trzeba odkładać do ponowienia, a nie pomijać, bo pominięta zmiana dostępności oznacza produkt, który w reklamach będzie dostępny aż do następnego pełnego pliku. Ważne jest też, żeby pełny feed i aktualizacje przez API nie nadpisywały się nawzajem starszymi danymi: pełny plik powinien być generowany z tych samych, aktualnych danych co aktualizacje różnicowe. Dokumentacja Merchant API wymaga, by produkty aktualizowane przez API znajdowały się w źródle danych typu API - sposób połączenia pliku i API trzeba więc zaplanować na początku, a nie dopiero przy pierwszych problemach.

[#przyklad] Uproszczona logika aktualizacji różnicowej: pobierz z ERP SKU, cenę i stan dostępny; porównaj z ostatnio wysłanymi wartościami zapisanymi w bazie integracji; dla zmienionych SKU wyślij częściową aktualizację ceny lub dostępności do Merchant API i katalogu Meta; zapisz nowe wartości i czas wysyłki; błędy odłóż do ponowienia.

Integracja ERP z feedem - na co uważać przy polskich systemach

Polskie systemy ERP różnią się dostępem do danych: część ma API lub mechanizmy eksportu, część wymaga odczytu z bazy danych albo dodatkowego modułu. Wpływa to na to, jak często da się pobierać stany i czy da się reagować na zmiany na bieżąco. Typowe pułapki przy integracji Comarch ERP opisujemy we wpisie integracja Comarch ERP XL i Optima ze sklepem - na co uważać.

Obciążenie ERP - częste zapytania o pełny katalog mogą spowalniać pracę działów, dlatego lepiej pobierać tylko zmiany,
Ceny netto i brutto - ERP często trzyma ceny netto, a reklama musi pokazać cenę brutto taką jak w sklepie,
Kilka magazynów - stan dostępny dla reklam to zwykle suma wybranych magazynów minus rezerwacje,
Warianty - każdy rozmiar i kolor to osobny produkt w feedzie z własnym stanem,
Okna serwisowe - aktualizacje ERP i kopie zapasowe nie mogą zatrzymać feedu bez alertu.

Jak kontrolować, czy feed z ERP jest aktualny

Nawet dobrze zbudowana integracja wymaga kontroli. Najważniejsze sygnały to ostrzeżenia i odrzucenia w diagnostyce Merchant Center oraz w menedżerze katalogu Meta, rozbieżności cen między feedem a stroną i produkty z dostępnością in_stock, które w ERP mają zerowy stan. Gdy do stanów dochodzą marketplace, warto spiąć feed z tą samą logiką co synchronizacja stanów magazynowych między sklepem a marketplace, żeby wszystkie kanały widziały ten sam stan. Typowe objawy i poprawki:

[#chart:wpr42c]

Codziennie - alert, gdy pełny feed nie został pobrany lub wysyłka różnic się zatrzymała.
Co tydzień - przegląd diagnostyki Merchant Center i katalogu Meta pod kątem ceny i dostępności.
Co miesiąc - porównanie losowej próbki produktów: ERP, strona sklepu, dane w Merchant Center.
Po każdej zmianie w ERP lub sklepie - test eksportu na kilku produktach przed wdrożeniem.

Od czego zacząć automatyzację feedu z ERP

Nie trzeba od razu budować pełnej integracji w czasie rzeczywistym. Pierwszym krokiem jest pomiar problemu: ile produktów w Merchant Center ma dostępność in_stock, a w ERP zerowy stan, ile ma inną cenę niż na stronie i jak długo trwa droga zmiany z ERP do reklamy. Wystarczy kilka dni porównań na próbce produktów, żeby zobaczyć, czy opóźnienie liczy się w minutach, czy w godzinach, i które kategorie są najbardziej narażone.

Drugi krok to skrócenie łańcucha. Często największą poprawę daje częstsze generowanie istniejącego feedu i częstsze pobieranie go przez Merchant Center albo przełączenie feedu z danych sklepu na dane prosto z ERP. Dopiero gdy to nie wystarcza, warto dodać aktualizacje różnicowe przez API, zaczynając od dostępności, bo to ona najczęściej marnuje budżet. Ceny promocyjne można dołączyć w kolejnym etapie.

Trzeci krok to utrzymanie. Integracja feedu z ERP powinna mieć właściciela, dokumentację mapowania pól i procedurę na wypadek awarii, np. możliwość szybkiego wstrzymania kampanii produktowych, jeśli feed przestanie się aktualizować przed dużą promocją. Takie przygotowanie jest tańsze niż jeden dzień kampanii, która kieruje ruch na puste karty produktów. Warto też co jakiś czas sprawdzić, czy feed nie zawiera produktów, których sklep w ogóle już nie sprzedaje, bo takie pozycje potrafią latami wisieć w katalogu reklamowym z nieaktualnymi danymi.

[#checklista] Feed z ERP gotowy do reklam: wspólny identyfikator SKU w ERP, sklepie i feedzie; cena brutto zgodna ze stroną; stan dostępny z buforem; produkty wycofane oznaczone jako niedostępne; pełny feed pobierany według harmonogramu; zmiany cen i stanów wysyłane przez API; alert o zatrzymaniu synchronizacji; okresowy przegląd diagnostyki.

Jak Vinson pomaga z feedem z ERP do reklam

Zapewniamy wsparcie programistyczne dla sklepów i sprzedawców: integracje, automatyzacje, poprawki i rozwój sklepów oraz narzędzi. Przy feedach z ERP analizujemy, gdzie powstaje opóźnienie, projektujemy eksport z ERP połączony z danymi sklepu, wdrażamy aktualizacje cen i stanów przez Merchant API i Catalog Batch API Meta oraz ustawiamy alerty. Jako Google Partner i Meta Business Partner wiemy, jak dane produktowe przekładają się na wyniki kampanii. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Jak często aktualizować feed produktowy z ERP?

Pełny feed z opisami i zdjęciami zwykle wystarczy aktualizować raz dziennie. Ceny i stany warto aktualizować częściej - przy szybkiej rotacji nawet co kilkanaście minut lub przy każdej zmianie w ERP. Google zaleca, aby przy aktualizacjach częstszych niż raz dziennie korzystać z API zamiast wielokrotnego pobierania pliku.

Czy można wysłać feed bezpośrednio z ERP do Google Merchant Center?

Tak, ale ERP zwykle nie ma wszystkich pól wymaganych w reklamach, np. tytułów marketingowych, zdjęć i linków. Najczęściej dane z ERP łączy się z danymi sklepu po SKU, a dopiero wynik trafia do Merchant Center. Częste zmiany cen i stanów można wysyłać osobno przez Merchant API.

Co się stanie, gdy dostępność w feedzie nie zgadza się ze stroną?

Google wymaga zgodności dostępności w danych produktowych z dostępnością na stronie i w procesie zakupu, a niezgodność może skutkować odrzuceniem produktu. Dodatkowo płacisz za kliknięcia klientów, którzy nie mogą kupić towaru. Dlatego stany z ERP powinny trafiać do feedu jak najszybciej.

Czym jest Merchant API i czy zastępuje Content API?

Merchant API to interfejs Google do zarządzania danymi w Merchant Center, w tym produktami i źródłami danych. Google zapowiedział wycofanie Content API for Shopping na 18 sierpnia 2026 r., więc nowe integracje warto budować na Merchant API. Aktualny harmonogram sprawdź w dokumentacji Google.

Czy feed z ERP wymaga programisty?

Zwykle tak, bo trzeba połączyć dane z ERP i sklepu, wybrać właściwą cenę i stan, obsłużyć autoryzację w API Google i Meta oraz zbudować alerty. Gotowe narzędzia feedowe pomagają, jeśli potrafią odczytać dane z Twojego ERP. Przy nietypowych systemach lub wielu magazynach potrzebna jest integracja dedykowana.

Feed z ERP z automatyczną aktualizacją cen i stanów chroni budżet reklamowy przed kliknięciami w produkty, których nie ma. Jeśli chcesz połączyć swój ERP z Google Merchant Center i katalogiem Meta, sprawdź wsparcie programistyczne Vinson.

Feed z ERP do reklam - jak zautomatyzować aktualizacje cen i stanów