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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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