Как Яндекс выявляет источники «флешмобов» в отзывах и рейтингах, анализируя историю браузера пользователей

Описание

Какую задачу решает

Патент решает задачу поддержания достоверности краудсорсинговых оценок (рейтингов, отзывов) в условиях информационных атак или стихийных «флешмобов» (упоминается в патенте как flash mob). Проблема заключается в том, что пользователи могут массово выставлять оценки под влиянием внешнего триггера (external trigger event) — например, вирусного обзора блогера или поста в социальной сети, — часто не имея реального опыта взаимодействия с объектом. Это искажает рейтинг. Патент предлагает механизм не просто фильтрации подозрительных оценок, но и выявления первоисточника (source), спровоцировавшего аномальную активность.

Что запатентовано

Запатентована система идентификации источника внешнего влияния на пользовательские оценки. Суть изобретения заключается в корреляции аномалий в распределении оценок (abnormal subset) с историей посещений (browsing history) пользователей. Система статистически выявляет веб-ресурсы, которые посещались участниками «флешмоба» значительно чаще, чем контрольной группой, и маркирует эти ресурсы как источники влияния.

Как это работает

Система анализирует распределение оценок во времени. При обнаружении аномального всплеска (например, резкого роста оценок «1»), не соответствующего типичному распределению, активируется анализ. Пользователи делятся на две группы: поставившие аномальные оценки (Группа 1) и остальные (Группа 2). Система извлекает историю посещений обеих групп из Web History Log. Используя статистические методы (в частности, Z-statistics), она ищет ресурсы (delta set), которые Группа 1 посещала значительно чаще. Эти ресурсы признаются источником триггера. Оценки пользователей, посетивших этот источник, могут быть исключены или пессимизированы.

Актуальность для SEO

Высокая. Проблема ревью-бомбинга, скоординированных атак на репутацию и влияния инфлюенсеров крайне актуальна для всех платформ, агрегирующих UGC (например, Яндекс.Карты, Маркет, Кинопоиск). Использование данных о поведении пользователей (включая историю посещений, доступную через экосистему Яндекса) для валидации их действий является передовым подходом к обеспечению качества данных.

Важность для SEO

Влияние на SEO значительно (7.5/10), особенно в области управления репутацией (ORM/SERM), локального SEO и E-commerce. Хотя патент не описывает алгоритмы веб-поиска, он критически важен для факторов, основанных на пользовательских рейтингах. Он демонстрирует техническую возможность Яндекса выявлять и нейтрализовывать попытки манипуляции рейтингами через внешние кампании путем анализа кросс-платформенного поведения пользователей. Это делает стратегии искусственного бустинга рейтингов высокорискованными.

Детальный разбор

Термины и определения

Abnormal Crowd-Sourced Label (Аномальная краудсорсинговая метка)

Оценка (рейтинг, отзыв), выставленная пользователем под влиянием внешнего триггера, а не обязательно на основе личного опыта. Отличается от мошеннических (fraudulent) меток (боты).

Abnormal Subset (Аномальное подмножество)

Набор оценок, демонстрирующий статистически значимое отклонение (всплеск) от типичного распределения. Предполагается, что он вызван внешним событием.

Delta Set (Дельта-набор)

Набор веб-ресурсов, выявленных путем анализа разницы в истории посещений между аномальной и контрольной группами. Содержит потенциальные источники триггера.

Digital Item (Цифровой объект)

Объект, которому пользователи выставляют оценки (например, товар, услуга, организация на карте, фильм).

External Trigger Event (Внешнее триггерное событие)

Событие (например, вирусный обзор, пост в блоге), которое мотивирует пользователей массово выставлять оценки.

Flash Mob («Флешмоб»)

Термин, используемый в тексте патента для описания массового выставления оценок пользователями под влиянием внешнего триггера.

Spike Trends (Тренды всплесков)

Анализ резких изменений в концентрации соседних значений оценок. Патент выделяет возможность Single Spike (одиночный всплеск) и Joint Spike (двойной всплеск).

Web History Log / Browsing History (Лог веб-истории / История посещений)

Данные о посещенных пользователем веб-ресурсах (URL) и времени доступа, хранящиеся на Tracking Server (например, данные Метрики или Браузера).

Z-statistics (Z-статистика)

Статистический метод, используемый для определения того, является ли разница в пропорциях посещений веб-ресурса между двумя группами пользователей статистически значимой, а не случайной.

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает основной метод выявления источника внешнего влияния на краудсорсинговые оценки.

1. Анализ набора краудсорсинговых меток, собранных за период времени.
2. Определение Abnormal Subset (аномального подмножества) меток, предположительно вызванного External Trigger Event.
3. Получение истории посещений (Browsing History) пользователей, предоставивших эти метки, из Web History Log.
4. Разделение истории посещений на две группы:
   • Группа 1 (First group): Связанная с аномальным подмножеством (участники флешмоба).
   • Группа 2 (Second group): Связанная с остальными метками (контрольная группа).
5. Генерация Delta Set веб-ресурсов путем анализа различий в посещениях между Группой 1 и Группой 2. В набор попадают ресурсы с Abnormal Pattern of Visits (аномальным паттерном посещений).
6. Ассоциирование веб-ресурса(ов) из Delta Set как источника внешнего триггерного события.

Claim 6 (Зависимый пункт): Уточняет метод определения аномального подмножества (Шаг 2).

Аномалия определяется путем анализа Spike Trends (трендов всплесков) между соседними значениями меток. Если эти тренды не соответствуют (misaligned) типичному распределению, фиксируется аномалия.

Claims 11, 12 и 13 (Зависимые пункты): Уточняют метод определения аномального паттерна посещений и идентификации источника (Шаг 5 и 6).

Рассчитываются пропорции пользователей, посетивших веб-ресурс, в Группе 1 (P1) и Группе 2 (P2). Если P1 больше P2, паттерн считается аномальным (Claim 11). Сравнение P1 и P2 выполняется с использованием Z-statistics (Claim 12). Если Z-статистика указывает на статистически значимое различие, веб-ресурс подтверждается как источник триггера (Claim 13).

Claims 3, 4, 5 (Зависимые пункты): Описывают корректирующие действия.

Система может исключить (discarding) (Claim 3) или понизить вес (lowering weight) (Claim 4) меток от пользователей, посетивших источник триггера. Это также может применяться проактивно к будущим оценкам (Claim 5).

Где и как применяется

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

Слой Качества и Метрик (QUALITY & GOVERNANCE LAYER)

Основное применение. Система функционирует как механизм антифрода и контроля качества краудсорсинговых данных, обеспечивая достоверность сигналов, основанных на пользовательских оценках.

• Взаимодействие: Система взаимодействует с серверами приложений, хранящими оценки, и с Tracking Server (Сервер отслеживания), хранящим историю посещений пользователей (данные Метрики/Браузера).
• На входе: Набор оценок для объекта за период времени; история посещений пользователей, выставивших эти оценки.
• На выходе: Идентификация источника(ов) внешнего триггера (URL); скорректированный вес или исключение оценок, признанных аномальными.

RANKING – Ранжирование

Косвенное влияние. Очищенные данные (скорректированные рейтинги) используются системами ранжирования (например, в локальном поиске или на Маркете). Предотвращая манипуляции рейтингами, система влияет на финальное ранжирование объектов.

На что влияет

• Конкретные типы контента и ниши: Критически важно для E-commerce (рейтинги товаров), Локального поиска (рейтинги организаций на Картах), медиа-контента (фильмы, приложения). Влияет на любые объекты с публичными рейтингами.
• Управление репутацией (ORM/SERM): Напрямую влияет на устойчивость рейтингов к внешним манипуляциям (как негативным атакам, так и искусственному бустингу).

Когда применяется

• Триггеры активации: Обнаружение статистически значимой аномалии (Spike Trend) в распределении оценок за короткий промежуток времени, которая не соответствует типичному паттерну (например, резкий рост количества оценок «1» или «10»).
• Условия работы: Необходим доступ к истории посещений (Web History Log) значительной части пользователей, выставивших оценки. Это предполагает использование данных экосистемы Яндекса.

Пошаговый алгоритм

1. Сбор данных и Мониторинг: Система собирает Crowd-sourced Labels для Digital Item в рамках скользящего временного окна (T).
2. Анализ распределения (Initial Label Analyzer):
   1. Рассчитывается разница в концентрации (DIVs — Difference in Values, описано в патенте) между соседними значениями оценок.
   2. DIVs нормализуются и ранжируются.
   3. Выявляются аномально высокие значения (Spike Trends), не соответствующие типичному распределению.
3. Определение Аномалии (Abnormal Subset Selector): Если выявлены значительные Spike Trends, система определяет Abnormal Subset оценок (флешмоб).
4. Получение Истории Посещений (Browsing History Acquirer): Запрос истории посещений пользователей за период T у Tracking Server.
5. Сегментация Пользователей (Browsing History Parser): Пользователи делятся на две группы:
   • Группа 1 (Флешмоб): Пользователи, выставившие оценки из Abnormal Subset.
   • Группа 2 (Контроль): Остальные пользователи.
6. Генерация Дельта-набора (Delta Set Generator):
   1. Для каждого URL рассчитывается пропорция пользователей, посетивших его в Группе 1 (P1) и Группе 2 (P2).
   2. Сравнение P1 и P2 с использованием Z-statistics.
   3. Если P1 статистически значимо больше P2, URL добавляется в Delta Set как потенциальный источник триггера.
7. Ранжирование источников: Ресурсы в Delta Set могут быть ранжированы по пропорции пользователей (Claim 14). Выбираются Топ-N источников триггера.
8. Принятие Мер (Final Label Analyzer):
   • Идентификация пользователей, посетивших источник триггера.
   • Исключение или понижение веса (lowering weight) их оценок.
   • Проактивный мониторинг будущих оценок от пользователей, посетивших этот источник.

Какие данные и как использует

Данные на входе

• Поведенческие факторы (Ключевые данные):
  • Web History Log / Browsing History: Подробные логи посещенных URL и времени доступа (Access time) для каждого пользователя. Критически важно для выявления источника влияния.
  • Действия пользователя (UGC): Факт выставления оценки, значение оценки (Crowd-sourced labels), время выставления.
• Временные факторы: Временные метки используются для определения периода анализа (T) и корреляции посещений веб-ресурсов с выставлением оценок.
• Системные данные:
  • Typical Distribution: Эталонные данные о нормальном распределении оценок.

Какие метрики используются и как они считаются

• Difference in Values (DIVs): Метрика для анализа распределения. Рассчитывается как разница в доле (концентрации) между двумя соседними значениями оценок (описано в патенте).
• Normalized DIVs: DIVs, приведенные к единой шкале для сравнения и выявления всплесков (Spike Trends).
• Proportion of Users (P1, P2): Доля пользователей в Группе 1 (Флешмоб) и Группе 2 (Контроль), посетивших определенный URL.
• Z-statistics (Z-статистика): Статистический метод, используемый для определения того, является ли разница между пропорциями P1 и P2 статистически значимой, или она случайна. Это ключевой механизм для надежного подтверждения источника триггера (Claim 12).

Выводы

1. Яндекс валидирует достоверность пользовательских сигналов через историю браузера. Патент подтверждает, что Яндекс имеет техническую возможность анализировать детальную историю посещений пользователей (Browsing History) для контроля качества на своих сервисах (Карты, Маркет и т.д.).
2. Целенаправленная борьба с «Флешмобами» и Ревью-бомбингом. Система разработана для противодействия не просто спаму или ботам, а скоординированным или стихийным действиям реальных пользователей, чье мнение сформировано внешними триггерами (вирусные посты, обзоры).
3. Идентификация источника влияния. Ключевая особенность — не фильтрация подозрительных оценок, а точное определение веб-ресурса (URL), спровоцировавшего флешмоб, путем статистического анализа поведенческих различий (Z-statistics).
4. Контекст поведения определяет вес отзыва. Достоверность оценки зависит от поведения пользователя до ее выставления. Если пользователь посетил выявленный источник влияния, его оценка теряет в весе или исключается.
5. Важность экосистемы Яндекса. Эффективность системы напрямую зависит от объема данных об истории посещений, что подчеркивает стратегическую важность Яндекс.Браузера, Метрики и единого аккаунта для сбора этих данных.

Практика

Best practices (это мы делаем)

• Стимулирование органических и распределенных отзывов: Сосредоточьтесь на получении отзывов от реальных клиентов в естественном режиме, а не путем массовых кампаний. Органическое распределение оценок устойчиво к анализу на «флешмобы».
• Мониторинг репутации (ORM) и информационного поля: Отслеживайте появление вирусных обзоров или постов о вашем бренде. Если начинается флешмоб (позитивный или негативный), будьте готовы к тому, что Яндекс может применить этот алгоритм и скорректировать рейтинги.
• Аккуратная работа с инфлюенсерами: При запуске кампаний у блогеров избегайте прямых призывов поставить оценку. Если кампания приведет к резкому, неестественному всплеску однотипных оценок, Яндекс может идентифицировать источник кампании и нивелировать ее эффект.

Worst practices (это делать не надо)

• Организация искусственных «флешмобов»: Попытки массово стимулировать положительные отзывы (или негативные для конкурентов) через внешние кампании (соцсети, блоги, Telegram-каналы). Система специально разработана для обнаружения источника такой активности и нейтрализации ее эффекта.
• Использование буксов и бирж заданий: Если пользователи переходят для выполнения задания с одного и того же источника (сайта букса), этот источник будет быстро вычислен как триггер, а отзывы — аннулированы из-за Abnormal Pattern of Visits.
• Резкие накрутки однотипных отзывов: Покупка большого количества отзывов с максимальной оценкой за короткий промежуток времени создаст аномальный всплеск (spike trend), что активирует систему анализа.

Стратегическое значение

Патент имеет высокое стратегическое значение, демонстрируя глубину поведенческого анализа Яндекса. Он подтверждает, что Яндекс использует данные кросс-платформенного отслеживания (собранные через Метрику/Браузер) для обеспечения качества своих сервисов. Для SEO и ORM это означает, что манипулировать пользовательскими сигналами в экосистеме Яндекса становится значительно сложнее. Долгосрочная стратегия должна опираться на органическое улучшение продукта и клиентского сервиса, а не на искусственное управление рейтингами.

Практические примеры

Сценарий: Нейтрализация ревью-бомбинга фильма на Кинопоиске (условный сервис Яндекса)

1. Событие: Популярный видеоблогер выпускает разгромный обзор нового фильма (на YouTube-канале, URL_A) и призывает подписчиков занизить его рейтинг.
2. Действие пользователей: Тысячи пользователей смотрят обзор и переходят на Кинопоиск, чтобы поставить фильму оценку «1».
3. Реакция системы (Мониторинг): Система обнаруживает резкий всплеск оценок «1». Spike Trend Analyzer фиксирует аномалию, не соответствующую типичному распределению.
4. Реакция системы (Анализ): Система запрашивает историю посещений пользователей, поставивших «1» (Группа 1), и сравнивает ее с контрольной группой (Группа 2).
5. Выявление источника: Анализ с помощью Z-statistics показывает, что 75% пользователей из Группы 1 посещали URL_A незадолго до выставления оценки, тогда как в Группе 2 этот URL посещали только 3%. URL_A признается источником флешмоба.
6. Результат: Система автоматически понижает вес или исключает оценки пользователей, которые посетили URL_A. Рейтинг фильма корректируется.

Вопросы и ответы