Porównywarki i AI: skąd model bierze ceny produktów

Zapytaj modelu o cenę produktu i dostaniesz liczbę podaną z pełnym przekonaniem. Bywa, że jest sprzed trzech tygodni, dotyczy innego wariantu albo pochodzi z porównywarki, która nie ma już Twojej oferty. Dla sklepu to nie kosmetyka: błędna kwota kasuje zaufanie, zanim klient kliknie link.

Model nie ma dostępu do Twojej bazy danych i nie pyta serwera o cennik. Składa odpowiedź z tego, co ma pod ręką, a to zależy od kilku kanałów o bardzo różnej świeżości.

Trzy źródła danych cenowych

Ceny, które widzisz w odpowiedziach asystentów, pochodzą praktycznie zawsze z jednego z trzech miejsc. Każde z nich ma inny czas reakcji na zmianę w Twoim panelu i inny stopień kontroli po Twojej stronie.

Pierwsze źródło to świeży pobór strony produktu, czyli sytuacja, w której narzędzie wyszukujące podpięte do modelu odwiedza Twój adres URL w momencie zadania pytania. To najlepszy scenariusz, bo cena jest wtedy praktycznie bieżąca. Zdarza się jednak rzadziej, niż się wydaje, i tylko gdy zapytanie jednoznacznie wskazuje na konkretny produkt lub sklep.

Drugie źródło to indeks wyszukiwarki i pamięć podręczna. Model dostaje fragment strony w wersji, w jakiej robot zapisał ją przy ostatnim poborze. Jeśli Twoja karta produktu jest odwiedzana raz na dwa tygodnie, to właśnie dwa tygodnie wynosi maksymalne opóźnienie ceny.

Trzecie źródło to treści osób trzecich: porównywarki, agregatory, katalogi, artykuły redakcyjne, zestawienia blogowe i wątki na forach. Tu opóźnienie jest nieograniczone, bo tekst z recenzji sprzed roku nadal zawiera kwotę sprzed roku i nikt go nie zaktualizuje.

Wniosek taktyczny jest prosty: nie wymusisz na modelu znajomości cennika, ale możesz sprawić, że najświeższe źródło będzie najłatwiejsze do odczytania.

Rola porównywarek i agregatorów

Porównywarki wygrywają w tej konkurencji o uwagę modelu z dwóch powodów. Po pierwsze podają dane w formie uporządkowanej: nazwa, cena, sklep, dostępność, wszystko w jednym bloku. Po drugie zbierają w jednym adresie URL kilkanaście ofert, więc odpowiadają na pytanie „ile to kosztuje” lepiej niż jakikolwiek pojedynczy sklep.

Konsekwencja jest niewygodna. Jeśli Twój produkt jest w porównywarce, to właśnie jej zapis ceny ma największą szansę trafić do odpowiedzi, nawet gdy Twoja własna karta produktu jest poprawnie opisana. A zapisy w porównywarkach starzeją się nierówno: część serwisów odświeża oferty codziennie, część trzyma archiwalne wpisy z ceną sprzed sezonu i dopiskiem o braku dostępności, który model potrafi zignorować.

Druga pułapka to zakres kwoty. Agregatory pokazują cenę bez kosztu dostawy, czasem z rabatem warunkowym, czasem w ujęciu ratalnym, a model przepisuje liczbę, nie przypis. Punktem wyjścia są więc własne, uporządkowane dane produktowe; opisaliśmy ten fundament w tekście o tym, jak przygotować sklep pod AI od strony feedu, opisów i kategorii.

Osobny kanał to dane przekazywane do ekosystemu zakupowego wyszukiwarki. Oferta w kanale handlowym odświeża się znacznie częściej niż strona produktu w indeksie, a trafia do podsumowań generowanych nad wynikami. Mechanikę rozkładamy w materiale o integracji oferty z Google Shopping i AI Overviews.

Cena w schema Offer i jej aktualność

Dane strukturalne są jedynym miejscem, w którym mówisz o cenie językiem maszyny, a nie językiem reklamy. Interesuje nas obiekt Offer zagnieżdżony w Product, a w nim cztery pola, które decydują o interpretacji: price, priceCurrency, availability oraz priceValidUntil. Definicje wszystkich właściwości znajdziesz w specyfikacji schema.org dla Offer, a wymagania po stronie wyszukiwarki w dokumentacji danych strukturalnych produktu.

Najczęstszy błąd techniczny nie dotyczy jednak samych pól, tylko momentu ich powstania. Jeśli cena jest wstrzykiwana do strony przez skrypt po stronie przeglądarki, a znacznik w surowym kodzie HTML zawiera wartość zerową albo placeholder, to robot zapisuje właśnie tę wartość pustą. Strona wygląda dla człowieka poprawnie, a dla maszyny nie ma ceny wcale.

Drugi błąd to porzucone priceValidUntil. Pole miało oznaczać koniec ważności oferty, a w praktyce bywa wypełniane datą z wdrożenia sklepu i od dawna należy do przeszłości. Dla parsera to sygnał, że kwota wygasła, a wygasła kwota to zaproszenie do sięgnięcia po inne źródło, czyli po porównywarkę.

Trzeci błąd to niespójność warstw. Cena w znaczniku, w widocznym tekście i w feedzie musi się zgadzać do groszy; rozbieżność obniża zaufanie do całej karty.

Promocje, warianty i ceny od

Największy chaos powstaje tam, gdzie jeden adres URL opisuje wiele kwot. Trzy sytuacje powtarzają się w każdym sklepie.

• Warianty z różną ceną. Rozmiar, pojemność, kolor premium: każdy wariant ma własną kwotę, a karta produktu jedną. Poprawnym opisem jest AggregateOffer z polami lowPrice i highPrice, ale wtedy godzisz się, że model najczęściej zacytuje wartość najniższą.
• Formuła „cena od”. W widocznym tekście brzmi uczciwie, w odpowiedzi asystenta zamienia się w cenę ostateczną, bo słowo „od” ginie w streszczeniu. Jeśli różnica między wariantem najtańszym i najdroższym przekracza kilkadziesiąt procent, lepiej rozdzielić produkty na osobne adresy URL.
• Promocje czasowe. Kwota promocyjna zapisana w znaczniku jako cena podstawowa zostaje w pamięci podręcznej długo po zakończeniu akcji. Czysty zapis to cena regularna w price i osobny znacznik promocji z datami obowiązywania.

Im mniej kwot na jednym adresie, tym mniejsze ryzyko, że model wybierze tę najmniej korzystną. Jeden produkt, jedna cena, jeden URL to nadal najbezpieczniejsza architektura.

Co zrobić przy błędnej cenie w odpowiedzi

Zgłoszenie „model podaje złą cenę” wymaga diagnozy, nie poprawki na oślep. Kolejność działań ma znaczenie, bo każdy krok eliminuje jedno źródło.

1. Ustal, skąd pochodzi liczba. Dopytaj model o źródło i o datę. Jeśli wskaże konkretny adres URL, połowa pracy jest za Tobą. Jeśli nie wskaże żadnego, prawdopodobnie mówi z pamięci i tu pomoże wyłącznie czas plus nowe publikacje.
2. Sprawdź surowy kod strony. Pobierz kartę produktu bez wykonywania skryptów i zobacz, czy cena w ogóle tam jest. To test, który najczęściej kończy diagnozę w pierwszej minucie.
3. Zweryfikuj spójność warstw. Porównaj kwotę ze znacznika, z widocznego tekstu i z eksportu feedu. Rozbieżność naprawiasz u siebie, nie u modelu.
4. Wymuś ponowny pobór. Zaktualizuj datę modyfikacji, zgłoś adres URL do ponownego indeksowania i upewnij się, że mapa witryny podaje nową datę. Dopóki robot nie wróci, poprawka nie istnieje.
5. Posprzątaj u osób trzecich. Odśwież wpisy w porównywarkach, w których masz konto, i poproś wydawców o korektę nieaktualnych kwot.
6. Dodaj jawną datę. Zdanie „cena obowiązuje od” z konkretną datą obok kwoty daje modelowi kryterium wyboru między Twoją wartością i starszą z zewnątrz.

Jak monitorować, co model podaje

Bez pomiaru każda z powyższych poprawek jest wiarą, nie wiedzą. Monitoring cen w odpowiedziach modeli różni się od klasycznego sprawdzania pozycji, bo odpowiedź nie jest stabilna: ten sam prompt zadany dwa razy daje różne sformułowania i czasem różne źródła.

Minimalny sensowny zestaw to kilkanaście zapytań na produkt lub kategorię, zadawanych w stałym rytmie i logowanych razem z odpowiedzią oraz listą cytowanych adresów URL. Patrzysz na trzy rzeczy: czy kwota jest poprawna, czy cytowany jest Twój adres i jak często odpowiedź zawiera liczbę. Ostatnia metryka bywa najbardziej pouczająca, bo milczenie o cenie to także wynik.

Taki log ma sens dopiero w dłuższym oknie: różnica między tygodniem a kwartałem to różnica między szumem i trendem. Dobór promptów i format logu opisaliśmy w przewodniku o monitoringu widoczności w ChatGPT.

I jedno przypomnienie o proporcjach: model przytacza cenę dlatego, że ufa całej karcie produktu. Sklep z rzetelnym opisem i spójnym feedem dostaje poprawną kwotę niemal przy okazji, a ten, kto naprawia wyłącznie liczbę, będzie ją naprawiał w nieskończoność.

Najczęstsze pytania