AI product updates - proces aktualizacji produktów 2026

AI product updates workflow to następny krok po jednorazowej kampanii bulk content. Sklep, który nauczył się generować 1000 opisów w jednym przebiegu, szybko odkrywa, że katalog zmienia się codziennie – nowe SKU, zmiana opakowania, nowe warianty kolorów, aktualizacja gwarancji. Ręczne utrzymanie pipeline staje się wąskim gardłem. Stały, zautomatyzowany proces aktualizacji produktów z wykorzystaniem AI rozwiązuje ten problem.

Ten przewodnik opisuje architekturę ciągłego procesu – od triggerów zmiany, przez kolejkę zadań i walidację, po re-indeksację w wyszukiwarkach i monitoring widoczności w modelach LLM. Pełny kontekst e-commerce pod AI zaczyna się w przewodniku SEO dla e-commerce.

W skrócie

Triggery aktualizacji: change data capture z bazy produktów, webhooki z PIM, zdarzenia z panelu administracyjnego.
Warstwa decyzyjna: reguły biznesowe klasyfikują zmianę (triggeruje pełną regenerację, tylko Offer, tylko alt-text zdjęć).
Kolejka zadań: Redis/BullMQ lub SQS z priorytetami i retry.
Walidacja: schema + długość + halucynacje + lint na 100% aktualizacji; odrzucone wracają do kolejki.
Re-indeksacja: ping sitemap i opcjonalny Indexing API dla nowych SKU; naturalny crawl dla aktualizacji.

Dlaczego stały proces zamiast kampanii ad-hoc

Kampania ad-hoc (bulk) działa raz na kilka miesięcy. Między kampaniami katalog „stygnie” – nowe SKU dostają puste lub importowane opisy, stare SKU się duplikują z wariantami. To się odbija w wynikach: Google indeksuje puste karty z niską jakością, LLM nie cytuje produktów bez struktury. Stały proces rozwiązuje ten problem – każda zmiana w katalogu przechodzi przez pipeline w ciągu godzin, nie miesięcy.

Kluczowa różnica pomiędzy bulk a stałym procesem to kolejność: bulk oczekuje na „gotowe dane”, proces ciągły pracuje z ciągłym strumieniem zmian. Architektura musi być asynchroniczna, tolerancyjna na częściowe dane i odporna na błędy. Jak ustabilizować bulk, opisujemy w artykule o bulk content dla 1000 produktów.

Trzy typy zdarzeń, które triggerują update

Typ zdarzenia	Źródło	Akcja
Nowy SKU	PIM / panel admin	Pełna generacja opisu + FAQ + schema
Zmiana specyfikacji	PIM / ERP	Regeneracja opisu z nowym polem
Zmiana ceny	ERP / cennik	Aktualizacja Offer (cena, priceValidUntil)
Zmiana stocku	ERP / magazyn	Aktualizacja availability
Nowe zdjęcia	CMS / media	Regeneracja alt-text, update schema image
Nowe opinie	Opineo / Ceneo / wewn	Update AggregateRating + Review[]
Zmiana gwarancji/zwrotu	Polityka sklepu	Update FAQ i sekcji „Gwarancja”
Rebranding / zmiana nazwy	Marketing	Pełna regeneracja + 301 redirect

Każdy typ wymaga innego modelu decyzyjnego i innej kolejki. Nie trzeba generować opisu od zera, gdy zmieniasz cenę – wystarczy akt Offer. Ta granularność obniża koszt API o 60-80% względem naiwnego „regeneruj wszystko”.

Change data capture – jak wychwycić zmianę

Najczęstsze podejście w 2026 to Change Data Capture (CDC) z bazy produktowej. PostgreSQL używa logicznej replikacji (pglogical lub Debezium), MySQL binlog. Dla Shopify, Magento, WooCommerce dostępne są webhooki natywne. Każda zmiana rekordu produkt wrzuca zdarzenie do kolejki z metadanymi: ID produktu, lista zmienionych pól, timestamp, autor.

Alternatywa dla mniejszych sklepów: cron-based polling co 15-30 minut. Pobiera się produkty z updated_at > last_check i przetwarza w batchu. Prostsze, ale z opóźnieniem. Dla sklepów poniżej 2000 SKU polling w zupełności wystarczy.

Webhooki z platformy

Shopify – products/update, products/create, products/delete; szczegóły w artykule o Shopify.
WooCommerce – natywne webhooki REST + plugin ACF do rozszerzeń.
Magento 2 – observer pattern lub dedykowany event bus.
PIM Akeneo – kolejki RabbitMQ z event subscribers.

Warstwa decyzyjna – co regenerować

Kolejka dostaje zdarzenie, decyzyjna warstwa klasyfikuje i kieruje do odpowiedniego workera. Reguły są proste i zazwyczaj ręcznie zdefiniowane w YAML lub JSON. Przykład:

rules:
  - if: event.fields includes ["name", "description", "specs"]
    then: action = regenerate_full
  - if: event.fields == ["price"]
    then: action = update_offer
  - if: event.fields == ["stock_level"]
    then: action = update_availability
  - if: event.type == "new_sku"
    then: action = generate_from_scratch

Silnik reguł może być prosty (match-case w Pythonie) lub złożony (RuleEngine, Drools) – dla większości sklepów wystarcza 50-100 linii kodu. Sama lista reguł rośnie z czasem – po 6 miesiącach produkcji jest ich zwykle 20-40.

Kolejka zadań – priorytety i retry

Kolejka obsługuje trzy priorytety: wysoki (nowe SKU, rebranding), średni (zmiana specyfikacji), niski (akt ceny, stock). Redis z BullMQ to standardowy stos dla Node.js; dla Pythona Celery z Redis lub RabbitMQ. Chmura: AWS SQS z DLQ, GCP Pub/Sub.

Wysoki priorytet – nowy produkt musi być widoczny w sklepie w ciągu 30 minut od dodania.
Średni priorytet – zmiana specyfikacji do 2 godzin.
Niski priorytet – akt ceny/stocku do 15 minut (operacyjne, ale łatwe).
Retry – 3 próby z exponential backoff (15 s, 60 s, 300 s).
Dead letter queue – po 3 nieudanych próbach zdarzenie trafia do DLQ i alertu.

Rate limiting vs priorytety

Worker respektuje rate limit API (OpenAI, Anthropic) i rozdziela tokeny wg priorytetu. Przy nasyceniu kolejki lower-priority czekają, a high-priority są obsługiwane natychmiast. Dobrym wzorcem jest rezerwacja 20% rate limit dla high-priority. Szczegółowy dobór modeli – w artykule o bulk AI content.

Worker generujący – kod i parametry

Worker to zazwyczaj mała aplikacja w Pythonie lub Node.js, która robi trzy rzeczy: pobiera zadanie z kolejki, wywołuje model AI, zapisuje wynik i oznacza zadanie. Typowy kod ma 200-400 linii. Kluczowe parametry:

timeout – 30-60 s na wywołanie modelu; dłużej = zabij i retry.
concurrency – 5-20 równoległych wywołań per worker.
instance count – 3-10 workerów w horyzontalnym skalowaniu.
model fallback – jeżeli GPT-4o-mini zwróci 429 lub 500, przełącz na Claude Haiku.
structured output – JSON schema dla deterministycznego wyniku.

Walidacja aktualizacji

Każdy wynik z modelu przechodzi walidację przed zapisem. Trzy warstwy: syntaktyczna, semantyczna, SEO.

Walidacja syntaktyczna

Poprawny HTML bez uszkodzonych tagów, poprawny JSON schema Product, poprawne pola (długość, format, typ). Narzędzia: cheerio dla HTML, ajv dla JSON schema. Czas walidacji: 100-300 ms per opis.

Walidacja semantyczna

Spójność danych: cena w opisie zgodna z ceną w Offer, wymiary w tekście zgodne z tabelą spec, marka w nazwie zgodna z polem brand. Nieujawnienie niezgodności blokuje zapis i trafia do manual review. Walidacja regex + porównanie z polami źródłowymi.

Walidacja SEO

Focus keyword obecny w tytule i H1, meta opis 140-160 znaków, alt-text zdjęć obecny, schema Product przechodzi Rich Results API. Pełen SEO-lint zabiera 1-3 sekundy per produkt (z powodu wywołania Rich Results API). Narzędziowy kontekst w przewodniku o narzędziach SEO.

Re-indeksacja i ping sitemap

Po zapisie zaktualizowanego produktu, sklep pinguje Google: submituje zaktualizowany sitemap URL do Search Console (API lub manualnie). Dla nowych SKU warto użyć Indexing API – szybsze indeksowanie w ciągu godzin zamiast dni. Dla aktualizacji istniejących SKU – naturalny crawl wystarczy, bo Google odwiedza popularne produkty codziennie.

Zdarzenie	Metoda indeksacji	Czas do widoczności
Nowy SKU	Indexing API + sitemap ping	4-24 h
Zmiana opisu	Naturalny crawl + sitemap lastmod	1-7 dni
Zmiana ceny	Merchant Center feed + schema update	2-24 h
Zmiana zdjęcia	Sitemap image lastmod	3-14 dni
Usunięcie SKU	301 do kategorii + sitemap usunięcie	7-30 dni

Dla Google Shopping

Feed Merchant Center musi być re-submittowany po zmianie ceny lub availability. Częstotliwość: 3-4 razy dziennie dla sklepów z częstymi zmianami, raz dziennie dla stabilnych katalogów. Szczegółowo w artykule o feedzie Shopping pod AI Overviews.

Obserwowalność pipeline

Bez monitoringu pipeline staje się czarną skrzynką. Minimalny dashboard zawiera sześć metryk:

Throughput – liczba zdarzeń na godzinę.
Lag – różnica między zdarzeniem w źródle a zakończeniem przetwarzania.
Error rate – procent zdarzeń trafiających do DLQ.
Koszt API – dzienny koszt w zł, rozbity per model.
Długość kolejki – liczba oczekujących zadań per priorytet.
Walidacja fail rate – procent aktualizacji odrzuconych w walidacji.

Dashboard w Grafana nad Prometheus lub Metabase nad Postgres. Alert w Slack przy: lag > 30 min, error rate > 5%, koszt API nagły wzrost x2, DLQ > 50.

Pomiar widoczności – czy aktualizacje działają

Stały pipeline daje inny profil pomiaru niż bulk. Zamiast jednorazowego benchmarku przed/po, mierzymy ciągle. Metryki:

Średni czas między dodaniem SKU a pierwszym ruchem organicznym na kartę (median time to first visit).
Procent nowych SKU widocznych w Perplexity w ciągu 30 dni.
Średnia liczba cytowań top 100 SKU tygodniowo.
CTR z SERP dla produktów zaktualizowanych w ciągu ostatniego tygodnia.

Pełna metodyka pomiaru w artykule o pomiarze widoczności sklepu w AI.

Koszt stałego procesu

Pozycja	Koszt miesięczny (1500 SKU, 300 zmian/mies.)
API OpenAI / Anthropic	400-1200 zł
Infrastruktura (worker + kolejka + DB)	300-800 zł
Monitoring i alerty	100-300 zł
Sampling ludzki (2-3% zmian)	1500-3000 zł
Utrzymanie / devops (0,2-0,3 etatu)	4000-8000 zł
Razem	6300-13300 zł/miesięcznie

Dla sklepu z 300 tys zł/miesięcznie przychodu organicznego to 2-4% marży – tzn. koszt marginalny, który zwraca się z samego wzrostu konwersji na zaktualizowanych kartach.

Najczęstsze błędy w stałym pipeline

Brak deduplikacji zdarzeń – te same zmiany przetwarzane 3-4 razy z powodu CDC retry. Rozwiązanie: idempotency key na zdarzeniu (ID + timestamp).
Pełna regeneracja przy drobnej zmianie – akt tylko ceny wywołuje 600 słów przez GPT-4o. Rozwiązanie: granularna reguły decyzyjne.
Brak rollbacku – nowa wersja opisu psuje produkt, brakuje drogi powrotnej. Rozwiązanie: wersjonowanie opisu z datą.
Nadmierne wysyłanie do Indexing API – limit 200 requests/dzień. Rozwiązanie: użycie tylko dla nowych SKU, reszta przez naturalny crawl.
Brak alertów – pipeline „żyje” w ciszy, po miesiącu okazuje się, że 20% zdarzeń leci do DLQ. Rozwiązanie: minimalny dashboard + Slack alerting.
Walidacja tylko syntaktyczna – semantyczne halucynacje przechodzą. Rozwiązanie: porównanie cena/waga/wymiary z polami źródłowymi.
Kolejka bez priorytetów – zmiana ceny nowego SKU czeka za tysiącami low-priority zdarzeń. Rozwiązanie: dedykowane kolejki per priorytet.
Zbyt długi prompt – prompt rośnie z każdą regułą, model zaczyna gubić instrukcje. Rozwiązanie: okresowy audyt i skracanie.

Plan wdrożenia w 8 tygodni

Tydzień 1: audyt obecnej bazy i wybór źródła zmian (webhook / CDC / polling).
Tydzień 2: kolejka, worker szkieletowy, pierwszy prompt.
Tydzień 3: walidator (3 warstwy), integracja z Rich Results API.
Tydzień 4: pilotaż 50 SKU produkcyjnie, monitoring wyników.
Tydzień 5-6: scale do 500 SKU, reguły decyzyjne granularne, dashboard w Grafana.
Tydzień 7-8: Indexing API dla nowych SKU, Merchant Center re-sync, pierwszy cykl pomiaru w LLM.

Dalsze iteracje są incrementalne – dodawanie reguł, poprawa promptu, rozszerzenie na kategorie i strony wsparcia. Miejsce tego pipeline w strategii opisujemy w przewodniku po strategiach AIO i SEO.

Integracja z innymi systemami

Pipeline aktualizacji produktów łączy się z pięcioma systemami. Dobre projekty zachowują granice między nimi – każdy mówi swoim protokołem.

ERP – ceny, stock, dostępność; zwykle REST API lub bezpośrednie połączenie do DB.
PIM – dane produktowe, specyfikacja; webhooki lub polling.
Sklep – docelowa platforma (WooCommerce, Shopify); REST / GraphQL API.
Merchant Center – feed Shopping; Content API for Shopping.
CRM / Marketing – informowanie o nowych produktach; webhook lub sync do platformy mail.

Błędy integracyjne

Najczęstszy problem: ERP i PIM mają inne ID produktu (SKU vs wewnętrzny identyfikator). Mapowanie w DB mapping_table z polami erp_id, pim_id, shop_id. Każdy worker konsultuje mapping przed akcją. Brak mapowania = zatrzymanie zadania i alert do operacji.

Pipeline a rebranding i ponowne nazewnictwo

Gdy produkt zmienia nazwę lub markę, potrzebna jest pełna regeneracja + 301 redirect + komunikacja do Search Console. Pipeline powinien mieć oddzielny tryb „rebranding”:

Stara karta dostaje 301 do nowego URL.
Nowa karta generowana od zera z nową nazwą, historią.
Sitemap: usunięcie starego, dodanie nowego z priorytet 1.0 przez 14 dni.
Search Console: removal starego URL po potwierdzeniu 301.
Merchant Center: replacement produktu w feed.

Rebranding bez tego trybu powoduje 2-4 tygodnie spadku ruchu. Z trybem – spadek 1-5% i odbicie w ciągu 30 dni.

Automatyzacja odpowiedzi na opinie

Pipeline można rozszerzyć o automatyczne generowanie odpowiedzi sklepu na opinie klientów. Model odpowiada na opinię w 1-2 zdaniach w imieniu sklepu (ton ustalony w szablonie). Ludzki redaktor zatwierdza 100% w pierwszym tygodniu, potem 20-30%. Efekt: średni czas odpowiedzi spada z 48 godzin do 30 minut, wskaźnik odpowiedzi rośnie z 30% do 95%. Opinie z odpowiedziami sklepu mają wyższy wskaźnik cytowania w LLM.

Bezpieczeństwo procesu

Automatyczny pipeline to ryzyko operacyjne – jedna błędna aktualizacja może zepsuć 1000 produktów. Trzy zabezpieczenia standardowe: (1) feature flag wyłączający writes do sklepu (kill switch), (2) canary deployment nowej wersji promptu na 1% ruchu przez 24 h, (3) automatyczny rollback gdy error rate przekroczy 10% przez 15 minut. Te trzy mechanizmy chronią katalog przed kaskadowymi awariami. Najlepsze praktyki ograniczania ryzyka w modelach Anthropic opisane są w dokumentacji Anthropic.

Skąd bierze się lag pipeline

Lag to różnica między momentem zmiany w źródle (ERP, PIM) a momentem, w którym zaktualizowana karta produktu pojawia się w sklepie. Składa się z pięciu komponentów.

Lag propagacji zdarzenia – czas od zmiany w DB do pojawienia się w kolejce. Webhook: 1-5 s. Polling: 0-15 min. CDC Debezium: 0,5-3 s.
Lag kolejki – czas oczekiwania na worker. Zależy od długości kolejki i liczby workerów. Typowo 0-60 s przy dobrym tuningu.
Lag generowania – wywołanie modelu AI. GPT-4o-mini: 2-8 s. Claude Haiku: 3-9 s. GPT-4o: 8-20 s.
Lag walidacji – Rich Results API 800-2000 ms plus walidacja własna 100-500 ms.
Lag zapisu – write do DB + invalidation cache + sklep API. 200-800 ms.

Suma: 6-25 sekund w idealnym przypadku, 1-5 minut w warunkach typowych. Lag powyżej 30 minut wskazuje problem i wymaga alertu. Największe oszczędności daje tuning kolejki i workerów – koszt zaniedbany często spada z 30 do 5 minut po jednym sprincie optymalizacji.

Case: pipeline w średnim sklepie AGD

Sklep AGD z 4200 SKU i średnio 40-80 zmian dziennie (ceny, stock, nowe produkty) uruchomił stały pipeline w styczniu 2026. Architektura: Postgres + Debezium + Redis Streams + 4 workery Node.js + OpenAI (GPT-4o-mini + GPT-4o dla top SKU) + walidator z Rich Results API. Łączny czas developmentu: 5 tygodni, zespół 2 inżynierów.

Efekty po trzech miesiącach: średni lag od zmiany do publikacji 8 minut (był 3-5 dni ręcznie), liczba nowych SKU indeksowanych w ciągu 24 h wzrosła z 45% do 96%, ruch organiczny na kart z nowymi produktami +42% w drugim miesiącu po wdrożeniu. Cytowania w Perplexity w zapytaniach „najlepszy X do Y” – produkt pojawia się w 18% zapytań (bazowo 4%).

Co zadziałało

Granularne reguły decyzyjne – 85% zdarzeń to tylko update Offer, co zredukowało koszt API o 78% względem naiwnej regeneracji.
Monitoring w Grafana z 3 alertami w Slack – zespół wychwycił 2 duże incydenty w pierwszym miesiącu (429 na Anthropic, bug w parserze HTML).
Canary na nowych promptach – jeden release cofnięty po 6 godzinach, bo fail rate walidatora wzrósł z 2% do 14%.

Co zawiodło

Pierwsza wersja kolejki bez priorytetów – nowe SKU czekały 4-6 godzin w kolejce z tysiącami aktualizacji stocku. Priorytety rozwiązały problem w jeden sprint.
Walidacja tylko syntaktyczna – dwa tygodnie generowała opisy z niepoprawnymi wagami (model halucynował). Dodanie porównania semantycznego z polami źródłowymi wyeliminowało problem.
Brak deduplikacji – Debezium powtarzał zdarzenia przy restart, pierwsza wersja generowała opis 3 razy. Idempotency key z hash polem source + timestamp rozwiązał.

Wybór między AWS, GCP, Azure

Pipeline mogą hostować wszystkie trzy główne chmury. Dla polskich sklepów najczęstszy wybór w 2026: GCP (dobra integracja z Analytics 4 i Merchant Center), AWS (pełne możliwości SQS + Lambda), Azure (wybór gdy firma ma już kontrakt na licencje Microsoft). Koszt infrastruktury praktycznie identyczny – różnice wynikają z istniejącego ekosystemu, nie ceny.

Alternatywą jest self-hosting na własnym VPS (Hetzner, OVH) – 30-50% tańszy od chmury, ale wymaga administratora sieci i większego wysiłku na HA. Dla stałego pipeline który musi mieć SLA 99,5%+ chmura jest pragmatycznym wyborem mimo wyższego kosztu, ponieważ zdejmuje z zespołu odpowiedzialność za utrzymanie sieci, backup i failover między regionami.

Jak pipeline wpływa na obciążenie bazy

Stały pipeline generuje dodatkowe obciążenie DB: zapisy wersji, read-write do kolejki, walidacja. Dla bazy obsługującej 4000-6000 SKU z 50-80 zmianami dziennie to typowo +15-25% obciążenia. Dobrym wzorcem jest separacja – osobny klaster Redis dla kolejki, osobny Postgres dla historii opisów, głowny sklep DB obciążony tylko odczytami z cache.

Indeksy na tabelach historii: B-tree na (product_id, created_at DESC), GIN na JSON schema jeśli robimy query po polach. Przy 100 000 wierszy historii query „pokaż ostatnie 10 wersji SKU X” wykonuje się w 5-15 ms.

Bezpieczne deployment promptu

Prompt produkcyjny w stałym pipeline jest krytyczną zależnością – jedna wada wpływa na setki nowych aktualizacji dziennie. Proces deploymentu powinien być taki sam jak dla kodu: PR review, testy, canary, monitoring.

Pull request w repozytorium z promptami – nowa wersja przechodzi review przez drugiego członka zespołu.
Testy offline – wersja promptu uruchamiana na zestawie 20-30 zamrożonych przykładów, wynik oceniany przez redaktora.
Canary 1% przez 24 godziny – monitoring: error rate, długość, fail rate walidatora.
Canary 10% przez kolejne 24 godziny jeśli metryki są akceptowalne.
Full rollout z opcją automatycznego rollbacku w ciągu 15 minut jeśli metryki przekraczają progi alarmowe.

Cykl od PR do pełnego deploymentu: 3-5 dni. Dla krytycznych fixów ścieżka szybka (fast-track) do 4-6 godzin z większym monitoringiem.

Koszt utrzymania w dłuższym horyzoncie

Po 6-12 miesiącach pipeline staje się stabilny i koszty się ustają. Typowy profil kosztu dla sklepu 3000-5000 SKU:

API (generowanie + walidacja) – 8-15 tys zł rocznie.
Infrastruktura – 5-10 tys zł rocznie (chmura + monitoring).
Devops (0,15-0,25 etatu) – 40-70 tys zł rocznie.
Sampling redaktorski – 20-35 tys zł rocznie.
Razem – 73-130 tys zł rocznie.

Dla sklepu z przychodem organicznym 2-4 mln zł rocznie to 2-6% budżetu SEO/content. Zwrot: 15-30% wzrost ruchu organicznego i 5-10% wzrost konwersji = 300-800 tys zł przychodu inkrementalnego rocznie. ROI 3-8x w pierwszym roku, dalej rośnie bo koszt stały a przychód kumulatywny.

Rola edytora w stałym pipeline

Automatyzacja nie eliminuje redaktora – zmienia jego rolę. W stałym procesie redaktor przestaje pisać opisy, a zaczyna nadzorować jakość. Typowy podział obowiązków:

Sampling QA – 2-3 godziny tygodniowo na przegląd losowych 30-50 aktualizacji.
Refinement promptu – 4-6 godzin miesięcznie na aktualizacje szablonu.
Ręczne kuratorskie edycje – 2-4 godziny tygodniowo na top SKU, gdzie AI nie daje rady.
Feedback dla devops – zgłaszanie bugów, propozycje nowych reguł.

Łącznie 1-2 dni tygodniowo dla sklepu 3000-5000 SKU. Role edytora jest kluczowa – bez człowieka w pętli pipeline traci jakość po 6-9 miesiącach. Model się nie starzeje, ale prompt tak – zmiany w trendach, produktach, regulacjach wymagają refreszu.

Wersjonowanie opisów i rollback

Każda aktualizacja powinna zapisywać poprzednią wersję opisu z timestampem i autorem („ai-pipeline-v2.3”). Tabela product_description_history z polami product_id, version, content, schema_json, prompt_version, created_at, applied_at. Rollback sprowadza się do podmiany wersji w tabeli głównej i invalidacji cache.

Retencja historii: 90-180 dni dla sklepu B2C, 365 dni dla B2B lub regulowanej branży. Przy 5000 SKU i średnio 15-20 wersjach rocznie to 100-300 MB – koszt storage pomijalny.

Diff i porównanie wersji

Przy rollbacku lub debugu potrzebny jest czytelny diff między wersjami. Biblioteka diff-match-patch (dostępna dla JS i Python) generuje HTML diff w 100-300 ms. Diff pokazujemy w panelu adminów – 5 sekund debugu i redaktor wie, co zmienił pipeline.

Pipeline a sezonowe kampanie

Black Friday, święta, sezon letni – w tych okresach katalog zmienia się 5-10 razy szybciej. Pipeline musi to udźwignąć. Dwa sposoby skalowania:

Horyzontalne – zwiększenie liczby workerów z 4 do 12-20 na czas kampanii.
Prioryteyzacja – drobne zmiany stocku przechodzą w trybie „best effort”, priorytet dla nowych kolekcji.

Testy obciążeniowe przed kampanią są standardem – symulacja 500-1000 zdarzeń/minutę przez 30 minut pokazuje, czy architektura wytrzyma szczyt. Ostatnie Black Friday u dużych sklepów dały 300-600 aktualizacji na minutę w godzinach szczytu.

FAQ – najczęstsze pytania

Czy można zacząć od polling zamiast CDC?

Tak, dla sklepów poniżej 3000 SKU polling co 15-30 minut jest wystarczający. CDC ma sens przy 5000+ SKU i krytycznym czasie reakcji poniżej 5 minut. Polling jest prostszy w implementacji (1-2 dni) i mniej ryzykowny.

Co, jeśli sklep nie ma PIM?

Polskie sklepy często pracują bez PIM. Źródłem prawdy jest wtedy sam sklep (WooCommerce, Shopify) albo ERP. Pipeline traktuje panel admin sklepu jako PIM i nasłuchuje na webhooki. To uproszczenie, które działa do 10 000 SKU. Powyżej tego progu PIM staje się nieodzowny.

Jak często regenerować opisy produktów bez powodu?

Nigdy bez powodu. Pełna regeneracja bez zmian w danych = marnowanie budżetu API i ryzyko halucynacji. Wyjątek: okresowy refresh raz na 12-18 miesięcy, gdy prompt się znacząco rozwinął. Wtedy regenerujemy w trybie bulk, nie w stałym procesie.

Czy można używać jednego pipeline dla wielu sklepów?

Tak, multi-tenant architecture jest standardem dla agencji i grup e-commerce. Każdy sklep ma własny namespace w kolejce, własny prompt, własny monitoring. Shared: infrastruktura (kolejka, workery, DB). Oszczędność kosztu devops: 60-70% przy 5+ sklepach.

Jak obsłużyć produkt sezonowy?

Produkty sezonowe (choinki, kostiumy halloween, grille) mają cykl widoczności – są sprzedawane 2-3 miesiące w roku. Pipeline powinien mieć flag „seasonal” i priorytet wysoki na początku sezonu (re-indeksacja + Indexing API + social ping). Poza sezonem karty pozostają bez zmian, ale dostępne.

Czy generowanie ma być synchroniczne czy asynchroniczne?

Zawsze asynchroniczne. Synchroniczne generowanie blokuje wątek API i nie skaluje się powyżej 10-20 SKU/min. Asynchroniczne z kolejką skaluje się do tysięcy. Wyjątek: ręczny edit w panelu administracyjnym, gdzie sklep operator chce natychmiastowy podgląd – tam synchroniczne wywołanie do GPT-4o-mini jest akceptowalne.

Jak testować nową wersję promptu bez ryzyka?

Canary deployment. Nowa wersja jest stosowana na 1-5% losowych zdarzeń przez 24-48 godzin. Mierzymy: error rate, długość opisów, fail rate walidatora. Jeżeli wskaźniki są lepsze lub równe, rollout na 100%. Jeżeli gorsze – automatyczny rollback i post-mortem.

Co z integracją z Analytics?

Pipeline powinien wysyłać event do Google Analytics 4 przy każdej aktualizacji produktu: event_name=product_update, custom_params={sku, change_type, timestamp}. To pozwala skorelować zmiany w produktach z wynikami w ruchu organicznym. Raport w GA4 „Zmiany produktów vs ruch” daje konkretne insights po 4-8 tygodniach.

Co dalej

Gdy stały pipeline działa dla opisów produktów, rozszerz go na opisy kategorii i feed Shopping pod AI Overviews. Efekt całościowy zbiera się w przewodniku SEO dla e-commerce.