Cena zależy od tego, kim jesteś: program lojalnościowy, ceny kontraktowe i agent zakupowy

Klasyczne SEO zakłada, że produkt ma jedną cenę. W rzeczywistości ma ich kilka: dla niezalogowanego, dla członka programu, dla poziomu w tym programie, dla kontrahenta B2B, dla regionu. Pytanie przestaje brzmieć „jaka jest cena”, a zaczyna: jaka cena przysługuje temu kupującemu i czy agent ma prawo ją poznać.

Google odpowiada na to zestawem twardych reguł z sankcją. UCP odpowiada, że to sprawa sprzedawcy rozstrzygana w czasie działania – i nie przewiduje sprawdzenia tej ceny wobec jakiegokolwiek zewnętrznego punktu odniesienia. Między tymi dwiema odpowiedziami jest luka, w którą łatwo wpaść.

Wszystkie reguły Google i cytaty ze specyfikacji odczytaliśmy 28 lipca 2026. To dokumenty zmieniane co kilka tygodni, więc datę warto traktować jako część wyniku.

Cena publiczna a cena przysługująca

Rozróżnienie, od którego trzeba zacząć, bo cała reszta z niego wynika. Cena publiczna to ta, którą zobaczy każdy. Cena przysługująca to ta, do której dany kupujący ma prawo. W wielu sklepach to dwie różne liczby, a systemy zewnętrzne widzą tylko pierwszą.

Sytuacja	Od czego zależy cena	Kto może ją zobaczyć
cena katalogowa	od niczego	wszyscy
cena promocyjna	od czasu trwania promocji	wszyscy
cena członkowska w programie darmowym	od zapisania się	wszyscy, bo każdy może się zapisać
cena poziomu w programie	od wydanej kwoty lub opłaty	tylko rozpoznani członkowie poziomu
cena kontraktowa B2B	od umowy	tylko uwierzytelniony kontrahent
cena regionalna	od regionu w kraju	kupujący z danego regionu
korzyść w punktach	od salda punktów	zalogowany członek
darmowa dostawa dla członków	od członkostwa i czasem progu zamówienia	rozpoznany członek

Osiem wierszy, osiem różnych reżimów. Sklep, który traktuje je jako jedną rzecz zwaną „promocją”, prędzej czy później złamie którąś politykę. Rozróżnienie samych cen promocyjnych i rabatów opisaliśmy osobno przy cenach promocyjnych i kodach rabatowych.

Dwa reżimy Google i granica, której nie wolno przekroczyć

To najważniejsza sekcja tego tekstu i jednocześnie rzecz opisywana w branży najbardziej niedbale. Google ma dwa osobne reżimy dla ceny zależnej od członkostwa, z zupełnie różnymi warunkami.

Reżim pierwszy: cena członkowska w zwykłym atrybucie ceny

Dozwolona, ale tylko przy spełnieniu wszystkich warunków naraz. Wymagania minimalne w artykule Google o rozbieżności ceny między danymi a stroną stawia sprawę jednoznacznie: „Make sure that any user in the target country can buy the product for the submitted price without paying for a membership”.

Warunki, które muszą zajść łącznie:

• zapisanie się nic nie kosztuje, a członkostwo jest dostępne dla wszystkich bez wyjątku,
• rejestracja jest prosta i możliwa na stronie produktu albo w koszyku,
• cena po rabacie jest wyraźnie pokazana na stronie docelowej.

Google dopuszcza przy tym potwierdzenie konta kodem aktywacyjnym wysłanym mailem albo SMS-em – to nie łamie warunku prostej rejestracji. Ale jeśli członkostwo jest płatne albo warunkowe, cena członkowska nie może iść w atrybucie ceny i próba obejścia tego jest naruszeniem.

Reżim drugi: dedykowany atrybut programu lojalnościowego

Tu obowiązuje reguła, która rozstrzyga najwięcej wątpliwości w praktyce. Instrukcja konfiguracji cen członkowskich formułuje ją tak: „You can display eligible pricing for instantly accessible membership tiers (whether free or paid) to everyone. (…) Pricing for tiers that are not instantly accessible to everyone will be displayed only to known members of those tiers through Customer Match targeting”.

Czyli kryterium nie brzmi „darmowe czy płatne”, tylko natychmiast dostępne czy nie. Poziom płatny, do którego każdy może wejść od ręki, wolno pokazać wszystkim. Poziom darmowy, ale wymagający wydania określonej kwoty w poprzednim roku – już nie.

	Zwykły atrybut ceny	Atrybut programu lojalnościowego
kiedy wolno	tylko program darmowy, otwarty dla wszystkich bez wyjątku	programy darmowe i płatne, dowolne poziomy
kto zobaczy cenę	wszyscy	przy poziomie natychmiast dostępnym wszyscy, przy pozostałych tylko rozpoznani członkowie
jak Google rozpoznaje członka	nie musi	Customer Match, Google Wallet albo deklaracja użytkownika
ryzyko przy błędzie	naruszenie polityki	wstrzymanie programu do czasu naprawy

Wymóg techniczny jest przy tym kategoryczny: „Ensure that the member price for both free and paid tiers are submitted in the price sub-attribute of the loyalty program attribute, and not in price or sale price”. Specyfikacja atrybutu loyalty_program powtarza to jeszcze ostrzej: „Submitting member prices using price or sale price isn’t allowed”.

Siedem podatrybutów, nie cztery

W większości opracowań spotkasz cztery: etykietę programu, etykietę poziomu, cenę i datę obowiązywania ceny. Specyfikacja atrybutu loyalty_program wymienia siedem, a różnica ma konsekwencje wdrożeniowe.

Podatrybut	Wymagalność	Do czego służy
program_label	wymagany w programie wielopoziomowym	identyfikator programu
tier_label	wymagany w programie wielopoziomowym	identyfikator poziomu
price	opcjonalny	cena członkowska
cashback_for_future_use	opcjonalny	zarezerwowany na przyszłość
loyalty_points	opcjonalny	punkty naliczane za zakup, liczba całkowita
member_price_effective_date	opcjonalny	okres obowiązywania ceny członkowskiej
shipping_label	opcjonalny	które oferty mają dostawę dla członków

Kruczek, który wywraca wdrożenia: „If you’re not able to provide the sub-attribute names in the header, you will need to provide all 7 sub-attributes in the value”. Jeśli nie podajesz nazw w nagłówku, musisz podać wszystkie siedem wartości w podanej kolejności. Do tego shipping_label w tej grupie nie jest tym samym co zwykła etykieta wysyłki, co Google zaznacza osobną notą.

Dwa dodatkowe wymagania, które łatwo przeoczyć, a oba są sprawdzane. Waluta ceny członkowskiej musi się zgadzać z walutą ceny zwykłej i promocyjnej. Cena członkowska musi być najniższą możliwą do uzyskania – jeśli na cenę członkowską da się nałożyć promocję sezonową, do Google idzie cena po tej promocji, a nie przed nią.

Google odradza też rozwiązywanie tego regułami feedu zamiast danymi. Rekomendacja jest wprost: używaj podatrybutu ceny i aktualizuj feed, chyba że dosłownie sto procent Twoich produktów ma ten sam rabat kwotowy dla członków.

Próg pięciu procent i pierwszeństwo promocji

Nawet poprawnie przekazana cena członkowska bywa niewidoczna. Dokumentacja programu lojalnościowego Merchant Center podaje warunek liczbowy: „Google will only showcase member pricing in ads when the member discount is >=5% or >=5 unit currency of regular price or sale price (when available)”.

Rabat trzyprocentowy jest więc w praktyce niewidoczny, mimo że jest poprawnie opisany. Warto przy tym zauważyć, że to zdanie mówi wyłącznie o reklamach – Google nie formułuje analogicznego progu dla bezpłatnych ofert produktowych.

Druga reguła bywa jeszcze bardziej zaskakująca: „When there is an unconditional merchant promotion for the product (…), promotion will show instead of member pricing”. Ogólnosklepowa promocja bez progu i bez wskazanej grupy odbiorców wypiera cenę członkowską z wyświetlania. Jeśli więc program lojalnościowy jest częścią strategii cenowej, promocje bezwarunkowe działają przeciwko niemu.

Jak Google sprawdza, czy cena w feedzie jest prawdziwa

Tu wchodzi mechanizm, którego istnienie zmienia sposób wdrażania. Dokument o kryteriach uczestnictwa w programie opisuje go bez ogródek: „Google periodically checks products that have member prices to ensure the price submitted to Google matches what’s showcased on your website. When such mismatch is found, we may temporarily pause your loyalty program”.

Innymi słowy Google okresowo weryfikuje te oferty, porównując dane ze stroną. Google nie podaje przy tym, jaką metodą – warto o tym pamiętać, bo w opisie zwykłych rozbieżności cenowych mowa jest o ręcznym przeglądzie prowadzonym przez zespół oceniający, nie o crawlerze. Praktyczny wniosek jest jednak ten sam: cena członkowska musi być realnie widoczna na stronie dla członków, a nie tylko obecna w pliku z danymi. Sam program przechodzi wcześniej przegląd redakcyjny trwający do 48 godzin, ze statusami od „Under Review” po „Active” albo „Rejected”.

Ważny szczegół operacyjny: po naprawie program nie wznawia się sam. Google pisze wprost, że po rozwiązaniu problemu trzeba wystąpić do pomocy technicznej o ponowną weryfikację.

Skala sankcji zależy od tego, którą regułę złamiesz, i te trzy poziomy warto rozróżniać. Rozbieżność ceny członkowskiej to wstrzymanie programu lojalnościowego. Rozbieżność zwykłej ceny między danymi a stroną to co innego – ostrzeżenie konta albo prewencyjne odrzucenie produktów, a przy nieudanej ponownej weryfikacji siedem dni roboczych karencji. Natomiast ukrycie warunku, od którego zależy cena, wpada pod politykę misrepresentation, gdzie wymieniono wprost „membership fees” jako czynnik wpływający na koszt, który trzeba ujawnić „clearly and noticeably”. Tam ton jest zupełnie inny: „your Google accounts will be suspended upon detection and without prior warning”.

To jest realna różnica między błędem operacyjnym a naruszeniem traktowanym jako rażące. O tym, jak rozbieżności cenowe wpływają na ocenę samego sprzedawcy przez modele, piszemy przy ocenie wiarygodności sprzedawcy.

Polska poza listą – i wyjątek, o którym się nie mówi

Zanim zaczniesz cokolwiek wdrażać, jedna informacja oszczędzająca tygodnie pracy. Program lojalnościowy Merchant Center działa w trzynastu krajach: Stany Zjednoczone, Australia, Brazylia, Meksyk, Kanada, Francja, Niemcy, Indie, Włochy, Holandia, Korea Południowa, Hiszpania i Wielka Brytania, przy czym Japonia ma osobny program punktowy. Polski nie ma na liście trzynastu krajów.

Co więcej, dostępność rozwarstwia się jeszcze bardziej wewnątrz tej listy. Prezentacja korzyści lojalnościowych w AI Mode i aplikacjach Gemini jest ograniczona do Stanów Zjednoczonych – Google pisze wprost „US only”.

Ale tu pojawia się rzecz, którą warto znać, bo istnieje ścieżka wyjątku, o której prawie się nie mówi. Specyfikacja atrybutu loyalty_program zawiera notę: „if your loyalty program is free to join and you either sell in countries where the loyalty program feature is unavailable, you can contact the support team to request an exception to submit your member price in price or sale price”.

Czyli dla sklepu z darmowym programem, sprzedającego w kraju bez wsparcia funkcji, istnieje ścieżka indywidualnej zgody na przekazanie ceny członkowskiej w zwykłym atrybucie ceny. To nie jest obejście reguły, tylko przewidziany w niej wyjątek – i wymaga kontaktu z pomocą techniczną, nie samodzielnej decyzji.

Druga rzecz o charakterze architektonicznym, wymieniona tylko w artykule o kodach krajów w programie lojalnościowym: „Loyalty programs support a single country per merchant center account”. Sprzedajesz z programem do trzech krajów – potrzebujesz trzech kont Merchant Center. To decyzja, którą trzeba podjąć przed wdrożeniem, nie po.

Zakaz zmiany ceny po lokalizacji, a ceny regionalne

To miejsce, w którym najczęściej pojawia się fałszywa sprzeczność. Wymagania minimalne w artykule Google o rozbieżności ceny między danymi a stroną zakazuje jednoznacznie: „Use of IP detection and dynamically changing prices: Don’t change the price of your product on your landing page based on a user’s location. Additionally, do not change price based on cookies, browsers, devices, or any other factor”.

Zdanie zwykle cytuje się do tego miejsca – i przez to wychodzi bez sensu, bo Google równocześnie oferuje regionalne ceny członkowskie. Rozwiązanie jest w trzecim zdaniu, które zwykle się pomija: „If you only target certain locations within a country, use regional pricing and availability”.

Różnica jest jakościowa, nie ilościowa. Przy cenach regionalnych to Google deklaruje region, a sklep się do tej deklaracji dostosowuje. Dokumentacja regionalnych cen członkowskich opisuje mechanizm wprost: „Google appends the region ID corresponding to the location of the shopper as a parameter to the clickthrough URL. Adjust your landing pages so that Google can accept this parameter”.

Zakazane jest więc zgadywanie lokalizacji po adresie IP i podmienianie ceny na tej podstawie. Dozwolone jest przyjęcie regionu przekazanego jawnie w adresie i pokazanie ceny, która została dla tego regionu zadeklarowana w danych. Kierunek przepływu informacji jest odwrotny – i to on decyduje o zgodności z polityką. Ceny regionalne działają przy tym wyłącznie tam, gdzie jednocześnie wspierane są ceny regionalne i program lojalnościowy, a sama funkcja jest oznaczona jako beta.

Trzy rodzaje cen w danych strukturalnych

Warstwa semantyczna ma własny model i własną pułapkę. Dokumentacja danych strukturalnych merchant listing rozróżnia trzy rodzaje cen: cenę aktywną, cenę przekreśloną i cenę członkowską.

Pułapka polega na tym, że dwie właściwości opisujące rodzaj ceny nie mogą wystąpić razem. Dokumentacja mówi: „The respective price specifications are identified by the price specification properties priceType and validForMemberTier, which must not be used together”. I dopowiada konsekwencję: „Price specifications containing both of these properties are ignored”.

Rodzaj ceny	Jak oznaczona	Czego nie może mieć
aktywna	brak obu właściwości	–
przekreślona	priceType ustawione na StrikethroughPrice	właściwości wskazującej poziom członkostwa
członkowska	właściwość wskazująca poziom członkostwa	właściwości priceType

Cena członkowska wymaga przy tym podania obok niej zwykłej ceny bieżącej. Sam program i jego poziomy można zdefiniować albo w Merchant Center, albo znacznikami na osobnej stronie opisującej organizację – a przy konflikcie wygrywa Merchant Center. Warto wiedzieć, że właściwości opisujące poziom członkostwa i naliczane punkty są nadal oznaczone jako beta. Podstawy poprawnego opisania oferty zebraliśmy przy warstwie semantycznej karty produktu.

I od razu zamknijmy furtkę, która mogłaby się wydawać obejściem: znaczniki nie omijają ograniczenia krajowego. Informacje o programie lojalnościowym pokazują się w wynikach wyszukiwania w ośmiu krajach – Australii, Brazylii, Kanadzie, Francji, Niemczech, Meksyku, Wielkiej Brytanii i Stanach Zjednoczonych. To lista jeszcze węższa niż trzynaście krajów samego programu.

Osobna informacja, którą Google podaje mimochodem, a która ma znaczenie dla każdego sklepu: korzyści lojalnościowe pokazywane są także przy ofertach znalezionych przez crawlera, nie tylko przy tych z przesłanych danych. Z tego można się wypisać, ale trzeba o to poprosić. W tym samym zdaniu Google wymienia „loyalty Gmail data sync” jako drugą rzecz, z której można zrezygnować – i jest to jedyna wzmianka o synchronizacji z pocztą w całej dokumentacji. Czym dokładnie ta synchronizacja jest i do czego służy, Google nie wyjaśnia; w wyliczeniu metod rozpoznawania członka wymienione są tylko trzy i Gmaila wśród nich nie ma.

Co na to protokół: identity linking w UCP

Specyfikacja identity linking w UCP opisuje trzy poziomy dostępu i to właśnie w nich znajduje się odpowiedź na pytanie o cenę.

Poziom	Uwierzytelnienie	Przykład ze specyfikacji
Public	brak	przeglądanie publicznego katalogu
Agent-authenticated	poświadczenia platformy	checkout gościa, utworzenie koszyka
User-authenticated	poświadczenia platformy plus token tożsamości użytkownika	zapisane adresy, pełna historia zamówień, personalized pricing

Cena spersonalizowana jest więc wymieniona wprost, jako trzeci przykład tego, co odblokowuje zalogowanie. Specyfikacja zaznacza przy tym, że logowanie niczego nie zamyka: „identity linking upgrades the experience, it does not gate it”.

Kluczowe zdanie dla naszego tematu jest jednak inne i pada przy przykładzie hurtowni: „Whether the user is B2B-eligible, what pricing they see, what payment terms apply – those are user attributes the merchant resolves at runtime, not additional scopes”. Cena zostaje więc świadomie wystawiona poza system zakresów uprawnień i przeniesiona do warunków rozstrzyganych po stronie sprzedawcy. Strukturę samego katalogu B2B opisaliśmy osobno przy katalogu B2B dla agentów zakupowych.

Warstwa bezpieczeństwa jest przy tym potraktowana poważnie: PKCE w wariancie S256 jest obowiązkowe, a wariant uproszczony wprost zakazany, walidacja parametru identyfikującego serwer autoryzacyjny jest wymagana wraz z zakazem normalizowania go przed porównaniem, dopasowanie adresu powrotnego musi być dokładne poza wyjątkiem dla adresów pętli zwrotnej, a token po odłączeniu konta musi zostać unieważniony. Autorzy zadbali o kryptografię. O cenie – nie.

Cena zmieniona na podstawie niesprawdzonej deklaracji

To najbardziej zaskakujące ustalenie tego tekstu i jednocześnie rzecz, której nie widzieliśmy dotąd nigdzie opisanej po polsku. W warstwie katalogowej UCP istnieje mechanizm, w którym platforma przekazuje informację o uprawnieniach kupującego – a sklep może na tej podstawie zmienić cenę w katalogu, zanim ktokolwiek się zaloguje.

Warstwa katalogowa mówi o tym wprost: sklep, który takie deklaracje przyjmuje, „MAY adjust price / list_price directly for strikethrough display”, a przypisanie zmiany do konkretnej deklaracji może przekazać osobnym komunikatem. Charakter samych deklaracji rozstrzyga warstwa finalizacji zakupu: „These are claims, not verified facts”.

Czyli agent może zadeklarować członkostwo bez żadnego dowodu, a sklepowi wolno na tej podstawie pokazać inną cenę. Protokół nie zostawia tego jednak całkiem bez ram i to trzeba oddać uczciwie: wszystkie przyjęte deklaracje „MUST be resolved before the transaction can complete”, a te, które przy finalizacji pozostaną niezweryfikowane, muszą skończyć się błędem z kodem eligibility_invalid. Weryfikacja jest więc przewidziana – tyle że dopiero na końcu ścieżki, długo po tym, jak cena trafiła do odpowiedzi agenta.

Dla sklepu oznacza to konkretne ryzyko operacyjne: cena członkowska może trafić do odpowiedzi agenta dla kogoś, kto członkiem nie jest, a rozczarowanie nastąpi dopiero w koszyku. To dokładnie ten rodzaj rozbieżności, który Google karze po swojej stronie – a protokół go nie tylko dopuszcza, ale opisuje jako przewidziane zachowanie.

Rekomendacja praktyczna jest prosta: nie stosować obniżki na podstawie samej deklaracji bez oznaczenia jej jako warunkowej, a najlepiej odłożyć cenę członkowską do momentu, w którym tożsamość jest potwierdzona. Mechanika przyjmowania niezweryfikowanych danych z zewnątrz to zresztą szerszy wzorzec, który opisaliśmy przy treści produktowej jako wektorze ataku.

Czego użytkownik nie dowie się z ekranu zgody

Z trzech ustaleń specyfikacji wychodzi wniosek, którego autorzy chyba nie zamierzali. Po pierwsze, ekran zgody renderuje sprzedawca: „Consent screens are rendered by the business’s authorization server”, a sama specyfikacja nie definiuje treści opisów uprawnień.

Po drugie, zaleca się grupowanie uprawnień w zrozumiałe zdania zamiast wyliczania operacji – „Allow [platform] to view your order history” zamiast technicznej nazwy uprawnienia. Zalecenie słuszne, ale z efektem ubocznym: opis staje się ogólniejszy niż to, co faktycznie się dzieje.

Po trzecie, personalizacja ceny działa niezależnie od udzielonych uprawnień. Specyfikacja mówi to wprost: sprzedawca rozstrzyga te rzeczy na podstawie kontekstu zalogowanego użytkownika „regardless of which scopes were granted”.

Uczciwe zastrzeżenie, bo obiegowa teza idzie tu za daleko: nie jest prawdą, że w protokole nie ma żadnego uprawnienia dotyczącego ceny. Warstwa katalogowa definiuje dwa, i to opisane wprost: wyszukiwanie w imieniu zalogowanego użytkownika obejmuje „personalized results, member pricing, gated inventory”, a odpytanie o konkretny produkt – „personalized pricing or availability”. Cena da się więc zabramkować uprawnieniem.

Problem jest subtelniejszy i przez to łatwiejszy do przeoczenia. Te uprawnienia są opcjonalne, opis każdego pisze sprzedawca, a personalizacja i tak zadziała bez nich, bo wynika z samego faktu zalogowania. Użytkownik zgadza się więc na wgląd w historię zamówień, dostaje przy okazji inną cenę, i jeśli sklep nie zadeklarował uprawnienia katalogowego z sensownym opisem, ekran zgody strukturalnie nie ma jak o tym poinformować. Protokół daje narzędzie – nie wymaga, żeby z niego skorzystać.

Dodajmy dla porządku, że cytujemy wydanie 2026-04-08, czyli to, które czytelnik zobaczy pod zwykłym adresem. W wersji roboczej ta warstwa wyraźnie się zmienia: doszły delegowani dostawcy tożsamości i sekcja o danych, które sprzedawca dopisuje z własnego stanu. Osobno powstaje też całe rozszerzenie opisujące programy lojalnościowe, którego w wydaniu 2026-04-08 jeszcze nie ma.

Odwrotny problem: jak nie ujawnić ceny zastrzeżonej

Dotąd chodziło o to, żeby właściwa cena dotarła do właściwej osoby. Teraz o to, żeby niewłaściwa nie dotarła do nikogo. W sklepach B2B cena kontraktowa wycieka częściej, niż się przypuszcza, i prawie zawsze przez ten sam zestaw miejsc.

Gdzie wycieka	Jak sprawdzić	Typowa przyczyna
dane strukturalne na karcie produktu	otworzyć stronę w trybie prywatnym i przeszukać źródło pod kątem ceny	szablon renderuje cenę z sesji, nie z warstwy publicznej
punkt końcowy interfejsu produktowego	wywołać go bez nagłówka uwierzytelniającego	autoryzacja sprawdzana w warstwie widoku, nie w danych
pamięć podręczna sieci dostarczania treści	porównać odpowiedź dla zalogowanego i niezalogowanego z tego samego adresu	brak rozdzielenia klucza pamięci podręcznej po stanie zalogowania
plik z danymi dla porównywarki	sprawdzić, która cena trafia do pliku dla kontrahenta z rabatem	generator bierze cenę efektywną zamiast katalogowej
dokumenty PDF z cennikami	wyszukać w Google frazę z nazwą pliku i domeną	cenniki wrzucone do katalogu publicznego i zaindeksowane

Ostatni wiersz jest najczęstszy i najłatwiejszy do sprawdzenia. Wystarczy zapytać wyszukiwarkę o pliki PDF w Twojej domenie zawierające słowo „cennik”. Jeśli cokolwiek się pokaże, sprawdź, czy to cennik przeznaczony do publikacji.

Checklista przed wdrożeniem

Dziesięć pytań, z których każde ma odpowiedź tak albo nie. Jeśli przy którymkolwiek odpowiedź brzmi „nie wiem”, to jest miejsce do sprawdzenia w pierwszej kolejności.

1. Czy Twój kraj jest na liście trzynastu? Jeśli nie, a program jest darmowy – czy wystąpiłeś o indywidualny wyjątek?
2. Czy program przechodzi kryteria Google? Newsletter, subskrypcja SMS, pobranie aplikacji, program partnerski i program poleceń nie są programami lojalnościowymi.
3. Czy poziomy są natychmiast dostępne? Od tego zależy, kto w ogóle zobaczy cenę.
4. Czy cena członkowska jest w dedykowanym podatrybucie, a nie w zwykłej cenie ani cenie promocyjnej?
5. Czy rabat wynosi co najmniej pięć procent albo pięć jednostek waluty?
6. Czy nie działa równolegle promocja bezwarunkowa, która wyprze cenę członkowską?
7. Czy cena członkowska jest widoczna na stronie dla członka? To jest sprawdzane.
8. Czy waluty się zgadzają i czy cena członkowska jest najniższą możliwą, po nałożeniu promocji sezonowych?
9. Czy cena zastrzeżona nie wycieka przez dane strukturalne, interfejs, pamięć podręczną, plik danych albo zaindeksowany dokument?
10. Czy agent może dostać cenę członkowską bez potwierdzonej tożsamości? Jeśli tak, czy jest oznaczona jako warunkowa?

Punkty od pierwszego do ósmego dotyczą zgodności z Google. Dziewiąty i dziesiąty dotyczą warstwy agentowej, której Google nie kontroluje i której nikt nie kontroluje. Sprawdzenie całości jest elementem szerszego audycie widoczności w AI, a same ceny warto objąć monitorowaniu cen i sygnalizowaniu zmian.

Co z tego wynika

Dwie warstwy podchodzą do tej samej sprawy odwrotnie. Google zbudował system reguł z progiem liczbowym, weryfikacją crawlerem, przeglądem redakcyjnym i sankcją w postaci zawieszenia. UCP świadomie wystawił cenę poza system uprawnień, nie przewidział sprawdzenia jej wobec ceny publicznej i dopuścił zmianę ceny na podstawie deklaracji, którą sam nazywa twierdzeniem, a nie dowodem.

Dla sklepu praktyczny wniosek jest jeden: jedno źródło prawdy o cenie i uprawnieniu, z którego korzystają wszystkie trzy kanały – strona, plik danych i odpowiedź dla agenta. Wszędzie tam, gdzie te trzy rozjeżdżają się choćby o kilka złotych, ryzyko materializuje się najpierw po stronie Google, bo tam jest kto sprawdza.

Naturalnym kolejnym krokiem jest sprawdzenie, jak model w ogóle rozstrzyga warunki zakupu – opisaliśmy to przy wyszukiwania na wymagania i przy badaniu nad odrzucaniem trafnych ofert. Jeśli chcesz zobaczyć całą układankę, prowadzi po niej mapie 10 warstw SEO w e-commerce, a warstwę pomiarową opisaliśmy przy atrybucji sprzedaży agentowej. Gotowość transakcyjną samego sklepu zbieramy przy gotowości sklepu na zakupy przez agenta, personalizację samych rekomendacji przy personalizacji rekomendacji w AI, a zakres i wycenę takiej pracy znajdziesz w cenniku SEO dla e-commerce; całość prowadzimy jako element pozycjonowania sklepu internetowego.