Магазин и продавец: рейтинг, отзывы, операционный рейтинг и качество хоста

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

Магазин и продавец: рейтинг, отзывы, операционный рейтинг и качество хоста

Сообщение anna_seo »

О чём этот разбор

Продолжаю серию по факторам товарной вертикали Яндекса (yandex.ru/products плюс товарный колдунщик в общем поиске). Сегодня - не про сам товар и не про цену, а про того, кто этот товар продаёт. То есть про сигналы уровня магазина и продавца: рейтинг, отзывы, операционный рейтинг и общее качество хоста.

Вертикаль внутри называется goods. Реестр факторов лежит в base/factors/factors_meta_gen.in - это 3144 фактора, у каждого CppName, человекочитаемый Name и набор Tags. По Tags видно, на каком уровне фактор считается (оффер или карточка модели) и в каких местах выдачи применяется. Всё, что ниже - вытащено грепом по этому реестру, имена настоящие, я их не сочинял.
Сразу дисклеймер. Это разбор по исходникам вертикали goods, а не официальная формула Маркета. Ранжирование крутится на CatBoost/MatrixNet (в data/formulas лежат скомпилированные модели), а это деревья решений - у факторов НЕТ фиксированных процентных весов. Поэтому ниже я говорю качественно: сильный сигнал, слабый, вспомогательный. Любые цифры вида "рейтинг это N процентов" - выдумка, у меня их не будет.
Группа сигналов: кто продавец

Концептуально вся группа делится на четыре пучка:
  • репутация по отзывам (SHOP_RATING, SHOP_OPINION_COUNT и производные)
  • операционка - как магазин реально исполняет заказы (SHOP_OPERATIONAL_RATING_*)
  • поведенческое по магазину (SHOP_CTR, SHOP_CLICKS, SHOP_SHOWS)
  • статика и качество хоста (HOST_QUALITY, SHOP_QUALITY_RATIO, рекомендации вендора, региональность)
И отдельно стоит репутация самой карточки модели (MODEL_RATING, MODEL_OPINIONS_COUNT) - это уже не про магазин, но в той же логике отзывов, поэтому добавлю в конце.

Репутация по отзывам

Базовая пара, которая живёт в реестре с самого начала (низкие индексы, считай ядро):

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

Name                       Tags
SHOP_RATING                TG_BASE TG_BLENDER_PLACE TG_OFFER
                           TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
SHOP_OPINION_COUNT         TG_BASE TG_BLENDER_PLACE TG_OFFER
                           TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
LOG_SHOP_OPINION_COUNT     TG_OFFER TG_BASE
  Description: Двоичный логарифм количества отзывов о магазине
SHOP_RATING - это та самая звёздная оценка магазина. SHOP_OPINION_COUNT - сколько отзывов набрано. А LOG_SHOP_OPINION_COUNT прямым текстом в Description описан как двоичный логарифм количества отзывов. Это очень показательная деталь: log нужен именно потому, что разница между 10 и 100 отзывами для модели важнее, чем между 5000 и 5100. То есть надёжность оценки растёт быстро на старте и почти упирается в потолок дальше. Магазину с нуля важно добрать первую сотню-другую отзывов, а дальше отдача по этому конкретному входу падает.

Обратите внимание на Tags: оба фактора стоят и на TG_OFFER (уровень оффера), и на TG_MODEL_OFFER_PLACE (карточка товара с офферами), и на TG_TEXT_PLACE (текстовая выдача), и на TG_BLENDER_PLACE (подмешивание в общую выдачу). То есть рейтинг магазина видят почти все места показа, где вообще участвует оффер. Это сильный, сквозной сигнал.

Есть ещё квантильная нарезка - SHOP_OPINION_COUNT_Q0/Q25/Q50/Q75/Q100 и аналогичные FIXED_SHOP_OPINION_COUNT_Q*. У них Tag - TG_CATEGORY:

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

SHOP_OPINION_COUNT_Q50         TG_CATEGORY
FIXED_SHOP_OPINION_COUNT_Q50   TG_CATEGORY
FIXED_SHOP_SHOWS_Q50           TG_CATEGORY
Смысл реконструирую так: это не абсолютное число отзывов, а позиция магазина внутри своей категории - квантиль (медиана, верхняя четверть и т.д.). Логика правильная: 200 отзывов в нишевой категории - это много, а в категории смартфонов - ничто. TG_CATEGORY означает, что значение нормируется относительно категории. FIXED_ версия, судя по названию, это зафиксированный (стабилизированный) вариант той же метрики, чтобы не дёргался от шума. Помечаю как реконструкцию - в реестре нет Description, я читаю по именам и тегу.

Операционный рейтинг - вот это важная часть

Самый интересный кусок, и у него в реестре есть Ticket и Wiki, значит это сравнительно поздняя осознанная разработка (тикет MARKETOUT-36242):

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

SHOP_OPERATIONAL_RATING_TOTAL              TG_BASE TG_OFFER
                                           TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
SHOP_OPERATIONAL_RATING_CANCELLATION_RATE  -//-
SHOP_OPERATIONAL_RATING_LATE_SHIP_RATE     -//-
SHOP_OPERATIONAL_RATING_RETURN_RATE        -//-
Это машинная проекция того, что Маркет снаружи называет индексом качества продавца. Разложено на три беды плюс итог:
  • CANCELLATION_RATE - доля отменённых магазином заказов
  • LATE_SHIP_RATE - доля просроченной отгрузки (поздно перевели заказ в "готов к отгрузке")
  • RETURN_RATE - доля возвратов/невыкупов по вине магазина
  • TOTAL - агрегированный операционный рейтинг
Это самая контролируемая магазином группа из всех. Тут нет ни поведения чужих пользователей, ни региона - только то, как ты сам исполняешь заказы. И тут же ловушка, которую подтверждает практика 2025-2026: запоздалый перевод статуса "готов к отгрузке" система фиксирует как просрочку, даже если по факту товар собран. То есть бьёт не только опоздание физическое, но и опоздание в интерфейсе/API.
Что доказано кодом: три операционные метрики (отмены, просрочка, возвраты) и итоговый рейтинг заведены отдельными факторами на уровне оффера и видны в карточке, текстовой выдаче. Что реконструкция: как именно они складываются в TOTAL и насколько резко штрафуют - это внутри CatBoost-модели, статического веса там нет.
Практический момент из сообщества: при провале индекса качества магазину не просто режут показы - растёт комиссия и теряется доступ к акциям, а в крайнем случае магазин временно отключают. Так что эти четыре фактора - не косметика, это про выживание оффера в выдаче в принципе.

Поведенческое по магазину

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

SHOP_CTR       TG_MODEL_OFFER_PLACE TG_BASE TG_BLENDER_PLACE TG_TEXT_PLACE
SHOP_CTR_ADJ   -//-
SHOP_CLICKS    -//-
SHOP_SHOWS     -//-
SHOP_SHOWS - сколько раз офферы магазина показали, SHOP_CLICKS - сколько кликнули, SHOP_CTR - их отношение. SHOP_CTR_ADJ - скорректированный CTR (adjusted): сырой CTR смещён позицией и категорией, поэтому держат отдельный сглаженный вариант. Это сигнал доверия аудитории к магазину как таковому, накопленный по всем его офферам. Контролируется лишь косвенно: хорошие цена, рейтинг и заголовок поднимают CTR, но напрямую его не накрутишь без риска. Я бы оценил как средний по силе вспомогательный сигнал - он сквозной (виден везде), но шумный для нового магазина с малой статистикой.

Качество хоста и прочая статика

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

HOST_QUALITY            TG_DOCUMENT_STATIC TG_BLENDER_PLACE TG_BASE
                        TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
SHOP_QUALITY_RATIO      TG_BLENDER_PLACE TG_BASE TG_MODEL_OFFER_PLACE
SHOP_RECOMMENDED_BY_VENDOR  TG_BASE TG_BLENDER_PLACE TG_OFFER
                            TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
SHOP_NAME_LATIN         TG_BASE TG_BLENDER_PLACE TG_OFFER ...
SHOP_NAME_UPPERCASE     TG_BASE TG_BLENDER_PLACE TG_OFFER ...
HOST_QUALITY помечен TG_DOCUMENT_STATIC - это статический сигнал качества хоста/магазина, считается заранее, не зависит от запроса. По сути аналог хостового качества из большого веб-поиска, перенесённый в товарную вертикаль. SHOP_QUALITY_RATIO - какое-то отношение качества (без Description, реконструирую как обобщённую долю/коэффициент качества магазина). SHOP_RECOMMENDED_BY_VENDOR - флаг "рекомендован вендором" (производителем), то есть авторизованный продавец бренда; это объяснимо сильный сигнал доверия в брендовых категориях.

Два почти забавных, но настоящих фактора - SHOP_NAME_LATIN и SHOP_NAME_UPPERCASE: латиница в названии магазина и КАПС в названии. Это не про репутацию, это анти-спам эвристики: КАПС и странная латиница исторически коррелируют с мусорными/серыми магазинами. Сами по себе слабые, но в связке с другими могут тянуть оффер вниз. Вывод банальный: не пишите название магазина капсом.

Региональная подгруппа (SHOP_FROM_RUSSIA, SHOP_IN_USER_REGION, DIST_BETW_USER_AND_SHOP_REGIONS, SHOP_DISTANCE_TO_MOSCOW и куча SHOP_REGION_*) - это уже не про репутацию, а про географию продавец-пользователь, у всех Tag TG_REGION. Подробно их разберу в отдельном треде про регион и доставку, тут только отмечу, что они существуют и считаются на уровне оффера.

Репутация карточки модели

Близкая по духу, но другой объект - рейтинг самого товара, а не магазина:

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

MODEL_RATING            TG_BASE TG_BLENDER_PLACE TG_MODEL
                        TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
MODEL_RATING_2          -//-
MODEL_RATING_PRECISE    TG_DOCUMENT TG_BASE  (точность до 2 знаков)
MODEL_RATING_COUNT      TG_DOCUMENT TG_BASE  (число оценок, не только текстовых)
MODEL_OPINIONS_COUNT    TG_DOCUMENT TG_BASE  (число текстовых отзывов)
MODEL_POSITIVE_OPINIONS_PART  TG_DOCUMENT TG_BASE
                        (доля положительных от текстовых отзывов)
Здесь Tag TG_MODEL - сигнал на уровне карточки. У моделей есть рейтинг (даже две версии MODEL_RATING и MODEL_RATING_2 - явно итерация формулы), точный рейтинг до сотых, отдельно счётчик всех оценок и счётчик именно текстовых отзывов, и доля позитива MODEL_POSITIVE_OPINIONS_PART. То есть система отличает "поставил пять звёзд" от "написал текстовый отзыв" - текстовые ценятся отдельно. Для продавца это значит: добавляйте офферы на хорошо отзывную карточку, а не плодите дубль-карточки без отзывов.

Что из этого реально контролирует магазин
  • Полностью свои: операционка - SHOP_OPERATIONAL_RATING_CANCELLATION_RATE, LATE_SHIP_RATE, RETURN_RATE. Не отменяйте заказы, вовремя переводите статус в API, минимизируйте возвраты по своей вине. Это самый прямой рычаг.
  • Управляемые работой с клиентом: SHOP_RATING и SHOP_OPINION_COUNT - просите отзывы, отвечайте даже на негатив (грамотный ответ снимает часть ущерба). На старте важна именно первая сотня отзывов (логарифм).
  • Гигиена: не капсить и не латинизировать название (SHOP_NAME_UPPERCASE, SHOP_NAME_LATIN), стать авторизованным продавцом бренда там, где есть SHOP_RECOMMENDED_BY_VENDOR.
  • Косвенные: SHOP_CTR/CTR_ADJ - тянутся вверх через цену, рейтинг и адекватный заголовок, напрямую не крутятся.
  • Не контролируется почти никак: HOST_QUALITY как статика и региональные факторы - это про вас как сущность и про географию, быстро не сдвинешь.
Границы вывода
Доказано кодом: перечисленные Name существуют в реестре factors_meta_gen.in вертикали goods с указанными Tags; операционные факторы заведены через тикет MARKETOUT-36242; LOG_SHOP_OPINION_COUNT по Description - двоичный логарифм числа отзывов; квантильные SHOP_OPINION_COUNT_Q* нормируются по категории (TG_CATEGORY); HOST_QUALITY статический (TG_DOCUMENT_STATIC). В этой группе я не нашёл ни одного TG_DEPRECATED/TG_UNUSED - все факторы живые.
Реконструкция (читаю по именам, без Description): точный механизм SHOP_QUALITY_RATIO, как складывается OPERATIONAL_RATING_TOTAL, разница между обычной и FIXED_ квантилью, относительная сила сигналов. CatBoost-модель не раздаёт факторам статических процентов - оценки силы качественные.
Если интересно - дальше в серии разберу отдельно региональный пучок (SHOP_FROM_RUSSIA, дистанции, мегаполисы) и поведенческие факторы выдачи. Вопросы и контраргументы по операционке приветствуются, особенно у тех, кто реально вытаскивал индекс качества из ямы.
👍 ❤️ 🔥 😄 🤔
Ответить
Поделиться темой: ✈ Telegram VK

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

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

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