Поведенческие сигналы и CTR: DOCUMENT_QUERY_CTR, клики, окна и заказы

[anna_seo]

Поведенческие сигналы в товарной вертикали: что реально лежит в коде

Продолжаю разбор факторов товарной выдачи Яндекса (yandex.ru/products плюс товарный колдунщик в основном поиске) по исходникам вертикали goods. В этот раз - самая мифологизированная группа: поведение. Клики, показы, CTR, длинные клики, заказы и окна агрегации. Реестр живёт в ya/extsearch/goods/base/factors/factors_meta_gen.in, там 3144 фактора, и по поведению набирается приличная пачка. Я выдрал реальные Name из реестра и посмотрел их Tags, чтобы отделить рабочее от мёртвого.

Сразу дисклеймер. Это разбор по исходному коду вертикали goods, а не официальная формула Маркета. Ранжирует CatBoost/MatrixNet (в data/formulas лежат скомпилированные деревья), а у деревьев нет фиксированных весов на фактор. Поэтому никаких "CTR = 30%". Где могу - говорю качественно: сильный сигнал, слабый сигнал, и помечаю реконструкцию.

Как это вообще устроено по уровням

В реестре у факторов есть Tags, и именно они говорят, где сигнал применяется. По поведению ключевые метки такие:

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

TG_DOCUMENT_QUERY_CTR   группа кликовых счётчиков документ-запрос
TG_TEXT_PLACE           текстовая выдача (список товаров)
TG_MODEL_OFFER_PLACE    карточка модели с офферами
TG_BLENDER_PLACE        подмешивание в блендер общей выдачи
TG_MODEL / TG_OFFER     уровень карточки / уровень оффера
TG_DEPRECATED           фактор мёртв, не учитывать
TG_UNUSED               посчитан, но в формулу не заведён
TG_DELETE_CANDIDATE     кандидат на удаление, доверять нельзя

По метке TG_DOCUMENT_QUERY_CTR в реестре набирается 126 строк. Это не значит "126 разных идей" - это одна идея (клики/показы/CTR) размноженная по нормировкам запроса и по сущностям (документ, категория, вендор).

Ядро: связка показы - клики - CTR

Базовая тройка живёт прямо в начале реестра и помечена сразу четырьмя местами - TG_MODEL_OFFER_PLACE, TG_BASE, TG_BLENDER_PLACE, TG_TEXT_PLACE. То есть работает и в списке, и на карточке, и в блендере:

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

MODEL_SHOWS      показы карточки модели
MODEL_CLICKS     клики по карточке модели
MODEL_CTR        отношение клики/показы
MODEL_CTR_ADJ    сглаженный CTR (adjusted)

OFFER_CLICKS     клики по конкретному офферу
OFFER_CTR        CTR оффера
OFFER_CTR_ADJ    сглаженный CTR оффера

SHOP_CTR         CTR на уровне магазина
SHOP_CTR_ADJ     сглаженный CTR магазина
CATEG_CTR        CTR на уровне категории
VENDOR_CTR       CTR на уровне вендора (бренда)

Обратите внимание на суффикс _ADJ. Сырой CTR на маленьких показах - шум: 2 показа, 1 клик, CTR 50 процентов, и что с того. _ADJ - это сглаженный (adjusted) CTR, подтянутый к среднему по группе на малых выборках. У VENDOR_CTR в коде даже есть человеческое Description: "Клики/Показы/CTR/Сглаженный CTR для вендора документа". Практический вывод: новый оффер без накопленной статистики живёт не на своём сыром CTR, а на сглаженных значениях вендора/категории/магазина. Поэтому репутация бренда и магазина реально подтягивает новинку.

Зачем столько уровней одного и того же

MODEL, OFFER, SHOP, CATEG, VENDOR - это пирамида. Если по конкретному офферу данных мало, модель опирается на агрегаты выше: магазин, категорию, бренд. Это и защита от шума, и одновременно механизм, через который "общая репутация" перетекает на отдельный товар.

DOCUMENT_QUERY_CTR: клики в привязке к запросу

Самая интересная подгруппа - это CTR не вообще, а под конкретный запрос. Документ (товар/карточка) мог получить клик именно по этому запросу - значит он этому запросу релевантен. Реальные имена и их Tags (везде TG_TEXT_PLACE, TG_DOCUMENT_QUERY_CTR, TG_BASE, TG_BLENDER_PLACE):

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

DOCUMENT_QUERY_SHOWS     показы документа по запросу
DOCUMENT_QUERY_CLICKS    клики документа по запросу
DOCUMENT_QUERY_CTR       CTR документа по запросу
DOCUMENT_QUERY_CTR_NAIVE наивный (несглаженный) CTR
DOCUMENT_QUERY_CTR_NAIVE_DIV_TOTAL_DOCUMENTS_CTR
                         CTR документа / средний CTR по выдаче

Последний - концептуально важный. Это не абсолютный CTR, а отношение к среднему по выдаче. Ровно то, о чём говорит и SEO-сообщество про основной поиск: Яндекс смотрит не на голую кликабельность, а на превышение над медианой конкретной выдачи. Здесь это зашито буквально в имени фактора через DIV_TOTAL_DOCUMENTS_CTR.

Нормировки запроса (суффиксы Q*)

Каждый из этих факторов размножен по способам канонизации запроса:

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

_QCANONICAL   каноническая форма
_QDNORM       d-нормализация
_QLOW         нижний регистр
_QLOWSORT     слова в нижнем регистре + сортировка
_QSYNNORM     синонимичная нормализация

Смысл: "купить iphone 15" и "айфон 15 купить" должны слипнуться в один ключ статистики. QSYNNORM ловит синонимы, QLOWSORT - перестановку слов. Для магазина вывод простой: клики по разным формулировкам одного интента суммируются, не нужно дробить усилия на точные словоформы.

Аналогичные семейства на категорию и вендор

Те же конструкции есть для категории и бренда:

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

CATEGORY_QUERY_CTR_NAIVE      CTR категории по запросу
CATEGORY_QUERY_CLICKS/SHOWS   плюс все нормировки Q*
VENDOR_QUERY_CTR_NAIVE        CTR вендора по запросу
VENDOR_QUERY_CTR_NAIVE_DIV_TOTAL_VENDORS_CTR

Длинные клики: клик, после которого не вернулись

CTR легко накрутить - кликнуть может кто угодно. Поэтому в коде есть отдельное большое семейство LONG_CLICK - длинный клик, то есть переход, после которого пользователь не отскочил мгновенно обратно (анти-pogosticking). Это уже сигнал удовлетворённости, а не просто привлекательности сниппета. Имена строятся как текстовые признаки поверх длинного клика:

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

YA_MARKET_LONG_CLICK_FULL_MATCH_VALUE
YA_MARKET_LONG_CLICK_BM15_MAX_ANNOTATION_K001
YA_MARKET_LONG_CLICK_120_SQRT_FULL_MATCH_VALUE
LONG_CLICK_SP_ALL_WCM_WEIGHTED_VALUE
QFUF_*_LONG_CLICK_*   (большая пачка проксимити-вариантов)

Здесь важная находка по тегам. У базовых LONG_CLICK_FULL_MATCH_VALUE и YA_MARKET_LONG_CLICK_FULL_MATCH_VALUE стоит:

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

Tags: [TG_BASE, TG_TEXT_PLACE, TG_DOCUMENT_TEXT_MACHINE, TG_DELETE_CANDIDATE]

TG_DELETE_CANDIDATE - кандидат на удаление. То есть конкретно эти текстово-машинные варианты длинного клика помечены как сомнительные/выводимые из эксплуатации. Подавать их как "рабочий рычаг" нельзя. Сама идея длинного клика жива (вариант LONG_CLICK_120_SQRT, окно 120 секунд), но именно эти FULL_MATCH-факторы - под вопросом. Это к тому, что в реестре полно исторического мусора: TG_DEPRECATED встречается 248 раз.

Суффикс 120_SQRT - это и есть окно из заголовка темы: длинный клик с порогом удержания около 120 секунд, корень для сжатия шкалы. Если человек провёл на карточке/у магазина больше порога - клик засчитан как длинный.

Rapid clicks: быстрые реалтайм-счётчики

Отдельная индустрия - семейство RAPID_CLICKS (тикеты MARKETOUT-43052, MARKETRANK-3). Это оперативные счётчики "показ -> клик -> длинный клик -> заказ", нарезанные по куче ключей сразу: HYPERID (модель), MSKUID (товар на маркете), VENDORID, CATEGID, ICOOKIE (пользователь), MARKETQUERYDOPP (запрос). Примеры реальных имён:

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

RAPID_CLICKS_RATIONALSIGMOID_SHOW_MSKUID         Tags: [TG_TEXT_PLACE]
RAPID_CLICKS_SHOW_TO_CLICK_DWELLTIME_MSKUID      Tags: [TG_TEXT_PLACE]
RAPID_CLICKS_SHOW_TO_CLICK_THRESHOLD_0_HYPERID
RAPID_CLICKS_SHOW_TO_CLICK_THRESHOLD_120_MSKUID
RAPID_CLICKS_SHOW_TO_ORDER_ALLORDERS_MSKUID      Tags: [TG_TEXT_PLACE]
RAPID_CLICKS_RATIONALSIGMOID_ORDERS_HYPERID

Расшифровка кусков имени:

• SHOW_TO_CLICK - конверсия из показа в клик
• SHOW_TO_CLICK_DWELLTIME - с учётом времени удержания
• SHOW_TO_ORDER_ALLORDERS - из показа в заказ (вот он, денежный сигнал)
• THRESHOLD_0 / THRESHOLD_120 - порог удержания, 0 и 120 секунд (те самые окна)
• RATIONALSIGMOID - сглаживание счётчика рациональным сигмоидом (опять анти-шум на малых данных)

Многие из них в Description честно подписаны как номер строки в rtmodels_factors.txt - это runtime-модель, считающаяся на лету. Но не всё включено: например RAPID_CLICKS_CLICKS_TO_LONG_CLICKS_MARKETQUERYDOPPNIDHID_CATEGID имеет Tags [TG_TEXT_PLACE, TG_UNUSED] - посчитан, но в формулу не заведён. Помечаю как мёртвый.

Заказы и конверсия: самый дорогой сигнал

Клик дешёвый, заказ - дорогой. На уровне карточки модели (TG_MODEL) есть прямые денежные факторы:

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

BLUE_MODEL_ORDERS                заказы модели за месяц (синий Маркет)
BLUE_MODEL_VIEWS                 просмотры карточки за месяц
BLUE_MODEL_VIEW_TO_ORDER_CONVERSION   конверсия захода в покупку
BLUE_CATEGORY_ORDERS_DIV_MODEL_CLICKS
SPLITTED_ORDERS_WITH_THIS_OFFER  заказы, привязанные к офферу (TG_OFFER)

А вот WHITE_MODEL_ORDERS (заказы на белом Маркете) помечен Tags [TG_BASE, TG_MODEL, TG_DEPRECATED] - мёртвый, наследие старой витрины. Живой - синий контур (BLUE_*). Это логично: после переезда на маркетплейс-модель заказы считаются на своей площадке, где они наблюдаемы.

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

Что из этого реально контролирует магазин

• CTR сниппета (MODEL_CTR, OFFER_CTR) - управляется качеством карточки: заголовок, главное фото, цена, наличие. Это то, что видно в выдаче до клика.
• DOCUMENT_QUERY_CTR - управляется релевантностью карточки запросам: точные характеристики в фиде, чтобы товар показывался по правильным запросам и собирал по ним клики.
• Длинный клик и dwelltime - полнота карточки: описание, характеристики, фото, отзывы, чтобы человек не отскочил обратно в выдачу.
• SHOW_TO_ORDER и конверсия - цена, наличие, скорость доставки, рейтинг магазина. Это то, что превращает клик в заказ.
• Агрегаты SHOP/VENDOR/CATEG - долгая репутация: ей подтягиваются новинки без своей статистики.

Про накрутку - прямо

Сообщество SEO много обсуждает накрутку ПФ, и в 2025-2026 Яндекс это давит фильтрами на основном поиске. В товарной вертикали накрутка кликов упирается в стену: сырой CTR сглаживается (_ADJ, RATIONALSIGMOID), оценивается относительно медианы выдачи (DIV_TOTAL_*), а ключевые деньги считаются по длинным кликам с порогом 120 секунд и по реальным оплаченным заказам (BLUE_MODEL_ORDERS, SHOW_TO_ORDER). Имитировать показ-клик можно, имитировать оплаченный заказ с доставкой - нет. Вкладываться в накрутку кликов смысла мало.

Границы вывода

Доказано кодом: перечисленные Name и их Tags существуют в реестре вертикали goods; есть сглаживание CTR (_ADJ), относительные CTR (DIV_TOTAL), окна 120 секунд (THRESHOLD_120, LONG_CLICK_120_SQRT), реалтайм-счётчики RAPID_CLICKS и денежные факторы BLUE_MODEL_ORDERS / VIEW_TO_ORDER_CONVERSION / SHOW_TO_ORDER.

Помечено мёртвым: WHITE_MODEL_ORDERS и USER_OFFER_CTR_PROMO_PERS - TG_DEPRECATED; RAPID_CLICKS_CLICKS_TO_LONG_CLICKS_..._CATEGID - TG_UNUSED; LONG_CLICK_FULL_MATCH_VALUE и YA_MARKET_LONG_CLICK_FULL_MATCH_VALUE - TG_DELETE_CANDIDATE. Их не подавать как рабочие рычаги.

Реконструкция (НЕ доказано кодом): относительная сила сигналов, утверждение "заказ сильнее клика", связь конкретных факторов с конкретными действиями магазина. Это интерпретация смысла имён и опыта, а не извлечённые веса. CatBoost-модель статических весов факторам не даёт - влияние любого признака зависит от остальных в дереве.

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