Разговорные атрибуты Merchant Center 2026: шесть полей, которые заводят товары в ответы AI Mode

Покупатель всё реже вводит «кроссовки для бега 42». Он спрашивает: «что взять для первого марафона, если у меня плоскостопие и бюджет до 15 тысяч». Классический товарный фид на такой вопрос ответить не может — в нём есть название, цена, GTIN и категория, но нет ничего, из чего можно собрать ответ. Разговорные атрибуты Merchant Center закрывают ровно этот разрыв: это шесть необязательных полей, из которых система собирает ответ о вашем товаре в диалоговых поверхностях Google.

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

Почему фид вдруг стал отвечать на вопросы

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

Обычный фид отвечает на вопрос «что это за товар». Разговорные атрибуты отвечают на вопросы «подойдёт ли он мне», «чем отличается от соседнего», «что к нему нужно докупить» и «насколько он популярен». Без них товар остаётся в каталоге, но выпадает из разговора — его просто нечем сравнивать. Как реклама вообще попадает в такие ответы, мы разбирали в материале реклама в AI Mode 2026, а оборотную сторону — покупку без перехода на ваш сайт — в разборе нативной оплаты в AI Mode.

Разговорные атрибуты — не ещё одно поле для SEO. Это перевод товарной базы с языка каталога на язык вопросов покупателя.

Шесть атрибутов: что это и какие лимиты

Атрибут	Что передаёт	Формат и лимит
question_and_answer	Пары «вопрос — ответ» о товаре	Структурированные пары, до 30 на товар
document_link	Ссылки на PDF: инструкции, спецификации, сертификаты	До 5 файлов на товар, до 50 МБ каждый
related_product	Связи с другими товарами и тип связи	ID товара или GTIN, до 30 связей на товар
item_group_title	Общее название семейства вариантов	Текстовое поле, общее для группы
variant_option	Чем именно отличается вариант: цвет, размер, материал, объём памяти	Характеристика варианта
popularity_rank	Относительная популярность товара	Числовая шкала 0–100, дробные значения допустимы

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

question_and_answer — самый недооценённый

До 30 пар «вопрос — ответ» на товар — это, по сути, возможность заранее ответить на всё, что покупатель спросил бы в чате или у консультанта. Система может сослаться на ваш ответ напрямую.

Где брать вопросы, чтобы не выдумывать:

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

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

related_product — связи, которые система не угадает сама

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

• part_of_set — входит в комплект;
• required_part — обязательная деталь, без которой товар не работает;
• often_bought_with — обычно покупают вместе;
• substitute — замена при отсутствии;
• different_brand — аналог другого бренда;
• accessory — аксессуар.

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

item_group_title и variant_option — дешёвая и быстрая победа

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

item_group_title задаёт общее имя семейства, variant_option — чем конкретный вариант отличается. Внедряется это обычно за день, потому что данные уже есть в базе: нужно лишь вывести их в отдельные поля, а не склеивать в название. Если названия товаров у вас собираются правилами, задача решается без разработчиков — подход описан в разборе правила фида Merchant Center.

popularity_rank — честный сигнал, который легко испортить

Числовая оценка от 0 до 100 говорит системе, какие товары у вас реально продаются. Соблазн поставить всем позициям 95 понятен и бессмысленен: ранг имеет смысл только как различающий сигнал. Если все товары «топовые», сигнала нет вообще.

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

document_link — там, где решает документ

До пяти PDF на товар, до 50 МБ каждый: инструкции, паспорта, сертификаты, таблицы совместимости. Для одежды это почти бесполезно, для техники, стройматериалов, автозапчастей и B2B-оборудования — часто решающий фактор, потому что покупатель сравнивает по спецификации, а не по описанию.

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

Порядок внедрения: от быстрого к тяжёлому

Заходить сразу во все шесть атрибутов — верный способ не сделать ни одного. Разумная последовательность опирается на соотношение «усилие / эффект».

Этап	Что делаем	Трудоёмкость	Что получаем
1	item_group_title + variant_option	Низкая: данные уже есть	Варианты перестают конкурировать сами с собой
2	popularity_rank по формуле	Низкая: одна выгрузка продаж	Система понимает ваши бестселлеры
3	question_and_answer для топ-200 товаров	Средняя: нужен контент	Товар попадает в ответы на содержательные вопросы
4	related_product для категорий с комплектами	Средняя: нужна экспертиза	Меньше возвратов, выше средний чек
5	document_link для технических категорий	Высокая: сбор и проверка файлов	Сравнение по спецификации играет за вас
6	Расширение Q&A на весь каталог	Высокая: процесс, а не задача	Покрытие длинного хвоста

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

Разговорные атрибуты Merchant Center меняют не фид, а процесс

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

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

Поэтому первое решение — организационное, а не техническое. Нужно назвать владельца каждого атрибута:

Атрибут	Кто реально владеет данными	Частота обновления
item_group_title, variant_option	Категорийный менеджер / контент-менеджер	При заведении товара
popularity_rank	Аналитик, автоматический расчёт	Еженедельно, в сезон чаще
question_and_answer	Поддержка + категорийный менеджер	Ежемесячная ревизия топ-категорий
related_product	Категорийный менеджер	При изменении ассортимента
document_link	Поставщик / отдел закупок	При смене версии товара

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

Разбор на одной категории: как это выглядит в работе

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

• Варианты. Было: шесть отдельных товаров «Наушники X чёрные», «Наушники X белые» и так далее. Стало: item_group_title = «Наушники X», variant_option = цвет. Система понимает, что это одна модель, и не тратит ответ на перечисление шести одинаковых строк.
• Вопросы. Из поддержки вытаскиваются реальные: «работают ли с ноутбуком», «сколько держат заряд при разговоре», «можно ли использовать один наушник», «есть ли шумодав в режиме прозрачности». Каждый — отдельная пара, с конкретным ответом и цифрой, где цифра уместна.
• Связи. accessory — чехол и переходник; substitute — модель на ступень ниже, когда основной нет в наличии; often_bought_with — кабель, если он не в комплекте. Именно здесь обычно и живёт прирост среднего чека.
• Документы. Инструкция и таблица совместимости в PDF — для тех, кто сравнивает по спецификации.
• Ранг. Рассчитан по продажам за 90 дней с поправкой на наличие: в наличии и продаётся — высокий, под заказ — ниже.

Самый заметный эффект в такой категории даёт не Q&A, а связка substitute + popularity_rank: когда топовой позиции нет на складе, у системы появляется основание предложить вашу же альтернативу, а не уйти к другому продавцу. Это прямой доход, который обычно теряется молча — ровно как и в случае с отклонёнными товарами или неверной ценовой позицией, разобранной в материале конкурентоспособность цен и бестселлеры в Merchant Center.

Сколько это стоит по времени

Чтобы планировать ресурс, грубые ориентиры по каталогу среднего размера (несколько тысяч SKU):

• Варианты и семейства — 1–2 дня работы с выгрузкой, если данные уже структурированы в базе; до двух недель, если варианты исторически склеены в название.
• Ранг популярности — полдня на формулу и настройку регулярного пересчёта.
• Q&A по топ-200 — 3–5 рабочих дней силами одного человека при наличии базы обращений поддержки.
• Связи товаров — от недели: это ручная экспертная работа по категориям, автоматизировать её полноценно не получится.
• Документы — зависит от поставщиков; часто самое долгое звено, потому что файлы приходится запрашивать.

Разумный план на квартал: первые два пункта в первый месяц, Q&A и связи во второй, документы в третий — с контрольной группой категорий, чтобы в конце было с чем сравнивать.

Типичные ошибки

• Копирование описания в ответы. Если ответ на вопрос «как ухаживать» дублирует абзац из описания, вы не добавили ни одного нового факта.
• Одинаковый ранг популярности у всего каталога. Сигнал, который не различает, — это отсутствие сигнала.
• Связи «ради связей». Отмечать often_bought_with для случайных пар — способ научить систему плохим рекомендациям и собрать возвраты.
• Сканы вместо текстовых PDF. Файл загрузился, пользы ноль.
• Разовое внедрение. Атрибуты устаревают вместе с ассортиментом. Без регулярного пересчёта через квартал вы будете отвечать на вопросы о товарах, которых уже нет.
• Игнорирование базовой гигиены фида. Разговорные атрибуты не чинят отклонённые товары и не компенсируют плохие изображения — требования описаны в материалах про отклонённые товары в Merchant Center и требования к изображениям товаров.

Отдельно отметим смежный сюжет: диалоговый агент рядом с видеообъявлением на YouTube тоже отвечает по данным фида, то есть ровно по этим полям. Подробности формата — в материале про один тап в Demand Gen и вертикальные креативы 9:16.

Как измерить эффект

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

1. Поэтапное внедрение. Раскатывайте атрибуты не на весь каталог сразу, а на половину сопоставимых по спросу категорий. Вторая половина — контрольная группа.
2. Сравнение на уровне категорий, а не товаров. Товарный уровень слишком шумный, особенно в сезон.
3. Метрики для сравнения. Доля показов по категории, конверсия из клика в заказ, доля возвратов и средний чек. Последние две реагируют на related_product и question_and_answer заметнее остальных.
4. Окно наблюдения — не меньше 4–6 недель. Товарные данные обновляются и переобрабатываются не мгновенно, и ранние выводы почти всегда ошибочны.
5. Сверка с кросс-платформенной отчётностью. Часть сдвига будет видна в отчётах Merchant Center — про их изменения мы писали в материале отчётность Merchant Center с 24 августа 2026.

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

И ещё один контекст для сравнения: 2026 год в целом сместил отчётность в сторону «что система собрала сама» — то же самое произошло в поиске, и разобрано это в материале отчётность AI Max и единый отчёт пути.

Кому это нужно в первую очередь

Честный ответ: не всем одинаково. Приоритет высокий, если у вас хотя бы два пункта из списка:

• широкий ассортимент с вариантами (одежда, обувь, мебель, электроника);
• товары с совместимостью и комплектующими (техника, авто, инструмент);
• высокая доля возвратов по причине «не подошло / не то»;
• длинный цикл выбора и высокий средний чек;
• сильная конкуренция по цене, где нужно выигрывать не ценой, а точностью подбора.

Если вы продаёте пять SKU одной категории, начните с question_and_answer и остановитесь — остальное не окупит работу. А если каталог большой и вопрос в масштабировании закупки под него, посмотрите агентские аккаунты Google Ads и другие сервисы PPC Rebels, а также общий разбор товарных фидов в Google Shopping.

Чек-лист на ближайший месяц

1. Проверить, что фид уходит через Merchant API и поддерживает новые поля.
2. Вывести item_group_title и variant_option из базы в отдельные поля фида.
3. Посчитать popularity_rank формулой и настроить еженедельный пересчёт.
4. Собрать 15–30 реальных вопросов по топ-200 товарам из поддержки и возвратов.
5. Разметить required_part и substitute в категориях с комплектующими.
6. Проверить PDF на текстовый слой и актуальность, затем подключить document_link.
7. Зафиксировать контрольную группу категорий и дату старта для последующего сравнения.

FAQ

Что такое разговорные атрибуты Merchant Center?

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

Как их передавать — через интерфейс или фид?

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

Сколько пар «вопрос — ответ» можно передать на товар?

До 30 пар. Качество важнее количества: двадцать содержательных ответов полезнее тридцати формальных.

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

До пяти PDF, каждый до 50 МБ. Файл должен содержать текстовый слой — скан-картинка бесполезна.

Какие типы связей поддерживает related_product?

part_of_set, required_part, often_bought_with, substitute, different_brand и accessory. Допускается до 30 связей на товар, указываются через ID товара или GTIN.

Как правильно считать popularity_rank?

Формулой, а не вручную: например, доля продаж за 90 дней с поправкой на наличие и возвраты, по шкале 0–100. Одинаковый ранг у всего каталога обнуляет смысл поля.

Это обязательные атрибуты?

Нет, все шесть необязательные. Но без них товар участвует в диалоговых ответах на минимуме данных — системе просто нечем его описать и сравнить.

Поможет ли это обычным Shopping-кампаниям?

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

С чего начать, если ресурсов мало?

С item_group_title и variant_option — данные обычно уже есть в базе, внедрение занимает день. Следом — popularity_rank по формуле.

Как понять, что атрибуты сработали?

Через поэтапное внедрение с контрольной группой категорий и сравнение доли показов, конверсии, доли возвратов и среднего чека на горизонте 4–6 недель. Товарный уровень для оценки слишком шумный.

Нужно ли обновлять эти поля регулярно?

Да. Ассортимент, популярность и спецификации меняются, а устаревшие ответы и документы работают против вас — они порождают возвраты. Минимум: ранг еженедельно, Q&A и документы — при каждом изменении товара.

Что будет, если заполнить поля формально?

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