Яндекс патентует метод борьбы с фейковыми отзывами путем анализа истории посещений пользователя. Система ищет в истории браузера URL-адреса, соответствующие страницам подтверждения транзакций (например, «Thank you page»). Для этого используются векторные представления (эмбеддинги) и шаблоны URL. Если такой URL найден, пользователь признается реальным покупателем, а его отзыв получает приоритет или пометку «подтвержденный».
Описание
Какую задачу решает
Патент решает задачу борьбы с мошенническими (фейковыми) отзывами и накруткой рейтингов на рекомендательных платформах (например, Яндекс.Маркет, Яндекс.Карты). Проблема заключается в том, что пользователи оставляют отзывы за плату, не совершив покупку и не взаимодействуя с организацией, что искажает рейтинги и вводит в заблуждение потребителей. Существующие методы верификации (например, проверка кредитных карт) вызывают проблемы с конфиденциальностью. Патент предлагает метод верификации без доступа к финансовым данным.
Что запатентовано
Запатентована система и метод для определения того, является ли пользователь «Genuine Customer» (реальным клиентом), путем анализа его истории посещений (Browsing History). Суть изобретения заключается в идентификации посещения пользователем «Transaction Confirmation Page» (страницы подтверждения транзакции, например, «Thank you page» после покупки) посредством анализа URL-адресов в его истории.
Как это работает
Система получает URL из истории браузера пользователя и генерирует для него векторное представление (Embedding), например, используя Word2Vector. Этот эмбеддинг сравнивается с базой данных (Genuity Database), содержащей эмбеддинги известных страниц подтверждения транзакций. Если новый эмбеддинг достаточно близок к шаблону (разница ниже Embedding Difference Threshold), URL признается страницей подтверждения, а пользователь — реальным клиентом. Система также использует URL Patterns (шаблоны URL) и маски для быстрого распознавания схожих страниц подтверждения у разных сайтов, использующих одинаковые CMS.
Актуальность для SEO
Высокая. Борьба с фейковыми отзывами является критически важной задачей для всех платформ с пользовательским контентом (UGC), включая сервисы Яндекса. Использование эмбеддингов для распознавания паттернов и структур данных является стандартной и актуальной практикой в машинном обучении.
Важность для SEO
Влияние на SEO значительно (7/10), особенно для Local SEO и E-commerce. Патент описывает механизм валидации подлинности отзывов. Если он реализован, подлинные отзывы получают больший вес и видимость, в то время как фейковые отзывы помечаются как мошеннические или удаляются. Это напрямую влияет на репутацию компании и сигналы ранжирования, получаемые на основе обратной связи пользователей на платформах Яндекса.
Детальный разбор
Термины и определения
- Browsing History (История посещений)
- Список URL-адресов, посещенных пользователем через браузерное приложение.
- CMS (Content Management System)
- Система управления контентом. Упоминается как причина, по которой разные организации могут иметь схожие структуры страниц подтверждения транзакций.
- Embedding (Эмбеддинг, Векторное представление URL)
- Численный вектор, представляющий URL. Генерируется (например, с помощью Word2Vec) таким образом, что схожие по структуре URL имеют близкие векторы в многомерном пространстве.
- Embedding Difference Threshold (Порог разницы эмбеддингов)
- Предопределенное пороговое значение, используемое для определения того, достаточно ли похожи два эмбеддинга (и, следовательно, URL, которые они представляют).
- Fraudulent User (Мошеннический пользователь)
- Пользователь, оставляющий отзывы без реального взаимодействия с организацией (например, платные отзывы).
- Genuine Customer (Реальный клиент)
- Пользователь, который действительно приобрел товар/услугу или иным образом взаимодействовал с организацией.
- Genuity Database (База данных подлинности)
- База данных, хранящая шаблонные эмбеддинги (Template Embeddings) и шаблоны URL (URL Patterns) известных страниц подтверждения транзакций.
- Mask (Маска)
- Последовательность символов (например, #, ?, *), представляющая структуру динамических частей URL (например, ID пользователя или ID транзакции).
- Recommendation Platform (Рекомендательная платформа)
- Платформа, предоставляющая пользовательские рейтинги и отзывы (например, Яндекс.Маркет, Яндекс.Карты).
- Transaction Confirmation Page (Genuity Confirmation Page) (Страница подтверждения транзакции)
- Веб-страница, указывающая на завершение транзакции (например, страница «Спасибо за покупку»).
- URL Pattern (Шаблон URL)
- Последовательность, представляющая структуру URL, состоящая из статических частей (например, domain/cart/) и динамических частей (представленных масками).
Ключевые утверждения (Анализ Claims)
Патент описывает систему верификации клиентов, основанную на анализе структуры URL в истории браузера с использованием машинного обучения.
Claim 1 (Независимый пункт): Описывает основной метод идентификации и обучения системы.
- Система получает URL из истории посещений электронного устройства пользователя.
- Генерируется эмбеддинг (векторное представление) для этого URL.
- Этот эмбеддинг сравнивается с шаблонными эмбеддингами, извлеченными из Genuity Database.
- Если разница между сгенерированным эмбеддингом и шаблонным эмбеддингом ниже установленного порога (Embedding Difference Threshold), сгенерированный эмбеддинг добавляется в Genuity Database.
Это описывает механизм распознавания страницы подтверждения транзакции на основе векторного сходства и непрерывного обновления базы данных известных страниц подтверждения.
Claim 2 (Зависимый от 1): Описывает действия, предпринимаемые при положительной идентификации.
- Если порог из Claim 1 соблюден (т.е. найдено сходство).
- Устройство пользователя помечается как связанное с Genuine Customer (реальным клиентом) организации.
- Система инициирует отображение отзыва, полученного с этого устройства, будущим клиентам.
Это связывает анализ URL с результатом борьбы с мошенничеством: верификацией клиента и публикацией его отзыва.
Claim 3 (Зависимый от 1): Описывает процесс создания Genuity Database.
- Система получает набор известных URL страниц подтверждения транзакций (шаблонные URL).
- Для каждого из них генерируется шаблонный эмбеддинг.
- Эти эмбеддинги сохраняются в Genuity Database.
Система инициализируется с помощью начального набора известных страниц «Спасибо за покупку».
Claim 6 (Зависимый от 1): Описывает генерацию шаблонов URL.
- Если порог из Claim 1 соблюден.
- Для идентифицированного URL генерируется URL Pattern (шаблон).
- Этот шаблон добавляется в Genuity Database.
Помимо эмбеддинга, система извлекает структурный шаблон (например, domain.com/order/####) для будущего использования.
Claim 9 (Зависимый от 8, который зависит от 1): Описывает использование шаблонов URL для верификации (альтернативный/быстрый путь).
- Система получает второй URL со второго устройства.
- Второй URL сравнивается непосредственно с ранее сгенерированным URL Pattern (из Claim 6).
- Если второй URL соответствует шаблону, второе устройство помечается как принадлежащее реальному клиенту, и его отзыв отображается.
Как только шаблон установлен (например, domain.com/order/####), будущие пользователи, посещающие этот сайт, могут быть верифицированы путем простого сопоставления с шаблоном, что быстрее, чем генерация и сравнение эмбеддингов.
Claim 16 (Зависимый от 1): Описывает действия при отрицательной идентификации (штрафные санкции).
- Если разница равна или превышает порог (т.е. совпадение не найдено).
- Система обращается к базе данных рекомендаций (Recommendation Database).
- Выполняется одно из действий: (i) отзывы с этого устройства помечаются как мошеннические ИЛИ (ii) отзывы удаляются.
Если система не может подтвердить, что пользователь посещал страницу подтверждения, его отзывы пессимизируются или удаляются.
Где и как применяется
Этот патент не применяется напрямую к ранжированию основного веб-поиска. Он относится к экосистеме пользовательского контента (UGC) и рекомендательным платформам, управляемым Яндексом (например, Яндекс.Карты, Яндекс.Маркет).
Сбор данных (Data Acquisition)
Система получает данные не путем сканирования веба (CRAWLING), а путем доступа к истории посещений пользователя (Browsing History). Это подразумевает интеграцию на уровне приложения (например, через Яндекс.Браузер или другие интегрированные сервисы) и требует соответствующего разрешения пользователя.
Индексирование и извлечение признаков (Indexing & Feature Extraction) (в контексте UGC)
Система обрабатывает отзывы, хранящиеся в Recommendation Database. Основной процесс — это извлечение признаков из URL (эмбеддинги, шаблоны, маски) и их хранение в Genuity Database. Для генерации эмбеддингов используется NLP-подход (упомянут Word2Vector), применяемый к структуре URL.
Ранжирование/Фильтрация (Ranking/Filtering) (в контексте UGC)
Результаты проверки подлинности напрямую влияют на то, как отзывы отображаются, фильтруются или взвешиваются на рекомендательной платформе. Подлинные отзывы отображаются или получают буст; мошеннические — скрываются или удаляются. Это косвенно влияет на SEO, поскольку оценки и тональность отзывов часто используются как сигналы доверия и качества сайта/бизнеса.
На что влияет
- Конкретные типы контента: Пользовательские отзывы (UGC), рейтинги организаций, товаров и услуг на платформах Яндекса.
- Конкретные ниши или тематики: Наибольшее влияние оказывается на E-commerce, локальный бизнес (Local SEO), сферу услуг и бронирования — везде, где отзывы играют ключевую роль в принятии решения.
Когда применяется
- Триггеры активации:
- Когда пользователь отправляет отзыв на рекомендательной платформе Яндекса.
- Периодически, для валидации существующих отзывов в базе данных.
- Когда система идентифицирует потенциального клиента (например, пользователь перешел из Яндекс.Маркета во внешний магазин).
- Условия: Алгоритм требует доступа к истории посещений пользователя (Browsing History).
Пошаговый алгоритм
Фаза 1: Инициализация (Офлайн)
- Сбор данных: Сбор начального набора известных URL страниц подтверждения транзакций от шаблонных организаций.
- Генерация эмбеддингов: Для каждого шаблонного URL генерируется Template Embedding (например, с использованием Word2Vec).
- Генерация шаблонов: Идентификация статических и динамических частей URL и генерация Template URL Patterns и масок.
- Заполнение базы данных: Сохранение шаблонных эмбеддингов и шаблонов в Genuity Database.
Фаза 2: Верификация (Онлайн/Рантайм)
- Триггерное событие: Пользователь отправляет отзыв или идентифицирован для верификации.
- Доступ к истории: Система запрашивает и получает URL из истории посещений пользователя (возможно, фокусируясь на временном интервале вокруг даты отзыва).
- Обработка URL (Быстрый путь — Сопоставление с шаблоном):
- Сравнение полученного URL с существующими URL Patterns в Genuity Database.
- Если найдено совпадение (разница < Pattern Difference Threshold): Переход к Фазе 3 (Genuine).
- Обработка URL (Глубокий путь — Анализ эмбеддингов):
- Если совпадение с шаблоном не найдено.
- Генерация нового эмбеддинга для полученного URL.
- Сравнение нового эмбеддинга с Template Embeddings в Genuity Database.
- Определение разницы (например, векторного расстояния).
- Решение о подлинности:
- Если разница ниже Embedding Difference Threshold: Переход к Фазе 3 (Genuine).
- Если разница выше порога для всех шаблонных эмбеддингов: Переход к Фазе 3 (Fraudulent).
Фаза 3: Действие и обновление
- Действия для реального клиента (Genuine):
- Пометка пользователя/устройства как реального клиента.
- Доступ к Recommendation Database и пометка связанного отзыва как подлинного.
- Обеспечение отображения/соответствующего взвешивания отзыва.
- Обновление базы данных: Добавление нового эмбеддинга в Genuity Database. Генерация нового URL Pattern для URL и его добавление в базу (активация Быстрого пути для будущих пользователей этого сайта).
- Действия для мошеннического пользователя (Fraudulent):
- Доступ к Recommendation Database.
- Пометка связанного отзыва как мошеннического ИЛИ удаление отзыва.
Какие данные и как использует
Данные на входе
- Технические факторы: URL-адреса из истории посещений пользователя (Browsing History) являются основным источником данных. Анализируются статические и динамические части URL.
- Пользовательские факторы: User ID (идентификатор пользователя), Electronic Device ID (идентификатор устройства). Используются для связи истории посещений с автором отзыва.
- Контентные факторы (UGC): Текст и рейтинг самих отзывов, хранящиеся в Recommendation Database.
Какие метрики используются и как они считаются
- URL Embedding: Векторное представление URL. В патенте явно упоминается применение алгоритма Word2Vector к URL для генерации этих векторов.
- Vector Difference/Distance (Разница/Расстояние векторов): Метрика, используемая для сравнения нового эмбеддинга с шаблонными эмбеддингами.
- Embedding Difference Threshold: Пороговое значение для определения сходства на основе векторного расстояния.
- URL Pattern/Mask Matching (Сопоставление шаблонов/масок URL): Структурное сравнение URL с предопределенными шаблонами (с использованием символов вроде #, ?, * для обозначения динамических частей).
- Pattern Difference Threshold: Пороговое значение для определения структурного соответствия (в тексте патента упоминается пример 10% отклонения, т.е. 90% совпадения).
- Genuity Mark (Метка подлинности): Бинарная или многоклассовая метка, применяемая к отзывам (например, Genuine, Fraudulent, Unconfirmed).
Выводы
- Верификация отзывов через историю браузера: Яндекс разрабатывает технические средства для валидации подлинности пользовательских отзывов путем доступа и анализа истории посещений пользователя. Это требует интеграции с пользовательскими приложениями (например, Яндекс.Браузер).
- Фокус на «Доказательстве покупки»: Ключевым элементом верификации является обнаружение посещения Transaction Confirmation Page («Thank you page»). Наличие соответствующего URL в истории служит доказательством совершения транзакции.
- Гибридный подход к анализу URL: Система использует два метода: (1) Embedding Analysis (анализ векторных представлений) для обнаружения новых структур страниц подтверждения, основываясь на сходстве с известными шаблонами (например, от популярных CMS), и (2) Pattern Matching (сопоставление с шаблонами) для быстрой проверки URL по уже известным структурам.
- Самообучаемость системы: Когда система обнаруживает новую страницу подтверждения через анализ эмбеддингов, она добавляет ее эмбеддинг и генерирует новый URL Pattern, пополняя Genuity Database.
- Прямые последствия для фейковых отзывов: Патент предусматривает жесткие меры для отзывов, которые не могут быть верифицированы: пометка как мошеннические или полное удаление из базы данных рекомендаций.
Практика
Best practices (это мы делаем)
- Стимулирование органических отзывов от реальных клиентов: Сосредоточьте усилия на получении отзывов от пользователей, которые действительно совершили покупку. Этот патент подтверждает, что только такие отзывы будут иметь ценность в долгосрочной перспективе.
- Оптимизация процесса покупки (для E-commerce): Убедитесь, что после завершения транзакции пользователь попадает на четкую страницу подтверждения (Transaction Confirmation Page). Желательно, чтобы URL этой страницы имел понятную структуру (например, /order-confirmed/, /thank-you/), что может облегчить ее идентификацию системами вроде описанной.
- Запрос отзыва сразу после транзакции: Интегрируйте запрос на отзыв (например, на платформах Яндекса) в процесс сразу после покупки или вскоре после нее. Это увеличивает вероятность того, что необходимый URL будет присутствовать в недавней истории браузера пользователя.
- Поощрение использования экосистемы Яндекса: Поскольку система требует доступа к истории браузера, пользователи, использующие Яндекс.Браузер или другие интегрированные сервисы Яндекса, с большей вероятностью смогут пройти верификацию.
Worst practices (это делать не надо)
- Покупка фейковых отзывов: Это становится крайне рискованной стратегией. Патент предоставляет Яндексу конкретный механизм для обнаружения и удаления таких отзывов, если авторы не могут доказать (через историю браузера) факт совершения транзакции.
- Использование сложных/нестандартных URL для страниц подтверждения: Если страница подтверждения генерируется с полностью динамическим или обфусцированным URL, который не имеет структурного сходства с типичными страницами подтверждения, система может испытывать трудности с ее распознаванием (хотя анализ эмбеддингов призван решить эту проблему).
- Игнорирование репутации на платформах Яндекса: Нельзя игнорировать качество и подлинность отзывов на Яндекс.Картах или Маркете, так как система активно работает над очисткой от спама.
Стратегическое значение
Патент подчеркивает стратегический приоритет Яндекса на обеспечение достоверности пользовательского контента (UGC). Доверие и подлинность (связанные с E-E-A-T) являются критически важными. Яндекс демонстрирует готовность использовать глубокий анализ пользовательских данных (историю браузера) для валидации сигналов. Для SEO и управления репутацией (ORM) это означает, что искусственные сигналы будут терять эффективность, а значение органического, подтвержденного пользовательского опыта возрастает.
Практические примеры
Сценарий 1: Обнаружение новой страницы подтверждения (Анализ Эмбеддингов)
- Ситуация: Пользователь А покупает товар на сайте «NewBikeShop.ru» (сайт новый, его шаблонов нет в базе Яндекса) и оставляет отзыв на Яндекс.Маркете.
- Действие системы: Яндекс получает доступ к истории браузера пользователя А и анализирует URL: «newbikeshop.ru/cart/success/id12345».
- Анализ: Система генерирует эмбеддинг для этого URL. Она обнаруживает, что этот эмбеддинг очень близок к шаблонным эмбеддингам сайтов на CMS «ShopMaster», которые уже есть в Genuity Database.
- Результат: Разница ниже порога. Пользователь А верифицирован. Отзыв публикуется. Система генерирует шаблон «newbikeshop.ru/cart/success/id#####» и добавляет его в базу.
Сценарий 2: Быстрая верификация (Сопоставление с шаблоном)
- Ситуация: Пользователь Б покупает товар на том же сайте «NewBikeShop.ru» через день и тоже оставляет отзыв.
- Действие системы: Яндекс анализирует URL из его истории: «newbikeshop.ru/cart/success/id12399».
- Анализ: Система использует быстрый путь (Fast Path). Она сравнивает URL с шаблоном, созданным в Сценарии 1 («newbikeshop.ru/cart/success/id#####»).
- Результат: URL соответствует шаблону. Пользователь Б мгновенно верифицирован. Отзыв публикуется.
Сценарий 3: Обнаружение фейкового отзыва
- Ситуация: Пользователь В получает деньги за написание положительного отзыва о «NewBikeShop.ru», но ничего там не покупал.
- Действие системы: Яндекс анализирует историю браузера пользователя В.
- Анализ: Система ищет URL, соответствующие шаблону «newbikeshop.ru/cart/success/id#####» или схожие по эмбеддингам с другими страницами подтверждения. Ничего не найдено.
- Результат: Разница выше порога, соответствия шаблону нет. Пользователь В не верифицирован. Согласно Claim 16, его отзыв помечается как мошеннический или удаляется.
Вопросы и ответы
Насколько вероятно, что Яндекс уже использует этот механизм?
Вероятность высокая. Патент подан в 2019 году (приоритет РФ) и опубликован в 2021. Борьба с накруткой отзывов является постоянной задачей для Яндекса (особенно на Картах и Маркете). Технологии, описанные в патенте (Word2Vec, анализ паттернов), хорошо освоены и широко применяются. Вполне вероятно, что элементы этой системы уже интегрированы в антифрод-системы Яндекса.
Требует ли этот механизм доступ к истории моего браузера?
Да, это ключевое требование патента. Система должна получить URL из истории посещений пользователя для анализа. На практике это, скорее всего, реализуется через собственные приложения Яндекса, такие как Яндекс.Браузер или мобильные приложения с интегрированным браузером, где пользователь предоставил соответствующие разрешения на обработку данных.
Что такое Genuity Database и как она наполняется?
Genuity Database — это база данных, хранящая эталонные образцы страниц подтверждения транзакций. Она содержит эмбеддинги (векторные представления) и структурные шаблоны (URL Patterns) этих страниц. Она наполняется двумя способами: инициализация известными шаблонами (например, от крупных магазинов или популярных CMS) и автоматическое пополнение, когда система обнаруживает новый URL, похожий по эмбеддингу на уже существующие шаблоны.
Как система отличает страницу товара от страницы подтверждения покупки?
Система использует машинное обучение (в частности, упоминается Word2Vec) для создания эмбеддингов URL. Эмбеддинги обучаются таким образом, чтобы векторы структурно схожих URL были близки. Страницы подтверждения (например, /thank-you, /order-success) имеют отличную структуру от страниц товаров (например, /product/model-123). Система сравнивает эмбеддинг URL пользователя только с эталонными эмбеддингами страниц подтверждения.
Что произойдет, если мой сайт использует нестандартную CMS и нестандартные URL?
Система может изначально не распознать вашу страницу подтверждения через быстрое сопоставление с шаблоном (Pattern Matching). Однако она использует анализ эмбеддингов (Embedding Analysis). Если структура вашего URL хоть немного похожа на другие известные страницы подтверждения (даже на других CMS), система может распознать ее, если разница векторов будет ниже порога. После распознавания она создаст новый шаблон для вашего сайта.
Как этот патент влияет на стратегии управления репутацией (ORM/SERM)?
Стратегии, основанные на покупке отзывов или использовании сетей исполнителей, становятся неэффективными и опасными. Система напрямую нацелена на их обнаружение и удаление. Приоритет смещается в сторону мотивации реальных клиентов оставлять органические отзывы и обеспечения бесшовного пользовательского опыта после покупки.
Влияет ли этот патент на ранжирование в основном поиске Яндекса?
Патент напрямую не описывает влияние на ранжирование в веб-поиске. Он фокусируется на фильтрации контента на рекомендательных платформах. Однако достоверные отзывы и высокие рейтинги на платформах Яндекса (Карты, Маркет) часто коррелируют с лучшим ранжированием и могут использоваться как сигналы доверия (Trust signals) в основном поиске. Таким образом, косвенное влияние на SEO есть.
Что такое URL Pattern и Mask в контексте патента?
URL Pattern — это шаблон структуры адреса. Он состоит из статической части (например, «www.site.com/cart/») и динамической части. Mask — это способ описания динамической части с помощью специальных символов. Например, если ID транзакции состоит из 5 цифр, маска будет «#####». Полный шаблон может выглядеть как «www.site.com/cart/order=#####».
Может ли пользователь обмануть эту систему, просто зайдя на страницу подтверждения без покупки?
Теоретически это возможно, если URL страницы подтверждения легко угадать и он не защищен сессией или аутентификацией. Однако большинство современных CMS генерируют уникальные ID транзакций в динамической части URL, которые действительны только для конкретной сессии покупки. Посещение старого или угаданного URL может не привести к отображению полноценной страницы подтверждения.
Какие действия предпринять SEO-специалисту для адаптации к этому алгоритму?
Для E-commerce и локального бизнеса ключевыми действиями являются: переход от стимулирования к органическому получению отзывов; обеспечение наличия четкой Transaction Confirmation Page после покупки; техническая проверка структуры URL этой страницы на читаемость и структурированность. Важно строить долгосрочную стратегию на основе реального клиентского опыта.