Покупка через ChatGPT і Google: як підготувати магазин до ACP, UCP і AP2
Два роки питання про штучний інтелект і електронну торгівлю звучало так: чи приведуть чат-інтерфейси трафік. Тепер це питання другорядне. Головне інше: чи здатен агент завершити покупку з вашого каталогу так, щоб жодна людина не відкрила вашу вітрину, і чи технічно готовий ваш магазин таке замовлення прийняти.
На це відповідають три протоколи, за якими стоїть майже вся значуща частина індустрії. Вони перебувають на різних стадіях, вирішують різні рівні задачі і не є конкурентами в тому сенсі, у якому це подають публікації. Далі – що саме кожен із них вимагає від продавця.
Три протоколи поруч
| ACP | UCP | AP2 | |
|---|---|---|---|
| Повна назва | Agentic Commerce Protocol | Universal Commerce Protocol | Agent Payments Protocol |
| Хто стоїть за ним | OpenAI і Stripe, відкритий код за ліцензією Apache 2.0 | Рада управління з представників Google, Shopify і Stripe; технічна рада з Amazon, Meta, Microsoft, Target, Etsy, Salesforce і Wayfair | Google, з екосистемою навколо A2A, UCP і FIDO Alliance |
| Що стандартизує | Як агент читає каталог, проходить оформлення і приймає делеговану оплату | Сумісність між комерційними системами через оголошувані можливості | Доказ того, що людина санкціонувала те, що агент збирається оплатити |
| Що віддає продавець | Товарний фід, ендпоінти оформлення за специфікацією і платіжного провайдера з делегованою оплатою | Профіль можливостей із переліком того, що підтримується: Checkout, Identity Linking, Order, Payment Token Exchange | Прямо нічого; протокол обмежує те, чим обмінюються агент і платіжна мережа |
| Рівень | Продавець – агент | Система – система | Довіра і авторизація |
| Статус | Специфікації опубліковані, працює в ChatGPT, відкритий стандарт | Можливості й розширення опубліковані, управління формалізоване | Версія 0.2, відкритий протокол, референсні реалізації |
ACP: чого насправді просять OpenAI і Stripe
Документація OpenAI щодо комерції ділить протокол на три специфікації. Продавець реалізує Agentic Checkout Spec. Платіжний провайдер реалізує Delegated Payment Spec. І всі передають дані про товари через Product Feed Spec. Сайт самого протоколу описує його як відкритий стандарт для програмних комерційних сценаріїв між покупцями, AI-агентами і бізнесами, спроєктований спільнотою під ліцензією Apache 2.0 і сумісний і з REST, і з MCP.
Дві деталі варто виправити, бо вони ходять світом у спотвореному вигляді. Специфікація товарного фіда приймає файл .txt або .tsv у UTF-8 із табуляцією як роздільником або .csv із комою, а також їхні gzip-варіанти. На момент написання вона не перелічує XML і JSON серед форматів фіда, попри те що це стверджують кілька популярних переказів. І ми не знайшли опублікованого граничного інтервалу оновлення на кшталт широко цитованих п’ятнадцяти хвилин. Якщо ваш план залежить від будь-якої з цих деталей, читайте специфікацію, а не переказ.
Обов’язкові поля цілком буденні, і в цьому суть: id, назва, опис, посилання, посилання на зображення, наявність, ціна, бренд і назва продавця, плюс два прапорці, які визначають, чи придатний товар для пошуку і для оформлення. Умовно – GTIN або MPN. Магазин із дисциплінованими даними про товари вже має більшу частину цього. Магазин, де опис товару живе у PDF, не має нічого.
UCP: протокол із цікавим списком учасників
UCP варто розуміти через його управління, а не через новини про запуск. Опублікований список мейнтейнерів саджає в раду управління Google, Shopify і Stripe, у технічну раду з торгівлі – представників Amazon, Meta, Microsoft, Target, Etsy, Salesforce і Wayfair, а в окрему раду з харчування – Square, Toast, DoorDash і Uber Eats. Це не ініціатива одного вендора, це майже вся сторона попиту і майже вся сторона пропозиції в одній кімнаті.
Репозиторій специфікації описує UCP як відкритий стандарт сумісності між комерційними суб’єктами, побудований із можливостей (Checkout, Identity Linking, Order, Payment Token Exchange) і розширень (Discounts, Fulfillment). Наслідок для продавця – це радше проєктне рішення, ніж інтеграція: бізнес оголошує через стандартизований профіль, які можливості він підтримує, а платформи самі це знаходять і налаштовуються. Ви публікуєте контракт про те, на що здатен ваш магазин, а не пишете окрему інтеграцію під кожного агента.
AP2: рівень, від якого залежить, кого судитимуть
Незручне питання агентної комерції – хто відповідає, коли агент купив не те. AP2, опублікований Google 16 вересня 2025 року і нині у версії 0.2, є спробою відповісти на нього криптографією, а не умовами договору.
Саме тут більшість вихідних довідок застаріли, тож перевіряйте до того, як почнете будувати. Поточна специфікація тримається на Checkout Mandate і Payment Mandate, кожен із яких існує у відкритому і закритому варіанті залежно від того, чи була людина присутня в момент покупки. AP2 називає їх верифікованими цифровими посвідченнями: захищеними від підробки криптографічно підписаними об’єктами, що подорожують разом із транзакцією. Ранні описи про три мандати з назвами Intent, Cart і Payment у вигляді W3C Verifiable Credentials були точними для запуску у вересні 2025 року і більше не описують протокол коректно. Ідея вціліла, форма змінилася.
Для продавця AP2 – це переважно те, що відбувається довкола вас, а не те, що ви впроваджуєте. Практичне значення в іншому: це механізм, завдяки якому замовлення від агента приходить із доказами, і саме тому еквайри й платіжні мережі взагалі погоджуються його обробляти.
Є ще один наслідок, про який рідко пишуть. Якщо покупку завершує агент, ваша сторінка товару перестає бути місцем переконання і стає джерелом даних. Усе, на чому тримався роздрібний онлайн-продаж – фотографії, компонування, банер із акцією, соціальні докази – до агента не доходить узагалі. Доходять поля: ціна, наявність, строк доставки, умови повернення, характеристики. Магазини, які роками вкладалися у вітрину і не вкладалися у дані, виявлять, що конкурують у середовищі, де їхня єдина перевага невидима. Це не привід кидати дизайн, бо люди нікуди не діваються, але це привід перестати вважати структуровані дані технічною формальністю.
Де вже перебувають платформи
Весняний випуск Shopify 2026 року робить напрямок явним. Там з’явився Catalog API, описаний як дані про товари, структуровані для агентів, підтримка UCP для оформлення на додаткових поверхнях і Shop Pay усередині AI-каналів, щоб покупка завершувалася просто в розмові. Як би ви не ставилися до маркетингу, платформа зі значною часткою ринку вирішила, що це базовий рівень, і продавців на інших платформах питатимуть, чому в них так не можна.
Що справді варто зробити цього кварталу
| Робота | Чому зараз | Ціна зволікання |
|---|---|---|
| Привести дані про товари до рівня полів специфікації фіда | Усі протоколи читають ті самі поля і жоден не вигадає відсутній GTIN | Висока. Це повільна ручна робота, яку не прискорити перед запуском |
| Опублікувати машиночитний фід | Придатний одночасно для реклами, маркетплейсів і агентів | Низька, але без нього не працює решта |
| Виправити структуровані дані на картках товару | Саме ціну, наявність і відгуки цитують у відповідь | Помірна. Див. наш гайд про те, що розмічати за Schema.org |
| Зробити залишки і ціни правдивими в реальному часі | Агент, який продав відсутній товар, створює не продаж, а повернення коштів | Висока. Зазвичай це задача інтеграцій, а не сайту |
| Виділити AI-переходи в аналітиці | Не можна керувати каналом, якого не видно | Низька, і це єдиний спосіб дізнатися, коли канал стане реальним |
| Реалізувати ендпоінти оформлення | Лише після того, як зроблено чотири рядки вище | Сьогодні низька. Це останній крок, а не перший |
Непафосна правда в тому, що чотири з цих шести рядків – звичайна гігієна даних і інтеграцій, яка окупається незалежно від того, чи прийде агентна комерція вчасно. Точність залишків між сайтом, складською системою і обліком – та сама задача, що й п’ять років тому, і ми розбирали її в матеріалі про зв’язку сайту з CRM і складом. Протоколи лише підвищили ціну помилки, бо людина пробачає застарілий залишок, а автомат відкриває суперечку.
Чого це поки не виправдовує
Команда Adobe Digital Insights повідомляє про дуже високі темпи річного зростання AI-переходів у роздрібі США і про кращу конверсію з них порівняно з іншими каналами. Це показники вендора з клієнтів Adobe Analytics, і читати їх треба саме з цією поміткою; власне резюме аналізу від Adobe говорить про тризначне зростання і стабільно кращу залученість та конверсію на масиві понад трильйон візитів, не стверджуючи при цьому, що обсяг великий.
А обсяг тут головне. Виміряна частка візитів з AI-джерел на незалежних наборах даних досі тримається близько половини відсотка, і ми докладно розібрали це в матеріалі про те, що сталося з електронною комерцією у 2026 році. Дуже високий темп зростання на дуже малій базі – це привід дешево підготуватися, а не привід перерозподіляти бюджет. Та сама дисципліна потрібна і з боку пошуку, про що ми писали в матеріалі про те, що пошук без кліків означає для органічного трафіку.
Помилка, якої варто уникнути, – вважати це маркетинговим проєктом. Ані в ACP, ані в UCP, ані в AP2 немає нічого від кампанії. Є якість каталогу, правдиві залишки, оформлення, яким може керувати третя сторона, і аналітика, здатна побачити, що сталося. Ширший погляд на те, які тренди електронної комерції справді впливають на продажі, робить ту саму різницю на більшому наборі мод.
Коротко
ACP звернений до продавця: фід, ендпоінт оформлення і платіжний провайдер, відкритий код від OpenAI і Stripe під Apache 2.0. UCP – рівень сумісності під управлінням Google, Shopify і Stripe із більшістю галузі в технічних радах, і він просить оголошувати можливості, а не будувати інтеграції. AP2 – рівень довіри, зараз версія 0.2 з мандатами Checkout і Payment у вигляді верифікованих цифрових посвідчень, і він переважно відбувається довкола вас. Весняний випуск Shopify 2026 року вже містить Catalog API і підтримку UCP.
Дві поширені тези перевірки не пройшли: специфікація фіда наразі не перелічує XML і JSON, а опублікованого обмеження на оновлення раз на п’ятнадцять хвилин ми не знайшли. Читайте специфікації.
Робота, яка окупається в будь-якому разі, – це дані про товари, реальні залишки і оформлення, яке зовнішня система здатна завершити без людини. Це звичайна інженерія електронної торгівлі, і саме нею ми займаємося, коли створюємо і перебудовуємо інтернет-магазини.
