Коммерческость: как поиск отличает магазин от статьи

Рейтинг: 0% · 0 голосов
Разбор устройства поиска и факторов ранжирования: реконструкция формулы, поведенческие, текстовые, ссылочные и хостовые факторы, антиспам, что живо и что давно мёртво. Аналитика на основе метаданных факторов web_production.
Ответить
Аватара пользователя
anna_seo
Сообщения: 58
Зарегистрирован: 11 май 2026, 05:31

Коммерческость: как поиск отличает магазин от статьи

Сообщение anna_seo »

Зачем поиску вообще делить выдачу на "магазин" и "статью"

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

Метаданные утечки факторов (web_production, 1923 фактора) показывают, что эта проблема решается не одной "формулой коммерческости", а связкой из двух вещей: классификаторов, которые определяют коммерческую природу запроса и документа, и модификатора, который под этот класс запроса переписывает расклад весов. Ниже - реконструкция этого механизма по именам факторов.

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

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

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

Mсвеж     - для свежих/новостных запросов резко поднимает вес
            Datetime и быстрых кликов (RapidClicks); группа Datetime

Mкоммерц  - для коммерческих запросов включает коммерческую
            релевантность: DSSM продуктности [772/777/778],
            CommercialDssm [812], штраф за переизбыток рекламы;
            группа TG_COMMERCIAL, ~76 факторов

Mгео/перс - LOCALIZED_COUNTRY, регион запроса [245/246],
            персональная история (стадии L3/rearrange)

ХолодСтарт- для запросов без кликовой истории
            (семейство HasNoQueryShows, факторы 64/78):
            вес поведенческой компоненты B падает, модель
            опирается на текстовую T и ссылочную H компоненты
Смысл такой архитектуры в том, что один и тот же документ оценивается по-разному в зависимости от того, в какой класс попал запрос. Для свежего запроса критична дата и скорость накопления кликов. Для запроса из длинного хвоста без истории показов поведенческая компонента просто бесполезна - кликов нет, и модель вынужденно перекладывает вес на текст и ссылки, иначе хвост вообще не отранжировать. А для коммерческого запроса включается целый отдельный пласт факторов, которого для информационного запроса как будто не существует.

Mкоммерц: что именно включается

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

Классификаторы магазинности и продуктности

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

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

Факторы продуктности (DSSM):
  [772]  DSSM продуктности
  [777]  DSSM продуктности
  [778]  DSSM продуктности
  [812]  CommercialDssm - коммерческая релевантность
Три фактора в районе [772/777/778] отвечают за продуктность - насколько документ "про товар", а не "про тему". CommercialDssm [812] - отдельный сигнал коммерческой релевантности, то есть соответствия документа коммерческому интенту запроса. Это разные вещи: документ может быть продуктным (карточка товара), но плохо релевантным конкретному коммерческому запросу, и наоборот.

EcomFeatures и штраф за рекламу

Помимо DSSM в коммерческий блок входят EcomFeatures - набор признаков электронной коммерции (атрибуты, характерные для интернет-магазина и товарных страниц). И отдельно - штраф за переизбыток рекламы. Это важная деталь: модель, включая коммерческую релевантность, одновременно наказывает страницы, перегруженные рекламными блоками. То есть коммерческость документа и рекламная замусоренность разводятся в разные стороны - быть магазином хорошо, быть рекламной свалкой плохо.

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

Коммерческий блок Mкоммерц (TG_COMMERCIAL, ~76 факторов):
  - DSSM продуктности      [772/777/778]
  - CommercialDssm         [812]
  - EcomFeatures           признаки e-commerce
  - штраф за переизбыток рекламы
Как это читается со стороны SEO

Главный практический вывод из этой структуры - тип запроса определяет, какие факторы вообще в игре. Это переворачивает обычную логику оптимизации "под фактор".
Нельзя оптимизировать документ "вообще". Можно оптимизировать его под класс запроса, по которому он претендует ранжироваться. Факторы из TG_COMMERCIAL для информационного запроса спят, факторы свежести для вечнозеленого запроса почти не работают, поведенческие сигналы в холодном старте отключены по весу.
Из этого следует несколько прикладных вещей.
  • Перед оптимизацией страницы надо определить класс целевого запроса. Если запрос коммерческий, в игре DSSM продуктности и CommercialDssm - и страница должна читаться моделью как продуктная: атрибуты товара, признаки e-commerce (EcomFeatures), а не лонгрид про то, "как выбрать".
  • Информационная статья на коммерческом запросе проигрывает структурно, а не из-за качества текста. Для нее группа TG_COMMERCIAL работает против - по продуктности она слаба, и хорошим текстом этот разрыв не закрыть, потому что текстовая компонента не та ось, по которой коммерческий запрос ранжируется в первую очередь.
  • Зеркально: товарную карточку бесполезно пихать в информационный запрос. Там коммерческий блок выключен, и преимущество по продуктности не конвертируется в позиции.
  • Переизбыток рекламы на коммерческой странице - это активный штраф внутри того же блока, который дает коммерческое преимущество. Монетизация рекламой и коммерческая релевантность тянут оценку в разные стороны.
Про холодный старт - смежный, но важный сюжет

Семейство HasNoQueryShows (факторы 64/78) показывает, что для запросов без кликовой истории поведенческая компонента B обесценивается. Для коммерческого длинного хвоста это особенно чувствительно: запрос может быть явно коммерческим (классификатор сработает, Mкоммерц включится), но кликовой статистики по нему нет. В такой ситуации одновременно работает коммерческий блок (DSSM продуктности, CommercialDssm) и отключенная поведенческая компонента - то есть документ ранжируется по текстовой T, ссылочной H и коммерческой релевантности, без опоры на поведение пользователей. Для нового товара или нового магазина это окно, где продуктность и текст решают, а поведенческого преимущества старых игроков еще нет.

Сводно

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

запрос -> классификатор -> класс -> модификатор -> активные факторы

коммерческий   -> Mкоммерц   -> TG_COMMERCIAL (~76):
                               DSSM продуктн. [772/777/778]
                               CommercialDssm [812]
                               EcomFeatures
                               штраф за рекламу
информационный -> модификатор не включает коммерч. блок
                               -> те же [772/812] по весу спят
свежий         -> Mсвеж      -> Datetime, RapidClicks вверх
без истории    -> ХолодСтарт -> B вниз, опора на T и H
Коммерческость в этой модели - не один балл "магазинности", а отдельный режим ранжирования, который классификатор включает под коммерческий запрос, активируя свой пласт факторов и одновременно штрафуя рекламную перегрузку. Различие "магазин против статьи" поиск делает не на уровне документа в вакууме, а на уровне пары запрос-документ: сначала определяется, какого класса запрос, и только потом - какими факторами по нему оценивать страницу.
Повторю дисклеймер: индексы и группировки взяты из метаданных утечки, веса и пороги иллюстративны и в реальной модели обучаемы. Это реконструкция архитектуры, а не боевые коэффициенты.
👍 ❤️ 🔥 😄 🤔
Ответить
Поделиться темой: ✈ Telegram VK

Вернуться в «SEO и факторы ранжирования»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость