Как Google использует "Overlapping Experiments" для одновременного тестирования множества изменений в алгоритмах и интерфейсе

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

Overlapping Experiments (Перекрывающиеся эксперименты)

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

Layer (Слой)

Контейнер для экспериментов. Ключевое свойство: любые два эксперимента в одном слое не могут выполняться на одном и том же запросе (не перекрываются). Эксперименты в разных слоях распределяются независимо и могут перекрываться.

Domain (Домен)

Контейнер, который может включать один или несколько слоев и/или другие вложенные домены. Используется для организации структуры экспериментов.

Overlapping Domain (Перекрывающийся домен)

Домен, содержащий несколько слоев, в которых эксперименты могут перекрываться.

Non-overlapping Domain (Неперекрывающийся домен)

Домен, содержащий один слой с неперекрывающимися экспериментами (аналог традиционного A/B-тестирования).

Launch Domain/Layer (Стартовый домен/слой)

Специальный тип слоя, используемый для постепенного запуска новых функций (ramp-up). Эксперименты в этих слоях устанавливают альтернативные значения по умолчанию (alternative default values) для параметров, которые могут перекрываться с экспериментами в других доменах.

Diversion Library (Библиотека распределения)

Программный компонент, связанный с бинарными файлами приложений (например, веб-сервером, сервером поиска), который реализует логику направления запросов в эксперименты на основе конфигурационных файлов.

Diversion Point (Точка распределения)

Конкретное место в цепочке обработки запроса (например, в начале обработки на веб-сервере или в конце обработки на сервере рекламы), где система принимает решение о направлении запроса в эксперимент.

Diversion Rules/Types (Правила/Типы распределения)

Методы определения того, какие запросы направляются в эксперимент. Включают User ID, Cookie ID (для обеспечения согласованного пользовательского опыта), Cookie-day ID и Random Traffic (случайный трафик).

Experiment Flags / Parameters (Флаги / Параметры эксперимента)

Конкретные параметры системы (например, порог продвижения рекламы, цвет фона, вес сигнала ранжирования), значения которых изменяются в рамках эксперимента.

Eligibility Conditions / Filter Hooks (Условия приемлемости / Фильтры)

Дополнительные условия для ограничения трафика, направляемого в эксперимент (например, только запросы на определенном языке, из определенной страны или с определенного сетевого домена).

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

Claim 1 (Независимый пункт): Описывает основной метод проведения перекрывающихся экспериментов.

1. Система получает множество пользовательских запросов.
2. Выполняются перекрывающиеся эксперименты на части этих запросов.
3. Каждый эксперимент изменяет ноль или более параметров, связанных с запросами или их обработкой.
4. Эксперименты организованы в несколько слоев (plurality of layers).
5. Правило перекрытия: Два или более эксперимента в разных слоях могут быть выполнены на одном и том же запросе.
6. Правило исключительности: Для любого данного слоя на одном и том же запросе может быть выполнен не более одного эксперимента.

Claim 2 (Зависимый от 1): Детализирует механизм распределения.

Запросы направляются в различные эксперименты на разных слоях. Некоторые запросы направляются в два или более эксперимента в разных слоях. Распределение запросов в каждом слое происходит независимо (independent) от распределения запросов в других слоях.

Claim 4 (Зависимый от 1): Описывает организацию параметров (флагов).

Параметры разделены на различные наборы так, что разные наборы параметров независимы друг от друга. Каждый набор параметров связан с определенным слоем, и разные наборы связаны с разными слоями. Это ключевой момент для понимания, как система определяет, какие эксперименты могут перекрываться: если они изменяют параметры из разных, независимых наборов.

Claim 8 (Зависимый от 1): Описывает методы распределения трафика.

Часть запросов направляется в эксперименты на основе одного или нескольких методов: случайный или псевдослучайный трафик (random or pseudo-random traffic), идентификаторы пользователей (user identifiers), идентификаторы cookie (cookie identifiers) или комбинация идентификаторов cookie и дат.

Claim 9 (Зависимый от 8): Устанавливает порядок схем распределения.

Существует упорядоченность (ordering) схем распределения. Например, при направлении запросов в эксперименты внутри данного слоя, распределение на основе идентификаторов пользователей выполняется перед распределением на основе идентификаторов cookie, которое выполняется перед распределением на основе случайных значений.

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

Это инфраструктурный фреймворк, который применяется повсеместно в системе обработки запросов Google (включая поиск, рекламу, карты, новости и т.д.) везде, где проводятся эксперименты.

QUNDERSTANDING – Понимание Запросов
Применяется для тестирования новых моделей интерпретации запросов или изменений в классификации интентов.

RANKING – Ранжирование
Применяется для тестирования новых алгоритмов ранжирования, корректировки весов сигналов или внедрения новых факторов.

METASEARCH – Метапоиск и Смешивание
Применяется для тестирования изменений в пользовательском интерфейсе (UI), алгоритмах смешивания результатов из разных вертикалей или презентации SERP-фич.

RERANKING – Переранжирование
Применяется для тестирования корректировок финальной выдачи (например, разнообразия или свежести).

Взаимодействие с компонентами: Система взаимодействует с веб-серверами, серверами поисковых результатов и серверами рекламных результатов. Это достигается за счет интеграции Diversion Libraries в бинарные файлы этих приложений. Библиотеки активируются в определенных Diversion Points в процессе обработки запроса.

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

• Пользовательский запрос и его метаданные (Cookie ID, User ID, язык, страна).
• Конфигурационные файлы, определяющие структуру слоев/доменов, активные эксперименты, Diversion Rules и Eligibility Conditions.

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

• Набор активных экспериментов для данного запроса.
• Измененные значения параметров (Experiment Flags), которые используются при дальнейшей обработке запроса (например, измененные оценки ранжирования, другой шаблон UI).

На что влияет

Патент описывает универсальный фреймворк тестирования. Он не ограничен конкретными типами контента или запросов. В патенте явно упоминается его применение к широкому спектру сервисов:

• Контент и Ниши: Поиск, Реклама (Ads), Карты (Maps), Новости (News), Финансы (Finance), Поиск продуктов (Product Search), Мобильные сервисы (Mobile devices).
• Типы страниц: Персонализированные и неперсонализированные домашние страницы.
• Параметры: Влияет на тестирование параметров, связанных с пользовательским интерфейсом (UI), ранжированием контента, рекламой и сопоставлением ключевых слов.

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

• Условия работы: Алгоритм применяется непрерывно, так как Google постоянно проводит эксперименты.
• Триггеры активации: Механизм активируется, когда запрос достигает Diversion Point в коде приложения.
• Активация конкретного эксперимента: Происходит, если запрос удовлетворяет Diversion Rules (например, попадает в 1% случайного трафика) И Eligibility Conditions (например, запрос на немецком языке).

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

Процесс обработки запроса и его распределения в эксперименты.

1. Получение запроса: Система получает пользовательский запрос.
2. Доступ к конфигурации: Система обращается к файлам данных, которые определяют текущую организацию экспериментов в слои и домены, а также правила распределения.
3. Определение домена: Для каждого запроса определяется, к какому домену он принадлежит (например, часть трафика может быть направлена в Non-overlapping Domain, а часть в Overlapping Domain).
4. Итерация по слоям: Система начинает итерацию по каждому слою внутри определенного домена.
5. Обработка вложенности: Если слой содержит вложенные домены, процесс рекурсивно повторяется для вложенных слоев внутри этих доменов.
6. Применение правил распределения (Diversion Rules): Для текущего слоя система применяет правила для выбора не более одного эксперимента. Это включает упорядоченный процесс (согласно Claim 9):
   1. Проверка экспериментов на основе User ID.
   2. Если не выбрано, проверка на основе Cookie ID.
   3. Если не выбрано, проверка на основе Cookie-day ID (если используется).
   4. Если не выбрано, проверка на основе Random Traffic.
7. Применение условий приемлемости (Eligibility Conditions): Проверяется, соответствует ли запрос дополнительным фильтрам выбранного эксперимента (например, язык, страна).
8. Распределение и модификация: Если эксперимент выбран и запрос приемлем, запрос направляется в этот эксперимент. Соответствующие параметры (Experiment Flags) модифицируются для этого запроса.
9. Переход к следующему слою: Система переходит к следующему слою в домене. Процесс распределения в новом слое происходит независимо от решений, принятых в предыдущих слоях.
10. Завершение обработки: После обработки всех слоев запрос выполняется с использованием финального набора модифицированных параметров.

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

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

Система использует следующие данные для принятия решений о распределении трафика:

• Пользовательские факторы:
  • User identifiers (Идентификаторы пользователей): используются для обеспечения согласованности опыта пользователя на разных устройствах.
  • Cookie identifiers (Идентификаторы cookie): используются для обеспечения согласованности в рамках одного браузера, особенно для UI-экспериментов.
  • Cookie-day identifiers (Комбинация Cookie ID и даты).
• Географические и языковые факторы:
  • Язык запроса.
  • Страна пользователя.
  • Сетевой домен (например, google.com или google.de).
• Технические факторы:
  • Информация о том, какой сервер или дата-центр обрабатывает запрос.
  • Тип браузера (упоминается как пример для фильтрации).
• Контентные факторы (Свойства запроса):
  • Сам текст запроса (может использоваться для query hash распределения).
  • Наличие определенных результатов или рекламы (используется на более поздних Diversion Points).

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

Патент описывает инфраструктуру для проведения экспериментов и детально перечисляет метрики, используемые для оценки результатов этих экспериментов (KPI). Система вычисляет эти метрики для сравнения контрольных и экспериментальных групп.

• Метрики дохода и монетизации:
  • Revenue per thousand queries (Доход на тысячу запросов).
  • Cost Per Click (Средний доход за клик): общий доход от кликов по рекламе, деленный на количество кликов.
• Метрики вовлеченности (Engagement) и кликов (CTR):
  • Click through rate (CTR) для рекламы (отдельно для верхнего и бокового блока).
  • Search CTR by position (CTR поисковых результатов по позициям).
  • Average click position (Средняя позиция клика).
  • Time to first click (Время до первого клика).
  • Количество запросов с хотя бы одним кликом (по поиску или рекламе), деленное на общее количество запросов.
• Метрики качества выдачи и рекламы:
  • Ad Coverage (Покрытие рекламой): доля запросов, для которых была показана хотя бы одна реклама.
  • Ad Depth (Глубина рекламы): среднее количество показов рекламы на запрос.
• Метрики поведения пользователей и отказов (Abandonment):
  • Queries per cookie (Количество запросов на cookie).
  • Visits per cookie (Количество визитов на cookie).
  • Abandonment rates (Показатели отказов): доля заброшенных запросов или визитов (запрос без последующих кликов или уточнений).
  • Next page queries (Запросы следующей страницы), деленные на общее количество запросов.

1. Масштаб и скорость тестирования: Инфраструктура Google спроектирована для обеспечения максимальной скорости и параллелизма тестирования. Overlapping Experiments позволяют проводить значительно больше тестов на том же объеме трафика по сравнению с традиционными A/B-тестами.
2. Независимость через слои: Система Layers позволяет разным командам (например, команде ранжирования и команде UI) тестировать изменения одновременно, не координируя свои планы, при условии, что их изменения затрагивают независимые наборы параметров (Experiment Flags).
3. Сложность реальной выдачи: Один пользовательский запрос часто подвергается нескольким экспериментам одновременно. Это означает, что SERP, которую видит пользователь, является результатом сложной комбинации базовых настроек и множества экспериментальных конфигураций.
4. Обнаружение взаимодействий: Система явно разработана не только для ускорения тестирования, но и для обнаружения взаимодействий (interactions) между, казалось бы, независимыми изменениями. Если два эксперимента в разных слоях взаимодействуют, Google может это измерить.
5. Постепенный запуск (Ramp-up): Launch Layers используются для постепенного развертывания новых функций (например, от 1% до 100% трафика). Они действуют как временные настройки по умолчанию, позволяя проводить нагрузочное тестирование и плавный переход.
6. Консистентность пользователя: Использование Cookie ID и User ID для распределения трафика (особенно для UI-экспериментов) гарантирует, что пользователь видит согласованный интерфейс во время теста, что важно для достоверности результатов.

ВАЖНО: Этот патент является инфраструктурным и описывает внутренние процессы тестирования Google. Он не дает прямых рекомендаций по оптимизации сайтов, но критически важен для понимания среды, в которой работают SEO-специалисты.

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

• Фокус на фундаментальных факторах и KPI: Поскольку поисковая среда постоянно флуктуирует из-за тысяч перекрывающихся экспериментов, оптимизация под алгоритмические лазейки неэффективна. Стратегия должна базироваться на улучшении тех метрик, которые Google использует для валидации своих тестов (перечислены в разделе 4.2): CTR, вовлеченность, низкие показатели отказов (Abandonment rates).
• Использование собственных A/B-тестов: Патент подтверждает эффективность методологии контролируемых экспериментов. SEO-командам следует активнее внедрять собственные системы тестирования (например, SEO split-testing) для проверки гипотез на своих сайтах, используя data-driven подход, аналогичный Google.
• Мониторинг долгосрочных трендов, а не колебаний: Учитывая экспериментальный характер выдачи, следует фокусироваться на долгосрочных трендах и ключевых бизнес-метриках, а не на ежедневных колебаниях позиций, которые могут быть результатом тестирования.

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

• Чрезмерная реакция на краткосрочную волатильность: Не следует вносить поспешные изменения на сайте в ответ на внезапные колебания позиций. Высокая волатильность часто является побочным продуктом системы Overlapping Experiments, а не обязательно следствием пессимизации конкретного сайта. Изменения могут быть временными.
• Попытки "Угадать алгоритм" по малым данным: Анализ небольшого набора SERP для "реверс-инжиниринга" обновлений алгоритмов ненадежен. Наблюдаемые изменения могут быть связаны со сложными взаимодействиями в экспериментальной среде, а не с глобальным изменением весов факторов.

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

Патент подчеркивает, что Google Поиск — это не статичная система, а динамичная среда, подвергающаяся постоянному многослойному экспериментированию. Это объясняет, почему изолировать влияние одного обновления алгоритма практически невозможно для внешних наблюдателей. Стратегическое значение для SEO заключается в принятии этой сложности и волатильности как нормы и построении стратегий, устойчивых к постоянным изменениям и сфокусированных на реальном пользовательском опыте.

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

Сценарий: Анализ необъяснимой волатильности SERP

1. Ситуация: SEO-специалист замечает резкое падение позиций по ключевому кластеру запросов в течение 2 дней, при этом инструменты мониторинга (e.g., Sensor) показывают высокую волатильность в нише.
2. Анализ с учетом патента: Вместо паники по поводу пессимизации, специалист предполагает, что это может быть результатом тестирования Google. Возможно, запущен новый эксперимент ранжирования (Слой 1), который, возможно, взаимодействует с новым шаблоном UI (Слой 2), что приводит к временному изменению выдачи.
3. Действия: Не вносить изменения на сайте. Продолжить мониторинг ситуации, анализировать метрики вовлеченности (CTR, отказы) в Google Search Console и системах аналитики.
4. Ожидаемый результат: В течение нескольких дней или недель система тестирования Google соберет данные, эксперимент завершится (или будет скорректирован), и волатильность снизится. Это позволяет избежать ненужных и потенциально вредных изменений на сайте.