Помните интернет-магазины, где на странице контактов висел номер ICQ? Зелёный цветок показывал, что менеджер онлайн и может ответить на запрос.  А про квитанцию Сбербанка в способах оплаты? Её нужно было распечатать, заполнить и отнести в отделение. Та ещё интернет-торговля.

В 2000-х всё стало иначе. ICQ сменили на чаты поддержки. Квитанции ушли в музей. Потом Price.ru и первые прайс-агрегаторы уступили место маркетплейсам. Интерфейсы стали лучше, оплата быстрее, доставка привычнее. Сейчас уже виден следующий слой: товар может стать ответом AI-ассистента на запрос покупателя. А дальше начнётся новая борьба за то, какие товары попадут в ответ машины.

Привет, Хабр. Меня зовут Дмитрий Смирнов. Я более 20 лет занимаюсь развитием бизнеса в ритейле, FMCG и смежных отраслях. В этой статье хочу описать путь ритейла не как историю красивых интерфейсов, а как историю потери контроля. Кто видит покупателя? Кто управляет карточкой? Кто решает, какой товар будет наверху? И что будет, когда первый контакт с покупателем уйдёт от маркетплейса к AI-ассистенту?

Когда интернет-магазин был своей территорией

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

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

А покупатель ходил по сайту почти как по магазину с продавцом-консультантом. Сначала смотрел каталог, потом открывал карточку, иногда звонил менеджеру и только после этого решался на заказ. Для современного e-commerce путь странный и длинный, но у него было одно сильное качество: магазин видел шаги человека почти целиком.

Было понятно, откуда он пришёл, на каком товаре задержался, где начал сомневаться и почему в итоге позвонил. Иногда причина покупки выяснялась вообще не из аналитики, а из разговора: «А точно есть в наличии?», «А привезёте завтра?», «А это оригинал?». Такие вопросы сразу показывали, что карточке не хватает доверия, понятного срока доставки или нормального описания.

Сайт как пульт управления продажами

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

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

Первый побег товара: фид для агрегатора

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

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

Но за простой идеей «выгрузить прайс» прятался более глубокий сдвиг. Товар впервые зажил вне сайта продавца в машинно-читаемом виде. Его можно было забрать агрегатором, разобрать на поля, поставить рядом с конкурентами и отсортировать по правилам чужой системы.

Технические грабли эпохи CSV: как рождался товарный фид

Сначала фид мог быть обычным CSV из Excel или выгрузкой из 1С. Потом появились XML и YML. Магазин формировал файл, клал его на сервер, а робот агрегатора приходил по ссылке и забирал данные. В файле лежали названия, цены, категории, ссылки на карточки и изображения, признаки наличия и  условия доставки. Иногда он содержал и набор характеристик.

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

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

Так у магазина появилась вторая витрина. Чужая, сухая и очень влиятельная.

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

Фид был маленькой ИТ-системой, хотя его так не называли

Сейчас старые товарные фиды можно назвать интеграционным контуром. Тогда это называли проще: «выгрузка для Маркета», «прайс для Price.ru», «файл для площадки». Название было бытовым, а сложность вполне настоящей.

Типовая схема выглядела так. Товарный учёт жил в 1С, сайт работал на 1С-Битрикс, Magento, UMI.CMS, NetCat или самописной CMS, обмен шёл через CommerceML или самописный механизм, а фид собирал отдельный модуль или PHP-скрипт. Где-то всё работало напрямую, где-то между 1С и сайтом появлялся CSV, где-то менеджер правил Excel руками, потому что без этой правки агрегатор начинал ругаться на категории, названия или цены.

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

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

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

Технические мелочи тоже добавляли веселья. Амперсанд в названии мог испортить XML, кавычки уезжали в неожиданный вид, а кодировка превращала нормальный русский текст в кракозябры. Где-то жил UTF-8, в другом месте  — Windows-1251, в третьем   ещё вспоминали KOI8-R. Один и тот же файл мог нормально проходить в одну площадку и падать в другой, потому что отличались требования.

Фотографии жили отдельной жизнью. У части SKU не было картинки, у других товаров она была, но слишком маленькая. Где-то изображение технически загружалось, но агрегатору не нравился размер, фон или формат. Вроде бы мелочь, но без картинки товар в выдаче терял клики, а иногда просто не проходил модерацию.

Инфраструктура на костылях

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

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

Сейчас это назвали бы техническим долгом. Тогда говорили: «Проверил? Работает? Тогда не трогай».

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

Available: да, нет и «почти да»

Самым нервным полем стало наличие. Для покупателя этот вопрос выглядел простым: товар либо можно купить, либо нельзя. Но внутри магазина все было сложнее.

Товар мог лежать на своём складе, быть у поставщика, ехать из другого города или числиться в остатках, которые обновляются с задержкой. Менеджер мог быть уверен, что сможет достать позицию, хотя формально её уже не было. Склад мог показывать одно, поставщик другое, а сайт третье. Внутри магазина такая неопределённость ещё как-то объяснялась звонком, комментарием менеджера и обещанием «сейчас уточним». Но агрегатору вся эта жизнь была неинтересна. Ему был нужен короткий машинный ответ. Условно, available: true или false.

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

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

Борьба за строку

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

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

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

Рынок мог свернуть в другую сторону

Маркетплейсы не выглядели заранее заданным финалом онлайн-ритейла. Интернет-торговля пробовала разные формы, и каждая какое-то время казалась перспективной.

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

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

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

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

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

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

Второй перелом: платформа забрала сделку

Агрегатор показывал предложения и отправлял покупателя в магазин. Маркетплейс пошёл дальше: он забрал сделку внутрь себя.

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

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

В 2020 году россияне сделали в онлайне около 830 миллионов заказов, и почти половина пришлась на крупные универсальные маркетплейсы. Дальше доля площадок только увеличивалась. По оценке АКИТ, в 2024 году российская интернет-торговля выросла примерно до 9 триллионов рублей.

«Чёрный ящик»: почему продавец перестал видеть клиента

Магазин продолжал продавать товар, но всё хуже понимал, кому и за счёт чего.

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

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

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

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

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

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

Продавец стал работать с алгоритмом

Когда витрина стала чужой, изменилась и команда. Раньше вокруг сайта жили CRM-маркетолог, контент-редактор, SEO, разработчики, закупщики, поддержка, аналитики, менеджеры по рекламе. В маркетплейсной модели значительная часть этой работы сжалась в роль менеджера площадки.

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

Что будет, если обновлять карточку чаще? Как влияет резкое снижение цены? Что даст внешний трафик? Почему товар вчера рос, а сегодня просел? Как площадка реагирует на out-of-stock? Почему реклама подорожала, хотя ставка почти не менялась?

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

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

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

Получился новый e-commerce. Уже не сайтовый, а платформенный.

Маркетплейс сильнее магазина не во всём

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

Но есть зоны, где отдельный магазин или бренд всё ещё сильнее.

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

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

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

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

Витрина может уехать к AI-ассистенту

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

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

«Подбери робот-пылесос для квартиры 70 метров, есть кошка и ковёр».
«Найди школьный рюкзак, чтобы был легкий и нормально сидел на ребёнке».
«Выбери корм для собаки с аллергией».
«Собери набор бытовой химии на месяц».
«Найди монитор для работы с таблицами, чтобы глаза меньше уставали».

Это нормальные человеческие запросы, но они плохо укладываются в старые фильтры и слишком длинны для обычного поиска по маркетплейсу. А вот AI-ассистенту такой формат подходит гораздо лучше.

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

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

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

Новый фид будет не похож на старый

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

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

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

Как это выглядит на практике

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

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

Старый фид говорил машине: «Вот товар».Новый фид должен говорить: «Вот товар, его свойства и ограничения, а вот задачи, где он подходит и доказательства».

Появится новая серая зона

Как только алгоритм начинает влиять на продажи, рынок ищет способы повлиять на алгоритм. Так было и с SEO, и с агрегаторами, и с маркетплейсами. С AI-ассистентами тоже будет похожая история.

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

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

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

Товар перестанет лежать на полке

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

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

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

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

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

Как это перекроит рынок

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

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

Когда-то товар убежал с сайта в фид. Потом из фида в карточку маркетплейса. Следующий побег будет глубже: наружу уйдёт сам товар как набор данных, свойств и вариантов.

И снова начнётся старая игра. Кто лучше описывает товар для машины, тот получает доступ к покупателю. Кто контролирует интерфейс выбора, тот контролирует рынок.