Агентная коммерция. Как подготовить бизнес к покупателю, который… не человек
Практическое руководство для тимлидов и маркетинговых директоров
Иван Сергеевич Дискин

© Иван Сергеевич Дискин, 2026

ISBN 978-5-0071-2876-6

Создано в интеллектуальной издательской системе Ridero

Агентная коммерция. Как подготовить бизнес к покупателю, который… не человек.
Практическое руководство для тимлидов и маркетинговых директоров

Оглавление

Часть I. Новый покупатель

Глава 1. Покупатель, который… не человек

Момент, который стоит увидеть своими глазами

Прежде чем читать дальше, проведите короткий эксперимент. Откройте ChatGPT и попросите его купить конкретный товар из вашей категории — не найти, не порекомендовать, а именно подобрать, оформить заказ и довести покупку до максимально возможного этапа.

Если ваша ниша связана с розничной торговлей, вы, скорее всего, увидите, что модель способна подобрать подходящий вариант, сравнить предложения, заполнить корзину и в поддерживаемых сценариях провести оформление заказа прямо внутри диалога. Для пользователя это всё чаще выглядит как единый разговор, а не последовательность переходов между сайтами.

Это уже не гипотетический сценарий «через несколько лет». По состоянию на середину 2026 года покупательские сценарии внутри ChatGPT доступны многомиллионной аудитории, а число запросов, связанных с выбором и покупкой товаров, исчисляется десятками миллионов в день. Параллельно Google и отраслевые партнёры развивают открытые протоколы, позволяющие ИИ-агентам взаимодействовать с каталогами, оформлением заказов и другими коммерческими системами.

Вопрос о том, будут ли ИИ-агенты совершать покупки от имени людей, уже практически снят. Теперь главный вопрос звучит иначе: готов ли ваш бизнес к покупателю, который приходит не через браузер, а через агента?

Три типа покупателя, который больше не человек

Термин «агентная коммерция» часто используют как единое понятие, хотя на практике он объединяет три принципиально разных сценария. Для бизнеса это важно: требования к данным, интеграциям и процессам в каждом случае отличаются.

Потребительские агенты действуют от имени конкретного человека. Пользователь формулирует задачу естественным языком, а агент сравнивает предложения, выбирает подходящий вариант и помогает оформить покупку. В одних сценариях человек подтверждает ключевые действия, в других агент выполняет почти весь процесс самостоятельно — в пределах предоставленных полномочий.

Корпоративные агенты работают от имени организации. Их задача — автоматизировать повторяющиеся закупки: пополнение расходных материалов, продление программных подписок, закупку типовых услуг или оплату согласованных счетов. Здесь решения принимаются не в свободном диалоге, а по заранее установленным правилам, бюджетам и политикам компании.

Машинные агенты взаимодействуют друг с другом без участия человека. Они оплачивают API, вычислительные ресурсы, доступ к данным и другие цифровые сервисы, используя инфраструктуру, рассчитанную на автоматические микроплатежи. Для большинства компаний этот сценарий пока менее актуален, чем первые два, однако именно он показывает, в каком направлении развивается экономика автономных цифровых взаимодействий.

В этой книге мы сосредоточимся прежде всего на потребительских и корпоративных агентах, поскольку именно они уже начинают менять розничную торговлю и B2B-продажи.

Почему это не то же самое, что видимость в ИИ

Термин «агентная коммерция» часто используют как единое понятие, хотя на практике он объединяет три принципиально разных сценария. Это важно, потому что требования к данным, интеграциям и бизнес-процессам в каждом случае различаются.

Потребительские агенты действуют от имени конкретного человека. Пользователь формулирует задачу естественным языком, а агент сравнивает предложения, выбирает подходящий вариант и помогает оформить покупку. В одних сценариях человек подтверждает ключевые действия, в других агент выполняет почти весь процесс самостоятельно — в пределах предоставленных полномочий.

Корпоративные агенты работают от имени организации. Их задача — автоматизировать повторяющиеся закупки: пополнение расходных материалов, продление подписок на программное обеспечение, закупку типовых услуг и оплату согласованных счетов. Здесь решения принимаются не в свободном диалоге, а по заранее установленным правилам, бюджетам и политикам компании.

Машинные агенты взаимодействуют друг с другом без участия человека. Они оплачивают обращения к API, вычислительные ресурсы, доступ к данным и другие цифровые сервисы, используя инфраструктуру, рассчитанную на автоматические микроплатежи.

Для большинства компаний именно первые два сценария станут предметом этой книги. Они уже начинают менять розничную торговлю и B2B-продажи, тогда как машинные агенты пока остаются скорее инфраструктурным направлением, чем массовым коммерческим каналом.

Масштаб, который нельзя игнорировать

Данные, появившиеся с середины 2025 года, показывают не постепенный, а очень быстрый переход к новому типу покупательского поведения. По оценкам независимых аналитических платформ, трафик на сайты ритейлеров из генеративных ИИ-систем за период с середины 2024 по середину 2025 года вырос на тысячи процентов год к году. Одновременно крупные игроки электронной коммерции сообщают о кратном росте числа заказов, инициированных через ИИ-интерфейсы и поиск.

Прогнозы также указывают на значительный экономический потенциал этого рынка. Ряд консалтинговых компаний оценивает, что к концу десятилетия агентная коммерция сможет обеспечивать сотни миллиардов долларов розничных продаж в США, а глобальный рынок — существенно больший объём.

Важны не столько сами цифры, сколько вывод из них. Самая рискованная стратегия сегодня — считать, что агентные покупки можно начать учитывать позже, когда рынок окончательно сформируется. Инфраструктура, о которой пойдёт речь в этой книге, уже работает: компании публикуют машиночитаемые каталоги, подключают агентные протоколы и перестраивают процесс оформления заказа под ИИ-агентов. Вопрос уже не в том, появится ли этот канал, а в том, насколько рано бизнес научится с ним работать.

Что вы получите к концу этой книги

каждая глава завершается практическим инструментом: протоколом, чек-листом или готовым шаблоном.

К концу книги у вас будут:

— ясная карта основных протоколов агентной коммерции и понимание, с какого из них начать;

— протокол аудита, который позволяет проверить, может ли ИИ-агент найти, оценить и оформить покупку вашего продукта;

— практический подход к адаптации каталога, ценообразования и логистики под требования агентных систем;

— система измерения агентских транзакций и оценки готовности бизнеса;

— организационная модель с понятным распределением ответственности внутри компании.

Эта книга не требует от читателя создавать собственных ИИ-агентов или глубоко погружаться в машинное обучение. Её задача — помочь подготовить коммерческую инфраструктуру к новому каналу продаж.

Первая проверка

Прежде чем двигаться дальше, проведите тот самый эксперимент, с которого началась глава, — но теперь зафиксируйте результат по простой схеме.

Попросите доступный вам ИИ-ассистент найти и, если это поддерживается, оформить покупку одного конкретного товара вашей компании. Затем ответьте на три вопроса:

— Нашёл ли агент товар и корректно ли его описал?

— Были ли цена и наличие точными на момент запроса?

— Если оформление заказа поддерживалось, удалось ли пройти этот процесс без ошибки?

Не воспринимайте отрицательный результат как неудачу. Он не означает, что ваш бизнес «не готов к ИИ», а лишь показывает, на каком этапе возникает разрыв: в данных, обнаружении товара, оформлении заказа или платёжной инфраструктуре.

Именно эти этапы мы разберём в следующей главе, где перейдём от общего представления об агентной коммерции к карте протоколов, лежащих в её основе.

Глава 2. Карта протоколов

Честное признание: единого стандарта пока не существует

Начнём с главного: единого общепринятого стандарта агентной коммерции сегодня не существует. Более того, нет убедительных оснований считать, что в ближайшей перспективе рынок сведётся к одному универсальному протоколу.

Разные технологические компании и отраслевые объединения развивают собственные протоколы и спецификации. Часть из них совместима между собой, часть решает разные задачи, а некоторые конкурируют за роль отраслевого стандарта. Это не пробел в вашей осведомлённости — таково текущее состояние рынка.

Хорошая новость в том, что большинство этих инициатив можно рассматривать не как набор несовместимых технологий, а как слои одной инфраструктуры. Одни отвечают за доступ к данным, другие — за оформление заказа, третьи — за доверие, платежи или взаимодействие между агентами.

Именно поэтому в этой главе мы будем изучать не отдельные бренды, а архитектуру. Если позже появятся новые протоколы, вам будет гораздо проще понять, какое место они занимают в общей системе.

Слой данных: MCP

В основании этой архитектуры лежит Model Context Protocol (MCP) — открытый протокол, разработанный для подключения ИИ-моделей к внешним источникам данных и инструментам. Изначально он создавался не как коммерческий стандарт, а как универсальный способ безопасно предоставлять модели актуальный контекст.

В агентной коммерции MCP решает самую базовую задачу: позволяет агенту получать в реальном времени информацию о товарах — цену, наличие, характеристики и другие структурированные данные. Без этого слоя более высокоуровневые сценарии выбора товара и оформления заказа теряют надёжность, потому что опираются на устаревшую или неполную информацию.

Практический вывод: прежде чем внедрять транзакционные протоколы, убедитесь, что каталог способен предоставлять актуальные данные через стандартизированный программный интерфейс. Именно качество этого слоя определяет, насколько уверенно агент сможет работать с вашим ассортиментом.

Слой полного цикла: UCP

Универсальный протокол коммерции (Universal Commerce Protocol, UCP) — это формирующийся открытый протокол, предназначенный для полного цикла агентной коммерции. Его цель — описать единый способ, которым ИИ-агенты могут обнаруживать товары, работать с корзиной, оформлять заказ, получать статус доставки и инициировать возвраты.

В отличие от MCP, который отвечает прежде всего за доступ к данным, UCP описывает коммерческие действия. Магазин публикует машиночитаемый манифест, в котором объявляет, какие возможности он поддерживает: поиск товаров, управление корзиной, оформление заказа, работу с заказами и другие функции. Агент читает этот манифест и понимает, как взаимодействовать с конкретным магазином без индивидуальной интеграции.

Практический смысл для бизнеса заключается не в самом названии протокола, а в принципе: вместо отдельных интеграций с каждым ИИ-ассистентом появляется возможность один раз описать свои коммерческие возможности в стандартизированном виде. Если этот подход станет массовым, небольшие магазины смогут значительно проще подключаться к агентным каналам на тех же технических основаниях, что и крупные ритейлеры.

Слой оформления заказа: ACP

Протокол агентской коммерции (Agentic Commerce Protocol, ACP) — открытый протокол, разработанный OpenAI совместно со Stripe. Он решает более узкую, но критически важную задачу: позволяет ИИ-агенту взаимодействовать с продавцом для оформления и завершения покупки.

В отличие от Универсального протокола коммерции (UCP), который описывает более широкий набор коммерческих возможностей, ACP сосредоточен на транзакционном сценарии: агент, определившись с выбором, инициирует оформление заказа и передаёт продавцу необходимые данные для его завершения.

Практически важная деталь: ACP рассчитан на подключение к существующей коммерческой инфраструктуре. Поэтому продавцу не нужно создавать отдельный магазин или полностью новую платёжную систему специально для ИИ-агентов. Если компания уже работает с поддерживаемой платёжной или торговой платформой, часть необходимой инфраструктуры может быть предоставлена на уровне этой платформы.

Слой платёжного доверия: AP2

Протокол платежей для агентной коммерции (Agent Payments Protocol, AP2), разработанный и продвигаемый Google, решает задачу, которая становится критически важной по мере распространения агентных транзакций: как убедиться, что конкретный платёж действительно санкционирован пользователем, а не стал результатом ошибки или неправомерного действия агента.

В основе AP2 лежат криптографически защищённые мандаты, которые связывают намерение пользователя с конкретной транзакцией и позволяют проверить, какие полномочия были предоставлены агенту. Это создаёт проверяемую цепочку подтверждений, которая может использоваться участниками платёжного процесса для установления того, был ли платёж авторизован надлежащим образом.

Для большинства компаний AP2 — не тот протокол, с которого следует начинать собственную интеграцию. Это прежде всего инфраструктурный слой доверия, который важно учитывать при выборе платёжного провайдера и партнёров по обработке платежей. На этапе первичной подготовки каталога и товарных данных он имеет гораздо меньшее значение.

Слой делегирования между агентами: A2A

Протокол Agent2Agent (A2A) предназначен для взаимодействия между ИИ-агентами: он позволяет одному агенту обнаруживать другого агента, понимать его возможности и передавать ему задачи. Это отдельный слой по сравнению с протоколами, которые связывают агента непосредственно с магазином или платёжной инфраструктурой.

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

Для большинства компаний, которые на первом этапе просто готовят существующий магазин к взаимодействию с ИИ-агентами, A2A не является приоритетом для немедленной интеграции. На него стоит обратить особое внимание, если компания сама создаёт экосистему агентов или планирует, что её агенты будут взаимодействовать с агентами других организаций.

Слой машинных микроплатежей: x402

x402 — открытый платёжный протокол, предназначенный для автоматических платежей между программными клиентами, в том числе ИИ-агентами. Он позволяет оплачивать доступ к API, данным, вычислительным ресурсам и другим цифровым сервисам непосредственно в рамках машинного взаимодействия, включая платежи на очень небольшие суммы.

Для большинства компаний, на которые ориентирована эта книга, x402 пока остаётся периферийным протоколом. Он прежде всего интересен бизнесам, чей продукт сам является цифровым ресурсом — например, API, сервисом обработки данных или вычислительной мощностью, — а не физическим или цифровым товаром, который человек покупает через агентный интерфейс.

Особый случай: платформы вне открытых стандартов

Отдельно стоит учитывать важное исключение: не все крупные игроки присоединяются к открытым протоколам и общим отраслевым инициативам. Некоторые крупные платформы электронной коммерции развивают собственные механизмы взаимодействия с ИИ-агентами, которые не сводятся к перечисленным выше протоколам.

Если значимая доля ваших продаж проходит через такую платформу, готовность к агентной коммерции для этого канала придётся оценивать отдельно: по правилам, интерфейсам и требованиям самой платформы. Не стоит исходить из предположения, что одна универсальная интеграция автоматически обеспечит присутствие бизнеса во всех агентных каналах.

Что происходит, даже если вы ничего не делаете

Последний, отрезвляющий факт этой главы: полное бездействие не означает полной невидимости для агентов. Существуют сервисы, которые способны взаимодействовать с существующим сайтом и выполнять действия в интерфейсе, в том числе заполнять формы оформления заказа, — примерно так же, как это делает человек в браузере. Для такого сценария со стороны компании может не требоваться специальная интеграция с агентным протоколом.

Это означает, что автоматизированные покупки через ваш сайт технически могут происходить и без специально подготовленного агентного интерфейса. При этом компания не обязательно понимает, кто именно инициировал такой сеанс, не контролирует логику действий агента и не может рассчитывать, что процесс пройдёт так же надёжно, как специально спроектированный агентный сценарий.

Поэтому осознанная интеграция — это не только возможность привлечь новый канал продаж. Это ещё и способ сделать взаимодействие с агентами предсказуемым, управляемым и наблюдаемым.

Приоритизация протоколов

Ответьте на три вопроса, чтобы определить, с какого протокола начинать.

1. На какой платформе электронной коммерции построен ваш магазин?

Если это одна из крупных, широко используемых платформ, проверьте, какие интеграции с агентными протоколами она уже поддерживает. Если нужная интеграция доступна на уровне платформы, начать с неё обычно проще, чем строить собственное подключение с нуля.

2. Где сосредоточен трафик вашей аудитории из ИИ-систем?

Если аналитика уже показывает заметный трафик из конкретного ИИ-ассистента, это веский аргумент в пользу того, чтобы в первую очередь изучить протокол или интеграционный механизм, через который этот ассистент взаимодействует с продавцами.

3. Есть ли у вас значимая доля продаж на платформе с собственной экосистемой агентов?

Если да, включите работу с этой платформой в план отдельным направлением. Не стоит рассчитывать, что интеграция с открытыми протоколами автоматически обеспечит присутствие во всех агентных каналах.

Эти три вопроса помогают определить не только технический приоритет, но и экономический смысл интеграции: начинать стоит там, где уже есть доступная инфраструктура, реальный спрос или значимый для бизнеса канал продаж.

Следующая глава переводит эту карту в конкретный пошаговый протокол диагностики: как проверить, на каком уровне готовности к каждому из этих слоёв реально находится ваш бизнес сегодня, а не в теории.

Глава 3. Аудит готовности

От разового теста к полной картине

Быстрая проверка из первой главы — попросить ассистента найти и, если это поддерживается, оформить покупку конкретного товара — даёт полезный, но неполный сигнал. Она показывает, работает ли весь путь в одном конкретном сценарии, но не позволяет понять, какой именно слой из карты второй главы стал точкой сбоя, если покупка не удалась.

Эта глава предлагает пошаговый протокол аудита, который проверяет каждый слой отдельно. В результате вместо общей тревоги «что-то не работает» вы получите точный список проблем и конкретных задач для технической команды.

Шаг 1. Проверка данных

Первый и самый фундаментальный слой — доступность точных и актуальных данных о товаре в машиночитаемой форме, о которой мы говорили в разделе про протокол контекста модели предыдущей главы. Проверьте, может ли ваша система предоставлять данные о товаре — название, цену, наличие, ключевые характеристики — через структурированный, программно читаемый интерфейс, а не только через HTML-страницу, рассчитанную на восприятие человеком.

Отдельно, и это критично, проверьте не только наличие структуры, но и скорость обновления данных. Намеренно измените цену или наличие конкретной тестовой позиции в системе управления магазином и измерьте, через какое время это изменение становится доступным агенту. Сравните полученную задержку с требованиями вашего сценария продаж: для товара с быстро меняющейся ценой или остатком даже небольшая задержка может привести к неверному предложению, ошибке при оформлении заказа или несоответствию между тем, что увидел агент, и фактическими условиями покупки.

Цель проверки — не добиться абстрактного «реального времени», а убедиться, что данные остаются достаточно актуальными на каждом этапе агентного сценария.

Шаг 2. Проверка манифеста и обнаружения

Если Если ваш магазин работает на платформе со встроенной поддержкой протокола полного цикла, проверьте, что соответствующий манифест действительно опубликован, доступен по предусмотренному протоколом адресу и проходит валидацию. Даже при корректно настроенной остальной инфраструктуре ошибка в манифесте может привести к тому, что агент не обнаружит магазин или неверно определит доступные ему возможности.

Если платформа не предоставляет встроенной поддержки такого механизма обнаружения, зафиксируйте это как отдельный технический долг. Это не означает, что остальные слои не могут быть готовы, но отсутствие стандартного механизма обнаружения может ограничивать доступность магазина для определённых агентных сценариев.

В результате проверки у вас должно быть чётко зафиксировано: существует ли манифест, корректен ли он, какие возможности магазина в нём заявлены и может ли агент обнаружить магазин и понять, какие действия ему доступны.

Шаг 3. Сквозная проверка оформления заказа

Это самый показательный и, как правило, самый трудоёмкий шаг протокола — реальная попытка пройти агентный сценарий покупки через хотя бы одного ассистента, поддерживающего соответствующую функцию. Пройдите весь доступный путь от формулировки запроса до максимально возможного этапа оформления и зафиксируйте каждый результат: на каком этапе агент корректно нашёл товар, получил актуальные цену и наличие, сформировал заказ и передал его на следующий этап. Отдельно оцените, насколько понятно пользователю представлены ключевые детали заказа и какие действия требуют его подтверждения.

Если сценарий обрывается, зафиксируйте точный момент и характер сбоя, а не только сам факт неудачи. Это поможет определить проблемный слой, но не всегда позволяет однозначно установить его причину. Например, ошибка при поиске товара может быть связана с данными или механизмом обнаружения, а сбой при оформлении — с интерфейсом оформления заказа, интеграцией с платформой или платёжной инфраструктурой.

Поэтому для каждого сбоя фиксируйте не только этап, но и наблюдаемое поведение: что запросил агент, какой ответ получил, какие данные передал дальше и на каком шаге возникла ошибка. Такая запись позволит технической команде воспроизвести проблему и проверить её уже на соответствующем уровне инфраструктуры.

Шаг 4. Проверка платёжного слоя

Убедитесь, что платёжный провайдер, через которого проходят транзакции вашего магазина, поддерживает необходимые механизмы авторизации и верификации агентских платежей, разобранные в предыдущей главе. Для распространённых платёжных решений часть такой инфраструктуры уже может быть доступна на уровне провайдера или используемой платформы и не требовать отдельной разработки со стороны продавца.

Но не стоит считать поддержку провайдера достаточной сама по себе. Проверьте, включены ли необходимые возможности в вашей конкретной конфигурации, совместимы ли они с используемым процессом оформления заказа и какие дополнительные изменения потребуются со стороны магазина. Особенно внимательно проведите эту проверку, если платёжная инфраструктура создавалась индивидуально или давно не пересматривалась.

Шаг 5. Проверка закрытых платформенных каналов

Если значимая доля продаж проходит через платформу с собственной экосистемой агентов, которую мы рассматривали в предыдущей главе как особый случай, проведите для неё отдельную версию шагов 1 и 3, следуя техническим требованиям самой платформы, а не только открытым протоколам.

Результаты этой проверки лучше фиксировать отдельно от результатов по открытым протоколам. Это разные технические направления готовности, и низкий результат по одному из них не обязательно означает низкий результат по другому. При этом их влияние на бизнес может пересекаться: один и тот же каталог, процесс оформления заказа или платёжная инфраструктура могут использоваться в нескольких каналах.

Шаг 6. Проверка неконтролируемого доступа

Последний, отдельно стоящий шаг — проверка риска, который мы обозначили в конце предыдущей главы: могут ли сторонние, не согласованные с вами сервисы автоматически взаимодействовать с формой заказа на вашем сайте.

Полностью исключить такую возможность технически сложно, поэтому задача аудита — не заблокировать любую автоматизацию, а понять текущий уровень экспозиции. Проверьте, какие автоматизированные запросы и действия допускают ключевые этапы оформления заказа, какие средства защиты и ограничения применяются и насколько подробно такие обращения фиксируются в журналах и аналитике.

Отдельно изучите историю аномальных попыток оформления заказа: необычную частоту запросов, повторяющиеся последовательности действий, признаки автоматизированного поведения и другие отклонения от обычных пользовательских сценариев. При этом не следует автоматически считать любой такой сигнал признаком работы ИИ-агента: те же характеристики могут быть свойственны ботам, скриптам или другим видам автоматизации.

Результатом этого шага должна стать оценка того, насколько компания понимает и контролирует автоматизированное взаимодействие с сайтом — как разрешённое, так и не согласованное заранее.

Сведение результата

Соберите результаты всех шести шагов в единую таблицу с тремя статусами по каждому пункту: «работает корректно», «работает с ограничениями», «не работает или не проверялось».

Такая таблица даёт не абстрактную оценку зрелости, а конкретный, приоритизированный список задач. В первую очередь разберите пункты со статусом «не работает»: для каждого определите, какой агентный сценарий или протокол он блокирует, насколько критична проблема и что потребуется для её устранения.

Особое внимание уделите проблемам на шагах 1 и 2. Недоступные или неактуальные данные и отсутствие корректного механизма обнаружения действительно могут сделать магазин недоступным для определённых агентных сценариев. Но это не означает, что остальные уровни инфраструктуры автоматически не готовы: каждый результат следует оценивать в контексте конкретного канала и протокола.

Не позволяйте при этом продвинутым задачам — например, оптимизации предложения под агента, которой посвящена следующая часть книги, — вытеснять базовые технические проблемы. Сначала устраните ограничения, мешающие агенту корректно обнаружить товар, получить достоверные данные и пройти оформление заказа, а уже затем переходите к оптимизации самого коммерческого предложения.

Протокол аудита готовности

Зафиксируйте результаты в документе из шести разделов, соответствующих шагам этой главы: данные, манифест и обнаружение, сквозное оформление заказа, платёжный слой, закрытые платформенные каналы, неконтролируемый доступ. По каждому разделу укажите текущий статус, дату проверки и конкретное следующее действие, если статус не «работает корректно».

Повторяйте аудит после значимых изменений в каталоге, процессе оформления заказа или платёжной инфраструктуре, а в остальное время — не реже одного раза в квартал. Протоколы и платформы, разобранные в предыдущей главе, продолжают развиваться, поэтому результат аудита, проведённого полгода назад, без повторной проверки уже нельзя считать надёжной картиной текущего состояния.

На этом заканчивается диагностическая часть книги. Следующая часть переходит от вопроса «что уже работает» к вопросу «как построить это правильно» — начиная с фундаментального слоя: машиночитаемых данных о товарах, которые необходимы для надёжной работы большинства агентных сценариев.

Часть II. Техническая инфраструктура

Глава 4. Машиночитаемый каталог

Разница между «есть разметка» и «данные готовы»

Многие компании, впервые сталкиваясь с задачей подготовки каталога к агентной коммерции, успокаиваются слишком рано: разметка Schema.org для товаров давно внедрена, фид для рекламных платформ исправно генерируется, страницы каталога выглядят технически корректно. Всё это полезно, но далеко не достаточно. Разница между «у нас есть разметка» и «наши данные готовы для агента» становится особенно заметна в момент, когда агент должен принять решение о покупке на основе актуального состояния товара.

Классический фид для рекламных площадок или структурированная разметка страницы решают прежде всего задачи обнаружения, индексации, сравнения и показа товаров. Они не обязательно обеспечивают ту же скорость обновления и согласованность данных, которая требуется для агентного сценария. Если агент видит наличие товара или цену, которые уже не соответствуют действительности, проблема возникает непосредственно в процессе покупки: это может привести к ошибке при оформлении заказа, изменению условий покупки или отмене заказа.

Поэтому готовность каталога к агентной коммерции определяется не самим наличием разметки или фида, а тем, насколько полно и своевременно машиночитаемые данные отражают реальное состояние товара. Именно эту разницу и предстоит разобрать в этой главе.

Четыре свойства, которые обязательны

Первое — стабильные, уникальные идентификаторы товара, согласованные во всех системах и каналах: внутренний артикул, универсальный код товара, идентификатор в конкретной платформенной интеграции. Расхождение идентификаторов между системой управления складом, сайтом и внешними фидами или интеграциями может привести к тому, что агент не найдёт нужный товар, свяжет его с неправильной позицией или не сможет сопоставить данные из разных источников.

Второе — структурированные, а не только описанные прозой характеристики. Материал, размер, цвет, комплектация, технические параметры должны существовать как отдельные, однозначно названные поля, а не только как фрагменты маркетингового текста, из которого эти детали приходится извлекать. Агент, сравнивающий несколько товаров по конкретному параметру, надёжнее работает со структурированным полем «объём: 500 мл», чем с фразой «удобная бутылка среднего размера для повседневного использования».

Третье — точная и детализированная информация о наличии, а не только бинарный статус «в наличии / нет в наличии». В зависимости от категории товара это может включать количество на складе, статус товара под заказ или с ограниченным тиражом, а для товаров с вариантами — наличие каждого конкретного варианта. Если агент получает информацию «товар в наличии», хотя нужного покупателю размера уже нет, это создаёт худший пользовательский опыт, чем корректное сообщение об отсутствии.

Четвёртое — своевременное обновление данных, соответствующее требованиям конкретного сценария. Для цены и наличия особенно важно, чтобы агент получал состояние товара с минимально необходимой задержкой, а не устаревшие данные из пакетной выгрузки. Для одних категорий обновления раз в несколько часов может быть достаточно, для других, например при быстро меняющихся ценах или ограниченных остатках, потребуется обновление практически в реальном времени.

Именно сочетание этих четырёх свойств — идентифицируемость, структурированность, детализация и своевременность — превращает обычный товарный каталог в надёжный источник данных для агентной коммерции.

Откуда чаще всего начинается работа

Хорошая новость в том, что для большинства компаний, уже присутствующих в электронной коммерции, не требуется строить эту инфраструктуру с нуля. У действующего интернет-магазина обычно уже есть хотя бы один структурированный источник товарных данных — фид для рекламных платформ, маркетплейсов, сервисов сравнения цен или собственных систем. Такой источник часто становится разумной отправной точкой, хотя и не обязательно содержит всё, что требуется для агентных сценариев.

Задача — не создать новую систему с нуля, а провести аудит существующего источника данных по четырём критериям из предыдущего раздела и последовательно закрыть обнаруженные разрывы. На практике это может означать добавление детализации наличия по вариантам, сокращение задержки обновления или повышение качества структурированных характеристик, которые исторически заполнялись формально, потому что использовались прежде всего для индексации и других задач, не требовавших от них такой точности.

Поэтому первый вопрос при подготовке каталога должен звучать не «какую новую систему нам построить?», а «что уже есть в наших товарных данных и чего в них не хватает для агентного сценария?».

Особый случай: варианты и комплекты

Отдельного внимания заслуживают товары с вариантами и составные предложения — комплекты из нескольких единиц, товары с настраиваемыми опциями, продукция с несколькими уровнями упаковки. Для агентных сценариев это особенно важный участок каталога: человек, листающий страницу с выпадающими списками размера и цвета, легко понимает логику выбора, а агент должен получить её в явной машиночитаемой форме.

Для каждого варианта должны быть однозначно определены его идентификатор, характеристики и статус наличия, а связь с родительским товаром должна быть явно представлена в структуре данных. Если цена, изображение или другие свойства отличаются между вариантами, это также должно быть отражено на уровне конкретного варианта, а не только родительского товара.

Компаниям с большим количеством вариантов стоит уделить этому участку каталога особое внимание. Ошибка в структуре связей может привести к тому, что агент предложит покупателю недоступную комбинацию характеристик, не покажет существующий вариант или передаст в оформление заказа данные, которые не соответствуют выбранной конфигурации.

Практический план внедрения

Начните с полного аудита текущего фида или системы товарных данных по четырём свойствам, разобранным в этой главе. Если данные для разных каналов продаж формируются независимо, проводите проверку отдельно по каждому значимому каналу.

Составьте приоритизированный список разрывов, начиная с идентификаторов и связей между сущностями. Без надёжного сопоставления товаров остальные улучшения теряют значительную часть своей ценности: агент, который не может однозначно определить нужную позицию, не сможет корректно использовать даже точные данные о наличии и цене.

Переведите обновление цены и наличия с редких пакетных выгрузок на более своевременный механизм там, где это технически и экономически оправдано: например, через программный интерфейс, событийную синхронизацию или другой способ быстро передавать изменения. Цель — не обязательно добиться обновления в режиме реального времени, а обеспечить такую свежесть данных, которая соответствует конкретному сценарию покупки. Если мгновенное обновление в краткосрочной перспективе недостижимо, зафиксируйте фактический интервал устаревания данных и учитывайте его как известный управляемый риск.

Проведите отдельную углублённую проверку товаров с вариантами и комплектов, следуя логике предыдущего раздела. Такая работа может оказаться трудоёмкой, поскольку затрагивает накопленные за годы данные, в которых человек привык компенсировать неоднозначности и неточности контекстом интерфейса. Для агента эта неявная логика должна быть представлена непосредственно в структуре данных.