Свежесть и реалтайм: Datetime, RapidClicks и быстрые клики

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

Свежесть и реалтайм: Datetime, RapidClicks и быстрые клики

Сообщение anna_seo »

Свежесть не глобальна: она включается классом запроса

Главная ошибка в трактовке метаданных утечки 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 - иначе длинный хвост не отранжировать
Принцип у всех один: классификатор запроса определяет режим, режим переписывает веса. Коммерческий запрос поднимает продуктовые DSSM и включает штраф за рекламный переизбыток. Гео/перс подтягивает регион и персональную историю. Холодный старт, наоборот, давит кликовую группу B, потому что кликов попросту нет, и перекладывает вес на текстовую (T) и ссылочную (H) составляющие. На этом фоне Mсвеж - режим, в котором вверх идут именно временные сигналы и сигналы быстрой реакции пользователей.

Что именно усиливает Mсвеж

Две группы факторов получают резко повышенный вес в свежестном классе.
  • Datetime - 8 факторов. Это временные характеристики документа: когда он появился, насколько актуальна его дата.
  • RapidClicks - 33 фактора. Это быстрые клики, реакция пользователей в короткий промежуток после показа.
Соотношение само по себе показательно: быстрых кликов в четыре с лишним раза больше, чем датовых факторов. Свежесть в новостном классе - это не только про дату документа, а в значительной мере про то, как на него реагируют прямо сейчас. Документ с правильной свежей датой, но без быстрой кликовой реакции, в этом режиме недотягивает - время и поведение работают в паре.

Из именованных сигналов в материале фигурируют:

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

FreshNewsDetectorPredict - предсказатель "это новостной/свежий сюжет"
AddTime                  - время добавления документа в индекс
FirstValidTs             - первая валидная временная метка документа
FreshNewsDetectorPredict логично читается как часть механизма, который и относит запрос (или сюжет) к свежестному классу - то есть как триггер включения режима Mсвеж. AddTime и FirstValidTs - это уже признаки самого документа на оси времени: момент попадания в индекс и первая достоверная временная метка. Разделение между ними неслучайно: дата публикации, заявленная в документе, и фактическое время, когда система впервые увидела документ как валидный, - разные вещи, и для свежестного ранжирования важна именно достоверная временная привязка, а не только то, что написано в разметке.

Когда дата важна, а когда нет

Ключевой практический вывод из устройства модификатора: датовые факторы и быстрые клики решают только внутри свежестного класса. На запросе, который классификатор не отнёс к свежим/новостным, модификатор Mсвеж не включён, и тогда:
  • свежая дата не даёт преимущества - вес Datetime остаётся низким;
  • быстрые клики не переписывают выдачу - RapidClicks не в приоритете;
  • выдачу определяют другие группы (текстовая релевантность, ссылочная, общая кликовая история, коммерческие/гео-сигналы по соответствующему классу).
Дата и быстрые клики решают исход только в свежестном классе запроса. Вне его обновление даты документа - косметика, не рычаг ранжирования.
Отсюда понятно, почему массовое проставление свежих дат на статичном, не-новостном контенте не работает и в принципе работать не может: для запроса, который не распознан как свежестный, модификатор не активирован, и факторы Datetime не получают того веса, ради которого дату трогали. Более того, рассинхрон между заявленной датой и AddTime/FirstValidTs - это не усиление сигнала, а потенциальный повод для системы не доверять заявленной свежести.

Что это значит на практике
  • Сначала класс, потом тактика. Прежде чем вкладываться в свежесть, нужно понять, свежестный ли это запрос. Если FreshNewsDetectorPredict-логика не относит сюжет к свежим, оптимизация под Datetime/RapidClicks - мимо.
  • Свежесть - это пара "время + реакция". 33 фактора RapidClicks против 8 Datetime говорят, что в новостном режиме критична быстрая кликовая реакция, а не только корректная дата. Свежая дата без трафика и без быстрых кликов недотягивает.
  • Достоверность временной метки. AddTime и FirstValidTs отделяют реальную свежесть от декларируемой. Игры с датой в разметке без реального обновления и реального появления в индексе не дают того, что даёт настоящая свежесть сюжета.
  • Не-новостной контент. Для статичных тем датовые манипуляции не рычаг. Там работают другие группы факторов, и ресурс лучше тратить на них.
Дисклеймер
Числовые соотношения (8 факторов Datetime, 33 RapidClicks, ~76 в TG_COMMERCIAL) и состав групп взяты из метаданных утечки. Любые веса в рассуждении иллюстративны: реальные веса обучаемы и проприетарны, в самих метаданных их нет. Всё вышесказанное - реконструкция логики по структуре и именам факторов, а не выгрузка коэффициентов ранжирования. Имена FreshNewsDetectorPredict, AddTime, FirstValidTs и индексы факторов приведены как они фигурируют в источнике; их точная семантика в продакшене может отличаться от реконструированной.
Итог простой и операциональный: свежесть - это режим, а не глобальная добавка. Datetime и RapidClicks переписывают выдачу там и только там, где запрос распознан как свежестный. На всех прочих классах дату документа имеет смысл держать честной и достоверной, но не рассчитывать, что она что-то решит.
👍 ❤️ 🔥 😄 🤔
Ответить
Поделиться темой: ✈ Telegram VK

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

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

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