Покупка през ChatGPT и Google: как да подготвите магазина си за ACP, UCP и AP2

Две години въпросът за изкуствения интелект и електронната търговия звучеше така: ще донесат ли чат интерфейсите трафик. Този въпрос вече е второстепенен. Същественият е друг: може ли агент да завърши покупка от вашия каталог, без човек изобщо да отвори витрината ви, и технически способен ли е магазинът ви да приеме такава поръчка.

На това отговарят три протокола, зад които стои почти цялата значима част от индустрията. Те са на различни етапи, решават различни слоеве и не са конкуренти в смисъла, в който ги представят публикациите. Следва какво точно изисква всеки от тях от търговеца.

Трите протокола едно до друго

ACP: какво всъщност искат OpenAI и Stripe

Документацията на OpenAI за търговията дели протокола на три спецификации. Търговецът реализира Agentic Checkout Spec. Доставчикът на платежни услуги реализира Delegated Payment Spec. А всички подават данни за продуктите през Product Feed Spec. Сайтът на самия протокол го описва като отворен стандарт за програмни търговски потоци между купувачи, AI агенти и бизнеси, проектиран от общност под лиценз Apache 2.0 и съвместим и с REST, и с MCP.

Две подробности заслужават поправка и начинът, по който се изкривиха, е по-поучителен от самите тях. Почти всеки преразказ твърди, че фийдът приема TSV, CSV, XML или JSON и се обновява на петнадесет минути. През октомври 2025 г. това беше вярно. Сега не е. Текущите указания за качване на файлове гласят: предпочитайте parquet, за предпочитане компресиран, поддържат се още jsonl.gz, csv.gz и tsv.gz, а препоръчителната честота е поне веднъж дневно. XML и обикновеният JSON ги няма, както и числото петнадесет минути. Отделен път, съвместим с Google Merchant, все още приема .txt или .tsv в UTF-8 с табулация или .csv със запетая и техните gzip варианти.

ACP пуска датирани ревизии приблизително на всеки шест до осем седмици, откакто Stripe и OpenAI го публикуваха на 29 септември 2025 г. План за интеграция, писан по преразказ, а не по датирана версия на спецификацията, ще остарее в рамките на тримесечие, а се променя точно това, от което зависи потокът ви от данни.

Задължителните полета са напълно делнични и точно това е смисълът: id, заглавие, описание, връзка, връзка към изображение, наличност, цена, марка и име на продавача, плюс два флага, които решават дали артикулът е допустим за търсене и за плащане. Условно GTIN или MPN. Магазин с дисциплинирани продуктови данни вече има повечето от това. Магазин, в който описанието на продукта живее в PDF, няма нищо.

UCP: протоколът с интересния списък участници

UCP е обявен от Google на 11 януари 2026 г., разработен съвместно с Shopify, Etsy, Wayfair, Target и Walmart и подкрепен от над двадесет други компании. Често го датират погрешно към майската конференция на Google за разработчици, но там беше представен Universal Cart: той е потребителският продукт, а UCP е инфраструктурата под него.

UCP се разбира най-добре през управлението му, а не през новините за пускането. Публикуваният списък с поддържащи слага в управителния съвет Google, Shopify и Stripe, в техническия съвет по търговия представители на Amazon, Meta, Microsoft, Target, Etsy, Salesforce и Wayfair, а в отделен съвет по храните Square, Toast, DoorDash и Uber Eats. Това не е инициатива на един доставчик, това е почти цялата страна на търсенето и почти цялата страна на предлагането в една стая.

Хранилището със спецификацията описва UCP като отворен стандарт за съвместимост между търговски субекти, изграден от възможности (Checkout, Cart, Catalog, Identity Linking, Order) и разширения (Discounts, Fulfillment), независим от транспорта и работещ върху REST, MCP и A2A. Следствието за търговеца е по-скоро проектантско решение, отколкото интеграция: бизнесът обявява чрез стандартизиран профил какви възможности поддържа, а платформите сами го откриват и се конфигурират. Публикувате договор за това на какво е способен магазинът ви, вместо да пишете отделна интеграция за всеки агент.

AP2: слоят, от който зависи кого ще съдят

Неудобният въпрос на агентната търговия е кой отговаря, когато агентът купи грешното. AP2, публикуван от Google на 16 септември 2025 г. и вече във версия 0.2, е опитът да се отговори с криптография, а не с общи условия.

Точно тук изходните справки на повечето хора са остарели, така че проверявайте, преди да строите. При пускането AP2 дефинираше три мандата: Intent Mandate, Cart Mandate и Payment Mandate. Текущата спецификация дефинира два: Checkout Mandate и Payment Mandate, всеки в отворена и в затворена форма в зависимост от това дали човекът е присъствал в момента на покупката. Intent и Cart вече не съществуват като обекти в спецификацията.

Една поправка заслужава да се направи твърдо, защото се повтаря почти навсякъде. Тези мандати не са W3C Verifiable Credentials и никога не са били. AP2 ги нарича верифицируеми цифрови удостоверения от самото начало, а текущата спецификация казва ясно, че за защита на мандатите Checkout и Payment се използва SD-JWT, конструкция на IETF. Ако доставчик ви казва, че интеграцията му стъпва на W3C VC, той е чел преразказ, а не спецификация.

Смени се и кой води проекта. През април 2026 г. Google дари AP2 на FIDO Alliance, където той продължава като стандарт на общността, а не като продукт на един доставчик. Първоначалното обявяване посочваше над шестдесет участващи организации, сред които Mastercard, American Express, PayPal, Adyen и Worldpay.

За търговеца AP2 е предимно нещо, което се случва около вас, а не нещо, което внедрявате. Практическото му значение е друго: това е механизмът, чрез който поръчка от агент пристига с доказателства, и точно затова обслужващите банки и картовите мрежи изобщо се съгласяват да я обработват.

Има и още едно следствие, за което рядко се пише. Ако покупката се завършва от агент, продуктовата ви страница престава да бъде място за убеждаване и се превръща в източник на данни. Всичко, върху което стоеше онлайн търговията на дребно, тоест снимките, подредбата, промо банерът, социалните доказателства, изобщо не стига до агента. Стигат полетата: цена, наличност, срок на доставка, условия за връщане, характеристики. Магазините, които години наред са влагали във витрината и не са влагали в данните, ще открият, че се състезават в среда, в която единственото им предимство е невидимо.

Къде вече са платформите

Пролетното издание на Shopify за 2026 г., публикувано на 17 юни 2026 г. под името Everywhere, прави посоката явна. В него има Catalog API, описан като продуктови данни, структурирани за агенти, поддръжка на UCP за плащане на допълнителни повърхности и Shop Pay вътре в AI каналите, за да може покупката да завърши направо в разговора. Съобщението за разработчици го формулира още по-направо: достъпът до каталога се отваря с API ключ и без одобрение, а UCP е описан като стандартът, който Shopify е разработил съвместно с Google. Каквото и да мислите за маркетинга, платформа със значителен пазарен дял е решила, че това е базово ниво, и търговците на други платформи ще бъдат питани защо при тях не може.

Какво наистина си струва това тримесечие

Скучната истина е, че четири от тези шест реда са обикновена хигиена на данните и интеграциите, която се изплаща независимо дали агентната търговия ще дойде навреме. Точността на наличностите между сайт, складова система и счетоводство е същата задача като преди пет години и я разгледахме в текста за свързването на сайт с CRM и склад. Протоколите само вдигнаха цената на грешката, защото човек прощава остаряла наличност, а автомат подава оспорване.

Какво това още не оправдава

Екипът на Adobe Digital Insights съобщи през април 2026 г., че трафикът от AI източници към търговските сайтове в САЩ е нараснал с 393% на годишна база през първото тримесечие на 2026 г., а през март 2026 г. е конвертирал с 42% по-добре от не-AI каналите като платено търсене и имейл, при положение че година по-рано е конвертирал с 38% по-зле. Това са показатели на доставчик от клиенти на Adobe Analytics и трябва да се четат точно с тази бележка; собственото резюме на анализа от Adobe говори за трицифрен растеж и последователно по-добра ангажираност и конверсия върху масив от над трилион посещения, без да твърди, че обемът е голям.

А обемът е същественото. Измереният дял посещения от AI източници в независимите набори данни още стои около половин процент и това разгледахме подробно в текста за това какво се случи с електронната търговия през 2026 г. Много висок темп на растеж върху много малка база е повод за евтина подготовка, а не за преразпределяне на бюджет. Същата дисциплина важи и от страната на търсенето, за което писахме в текста за това какво означава търсенето без клик за органичния трафик.

Грешката, която трябва да се избегне, е това да се третира като маркетингов проект. Нито в ACP, нито в UCP, нито в AP2 има каквото и да е от кампания. Има качество на каталога, верни наличности, плащане, което трета страна може да управлява, и аналитика, способна да види какво се е случило. По-широкият ни поглед върху това кои тенденции в електронната търговия наистина влияят на продажбите прави същото разграничение върху по-голям набор от моди.

Накратко

ACP е обърнат към търговеца: фийд, точка за плащане и платежен доставчик, отворен код от OpenAI и Stripe под Apache 2.0. UCP е слоят на съвместимостта, управляван от Google, Shopify и Stripe с по-голямата част от индустрията в техническите съвети, и той иска да обявявате възможности, а не да строите интеграции. AP2 е слоят на доверието, сега във версия 0.2 с мандати Checkout и Payment под формата на верифицируеми цифрови удостоверения, дарен на FIDO Alliance, и той се случва предимно около вас. Пролетното издание на Shopify за 2026 г. вече съдържа Catalog API и поддръжка на UCP.

Три широко разпространени твърдения не издържаха проверка. Форматите XML и JSON и обновяването на петнадесет минути бяха реални през октомври 2025 г. и оттогава са заменени с parquet и дневна честота. Мандатите на AP2 никога не са били W3C Verifiable Credentials. А UCP беше обявен през януари 2026 г., а не на майската конференция на Google. Четете датирани спецификации, а не преразкази.

Работата, която се изплаща при всички положения, са продуктовите данни, реалните наличности и плащане, което външна система може да завърши без човек. Това е обикновено инженерство в електронната търговия и точно с него се занимаваме, когато изграждаме и преработваме онлайн магазини.