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.
Przez lata karta produktu w sklepie była projektowana pod jedno wejście: ktoś wpisuje frazę w okno wyszukiwania, klika w wynik i trafia na stronę. Cała optymalizacja polegała na dopasowaniu treści do słów, których ten ktoś użył.
To wejście nie zniknęło, ale przestało być jedynym. Użytkownik telefonu może zrobić zdjęcie buta i zapytać o podobne modele, zaznaczyć fragment ekranu w trakcie przeglądania czegoś innego, nagrać krótkie wideo z pytaniem albo zadać pytanie głosem, pełnym zdaniem, jakby rozmawiał z człowiekiem. Od końca marca w wynikach po polsku pojawiają się też odpowiedzi generowane przez AI, które składają informacje z kilku stron naraz — to zmiana sprzed kilku dni, więc na wnioski jest jeszcze za wcześnie.
Wspólny mianownik tych sposobów jest jeden: w punkcie wyjścia nie ma frazy kluczowej. Jest obraz, dźwięk albo zdanie, które trzeba dopiero na coś przetłumaczyć. Ten wpis jest o tym, co z tego wynika dla konstrukcji karty produktu — nie o samych zdjęciach, bo o ich przygotowaniu piszę oddzielnie.
Warto oddzielić to, co działa, od zapowiedzi, bo w tej dziedzinie jedno miesza się z drugim wyjątkowo chętnie.
Działa rozpoznawanie obiektów ze zdjęcia i pokazywanie zbliżonych produktów wraz z ceną, informacją o promocji i opiniami — czyli funkcja, którą w praktyce większość osób zna z aparatu w telefonie. Działa zaznaczanie fragmentu tego, co widać na ekranie, i szukanie na jego podstawie bez wychodzenia z aplikacji. Działa też, od zeszłej jesieni, zadawanie pytania nagranym krótkim materiałem wideo. Działa wyszukiwanie głosowe, w praktyce od lat, tylko dziś częściej w formie pełnego pytania niż hasła.
Ostrożniej podchodziłbym do wnioskowania, że to wszystko już przekłada się na dużą część sprzedaży. Nie mam narzędzia, które pozwoliłoby mi ten udział zmierzyć — piszę o tym w ostatniej sekcji — więc opieram się wyłącznie na rozmowach z klientami i na tym, w których kategoriach w ogóle widać ruch z wyników graficznych: moda, wnętrza, części zamienne, rośliny.
Traktuję to więc nie jako zwrot, na który trzeba natychmiast przebudować sklep, ale jako kierunek, który przy okazji zwykłych prac nad kartą produktu warto uwzględnić. Tym bardziej że większość zaleceń jest identyczna z tym, co i tak pomaga w klasycznych wynikach.
Zapytanie obrazem jest bogate wizualnie i ubogie kontekstowo. System widzi kształt, kolor, materiał, fakturę, mniej więcej rozmiar w odniesieniu do otoczenia. Nie wie natomiast, po co pytający tego szuka, jaki ma budżet i czy chodzi o produkt nowy, czy zamiennik.
Zapytanie głosowe jest odwrotnością: kontekstu jest dużo, bo ludzie mówią pełnymi zdaniami i zdradzają w nich intencję, ale nie ma precyzji nazwy. Nikt nie wypowiada na głos numeru katalogowego. Zamiast tego pyta o „taki wąż do ciśnieniowego, co pasuje do starszego modelu”.
Z tych dwóch obserwacji wynika praktyczna zasada, którą stosuję przy pisaniu kart. Karta musi zawierać jedno i drugie: nazwy cech, które da się zobaczyć, oraz język, którym ludzie o produkcie mówią. Nie zamiast siebie, ale obok. Pierwsze jest pomostem między obrazem a tekstem, drugie między pytaniem a odpowiedzią.
Trzecia rzecz dotyczy odpowiedzi generowanych. Skoro system układa odpowiedź z fragmentów, to fragment musi być samodzielny — zdanie, które przeniesione w inne miejsce nadal ma sens i zawiera nazwę produktu, a nie „ten model”.
Najbardziej użyteczne przestawienie w myśleniu, jakie mogę tu polecić: przestać projektować kartę jako zestaw danych, a zacząć jako odpowiedź na kilka konkretnych pytań.
Pytania są zawsze podobne i przy każdej kategorii da się je spisać w kwadrans. Czy to pasuje do tego, co mam? Czym różni się od modelu obok w tej samej cenie? Jakie ma wymiary w odniesieniu do czegoś znanego? Ile czekam na dostawę i co, jeśli nie będzie dobre?
Karta, która odpowiada na te pytania wprost i wcześnie, wygrywa niezależnie od sposobu, w jaki użytkownik do niej dotarł. Kluczowe słowo to „wprost”: informacja o zwrotach ukryta w regulaminie na innej podstronie nie jest odpowiedzią.
Kolejność też ma znaczenie. Pierwszy ekran karty powinien pokrywać cztery rzeczy: co to jest, dla kogo, ile kosztuje i kiedy będzie. Wszystko, co wymaga trzech przewinięć, jest w praktyce niewidoczne — zarówno dla użytkownika, jak i dla systemu, który podsumowuje stronę.
To najbardziej praktyczna część i zwykle najbardziej zaniedbana.
Te informacje wpisuję w treść karty jako zdania, a nie wyłącznie w tabelę parametrów. Tabela jest dobra dla porównania, ale zdanie daje się zacytować i przenieść.
Wszystko, co opisałem wyżej, ma swoje odbicie w warstwie maszynowej i te dwie warstwy muszą się zgadzać.
Na karcie oznaczam produkt danymi strukturalnymi: nazwę, identyfikatory producenta, cenę i walutę, dostępność, warunki dostawy i zasady zwrotów. Same zasady zwrotów da się od zeszłego roku opisać także na poziomie całego sklepu, co przy dużym katalogu jest znacznie wygodniejsze niż powtarzanie tego przy każdym produkcie. Warunków dostawy tak nie skrócisz — te trzeba podawać przy ofercie albo w Merchant Center.
W feedzie produktowym pilnuję atrybutów opisowych — koloru, materiału, rozmiaru, grupy wiekowej, płci — a nie tylko tych obowiązkowych. To one pozwalają dopasować produkt do zapytania, w którym nie ma nazwy modelu.
Zasada nadrzędna: rozbieżność między kartą, feedem i danymi strukturalnymi jest gorsza niż brak informacji. Cena inna niż na stronie albo dostępność sprzed tygodnia to nie tylko problem techniczny, ale w skrajnym wypadku powód zablokowania oferty.
Multimodalne wejście uwypukla problem, z którym sklepy mają kłopot od zawsze: co zrobić z dwudziestoma odcieniami tego samego modelu.
Z perspektywy zapytania obrazem odcień jest istotą pytania. Ktoś fotografuje konkretny kolor i chce ten kolor. Jeśli wszystkie warianty siedzą pod jednym adresem, a wybór odbywa się dopiero po wejściu na stronę, dopasowanie jest utrudnione, bo strona nie mówi jednoznacznie, co pokazuje.
Nie mam tu jednej rekomendacji dla każdego sklepu, bo osobne adresy dla każdego wariantu potrafią rozdrobnić widoczność i zamieszać w indeksowaniu. Kompromis, który stosuję najczęściej: jedna karta główna z pełnym opisem oraz osobne adresy dla wariantów istotnie różniących się wyglądem, z zachowaniem jasnego wskazania wersji podstawowej i z opisem, który różnicę nazywa słowami.
W zestawach i wielopakach jedyne, co naprawdę pomaga, to nazwanie zawartości w tytule i pierwszym akapicie. Rozpoznanie ze zdjęcia, że w kartonie są cztery sztuki, a nie jedna, jest zadaniem, którego żaden system dziś nie wykona za Ciebie.
Uczciwa odpowiedź: pomiar jest tu słaby i trzeba to powiedzieć klientowi przed rozpoczęciem prac.
Dane o wyświetleniach z wyszukiwania obrazem nie są wydzielone w raportach w sposób, który pozwoliłby ocenić kampanię. Zapytań głosowych nie odróżnisz od wpisanych. Odwiedziny z odpowiedzi generowanych też nie mają własnego oznaczenia. To znaczy, że nie zbudujesz na tym raportu z jednoznacznym wskaźnikiem.
Co daje się obserwować: udział zapytań długich i pytających w raporcie skuteczności, widoczność w wynikach graficznych, wejścia na karty produktowe bez wcześniejszej wizyty na listingu, a w sklepach z dużym katalogiem — zmiany w rozkładzie ruchu między kartami wariantów.
Dlatego traktuję te prace nie jako osobny projekt z własnym wskaźnikiem, ale jako podniesienie standardu karty produktu. Wszystkie wymienione zmiany działają również wtedy, gdy użytkownik przyszedł najzwyklejszą drogą — a to jest argument, który zwykle wystarcza, żeby je wdrożyć.
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 |