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 wyszukiwanie obrazem traktowałem jako funkcję dla ciekawskich. Ktoś fotografował roślinę, żeby sprawdzić, jak się nazywa, i na tym się kończyło. Ostatnie dwa lata zmieniły to na tyle, że temat wrócił do rozmów o sklepach internetowych — i to nie z inicjatywy agencji, ale klientów, którzy sami zaczęli tak szukać.
Najwięcej zmieniło przeniesienie tej funkcji z osobnej aplikacji do miejsc, w których użytkownik już jest. Lens siedzi w pasku wyszukiwania w aplikacji Google, w przeglądarce na telefonie, a od początku 2024 roku na części telefonów z Androidem także pod długim przytrzymaniem przycisku ekranu głównego, w funkcji Circle to Search. Zmienia to liczbę okazji do użycia, a nie samą technologię.
Poniżej opisuję, co Google robi ze zdjęciem produktu i które elementy po naszej stronie mają na to wpływ. Uprzedzam od razu: część rzeczy, których oczekują klienci, jest po prostu poza naszym zasięgiem.
Warto rozróżnić kilka rzeczy, bo w rozmowach zwykle wrzuca się je do jednego worka.
Na majowej konferencji Google I/O zapowiedziano dodatkowo możliwość zadawania pytań nagraniem wideo. Na koniec września to nadal tylko zapowiedź — Google mówi o eksperymencie w Search Labs w Stanach Zjednoczonych i po angielsku, ale nie podało daty, od kiedy będzie go można włączyć. Tym bardziej nie jest to funkcja, na którą można planować budżet w polskim sklepie. Wspominam o niej dlatego, że pokazuje kierunek: wejściem do wyszukiwarki coraz częściej nie jest tekst.
Mechanizm jest dużo bardziej prozaiczny, niż sugeruje słowo „rozpoznawanie”.
Lens wycina z kadru obiekt, zamienia go na reprezentację numeryczną i szuka najbliższych dopasowań w zbiorze obrazów, które Google zindeksowało. Jeśli obiekt zostanie rozpoznany jako produkt, wyniki wzbogacane są danymi z zasobu informacji o produktach, jaki Google buduje z feedów sklepowych, stron produktowych i danych strukturalnych.
Z tego wynikają dwa praktyczne wnioski. Po pierwsze, zdjęcie musi być zindeksowane, żeby w ogóle mogło zostać dopasowane — obraz, do którego robot nie ma dostępu, nie istnieje dla tej funkcji. Po drugie, dopasowanie odbywa się między obrazami, więc jakość i sposób kadrowania mają realne znaczenie, a nie tylko estetyczne.
Trzecia rzecz jest mniej oczywista: sam obraz rzadko wystarcza do rozstrzygnięcia, o który konkretny model chodzi. Dwa krzesła tej samej klasy wyglądają na zdjęciu niemal identycznie. To, co je rozróżnia, siedzi w tekście wokół obrazu i w danych produktowych.
Lista jest krótka i nudna, a mimo to na większości kont, które przejmuję, połowa punktów nie jest spełniona.
Zdjęcie główne produktu powinno być duże, ostre i pokazywać jeden przedmiot na jednolitym tle. Kolaże, zdjęcia z kilkoma wariantami w jednym kadrze i grafiki z nałożonym tekstem promocyjnym utrudniają dopasowanie, bo obiekt przestaje być jednoznaczny.
Do tego kilka rzeczy technicznych: obraz w rozsądnie wysokiej rozdzielczości, ale skompresowany tak, żeby nie psuł czasu wczytywania; format nowoczesny, z zachowaniem wersji zapasowej dla starszych przeglądarek; stały adres pliku, bo zmiana ścieżki przy każdym wdrożeniu zeruje historię indeksowania.
Osobno warto pomyśleć o zdjęciach dodatkowych. Produkt sfotografowany w użyciu, z boku i w otoczeniu daje więcej punktów zaczepienia niż jedno ujęcie na białym tle. Ludzie fotografują rzeczy w mieszkaniach i na ulicy, nie w studiu.
Tu jest największa różnica między sklepem, który da się dopasować, a takim, który jest dla wyszukiwarki bezimienny.
Nazwa pliku powinna opisywać przedmiot, a nie pochodzić z aparatu. Ciąg cyfr z fotografii to zmarnowana informacja. Atrybut alternatywny wypełniam opisem tego, co widać, w naturalnym języku — bez upychania słów kluczowych, bo to nie pomaga, a przy czytnikach ekranu wprost przeszkadza.
Dalej: tekst bezpośrednio przy obrazie. Podpis pod zdjęciem, nagłówek sekcji, tytuł produktu w tym samym bloku. Google wykorzystuje otoczenie obrazu do ustalenia, czego dotyczy, więc galeria umieszczona w oderwaniu od opisu traci część kontekstu.
Warto też zadbać o dane licencyjne w metadanych pliku, jeśli zdjęcia są własne. Google obsługuje oznaczanie obrazów informacją o licencji i podmiocie uprawnionym — dla producenta albo marki, której zdjęcia krążą po sieci, to jedyny sposób, żeby przy obrazie pojawiła się informacja o źródle.
Optymalizacja pod wyszukiwanie wizualne w sklepie to w dużej części zwykła higiena danych produktowych.
Na stronie produktu potrzebne są dane strukturalne z nazwą, obrazem, ceną, walutą i dostępnością. Bez nich rozpoznany wizualnie przedmiot nie ma z czym zostać połączony i nie trafi do wyników zakupowych, choćby zdjęcie było doskonałe.
Po stronie Merchant Center liczy się to samo w innej formie: poprawny atrybut z adresem zdjęcia głównego, zdjęcia dodatkowe, identyfikatory takie jak kod producenta i numer katalogowy, spójne warianty. Konta, w których warianty kolorystyczne mają to samo zdjęcie, tracą dokładnie tam, gdzie wyszukiwanie wizualne miałoby pomóc — bo użytkownik fotografuje konkretny kolor.
Migracja kont do nowej wersji Merchant Center, prowadzona przez ten rok, niczego tu nie zmienia merytorycznie. Zmienia układ interfejsu, nie wymagania wobec zdjęć.
Najczęstsza przyczyna zerowego efektu wszystkich powyższych działań jest banalna: obrazy nie są zindeksowane.
Sprawdzam więc trzy rzeczy. Czy plik robots nie blokuje katalogu z grafiką albo domeny sieci dostarczania treści, na której siedzą zdjęcia. Czy leniwe wczytywanie jest wdrożone w sposób, który zostawia w kodzie prawidłowy adres źródłowy, a nie podmienia go dopiero skryptem po przewinięciu strony. Czy w mapie witryny są wpisy dla obrazów albo osobna mapa graficzna.
Do tego jedna rzecz, o której łatwo zapomnieć przy przenoszeniu zdjęć na zewnętrzną domenę: taka domena powinna być zweryfikowana w Search Console jako osobna usługa, bo inaczej dane o wyświetleniach grafiki po prostu nie mają gdzie się pokazać.
W raporcie skuteczności warto przy tym przełączyć typ wyszukiwania na grafikę. To jedyny dostępny widok tego rodzaju ruchu — osobnego raportu dla Lens nie ma i nie zapowiadano, że będzie.
Kończę listą rzeczy, których nie obiecuję klientom, bo nie mam na nie wpływu.
Nie da się wybrać, które zdjęcie Google uzna za dopasowanie. Nie da się wykluczyć konkurencji z listy wyników przy rozpoznanym produkcie. Nie ma narzędzia do podglądu, jak nasz produkt wygląda w wynikach wizualnych dla dowolnego zdjęcia zrobionego przez użytkownika — pozostaje testowanie ręczne na własnym telefonie, na kilku ujęciach.
Nie ma też żadnej dźwigni, która przyspieszy dopasowanie produktu niszowego, o którym w sieci jest kilka zdjęć. Wyszukiwanie wizualne działa najlepiej tam, gdzie materiału jest dużo — czyli w kategoriach popularnych i przy markach obecnych u wielu sprzedawców.
Dlatego traktuję to jako pracę fundamentową, nie kampanię. Porządne zdjęcia, opisany kontekst, poprawne dane produktowe i zindeksowana grafika przydają się w kilku kanałach naraz. Sam Lens jest premią za zrobienie tego, co i tak trzeba było zrobić.
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 |