Как Google учитывает объем трафика для загрузки страницы при ранжировании, особенно для пользователей с лимитированным интернетом

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

Data Measure (Показатель объема данных)

Метрика, связанная с документом, которая указывает на объем данных (трафика), необходимый для его загрузки и отрисовки. Может быть фактическим измеренным значением (в байтах, кБ, МБ) или нормализованной оценкой.

Document Data Usage Module (Модуль оценки объема данных документа)

Компонент системы индексирования, отвечающий за доступ к документу, измерение объема трафика при его загрузке и сохранение Data Measure.

Document Similarity Module (Модуль схожести документов)

Компонент системы ранжирования, который определяет, содержат ли два или более документа похожий контент (similar content).

Limited Data Plan (Лимитированный тарифный план)

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

Navigational Query (Навигационный запрос)

Запрос, указывающий на намерение найти конкретный веб-сайт или страницу (например, "facebook"). Для таких запросов алгоритм может отключаться.

Non-navigational Query (Не навигационный запрос)

Запрос (информационный или транзакционный), не имеющий целью конкретный сайт. Для таких запросов алгоритм применяется с большим весом.

Query Analysis Module (Модуль анализа запросов)

Компонент, определяющий характеристики запроса и контекст пользователя, в частности, является ли запрос навигационным и используется ли Limited Data Plan.

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

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

1. Система получает поисковый запрос.
2. Определяется, что запрос, вероятно, отправлен через limited data plan.
3. Идентифицируются релевантные документы.
4. Определяется first data measure для первого документа (на основе данных, полученных при предыдущем извлечении документа).
5. Первый документ ранжируется относительно других документов на основе (i) first data measure И (ii) факта определения limited data plan.

Ядро изобретения заключается в условном применении фактора объема данных: ранжирование корректируется только тогда (или сильнее), когда система считает, что пользователь ограничен в потреблении трафика.

Claim 2, 3, 4 (Зависимые): Детализируют сценарий с похожими документами.

1. Определяется, что второй документ похож на первый.
2. Определяется second data measure для второго документа.
3. Ранжирование первого документа относительно второго основывается на сравнении их data measures (Claim 3).
4. Если data measure первого документа указывает на меньшее потребление данных, чем у второго, первый документ ранжируется выше (Claim 4).

Если контент схож, система предпочитает более "легкую" версию.

Claim 5 (Зависимый): Добавляет дополнительное условие.

Ранжирование на основе data measure происходит, только если запрос определен как non-navigational.

Claim 6, 7, 8 (Зависимые): Описывают механизм корректировки оценки.

1. Определяется начальный рейтинг (initial ranking) документа, не зависящий от data measure (Claim 6).
2. Начальный рейтинг модифицируется на основе data measure.
3. Если data measure пропорционален объему данных, модификация может происходить путем умножения начальной оценки релевантности (initial relevance score) на величину, обратную data measure (1 / Data Measure) (Claim 8).

Это математически означает, что чем больше объем данных, тем ниже итоговая оценка.

Claim 13 (Зависимый): Уточняет механизм взвешивания.

Вес (weighting) фактора data measure в ранжировании зависит от степени вероятности (likelihood) того, что запрос отправлен через limited data plan.

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

Изобретение затрагивает несколько этапов поиска, связывая данные индексирования с контекстом запроса для корректировки ранжирования.

INDEXING – Индексирование и извлечение признаков
На этом этапе работает Document Data Usage Module. Он загружает документ и все необходимые для его отрисовки ресурсы (изображения, JS, CSS) и измеряет общий объем потребленных данных. Полученный Data Measure сохраняется в индексе вместе с идентификатором документа.

QUNDERSTANDING – Понимание Запросов
На этом этапе работает Query Analysis Module. Он анализирует запрос и контекст пользователя в реальном времени, чтобы определить:

• Является ли запрос навигационным или нет.
• Какова вероятность того, что пользователь использует Limited Data Plan (на основе IP, типа сети и т.д.).

RANKING / RERANKING – Ранжирование и Переранжирование
Основное применение патента. Ranking Engine использует результаты этапа QUNDERSTANDING как триггеры.

1. Применение сигнала: Если обнаружен Limited Data Plan и/или запрос Non-navigational, Data Measure используется как сигнал ранжирования (например, для модификации initial relevance score).
2. Обработка схожести: Document Similarity Module может идентифицировать документы с похожим контентом. В этом случае их взаимное ранжирование определяется сравнением их Data Measures.

Входные данные:

• Запрос пользователя и контекстные данные (сеть, устройство).
• Набор релевантных документов из индекса.
• Предварительно рассчитанные Data Measures для этих документов.
• Начальные оценки релевантности (Initial relevance scores).

Выходные данные:

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

На что влияет

• Конкретные типы контента: Сильнее всего влияет на страницы с большим количеством неоптимизированных медиафайлов (изображения, видео), избыточным кодом JavaScript и многочисленными сторонними скриптами (реклама, аналитика).
• Определенные форматы контента: Дает преимущество оптимизированным форматам (например, легким мобильным версиям) перед тяжелыми десктопными версиями при поиске с мобильных устройств.
• Географические факторы: Имеет критическое значение в регионах, где распространены медленные мобильные сети (например, 2G/3G) или дорогие тарифные планы с оплатой за трафик.

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

Алгоритм применяется выборочно, при выполнении определенных условий:

• Триггер активации 1 (Основной): Система определяет высокую вероятность того, что запрос отправлен пользователем, использующим limited data plan.
• Триггер активации 2 (Уточняющий): Запрос классифицирован как non-navigational. Для навигационных запросов фактор может игнорироваться, так как пользователь хочет попасть на конкретный сайт независимо от его размера.
• Условие сравнения: Когда в выдаче присутствуют два или более документа, идентифицированных как имеющие similar content.

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

Процесс А: Измерение объема данных (Этап Индексирования)

1. Идентификация документа: Система обнаруживает документ для индексации.
2. Доступ и загрузка: Document Data Usage Module загружает документ, эмулируя поведение браузера (загрузка HTML и всех связанных ресурсов для отрисовки).
3. Измерение: Определяется общий объем данных (трафика), использованный для загрузки. Это может быть среднее значение по нескольким загрузкам, если контент динамический (например, реклама).
4. Сохранение: Идентификатор документа ассоциируется с рассчитанным Data Measure в индексе.

Процесс Б: Ранжирование (Real-time)

1. Получение запроса.
2. Анализ контекста (QUNDERSTANDING): Query Analysis Module определяет вероятность использования Limited Data Plan и классифицирует запрос (Navigational/Non-navigational).
3. Определение веса фактора: На основе анализа контекста определяется вес (weighting) для Data Measure. Если вероятность Limited Data Plan низкая, вес может быть нулевым или минимальным.
4. Идентификация и начальное ранжирование: Система находит релевантные документы и рассчитывает initial relevance scores.
5. Анализ схожести (Опционально): Document Similarity Module проверяет наличие документов с похожим контентом среди кандидатов.
6. Корректировка ранжирования:
   • Сценарий 1 (Общий): Если вес фактора > 0, initial relevance scores модифицируются с учетом Data Measure (например, делением на Data Measure).
   • Сценарий 2 (Схожий контент): Если найдены похожие документы, их взаимное ранжирование корректируется так, чтобы документ с меньшим Data Measure получил более высокую позицию.
7. Предоставление результатов: Формируется финальная выдача.

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

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

• Технические факторы: Общий объем байтов, загруженных при доступе к документу. Это включает размер HTML-кода, CSS, JavaScript, изображений, шрифтов, видео и других ресурсов, необходимых для отрисовки страницы.
• Пользовательские факторы: Данные об устройстве и подключении пользователя (например, IP-адрес, User-Agent, информация о сети, MAC-адрес, cookies), которые используются для определения вероятности использования Limited Data Plan.
• Поведенческие факторы (косвенно): История кликов (selection rate) по запросу может использоваться для определения, является ли запрос Navigational (например, если один результат получает подавляющее большинство кликов).
• Контентные факторы: Текст, метаданные, ключевые слова, сущности (entities) используются для определения схожести контента между документами.

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

• Data Measure: Измеряется путем фактической загрузки документа и подсчета использованного трафика на этапе индексирования.
• Likelihood of Limited Data Plan: Вероятностная оценка, основанная на контексте пользователя.
• Формулы и алгоритмы расчета: Патент предлагает несколько вариантов корректировки рейтинга:
  • Умножение начальной оценки на обратную величину Data Measure (Claim 8):