Dlaczego łączę OpenAI z n8n właśnie przy opisach produktów

Pierwszy raz zderzyłam się z problemem opisów produktów przy wdrożeniu dużego sklepu z elektroniką na WooCommerce. Na spotkaniu w biurze klienta na Domaniewskiej marketing pokazał mi excela z kilkuset SKU i pytanie: „Marta, a ile osób musimy zatrudnić, żeby to ogarnąć w dwa tygodnie?”. Wtedy po raz kolejny uświadomiłam sobie, że ręczne pisanie opisów na masową skalę po prostu przestaje mieć sens.

Integracja OpenAI z n8n daje w tym obszarze dokładnie to, czego takiemu zespołowi brakowało: automatyczne, powtarzalne procesy tam, gdzie wcześniej królował chaos. Modele językowe, takie jak GPT‑4 czy gpt‑4o‑mini, potrafią wygenerować sensowne, sprzedażowe opisy z ogromnych tabel danych produktowych. A n8n zapewnia kręgosłup całej operacji – od pobrania danych z WooCommerce czy Shopify, przez wysłanie ich do OpenAI, aż po aktualizację opisów w sklepie.

Przy setkach SKU dziennie ręczne pisanie treści to nie tylko duży koszt, ale też ryzyko niespójnego stylu, błędów i zwykłego ludzkiego zmęczenia. W dobrze zaprojektowanym workflow w n8n nadzór nad partią około 200 produktów naprawdę można sprowadzić do kilku minut. Resztą zajmują się roboty.

Dla mto nie jest „magia AI”. zdrowy rozsądek: ludzie zajmują się strategią, kreacją i decyzjami biznesowymi, a algorytmy robią żmudną, powtarzalną robotę.

Co naprawdę zyskujesz, automatyzując 200 opisów naraz

Kilka miesięcy temu w jednej z hurtowni z branży beauty w Sosnowcu policzyłyśmy z właścicielką, ile realnie kosztuje ją ręczne pisanie opisów. Copywriter potrzebował około 20 minut na jeden produkt. Przy większych dostawach lista do „obrobienia” puchła do kilkuset SKU.

Przyjmijmy coś prostego: jeśli opis jednego produktu zajmuje 15–30 minut, to przy 200 SKU robi się z tego kilkadziesiąt godzin pracy. I to przy założeniu, że wszyscy mają dobry dzień i nikt nie myli modeli czy pojemności.

Automatyzacja tego procesu z OpenAI i n8n odwraca proporcje:

  • czas zespołu przenosi się z pisania na nadzór i korekty,
  • wdrożenie nowych produktów nie blokuje się na „copywriter ma opóźnienie”,
  • styl komunikacji pozostaje spójny, bo wynika z jednego, dobrze przemyślanego promptu,
  • SEO przestaje być „doklejką” – staje się wbudowanym elementem całego procesu.

Przy 200 SKU zaczyna być dobrze widać efekt skali: raz zbudowany workflow można uruchamiać wielokrotnie, a dopracowany system promptu i struktura danych pracują dla ciebie każdego dnia.

Dane produktowe: fundament, którego nie widać na pierwszy rzut oka

Największy skok jakości w opisach nie wydarzył się u mnie wtedy, gdy przeszłam z GPT‑3.5 na GPT‑4. Paradoksalnie – poprawa była większa, gdy zaczęłam przed OpenAI porządnie „myć” dane w n8n.

Przy jednym z projektów magazyn z częściami samochodowymi miał w bazie takie kwiatki w nazwach jak „SUPER PROMO!!!”, stare kody dostawców i pomieszane jednostki. Gdy przepuściłam te dane bezpośrednio przez model, opisy były poprawne językowo, ale kompletnie nieskalibrowane: mieszały np. litry z mililitrami, a w nazwach pojawiały się śmieciowe dopiski z ERP.

W praktyce przygotowanie danych oznacza kilka rzeczy:

  • ID / SKU, nazwa, kategoria, kluczowe parametry – wszystko musi być uzupełnione i w tej samej logice,
  • w n8n opłaca się dodać etap pre‑czyszczenia: usuwanie śmieci z nazw, unifikacja jednostek, poprawianie prostych błędów,
  • dobrze sprawdzają się arkusze Google Sheets lub CSV jako warstwa pośrednia – łatwo tam coś zmienić, zanim trafi do API sklepu.

Zauważyłam, że taka warstwa „higieny danych” wyciąga jakość opisów bardziej niż sama zmiana modelu. Ładniejszy model na brudnych danych po prostu elegancko opisuje bałagan.

Dobrze przygotowane dane mają jeszcze jeden efekt uboczny: znika masa mikropoprawek po stronie zespołu. Zamiast poprawiać literówki w nazwach, można wreszcie skupić się na tym, czy opis faktycznie sprzedaje.

Jak układa się architektura: n8n jako kręgosłup ekosystemu AI

W jednym z projektów dla sklepu meblowego w Gdańsku zaczynaliśmy od bardzo prostej integracji OpenAI. Skończyło się na rozbudowanym ekosystemie, który korzystał jednocześnie z GPT‑4, Google Vision i wewnętrznego modelu open‑source zainstalowanego na serwerze klienta. Wszystko spięte w n8n.

Rdzeń wygląda zwykle podobnie:

  • dedykowany node OpenAI w n8n – tu wybieram model (GPT‑4 lub gpt‑4o‑mini), ustawiam parametry i pracuję na roli systemowej oraz user promptach,
  • HTTP Request w n8n – dzięki temu mogę wpiąć prawie każde API: Azure OpenAI, Google AI (Gemini), AWS Comprehend, Google Vision, Rekognition, Textract i inne,
  • opcjonalnie – self‑hosted modele open source, jeśli firma nie chce wypuszczać części danych na zewnątrz.

Kluczową rzeczą, którą zawsze ustawiam, jest stały node z System Prompt. Traktuję go jak globalny „kodeks stylu” dla sklepu. Dzięki temu, jeśli klient po pół roku stwierdzi, że chce bardziej konkretny ton albo inne podejście do SEO, zmieniam to w jednym miejscu, a nie w kilkunastu workflowach. Rozrzut jakości między SKU od razu się zmniejsza.

Coraz częściej dokładam też do system promptu dwie rzeczy: krótką, unikalną propozycję wartości sklepu i opis typowego klienta (np. „kupujący to właściciele małych warsztatów na terePolski, którzy szukają niezawodnych. niekoniecznie najtańszych rozwiązań”). To jedno z tych ustawień, które „niby kosmetyczne”, a nagle opisy przestają być tylko poprawne językowo i zaczynają realnie sprzedawać.

Workflow dla 200 SKU – jak to układam krok po kroku

W jednym z projektów dla sklepu na Shopify właścicielka z Białegostoku poprosiła mnie, żebym „zrobiła to tak, żeby jak padnie internet, to nie trzeba było zaczynać od zera”. To dobre podsumowanie tego, jak myślę o workflow: ma wytrzymać potknięcia i dać się łatwo wznowić.

Typowa ścieżka dla około 200 SKU wygląda u mnie tak:

  1. Trigger – zwykle planowane uruchomienie (Schedule) raz dziennie lub po dodaniu nowych produktów. W krytycznych sytuacjach dokładam Webhook, żeby można było odpalić proces „na żądanie”.
  2. Pobranie danych – najczęściej z API sklepu (WooCommerce, Shopify, PrestaShop) albo z arkusza Google. W tym miejscu często od razu odcinam niepotrzebne pola, żeby nie pompować tokenów.
  3. Pre‑czyszczenie danych w n8n – JavaScript/Function Node do usuwania śmieci z nazw, normalizacji jednostek, porządkowania kategorii.
  4. Loop Over Items – każdy produkt leci osobno. Przy większych batchach dokładam batchowanie i retry, żeby nie wpaść w limity API i timeouty.
  5. OpenAI node – tu generuję szkic opisu. Świadomie piszę „szkic”, bo bardzo często dopinam stałe bloki (np. informacje o dostawie, gwarancji, instrukcjach) już w n8n, zamiast każdorazowo prosić o nie model. To zmniejsza koszty i ułatwia A/B testy.
  6. Walidacja i zapis – w zależności od ustaleń ze sklepem: zapis jako „Szkic” w WooCommerce/Shopify, zapis do bazy lub do arkusza do dalszej weryfikacji.

Przy takim podejściu większość problemów technicznych przy 200 SKU wynika z limitów API, a nie z n8n. Dlatego tak duży nacisk kładę na batchowanie, retry i zapisywanie postępu. Jeśli workflow padnie w połowie, chcę mieć możliwość wznowienia od konkretnej partii, a nie od początku.

Jak konfiguruję OpenAI w n8n, żeby model „mówił jak marka”

Kiedy siedziałam nad pierwszą wersją promptu dla sklepu z odzieżą outdoorową, mieliśmy spór o jedno zdanie w system prompt: czy wolno modelowi zgadywać brakujące dane. Właściciel uparł się, że ma „wrażliwych” klientów i nie może być mowy o jakichkolwiek domysłach. I miał rację.

W konfiguracji node’a OpenAI trzy rzeczy robią największą różnicę:

  1. System Prompt jako stały punkt odniesienia
    Traktuję go jak instrukcję dla nowej osoby w dziale contentu. W tym miejscu:

    • definiuję rolę (np. „doświadczona copywriterka e‑commerce specjalizująca się w AGD”),
    • opisuję styl (konkretny, bez marketingowej piany, po polsku),
    • dodaję zasady bezpieczeństwa (np. „jeśli brakuje danych technicznych, napisz wprost, że nie są dostępne i nie zgaduj parametrów”).

    Bardzo pomaga umieszczenie kilku idealnych, realnych opisów po polsku z danej kategorii. Modele lepiej łapią idiomy, rytm języka i poziom szczegółowości.

  2. User Prompt – mniej „lista słów kluczowych”, więcej intencji
    Zauważyłam, że modele lepiej reagują na opis intencji SEO niż na surową listę fraz. Zamiast:

    „Użyj fraz: ‘piekarnik do zabudowy’, ‘piekarnik energooszczędny’…”

    piszę raczej:

    „Opis ma pomóc osobie szukającej energooszczędnego piekarnika do zabudowy, która porównuje 2–3 modele i boi się ukrytych kosztów użytkowania.”

    To znacząco zmniejsza ryzyko keyword stuffing i poprawia konwersję.

  3. Model i structured output

    • przy dużych wolumenach chętnie korzystam z gpt‑4o‑mini – bardzo dobry stosunek jakości do ceny,
    • tam, gdzie opis ma być „bardziej premium” (np. marka własna klienta), włączam GPT‑4,
    • przy bardziej złożonych scenariuszach używam structured output / function calling, żeby dostać np. osobno: nagłówek, lead, opis główny, bullet‑pointy, meta title, meta description.

Modele mają tendencję do dorabiania brakujących parametrów, jeśli im tego nie zabronimy. Dlatego często stosuję dwuetapowy schemat: najpierw proszę model o zidentyfikowanie braków i ich wypisanie, dopiero potem o wygenerowanie właściwego opisu z jasnym wymogiem, że tam, gdzie nie ma danych, ma to napisać wprost.

Jak zadbać o unikalność i SEO bez odklejania się od rzeczywistości

W jednym z marketplace’ów z elektroniką w Krakowie poproszono mnie o przejrzenie opisów wygenerowanych przez „gotową wtyczkę AI”. Na wejściu wyglądało to dobrze, ale po kilku produktach zaczęliśmy z zespołem widzieć powtórzenia całych akapitów. Robot pisał poprawnie, lecz „taśmowo”.

Żeby tego uniknąć, ustawiam kilka zasad:

  • jakość danych wejściowych – im lepiej opisane parametry, tym mniej pokusy, żeby model nadrabiał „kreatywnością”,
  • System Prompt z wyraźnym zakazem zgadywania i zachętą do przyznawania się do braku danych,
  • podział produktów na rodziny: najpierw generuję opis dla rodziny (np. seria laptopów), zapisuję go i wykorzystuję jako kontekst przy pojedynczych SKU. Dzięki temu opisy przestają być kopiami z wymienionymi cyferkami w nazwie modelu,
  • ustawienie workflow tak, by opisy trafiały do sklepu jako Szkic – zespół może przelecieć najważniejsze produkty i złapać ewentualne wpadki, zanim zobaczy je klient.

W praktyce zwykle dzielę asortyment na dwie grupy: większość produktów leci w pełni automatycznie, a około jednej piątej – kluczowe, najbardziej dochodowe SKU – dostaje dodatkową, ludzką weryfikację. Ta proporcja bardzo często daje najlepszy balans między czasem a jakością.

Koszty, tokeny i gdzie naprawdę „ucieka” budżet

Kiedy w jednym z projektów klient z Wrocławia zapytał mnie, „czy ten GPT nie zje nam budżetu marketingowego w miesiąc”, usiadłyśmy razem przy jego panelu OpenAI i zaczęłyśmy rozbierać koszty na czynniki pierwsze.

Dla batcha około 200 SKU wygląda to zwykle tak:

  • na jeden produkt przypada w praktyce mniej więcej 1000–1500 tokenów (prompt + odpowiedź),
  • czyli dla 200 produktów mówimy o łącznym zużyciu w okolicach 200–300 tys. tokenów,
  • przy ekonomicznym modelu pokroju gpt‑4o‑mini cały batch potrafi zmieścić się poniżej jednego dolara,
  • czas generowania: pojedynczy request to zwykle ułamek sekundy do kilku sekund, więc cały batch spokojnie zamyka się w kilku minutach, zwłaszcza gdy n8n robi równoległe wywołania.

Prawdziwy koszt często wynika z samego pisania opisów. z:

  • przesyłania ogromnych JSON‑ów z kompletnymi danymi technicznymi,
  • dorzucania całej historii promptów przy każdym wywołaniu.

Dlatego w dobrze zaprojektowanym workflow:

  • wyciągam tylko potrzebne pola (nazwę, kluczowe parametry, kategorie, kilka tagów SEO),
  • trzymam historię po stronie n8n, a nie w każdym kolejnym wywołaniu do API,
  • stałe fragmenty tekstu (np. sekcje o dostawie, gwarancji) dokładam już po stronie n8n.

Taki układ znacząco zmniejsza liczbę tokenów i przy okazji porządkuje strukturę opisów.

Bezpieczeństwo, limity i obsługa błędów – o czym zawsze mówię klientom

W jednym z pierwszych projektów na n8n popełniłam błąd, którego długo nie zapomnę: puściłam dużą partię produktów bez sensownego retry i bez zapisu postępu. W połowie procesu API klienta zaczęło odpowiadać błędami, a my nie wiedzieliśmy, które produkty są już zaktualizowane, a które nie. Od tamtej pory uczę się na cudzych błędach, ale tamten był mój własny.

Dziś robię to tak:

  • klucz OpenAI trzymam wyłącznie w credentials n8n, z odpowiednimi uprawnieniami,
  • limity API od samego początku biorę pod uwagę w projekcie – lepiej mieć dwa spokojne przebiegi po 100 SKU niż jeden nerwowy na 500,
  • w node’ach OpenAI i HTTP Request ustawiam odpowiednią obsługę błędów (np. On Error → Continue), tak żeby pad jednego produktu nie zatrzymał całej partii,
  • workflow zapisuje status przetwarzania – nawet jeśli serwer n8n się zrestartuje, wiem, od którego miejsca kontynuować.

Jeśli chodzi o wrażliwe dane: w typowym scenariuszu opisów produktowych mówimy o parametrach technicznych, więc ryzyko jest relatywnie niewielkie. W przypadku informacji, które klient uznaje za poufne, częściej sięgam po modele self‑hosted lub rozwiązania typu Azure OpenAI z bardziej granularnymi ustawieniami prywatności.

Wielojęzyczność, inne usługi AI i dalsza rozbudowa

W jednym z moich ulubionych projektów – sklepie z wyposażeniem gastronomicznym, który sprzedaje do Niemiec i Czech – największym bólem były opisy w trzech językach. Zespół w Warszawie pisał tylko po polsku, a reszta szła do zewnętrznej agencji.

Po wdrożeniu automatyzacji workflow wyglądał mniej więcej tak:

  • generacja głównego, polskiego opisu w OpenAI,
  • dodatkowe wywołania do DeepL/Google Translate przez HTTP Request w n8n dla innych języków,
  • lokalne korekty tylko przy najbardziej strategicznych produktach.

n8n nie ogranicza się jednak do samych tłumaczeń. Bez większego problemu dokładam:

  • analizę treści w Google Cloud Natural Language czy AWS Comprehend – np. do automatycznego tagowania,
  • analizę obrazów przez Google Vision czy AWS Rekognition – by wyciągać dodatkowe informacje z fotografii produktu,
  • integrację z narzędziami analitycznymi (np. dane o CTR, czasie na stronie) i wykorzystanie ich jako kontekstu do późniejszych optymalizacji opisów.

Po pewnym czasie naturalnym krokiem jest wprowadzenie prostych AI Agentów, którzy np. raz na miesiąc sprawdzają skuteczność opisów (wejścia, konwersje, odrzucenia), zgłaszają anomalie i proponują nowe warianty treści do testów.

Najczęstsze pytania, które słyszę przy takich wdrożeniach

Na warsztatach z jednym zespołem w Katowicach spisałam na tablicy pytania, które padły w ciągu pierwszej godziny. Do dziś prawie nic się nie zmieniło – w innych firmach słyszę właściwie to samo:

  • „Czy musimy umieć programować?” – do podstawowych workflowów wystarczy znajomość logiki procesów i chęć do klikania w n8n. JavaScript przydaje się przy bardziej zaawansowanych transformacjach, ale to raczej etap drugi.
  • „Czy OpenAI zapamięta nasze dane?” – domyślnie dane z API nie są używane do trenowania modeli, a w planach biznesowych można włączyć dodatkowe ograniczenia. W opisach produktów i tak rzadko mówimy o czymś naprawdę wrażliwym.
  • „Czy możemy to mieć w kilku językach?” – tak, i to wieloma ścieżkami: przez sam OpenAI, przez dedykowane API tłumaczeniowe, albo hybrydowo (np. polski → model, inne języki → tłumaczenie tego, co wygenerował).
  • „Czy da się to zrobić etapami?” – jak najbardziej. Często zaczynamy od prostego workflowu na 20–50 SKU, patrzymy na efekty, dopiero potem przeskakujemy na 200 i więcej.

Od 200 SKU do pełnej automatyzacji – jak do tego podchodzę w praktyce

W jednym z niedawnych projektów klient na Shopify zaczął od jednorazowego batcha 200 SKU „na próbę”. Po miesiącu rozmawialiśmy już o automatycznych aktualizacjach opisów przy każdej zmianie parametrów w ERP, integracji z kampaniami reklamowymi i testach A/B różnych wariantów treści.

Te 200 produktów to świetny próg wejścia:

  • wystarczająco dużo, żeby wychwycić realne problemy (limity, jakość danych, błędy w schemacie),
  • wystarczająco mało, żeby ewentualne poprawki dało się wprowadzić bez paraliżowania sklepu.

Jeśli masz sklep na WooCommerce, Shopify czy PrestaShop, taki projekt zwykle rozkłada się na dwie fazy:

  1. Budowa i testy workflow – kilka–kilkanaście godzin pracy: integracje, prompty, czyszczenie danych, obsługa błędów.
  2. Stała eksploatacja i rozwój – minimalny nadzór przy każdym batchu, a równolegle stopniowa rozbudowa: inne języki, więcej kategorii, integracje z analityką.

Automatyzacja opisów produktów z wykorzystaniem n8n i OpenAI to z mojego punktu widzenia przede wszystkim inwestycja w skalowalność. Raz zbudowana architektura pracuje dalej, kiedy ty zajmujesz się już kolejnymi obszarami – kampaniami, marżami, nowymi rynkami. I tu właśnie widać tę symbiozę ludzkiej kreatywności z algorytmiczną precyzją, o której często mówię: człowiek ustawia kierunek, a maszyny dbają, żeby każdy kolejny SKU dostał opis na odpowiednim poziomie.