AI pyta nie tylko „czy jest”, ale „kiedy dotrze”. Dostawa i order tracking jako dane produktowe

Sklep, który nie podaje handling time na poziomie produktu, nie definiuje handling_cutoff_time i deklaruje darmową wysyłkę bez podania progu — przegrywa porównanie w AI, zanim agent w ogóle oceni cenę. Trzy konkretne działania (konfiguracja per-product w Merchant Center, cut-off i spójność feed↔strona) eliminują najczęstsze rozbieżności.

Cena produktu bez kosztu i terminu dostawy to niepełna informacja zakupowa. W agentic commerce, gdzie agent AI porównuje oferty wielu sprzedawców dla tego samego produktu, dane o dostawie stają się atrybutem decyzyjnym – nie dodatkiem. Dla sklepów internetowych, które inwestują w pozycjonowanie e-commerce, dane logistyczne to kolejny wymiar optymalizacji, który wpływa na widoczność produktów w AI. Google Merchant Center oferuje dedykowane pola feedowe dla handling time, transit time i kosztu wysyłki. ChatGPT zbiera dane o dostawie z feedów OpenAI i ze stron sklepów. Problem polega na tym, że deklarowane terminy dostawy rzadko odpowiadają rzeczywistości, a systemy AI nie mają mechanizmu weryfikacji ETA w czasie rzeczywistym. W tym artykule dokumentujemy, jakie dane o dostawie są dostępne dla systemów AI, gdzie powstają rozbieżności i co sklep może zrobić, żeby nie przegrywać porównań z powodu niekompletnych informacji logistycznych. Dane o dostawie to element strategii content marketingowej, który bezpośrednio wpływa na postrzeganie oferty przez AI.

Dlaczego dane o dostawie zyskują na znaczeniu w AI commerce?

Tradycyjny e-commerce ukrywa pełny koszt dostawy do momentu koszyka. Użytkownik widzi cenę produktu, klika „dodaj do koszyka”, przechodzi do checkoutu i dopiero wtedy dowiaduje się, że wysyłka kosztuje 15 zł i trwa 5-7 dni roboczych. W modelu konwersacyjnym AI ten schemat się zmienia.

Gdy użytkownik pyta ChatGPT „jaki jest najlepszy powerbank do 150 zł z szybką dostawą”, agent AI musi uwzględnić trzy wymiary jednocześnie: cenę produktu, koszt dostawy i czas dostawy. Atrybuty dostawy stają się częścią konwersacyjnych atrybutów produktu, które AI uwzględnia przy selekcji. Mechanizm wyboru sprzedawcy przez AI omówiliśmy szczegółowo w kontekście karty produktu i danych strukturalnych. Jeśli sklep A oferuje powerbank za 129 zł z dostawą za 14,99 zł w 5 dni, a sklep B oferuje ten sam model za 139 zł z darmową dostawą następnego dnia – odpowiedź „najlepszy” zależy od tego, jak agent waży te wymiary. Według dokumentacji OpenAI, ChatGPT uwzględnia przy selekcji produktów m.in. cenę, dostępność i recenzje – ale nie precyzuje wagi danych logistycznych.

Problem narasta w kontekście porównywania ofert wielu sprzedawców dla tego samego GTIN — dynamikę rywalizacji między marketplace a sklepem własnym opisujemy w artykule o marketplace vs sklep w AI search. Jeśli produkt jest identyczny, jedyną różnicą między ofertami są: cena, koszt dostawy, czas dostawy, polityka zwrotów i reputacja sprzedawcy (budowana m.in. przez sentyment i atrybuty w opiniach klientów). Bez danych o dostawie agent ma do dyspozycji tylko cenę – i faworyzuje najtańszą ofertę, nawet jeśli jej delivery promise jest nierealistyczny.

Jakie dane o dostawie są dostępne w Google Merchant Center?

Google Merchant Center oferuje rozbudowany zestaw atrybutów feedowych dotyczących dostawy. Problem polega na tym, że większość sklepów konfiguruje je na poziomie konta, nie produktu – co prowadzi do uśrednionych, często niedokładnych deklaracji.

Atrybuty handling time

Atrybut	Opis	Format
min_handling_time	Minimalny czas od złożenia zamówienia do nadania przesyłki	Liczba całkowita (dni robocze)
max_handling_time	Maksymalny czas od złożenia zamówienia do nadania przesyłki	Liczba całkowita (dni robocze)
handling_cutoff_time	Czas graniczny, po którym zamówienie przesuwa się na następny dzień roboczy	Godzina (np. 14:00)
shipping_handling_business_days	Dni tygodnia, w których sklep realizuje zamówienia	Lista dni

Handling time to czas od momentu złożenia zamówienia do momentu przekazania przesyłki kurierowi. Jeśli klient zamawia we wtorek, a przesyłka opuszcza magazyn najpóźniej w piątek, max_handling_time wynosi 3 dni. Domyślnie dni robocze to poniedziałek-piątek, ale można skonfigurować inne – w tym weekendy.

Handling cutoff time to stosunkowo nowy atrybut w ekosystemie Merchant Center. Definiuje godzinę graniczną – zamówienie złożone przed cut-off jest realizowane tego samego dnia, po cut-off przesuwa się na następny dzień roboczy. Bez tego atrybutu Google nie wie, czy zamówienie złożone o 22:00 zostanie nadane tego samego dnia czy następnego.

Atrybuty transit time

Atrybut	Opis	Format
min_transit_time	Minimalny czas od nadania przesyłki do dostarczenia	Liczba całkowita (dni robocze)
max_transit_time	Maksymalny czas od nadania przesyłki do dostarczenia	Liczba całkowita (dni robocze)
shipping_transit_business_days	Dni tygodnia, w których kurier doręcza przesyłki	Lista dni

Szacowana data dostawy obliczana jest jako: max_handling_days + max_transit_days. To formuła pesymistyczna – zakłada najgorszy scenariusz. Sklep, który podaje realistyczne handling time i transit time, dostaje dokładniejsze ETA niż sklep z zawyżonymi buforami.

Atrybuty kosztów wysyłki

Atrybut shipping [shipping] pozwala zdefiniować koszt i warunki wysyłki na poziomie produktu – to element, który warto uwzględnić w ramach audytu treści e-commerce. Obejmuje sub-atrybuty: country, region, service, price, min/max_handling_time, min/max_transit_time. Jeśli dane na poziomie produktu i na poziomie konta kolidują, pierwszeństwo mają dane produktowe. Więcej o strukturze feedu i jej wpływie na widoczność AI opisujemy w artykule o feedzie produktowym i AI visibility.

Źródło: Google Merchant Center Help – Handling time i Shipping attribute, weryfikacja: 17 sierpnia 2026.

Co wie ChatGPT o dostawie i skąd bierze te dane?

ChatGPT zbiera dane o dostawie z dwóch źródeł: feedów produktowych (Agentic Commerce Protocol lub Shopify Catalog) oraz crawlingu stron sklepów.

Dane z feedów OpenAI

Specyfikacja OpenAI Commerce Products Feed Reference wymaga, aby sprzedawcy podali informacje o metodach wysyłki, kosztach i szacowanych czasach dostawy (OpenAI Developers – Products). Dokumentacja wskazuje również, że użytkownik powinien potwierdzić finalną cenę, podatki, opłaty i koszty wysyłki na stronie sprzedawcy.

To oznacza, że dane o dostawie w ChatGPT są deklaratywne – podaje je sprzedawca, a system nie weryfikuje ich w czasie rzeczywistym. Nie ma mechanizmu, który sprawdza, czy sklep deklarujący „dostawę w 24h” faktycznie nadaje przesyłki tego samego dnia.

Dane z crawlingu

ChatGPT może również odczytać dane o dostawie ze strony produktu – jeśli są tam wyeksponowane w czytelny sposób. Problem: informacje o dostawie na stronach e-commerce są często dynamiczne (zależą od kodu pocztowego, metody płatności, pory dnia), ukryte w zakładkach lub ładowane JavaScript-em. Agent AI widzi to, co jest dostępne w HTML lub co zwraca Shopify Catalog – nie to, co użytkownik zobaczy po interakcji z kalkulatorem wysyłki.

Pięć typowych rozbieżności w danych o dostawie

Na podstawie analizy feedów i stron produktowych identyfikujemy pięć najczęstszych źródeł niespójności:

1. Deklarowany termin vs rzeczywisty czas realizacji

Sklep deklaruje w feedzie max_handling_time = 1 (nadanie następnego dnia roboczego), ale w praktyce realizacja trwa 2-3 dni. Przyczyny: brak aktualizacji feedu po zmianie procesów magazynowych, deklarowanie optymistycznego scenariusza zamiast realistycznego, brak uwzględnienia weekendów i świąt. Dokumentacja Google wymaga, aby handling time odzwierciedlał realistyczny czas realizacji.

2. Koszt wysyłki w feedzie vs na stronie

Feed deklaruje shipping price = 0 PLN (darmowa wysyłka), ale darmowa wysyłka obowiązuje dopiero od określonego progu zamówienia. Produkt za 49 zł ma w feedzie „free shipping”, ale na stronie okazuje się, że darmowa wysyłka jest od 100 zł. Agent AI, który porównuje oferty na podstawie feedu, faworyzuje tę ofertę niesłusznie.

3. Brak cut-off time

Sklep nie definiuje handling_cutoff_time. Zamówienie złożone o 22:00 jest traktowane tak samo jak zamówienie z 10:00. W rzeczywistości zamówienie po godzinie 14:00 jest realizowane dopiero następnego dnia. Bez cut-off systemy AI nie mogą poprawnie oszacować, kiedy przesyłka dotrze.

4. Uśrednione dane na poziomie konta vs zróżnicowanie produktowe

Sklep konfiguruje shipping settings na poziomie konta Merchant Center: max_handling_time = 3, max_transit_time = 5. Ale produkty magazynowe mają handling time 1 dzień, a produkty na zamówienie – 10 dni. Uśredniony parametr nie oddaje rzeczywistości dla żadnej z kategorii.

5. Availability vs delivery contradiction

Produkt ma status „in_stock” w feedzie, ale na stronie widnieje informacja „dostępny za 2-3 tygodnie” lub „na zamówienie”. Technicznie produkt jest dostępny do zakupu, ale czas dostawy jest znacząco dłuższy niż sugeruje status availability. Agent AI, który widzi „in_stock”, zakłada standardowy czas dostawy. O konsekwencjach rozbieżności między deklarowaną a faktyczną dostępnością pisaliśmy w kontekście data freshness w AI Mode.

Jak AI może porównywać „najtańszy” z „najszybszy”?

Gdy użytkownik pyta o „najtańszy” produkt, agent AI waży cenę produktu i (jeśli ma dane) koszt wysyłki. Gdy pyta o „najszybszy”, waży handling time i transit time. Problem pojawia się przy zapytaniach łączonych: „najlepszy stosunek ceny do czasu dostawy” lub „tani i szybki”.

Scenariusze porównania

Sklep	Cena produktu	Koszt wysyłki	Łączny koszt	ETA (max)	Odpowiedź na „najtańszy”	Odpowiedź na „najszybszy”
A	129 zł	14,99 zł	143,99 zł	6 dni roboczych	Tak (jeśli agent liczy łączny koszt) lub Nie (jeśli liczy cenę produktu)	Nie
B	139 zł	0 zł	139 zł	2 dni robocze	Tak (jeśli liczy łączny koszt)	Tak
C	125 zł	19,99 zł	144,99 zł	4 dni robocze	Nie	Nie

Problem: nie wiemy, jak ChatGPT waży te wymiary. Nie istnieje publiczna dokumentacja algorytmu rankingowego. Obserwacja sugeruje, że przy zapytaniu „najtańszy” agent prezentuje produkty od najniższej ceny produktu (nie łącznego kosztu), ale to wymaga systematycznej weryfikacji. W kontekście pozycjonowania w AI oznacza to, że kompletność danych o dostawie może wpływać na to, czy oferta w ogóle zostanie zaprezentowana.

Weryfikacja tego mechanizmu wymaga kontrolowanego testu: wyboru produktów z co najmniej trzema sprzedawcami, zadania pytań „najtańszy [produkt]” i „najszybsza dostawa [produkt]” w kilku powtórzeniach, a następnie porównania odpowiedzi ChatGPT z danymi z feedów i stron. Na dzień publikacji nie dysponujemy wynikami takiego testu – to kierunek dalszych badań.

Order tracking – sygnał zaufania, którego AI jeszcze nie mierzy

Order tracking to informacja o statusie realizacji zamówienia po zakupie. W tradycyjnym e-commerce to domena e-maili transakcyjnych i stron śledzenia przesyłek. W agentic commerce tracking staje się potencjalnym sygnałem zaufania.

Dlaczego tracking ma znaczenie dla AI

Jeśli agent AI rekomenduje sklep (a personalizacja rekomendacji AI uwzględnia historię interakcji), a użytkownik doświadcza: braku informacji o statusie zamówienia, opóźnień bez powiadomienia, niespójności między deklarowanym ETA a rzeczywistym czasem dostawy – zaufanie do rekomendacji AI spada. Na poziomie systemowym: jeśli platforma gromadzi dane o jakości realizacji zamówień (np. przez Shopify, Google), może wykorzystać je do scoringu sprzedawcy. Temat oceny wiarygodności sprzedawcy przez AI rozwijamy w artykule o merchant trust score.

Co jest dostępne obecnie

• Shopify: zamówienia z agentic storefronts pojawiają się w panelu Shopify z pełnym trackingiem (więcej o integracji Shopify z AI w artykule o agentic commerce readiness). Dane o realizacji (fulfillment rate, czas nadania) są dostępne wewnętrznie, ale nie ma publicznej dokumentacji o ich wpływie na ranking w kanałach AI.
• Google Merchant Center: Google wymaga podania shipping settings i weryfikuje je. Sklepy z historią niedotrzymywania deklarowanych terminów mogą utracić odznakę „fast shipping” lub obserwować obniżenie widoczności w Shopping.
• OpenAI/ChatGPT: brak publicznej dokumentacji o wykorzystaniu danych post-purchase do scoringu sprzedawcy. Obecny model ChatGPT commerce jest pre-purchase (discovery i redirect). Polityka handlowa OpenAI zabrania misrepresentation, w tym dot. dostępności i warunków dostawy.

Na dzień weryfikacji (sierpień 2026) żadna z platform AI nie publikuje danych o wpływie jakości realizacji zamówień na ranking produktów w odpowiedziach AI. Audyt widoczności w AI pozwala zidentyfikować, które elementy oferty są widoczne dla agentów, a które pozostają poza ich zasięgiem. To nie oznacza, że te dane nie są zbierane – oznacza, że nie ma publicznej dokumentacji.

Dane o dostawie na stronie produktu – co widzi AI, a czego nie?

Agent AI crawlujący stronę produktu widzi to, co jest dostępne w HTML. Problem: kluczowe informacje o dostawie są często ukryte za interakcjami użytkownika.

Co jest zwykle widoczne w statycznym HTML

• Informacja „darmowa wysyłka od X zł” (jeśli jest w stałym elemencie strony).
• Deklarowany czas dostawy typu „wysyłka w 24h” lub „dostawa 2-3 dni robocze” (jeśli jest w opisie lub dedykowanym bloku).
• Badge „szybka wysyłka” lub „next day delivery” (jeśli jest renderowany server-side).

Co jest zwykle ukryte

• Dokładny koszt wysyłki (wymaga podania kodu pocztowego lub wyboru metody).
• Czas dostawy do konkretnej lokalizacji (wymaga kalkulatora).
• Dostępność w punkcie odbioru (wymaga geolokalizacji).
• Cut-off time na dany dzień (dynamiczny, zależny od pory dnia).
• Status realizacji bieżących zamówień (oczywiście niedostępny publicznie).

Rekomendacja: informacje o dostawie, które mają wpływać na widoczność w AI, powinny być dostępne w statycznym HTML strony produktu – nie w dynamicznych widgetach ładowanych JavaScript-em. Dane z feedu (Merchant Center, OpenAI, Shopify Catalog) są bardziej niezawodnym źródłem niż crawling, ale feed wymaga aktywnego zarządzania. Google rozbudowuje atrybuty shipping o transit business days i handling business days, co zwiększa granularność deklaracji.

Checklista danych o dostawie dla sklepu

Google Merchant Center

1. Skonfiguruj handling time na poziomie produktu, nie tylko konta. Produkty magazynowe i na zamówienie powinny mieć różne wartości.
2. Ustaw handling_cutoff_time – bez tego Google nie wie, czy zamówienie z wieczora będzie zrealizowane tego samego dnia.
3. Zdefiniuj shipping_handling_business_days i shipping_transit_business_days, jeśli realizujesz zamówienia w weekendy.
4. Ustaw shipping price na poziomie produktu, jeśli różne produkty mają różne koszty wysyłki.
5. Regularnie weryfikuj, czy deklarowane czasy odpowiadają rzeczywistości – Google monitoruje spójność. Metodologię weryfikacji danych produktowych opisujemy w kontekście fact-checku danych z wielu źródeł.

Strona produktu

1. Umieść informację o czasie dostawy w statycznym HTML strony produktu (nie w widgecie JS).
2. Jeśli oferujesz darmową wysyłkę od progu, podaj próg obok informacji o dostawie.
3. Nie deklaruj „wysyłka w 24h”, jeśli dotyczy to tylko zamówień złożonych przed godziną X. Podaj cut-off.
4. Odróżnij availability (dostępność do zakupu) od delivery time (czas dostarczenia). „In stock” ≠ „dostarczymy jutro”.
5. Dodaj structured data (schema.org) dla shippingDetails, jeśli to możliwe. OfferShippingDetails pozwala zdefiniować deliveryTime, shippingRate i shippingDestination.

Feed OpenAI / Shopify Catalog

1. Upewnij się, że metody wysyłki, koszty i szacowane czasy dostawy są podane w feedzie.
2. Nie deklaruj darmowej wysyłki w feedzie, jeśli obowiązuje ona od progu zamówienia – to misrepresentation.
3. Aktualizuj dane o dostawie tak samo regularnie jak dane o cenach i dostępności (specyfikacja feedu OpenAI).

Case study: spójność danych o dostawie w feedzie, na stronie i w odpowiedzi AI

Metodologia case study zakłada analizę pięciu sklepów (po dziesięć produktów na sklep) z pomiarami w różne dni tygodnia i o różnych porach dnia, aby uwzględnić wpływ cut-off time na deklaracje dostawy.

Na podstawie danych z kont Merchant Center, którymi zarządzamy, możemy wskazać realne wzorce. Spośród analizowanych kont: Sterkowski (5000 produktów, feed score 94), DoStudni.pl (4515 produktów, feed score 94), Parrot Planet (3803 produkty, feed score 100) i Skoszone.pl (366 produktów, feed score 91) — żadne nie konfiguruje handling time na poziomie pojedynczego produktu. Wszystkie korzystają z ustawień na poziomie konta, co oznacza, że produkt magazynowy i produkt na zamówienie mają identyczny deklarowany czas realizacji.

Konsekwencja: gdy agent AI porównuje czapkę Sterkowski (produkt szyty na zamówienie, realny handling time 5-7 dni) z produktem Parrot Planet (towar magazynowy, realny handling time 1 dzień), oba mają w feedzie ten sam max_handling_time z poziomu konta. AI nie ma podstaw, żeby preferować szybszą opcję — bo w feedzie obie wyglądają identycznie.

Dodatkowy wzorzec: żadne z analizowanych kont nie definiuje handling_cutoff_time. Oznacza to, że zamówienia złożone o 22:00 i o 10:00 są traktowane przez systemy AI tak samo, mimo że w rzeczywistości zamówienie wieczorne jest realizowane dopiero następnego dnia roboczego.

Schema.org: OfferShippingDetails – jak strukturyzować dane o dostawie

Schema.org oferuje typ OfferShippingDetails, który pozwala strukturyzować dane o dostawie w sposób zrozumiały dla wyszukiwarek i agentów AI. Spójność danych strukturalnych z treścią strony jest tematem, który omawiamy szerzej w artykule o DOM, Product Schema i spójności danych. Jest to rozszerzenie typu Offer, które definiuje warunki wysyłki dla konkretnej oferty.

Kluczowe właściwości

Właściwość	Typ	Opis
shippingRate	MonetaryAmount	Koszt wysyłki (wartość + waluta)
deliveryTime	ShippingDeliveryTime	Szacowany czas dostawy
shippingDestination	DefinedRegion	Region dostawy (kraj, kod pocztowy)
doesNotShip	Boolean	Czy produkt nie jest wysyłany do danego regionu
transitTimeLabel	Text	Etykieta czasu tranzytu (np. „standard”, „express”)

ShippingDeliveryTime z kolei pozwala zdefiniować: handlingTime (QuantitativeValue – min/max w dniach), transitTime (QuantitativeValue), businessDays (OpeningHoursSpecification – dni i godziny), cutoffTime (czas graniczny). Pełna specyfikacja dostępna w schema.org/OfferShippingDetails.

Wdrożenie OfferShippingDetails nie gwarantuje lepszej widoczności w AI – ale zapewnia, że dane o dostawie są dostępne w formacie strukturyzowanym, który systemy AI mogą odczytać bez parsowania tekstu naturalnego ze strony. Jeśli potrzebujesz wsparcia przy wdrażaniu danych strukturalnych, konsultacje SEO pozwalają zaplanować implementację krok po kroku.

Ramka patentowa: kontekst mechanizmów przetwarzania atrybutów dostawy

Poniższe patenty opisują mechanizmy techniczne. Nie dowodzą, że są obecnie używane w ChatGPT, Google AI Mode ani żadnej innej konkretnej powierzchni. Wykorzystujemy je jako kontekst architektoniczny.

US11249993B2 – izolowane atrybuty i fakty

Patent opisuje system ekstrakcji i izolacji poszczególnych atrybutów z dokumentu produktowego. W kontekście danych o dostawie: system może wyodrębnić „czas dostawy: 2-3 dni robocze” jako izolowany fakt, nawet jeśli informacja jest ukryta w długim opisie produktu. Patent: klasa Direct.

US20240205175A1 – dynamiczne pola z wielu źródeł

Patent opisuje mechanizm łączenia danych z wielu źródeł w dynamiczny zestaw atrybutów. W kontekście dostawy: system może połączyć cenę z feedu, koszt wysyłki ze strony i czas dostawy z Merchant Center w jedną kartę porównawczą. Patent: klasa Supporting.

US20260087404A1 – wartości czasowe w modelowaniu treści

Patent opisuje przetwarzanie wartości temporalnych (czasowych) w kontekście treści. W kontekście dostawy: „wysyłka w 24h” to wartość temporalna, która wymaga kontekstu (od kiedy? w jakich dniach? z jakim cut-off?). System musi rozumieć, że „24h” nie zawsze oznacza „jutro”. Patent: klasa Directional.

US12561387B2 – działania i parametry obsługiwane przez zasób

Patent opisuje indeksowanie akcji dostępnych dla zasobu. W kontekście dostawy: system rozpoznaje, że dla produktu z handlerem „buy” dostępne są parametry „shipping method”, „delivery address” i „estimated delivery date”. Agent może prezentować te parametry użytkownikowi jako część rekomendacji. Patent: klasa Direct.

Co może zrobić sklep – działania według priorytetu

Priorytet	Działanie	Koszt	Wpływ
Wysoki	Skonfigurować handling time na poziomie produktu w Merchant Center	Niski (jednorazowa konfiguracja)	Dokładniejsze ETA w Google Shopping i AI Mode (dokumentacja)
Wysoki	Ustawić handling_cutoff_time	Niski	Google wie, które zamówienia będą nadane tego samego dnia
Wysoki	Zweryfikować spójność: koszt wysyłki w feedzie = na stronie	Niski-średni (audyt)	Eliminacja misrepresentation
Średni	Dodać OfferShippingDetails w schema.org	Średni (dev)	Strukturyzowane dane o dostawie dla AI crawlerów
Średni	Umieścić czas dostawy w statycznym HTML strony produktu	Niski	Dane widoczne dla crawlerów AI
Średni	Oddzielić handling time dla produktów magazynowych vs na zamówienie	Niski-średni	Realistyczne ETA zamiast uśrednionego
Niski	Monitorować delivery promise vs rzeczywisty czas nadania	Ciągły	Ochrona reputacji i potencjalne sygnały scoringowe

Czego nie robić

• Nie deklarować „wysyłka w 24h”, jeśli nie dotyczy to wszystkich zamówień. Deklaracja w feedzie musi odpowiadać najgorszemu realistycznemu scenariuszowi (zamówienie po cut-off, w piątek wieczorem).
• Nie ustawiać darmowej wysyłki w feedzie, jeśli obowiązuje od progu. To misrepresentation – Google może obniżyć widoczność, a ChatGPT zaprezentuje nieprawdziwą informację.
• Nie ignorować handling_cutoff_time. Bez cut-off systemy nie wiedzą, czy zamówienie z wieczora będzie zrealizowane dziś czy jutro.
• Nie traktować „in_stock” jako równoważnika „szybka dostawa”. Produkt na zamówienie z 14-dniowym czasem realizacji może mieć status in_stock.
• Nie kopiować danych o dostawie z konta na wszystkie produkty. Różne kategorie produktów mają różne czasy realizacji.
• Nie obiecywać, że dodanie danych o dostawie poprawi pozycję w AI. Dane o dostawie są warunkiem kompletności oferty, nie czynnikiem rankingowym udokumentowanym publicznie. Kompleksowy audyt SEO powinien uwzględniać spójność danych logistycznych między feedem a stroną.

Najczęstsze pytania o dane dostawy w AI commerce

Ograniczenia tego artykułu

• Artykuł opiera się na dokumentacji Google Merchant Center i OpenAI z weryfikacją na dzień 17 sierpnia 2026. Atrybuty feedowe i ich wymagania mogą się zmienić.
• Nie mamy dostępu do algorytmu rankingowego ChatGPT ani Google AI Mode. Nie wiemy, jak systemy AI ważą dane o dostawie w porównaniu z ceną i innymi atrybutami.
• Case study wymaga kontrolowanych pomiarów z różnymi kodami pocztowymi i dniami tygodnia. Sekcja case study opisuje metodologię planowanego badania – wyniki zostaną uzupełnione po zebraniu danych. O pomiarze efektywności kanałów agentic commerce w GA4 piszemy w artykule o atrybucji agentic commerce.
• Nie wykonywaliśmy zakupów testowych. Dane o rzeczywistym czasie realizacji wymagają zgody sklepów i nie mogą być zbierane automatycznie.
• Wpływ danych post-purchase (tracking, delivery quality) na ranking AI nie jest udokumentowany publicznie przez żadną platformę.