Архитектура товарной вертикали: фид, индекс Маркета, report и 3144 фактора

[anna_seo]

Зачем вообще разбирать архитектуру, а не сразу факторы

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

Дисклеймер сразу: это разбор по исходникам товарной вертикали (дерево ya/extsearch/goods), а не официальная формула Маркета. Часть факторов в реестре помечена как deprecated/unused - их не подаю как рабочие. Финальная модель - это CatBoost/MatrixNet, дерево решений, у факторов НЕТ фиксированных процентных весов. Где оцениваю влияние - делаю это качественно и помечаю как реконструкцию.

Общая схема конвейера

Грубо вся машина делится на две половины: оффлайн (сборка индекса) и онлайн (обработка запроса). Вот как это выглядит сверху.

Код: Выделить всё

ОФФЛАЙН (upstream, дерево market/, НЕ goods)
  магазин -> YML-фид (офферы) -> приём фидов
       -> матчинг офферов в карточки моделей
       -> категоризация
       -> сборка ПОКОЛЕНИЯ индекса
       -> ресурс MARKET_REPORT_DIST_META (торренты шардов)

РАСКАТКА (~ каждые 12 часов)
  MARKET_REPORT_DIST_META
       -> MAKE_GOODS_SHARDMAP_GENCFG (sandbox)
       -> 8 шардов (по 2 реальных в каждом)
       -> nanny раскатывает шардмапу на бекенды report
       -> индекс грузится прямо в память (IndexWarmupMode=2)

ОНЛАЙН (на каждый запрос)
  юзер -> apphost -> begemot (интент, market.cpp)
       -> report (базовый поиск + ранжирование)
       -> места выдачи (текст / карточка / блендер)

Ключевой момент, который многие пропускают: приём фидов, матчинг и категоризация - это upstream, он живёт в репозитории market/, а НЕ в дереве goods. В goods приезжает уже готовое поколение индекса. То есть когда вы правите фид, вы воздействуете на самый верх трубы, и до рантайма это докатывается с заметной задержкой.

Как собирается и раскатывается поколение индекса

После того как поколение индекса собрано, в sandbox появляется ресурс MARKET_REPORT_DIST_META - в нём лежат торрент-ссылки на куски индекса (шарды, dssm-модели, мапинги). По этому ресурсу таска MAKE_GOODS_SHARDMAP_GENCFG строит шардмапу.

• Каждые ~12 часов берётся последнее готовое поколение (по умолчанию - турбо-индекс, у ресурса атрибут is_turbo=true).
• Из него строятся 8 шардов, в каждом по 2 реальных шарда, плюс доп-ресурс GOODS_REPORT_DATA с конфигами бекендов.
• Шардмапа - это текстовый файл: для каждого хоста прописан торрент с его шардом. nanny находит хост, выкачивает торрент.
• Собранные шарды живут около месяца, а сами исходные файлы дист-ресурса - всего несколько дней (по старым уже индекс не построишь).
• Сам индекс грузится напрямую в память репорта - за это отвечает флаг IndexWarmupMode=2, поэтому выдача быстрая.

Практический вывод номер один: в goods-дереве раскатка поколения - это про 12-часовой ритм релиза шардмапы. Но это НЕ то же самое, что частота приёма вашего фида. Фид принимается upstream в market/ заметно чаще (см. ниже про цены). Не путайте две разные задержки.

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

Онлайн-путь запроса: apphost, begemot, report

Когда приходит запрос (yandex.ru/products или товарный колдунщик в основном поиске), он идёт так:

• apphost - оркестратор графа, ходит в report через балансер.
• begemot (бегемот) - определяет интент. Для колдунщика это поход в граф веба, для main-выдачи отдельная вершина. Основные правила Маркета и ТВ лежат в search/begemot/rules/src_setup/market/market.cpp. Именно тут решается, товарный ли это запрос вообще и какой у него тип.
• report - базовый поиск по шардам + применение формулы ранжирования. Именно здесь крутятся 3144 фактора.

Для дебага полезно знать: запрос в репорт можно достать через json_dump_requests=MARKET_REPORT_PROXY, а стрельнуть в конкретную машинку через srcrwr. Это к тому, что вся выдача воспроизводима - можно посмотреть, какой именно интент begemot присвоил вашему запросу.

Реестр факторов и места выдачи

Реестр живёт в ya/extsearch/goods/base/factors/factors_meta_gen.in. Я прогнал по нему grep: индексов там 0..3143 (в файле строк с Index около 3146, плюс служебные). У каждого фактора есть CppName, Name и набор Tags. Теги - это и есть карта того, ГДЕ и НА КАКОМ УРОВНЕ фактор работает. Вот реальное распределение по тегам (вывод grep, отсортирован по частоте):

Код: Выделить всё

ТЕГ                       ШТУК   ЧТО ОЗНАЧАЕТ
TG_BASE                   2698   исходные/базовые факторы
TG_TEXT_PLACE             2419   текстовая выдача
TG_DOCUMENT_TEXT_MACHINE   943   текстовый матчинг документа
TG_BLENDER_PLACE           904   подмешивание в блендер выдачи
TG_DELETE_CANDIDATE        884   кандидаты на удаление (осторожно)
TG_MODEL_OFFER_PLACE       491   карточка товара с офферами
TG_QUERY_ONLY              305   только про запрос
TG_DEPRECATED              248   мёртвые - НЕ рабочие
TG_DOCUMENT_QUERY_CTR      126   поведенческие (CTR)
TG_MODEL                   115   уровень карточки модели
TG_UNUSED                  108   не используются
TG_DJ                       97   рекомендательные
TG_DSSM                     59   нейросетевые
TG_OFFER                    42   уровень оффера
TG_DELIVERY                 42   доставка

Сразу видно структуру. Львиная доля - текстовые факторы (TG_TEXT_PLACE, TG_DOCUMENT_TEXT_MACHINE): это сопоставление текста запроса с названием и характеристиками. Поэтому название карточки и заполненность атрибутов - не косметика, а топливо для самой массовой группы сигналов. Отдельно держите в голове: 248 факторов помечены TG_DEPRECATED и 108 TG_UNUSED - почти 350 штук из реестра это балласт, на который ориентироваться нельзя.

Несколько реальных имён, которые я подтвердил грепом, чтобы было понятно, как это выглядит в коде:

Код: Выделить всё

УРОВЕНЬ ОФФЕРА (TG_OFFER / TG_DELIVERY)
  OFFER_PRICE
  OFFER_PRICE_DIV_OVERALL_MEDIAN_MODEL_PRICE
  OFFER_PRICE_DIV_OVERALL_AVG_CATEGORY_PRICE
  DELIVERY_FREE / DELIVERY_EXPRESS / DELIVERY_LOCAL
  DELIVERY_FROM_DAYS / DELIVERY_TO_DAYS
  SHOP_RATING

УРОВЕНЬ КАРТОЧКИ МОДЕЛИ (TG_MODEL)
  MODEL_CTR / MODEL_CTR_ADJ
  MODEL_RATING / MODEL_RATING_COUNT / MODEL_RATING_PRECISE
  MODEL_CONVERSION
  MODEL_CLICKS
  MODEL_AVG_PRICE_TO_MIN_PRICE
  MODEL_DISCOUNT

Обратите внимание на OFFER_PRICE_DIV_OVERALL_MEDIAN_MODEL_PRICE и OFFER_PRICE_DIV_OVERALL_AVG_CATEGORY_PRICE - цена в Маркете почти всегда нормированная: не абсолютное число, а отношение к медиане по модели и к средней по категории. Это важно: дорого или дёшево определяется не самой ценой, а её позицией в облаке конкурентов.

Реконструкция, не точные веса: судя по составу факторов, на карточке товара (TG_MODEL_OFFER_PLACE) сильными сигналами выступают связка цена-относительно-конкурентов (OFFER_PRICE_DIV_*), накопленное поведение карточки (MODEL_CTR, MODEL_CONVERSION) и доверие к магазину/модели (SHOP_RATING, MODEL_RATING_COUNT). Но финальный порядок считает CatBoost-дерево, и вклад любого фактора зависит от значений остальных. Никаких "цена = 30%" не существует.

Что говорит актуальная практика 2025-2026 про обновления

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

• Общая индексация офферов на стороне приёма фидов идёт примерно каждые 3-6 часов, без жёсткого расписания; при техработах окно растягивается.
• Изменения цены и скидки подхватываются заметно быстрее - порядка 30-40 минут.
• Фид в кабинете рекомендуют обновлять не реже раза в 30 дней, а лучше держать автообновление (файл в корне сайта или интеграция с CMS).
• Название карточки (тип + бренд + модель + ключевые свойства, 60-100 символов) - самый весомый элемент и для внутреннего матчинга, и для CTR. Описание - связный текст с естественными ключами.
• Категорийные обязательные поля: размер и цвет через param для одежды, warranty для электроники, ISBN для книг. Без них оффер хуже матчится в карточку.
• ID оффера должен быть стабильным и одинаковым во всех фидах одного товара. Это прямо влияет на матчинг в одну карточку модели.

Сложите это с архитектурой выше - и получается двухуровневая задержка. Цена обновляется за полчаса на уровне приёма, общий индекс офферов переваривается за 3-6 часов, а в goods-рантайм готовое поколение раскатывается шардами раз в ~12 часов. Поэтому резкие правки фида не дают мгновенного эффекта в выдаче, а нестабильный фид (то отдаёт, то падает, прыгает available, плавают ID) бьёт сразу по нескольким уровням.

SEO-вывод

Главный практический тезис: в товарной вертикали выигрывает не тот, кто разово оптимизировал карточку, а тот, у кого фид стабилен и предсказуем во времени. Стабильный ID оффера - устойчивый матчинг в карточку модели. Стабильная отдача и корректный available - оффер не выпадает между поколениями индекса. Стабильная цена без дёрганья - чистые относительные факторы OFFER_PRICE_DIV_* и спокойное накопление поведенческих MODEL_CTR/MODEL_CONVERSION.

Что делать руками:

• Закрепить ID офферов раз и навсегда; не перегенеривать их при каждой выгрузке.
• Держать автообновление фида и следить за uptime отдачи - падения фида это просадки в индексации.
• Заполнять обязательные категорийные param полностью - это топливо для самой массовой группы текстовых факторов.
• Цену двигать осознанно: важна не абсолютная цифра, а позиция относительно медианы по модели и средней по категории.
• Не ждать мгновенной реакции выдачи: учитывать слой ~30 мин (цена), 3-6 ч (офферы) и ~12 ч (раскатка поколения).

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