Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Opisy produktów to w większości sklepów, które audytuję, najbardziej zaniedbany element całego serwisu. Nie dlatego, że nikt ich nie napisał — zwykle są. Dlatego, że napisano je jako wypełnienie miejsca pod zdjęciem, bez pojęcia, kto i po co będzie je czytał.
W ostatnich kilkunastu miesiącach zrobiło się to bardziej kosztowne niż wcześniej. Ten sam tekst trafia dziś nie tylko do klienta na karcie produktu, ale też do pliku produktowego, z którego korzystają kampanie, i do systemów, które streszczają oferty i wybierają, co pokazać jako odpowiedź. Trzy różne odbiory, jeden tekst.
Nie uważam, że trzeba pisać trzy wersje. Uważam, że wystarczy zmienić kolejność: najpierw sprawdzalne fakty, potem argumenty sprzedażowe. Poniżej rozbieram to na części, z uwagami o tym, gdzie najczęściej widzę błędy.
Pierwszy odbiorca to człowiek z konkretnym pytaniem. Czy to pasuje do mojego sprzętu, czy zmieści się w tej przestrzeni, czy nadaje się do zmywarki, ile to waży, jak długo poczekam. Kupujący nie czyta opisu jak artykułu — skanuje go w poszukiwaniu jednej informacji, która zdecyduje.
Drugi to plik produktowy i system reklamowy, który go czyta. Tu opis pełni funkcję źródła danych: dopasowuje ofertę do zapytań, których nie ma w tytule produktu, i uzupełnia atrybuty, jeśli nie podano ich osobno.
Trzeci to systemy generujące odpowiedzi, w tym podsumowania w wyszukiwarce, obecne w polskich wynikach od marca. One niczego nie kupują, ale wybierają, co streścić. A streścić da się tylko to, co jest w tekście napisane jednoznacznie. „Wysoka jakość wykonania” nie jest informacją, którą można zacytować. „Korpus ze stali nierdzewnej 0,8 mm” — jest.
Dobra wiadomość: te trzy zestawy potrzeb prawie się nie kłócą. Wszystkie trzy nagradzają konkret i karzą lanie wody.
Zaczynam od jednego zdania, które mówi, co to jest i dla kogo. Bez nazwy marki na początku, bez przymiotników. Człowiek, który trafił z wyszukiwarki na kartę produktu, musi w ciągu sekundy potwierdzić, że jest w dobrym miejscu.
Potem idzie blok najważniejszych parametrów w formie listy — te, które faktycznie decydują o wyborze w danej kategorii, a nie wszystkie dostępne. Przy fotelu biurowym to nośność, zakres regulacji i rodzaj tapicerki, nie kolor śrub. Ten blok jest jednocześnie najłatwiejszy do zacytowania i najczęściej czytany przez ludzi.
Dalej rozwinięcie: zastosowania, ograniczenia, z czym współpracuje, czego nie obsługuje. Tutaj mieści się perswazja, bo tutaj można pokazać, że rozumiemy problem klienta. Ale nadal w formie „nadaje się do…”, nie „to najlepszy wybór dla…”.
Na końcu odpowiedzi na pytania, które i tak przyjdą mailem albo przez czat: dostawa, zwrot, gwarancja, zgodność. Ta część jest najczęściej pomijana, a to ona najbardziej pomaga w kategoriach, gdzie klient się waha.
To najprostsza zasada redakcyjna, jaką znam dla sklepów: każde zdanie opisu powinno dać się zweryfikować. Jeśli nie da się sprawdzić, czy jest prawdziwe, prawdopodobnie nic nie znaczy.
Konsekwencją jest przeniesienie danych z opisu w miejsca, w których należą. Jeśli produkt ma numer GTIN, markę, materiał, rozmiar, kolor i grupę wiekową, to powinny być wypełnione jako osobne atrybuty w pliku produktowym, a nie tylko wspomniane w zdaniu. Ta różnica jest istotna: atrybut jest jednoznaczny, zdanie trzeba interpretować.
Osobno pilnuję znaczników danych strukturalnych typu Product na karcie produktu — cena, dostępność, waluta, identyfikatory, oceny, jeśli są prawdziwe. Warunek jest jeden i niepodlegający dyskusji: dane w znacznikach, w pliku produktowym i na widocznej stronie muszą się zgadzać. Rozjazd między nimi to najczęstsza przyczyna odrzuceń ofert, jaką widzę w Merchant Center, i jednocześnie sygnał niespójności dla każdego systemu, który tę stronę czyta.
Warto też pamiętać o polityce zwrotów. Od roku można ją podać raz dla całego sklepu w znaczniku organizacji, zamiast powtarzać przy każdym produkcie, a jeśli sklep ma konto sprzedawcy, to tam pozostaje zalecane miejsce. To detal, który przy dużym asortymencie oszczędza sporo pracy.
Tych dwóch rzeczy nie należy mieszać i widzę tu dwa błędy w równych proporcjach.
Pierwszy: identyczny tekst wysyłany w oba miejsca, razem ze znacznikami HTML, wypunktowaniem i wezwaniem do działania. Pole opisu w pliku produktowym nie jest miejscem na treści promocyjne — bez tekstu o darmowej dostawie, bez wersalików, bez informacji o rabacie. Takie oferty są odrzucane albo, co gorsza, ograniczane bez wyraźnego komunikatu.
Drugi: pole opisu w pliku wypełnione jednym zdaniem, bo „i tak nikt tego nie czyta”. Czyta to system dopasowujący ofertę do zapytania. Limit jest wysoki, więc nie ma powodu, żeby wysyłać tam ogryzek. Zaczynam od najważniejszych informacji, bo koniec długiego opisu ma mniejsze znaczenie.
Praktycznie robię to tak: piszę pełny opis na stronę, a do pliku trafia jego wersja bez formatowania i bez treści marketingowych, ułożona od najbardziej konkretnych informacji. Jeśli sklep generuje plik automatycznie z opisu na karcie, warto sprawdzić, co dokładnie się w nim ląduje — bardzo często wraz z tekstem przechodzi cała nawigacja i stopka.
Nie udaję, że przy asortymencie liczonym w tysiącach pozycji ktoś napisze wszystko ręcznie. Sam używam narzędzi do tekstu, ale w wąskim zakresie: do przeredagowania istniejących danych producenta, do ujednolicenia formy w obrębie kategorii i do przygotowania szkieletu, który potem uzupełniam faktami.
Granica, której nie przekraczam, jest prosta. Generator nie może być źródłem faktów o produkcie. Wszystkie parametry pochodzą z karty producenta albo z pomiaru, nie z modelu, który potrafi je uzupełnić na podstawie prawdopodobieństwa. Wymyślony wymiar w opisie to nie problem SEO, to zwrot towaru i reklamacja.
Druga granica dotyczy skali. Zasady Google od marca 2024 roku wyraźnie obejmują masowo produkowaną treść tworzoną bez wartości dla użytkownika i były egzekwowane. Sześćset opisów zbudowanych z tego samego szablonu, w których zmienia się tylko nazwa modelu, wpisuje się w to wprost. Samo korzystanie z narzędzi nie jest problemem — wytyczne jasno mówią, że liczy się jakość i przydatność wyniku, a nie sposób jego powstania.
Trzecia rzecz to redakcja. Każdy wygenerowany opis w moim procesie przechodzi przez człowieka, który zna kategorię. Nie po to, żeby poprawić język, ale żeby wyłapać zdania, które brzmią dobrze i nic nie znaczą.
Nie zmieniam całego katalogu naraz, bo wtedy nie da się niczego wywnioskować. Biorę jedną kategorię, przepisuję ją w całości i zostawiam pozostałe jako punkt odniesienia.
Patrzę potem na trzy źródła. W Search Console na zapytania, które prowadzą do kart produktów w tej kategorii — czy pojawiają się nowe, bardziej szczegółowe, i czy rośnie liczba wyświetleń. W wewnętrznej wyszukiwarce sklepu na to, czego ludzie szukają po wejściu na kartę, bo to lista informacji, których w opisie zabrakło. I w kontakcie z klientem — powtarzające się pytania przed zakupem są najtańszym możliwym audytem opisów.
Do tego wskaźnik, o którym łatwo zapomnieć: liczba zwrotów w kategorii. Opis, który obiecuje więcej, niż produkt daje, podnosi konwersję i zwroty jednocześnie. To pozorna wygrana.
Kolejność ustalam po pieniądzach, nie po literach. Najpierw produkty, które generują najwięcej ruchu i marży, potem te, które mają dużo wyświetleń przy niskiej konwersji — bo tam opis jest najbardziej prawdopodobnym winowajcą. Na końcu długi ogon, i to zwykle w formie uporządkowanych szablonów zasilanych prawdziwymi danymi, a nie tekstów pisanych od zera.
Przy okazji porządkuję kategorie, bo opis produktu nie działa w oderwaniu od struktury. Jeśli na stronie kategorii nie ma żadnego wprowadzenia, a filtry generują setki niemal identycznych adresów, najlepsze opisy pojedynczych produktów tego nie naprawią.
Ostatnia uwaga, z doświadczenia: raz napisany opis nie jest gotowy na zawsze. Producenci zmieniają specyfikacje, zestawy się rozjeżdżają, zniknięcie jednego wariantu unieważnia zdanie o zgodności. Wpisuję więc do procesu prosty przegląd — przy każdej zmianie ceny albo dostawy sprawdzam, czy opis wciąż mówi prawdę. Nudne, ale to jedyna część tej pracy, która chroni przed najgorszym scenariuszem: sklepem, który obiecuje coś, czego nie sprzedaje.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |