Утечка Google 2024: что документы говорят о кликах и NavBoost

Что именно утекло и когда

5 мая 2024 года Рэнд Фишкин, сооснователь SparkToro, получил письмо: автор утверждал, что у него есть внутренняя документация поискового подразделения Google. 24 мая на видеозвонке источник показал документы: больше 2 500 страниц описания API с 14 014 атрибутами. Позже он назвал себя: Эрфан Азими, основатель EA Eagle Digital.

Фишкин подключил Майка Кинга из iPullRank. Кинг насчитал в документации 2 596 модулей. Оба разбора вышли в ночь на 28 мая по UTC, в США ещё было 27-е.

Это не взлом. Документация внутреннего Content Warehouse API по ошибке попала в публичный репозиторий клиентской библиотеки на GitHub. По истории коммитов, на которую ссылаются Фишкин и Кинг, код появился там 27 марта 2024 года и был убран 7 мая. The Register называет другую дату публикации — около 13 марта; дата удаления совпадает.

29 мая Google подтвердил изданию The Verge, что документы подлинные.

NavBoost: главное прозвучало в суде

18 октября 2023 года на антимонопольном процессе «США против Google» показания давал вице-президент Google по поиску Панду Наяк. Вот что сказано о NavBoost в открытой стенограмме:

• Это одна из базовых систем поиска. По словам Наяка, она появилась примерно в 2005 году, возможно, и раньше.
• Система запоминает клики по прошлым запросам и обучается на пользовательских данных. Окно — все запросы за последние 13 месяцев. До 2017 года было 18.
• Данные «нарезаются» по локали и отдельно по мобильным и десктопу. Для каждой категории — свой набор данных.
• Glue, по словам Наяка, — «просто другое название NavBoost» для остальных элементов выдачи, кроме веб-результатов.

Судья попросил оценить место NavBoost среди сигналов. Наяк ответил, что преуменьшать его не хочет, но важных сигналов много. Итог: «один из важных сигналов». В другом месте допроса он назвал NavBoost фактором, но «ни в коем случае не единственным». Всего сигналов, по его словам, возможно, больше сотни, а для отбора документов важнее всего сам документ и слова на странице. И напомнил: у многих документов кликов может не быть вовсе.

В решении судьи Амита Мехты от 5 августа 2024 года NavBoost описан как сигнал, который связывает запросы и документы, запоминая клики. Там же оценка масштаба: 13 месяцев пользовательских данных Google эквивалентны более чем 17 годам данных Bing.

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

Какие клик-сигналы названы в документах

Утечка добавила к показаниям названия полей. По подсчёту Кинга, слово Navboost встречается в документации 84 раза, у пяти модулей оно стоит в названии.

В модуле, который описан как «сигналы кликов и показов для Craps», перечислены:

• goodClicks и badClicks — «хорошие» и «плохие» клики, без описаний;
• lastLongestClicks — по описанию в соседнем модуле CrapsData, число кликов, которые были последними и самыми долгими в связанных запросах;
• impressions — показы;
• unsquashedClicks, unsquashedLastLongestClicks, unsquashedImpressions — те же величины без «сжатия»;
• unicornClicks — подмножество кликов, связанных с событиями от «Unicorn-пользователей». Кто это, не объяснено.

Что такое «сжатие», в этом модуле тоже не объяснено. Кинг ссылается на патент Google, где squashing — функция, которая не даёт одному большому сигналу доминировать над остальными. Его вывод: клики нормализуются, чтобы сигналом нельзя было бесконтрольно манипулировать. Это интерпретация, а не строка из документов.

В модуле, связанном с индексированием, есть поле lastGoodClickDateInDays — дата последнего хорошего клика по документу. В CrapsData счётчики делятся на срезы по стране, языку и устройству — это совпадает с «нарезкой» из показаний Наяка. Атрибута с названием dwell time Кинг в документации не нашёл: по его оценке, долгие клики измеряют по сути то же.

Данные Chrome

В модуле, связанном с оценкой качества страниц, есть атрибут chromeInTotal с описанием «просмотры в Chrome на уровне сайта». В документе о быстрых ссылках есть поле topUrl — список URL с наивысшим значением chrome_trans_clicks. Фишкин читает это так: Google, вероятно, по кликам в Chrome определяет самые популярные страницы сайта для быстрых ссылок.

Более сильные утверждения принадлежат источнику, а не документам. С его слов, потребность в полном кликстриме была главным мотивом создания Chrome, а история cookie и данные залогиненных пользователей Chrome применяются против кликового спама. Фишкин подаёт это как заявления источника, не как факт.

Что Google говорил раньше и что ответил

Кинг собрал старые публичные заявления. По его подборке, Гэри Иллиш говорил, что использовать клики напрямую в ранжировании было бы ошибкой, а в другой раз назвал dwell time и CTR выдумкой. Про Chrome он приводит слова Мэтта Каттса и Джона Мюллера: данные браузера в органическом поиске не используются.

При этом в официальном описании работы поиска Google пишет, что использует агрегированные и анонимизированные данные о взаимодействиях, чтобы оценивать релевантность результатов. Поведенческие данные как класс Google не отрицал. Спор шёл о формулировках: «напрямую», «CTR», «dwell time».

На утечку Google ответил коротко. Представитель компании Дэвис Томпсон в письме The Verge предостерёг от неточных предположений о поиске на основе вырванной из контекста, устаревшей или неполной информации.

Чего из утечки вывести нельзя

Это документация, а не код. Кинг сравнивает с утечкой Яндекса: там был код без объяснения логики, здесь — часть логики за тысячами атрибутов, но без кода.

Ограничения признают оба автора:

• Весов нет. Неизвестно, как атрибуты взвешиваются в функциях скоринга.
• Неизвестно, всё ли описанное используется. Часть атрибутов помечена как устаревшие. В описании unsquashedClicks сказано, что в текущем формате поле не заполняется.
• The Verge добавляет: сведения могут быть устаревшими, применяться только для обучения или собираться, но не использоваться в поиске.

Документы показывают, что в системах Google есть отдельные поля для хороших, плохих и самых долгих кликов. Они не говорят, сколько эти клики весят, и не доказывают, что рост числа кликов сам по себе поднимает позиции.

Параллель с Яндексом — предостережение. В январе 2023 года в сеть попал его код. В первом файле нашли 1 922 фактора, больше 64% из них помечены как неиспользуемые или устаревшие. Из 102 факторов с тегом dwell time действующими остались 39. Яндекс заявил, что архив соответствует устаревшей версии репозитория и содержит в том числе тестовые алгоритмы. Поле в документации или коде — ещё не участие в формуле.

Что делать специалисту

Спорить, учитывает ли Google клики, больше незачем: это подтверждено под присягой и записано в решении суда. Полезнее пересмотреть свои отчёты.

• Оценивайте клик как исход поиска, а не как CTR. Фишкин видит в полях про хорошие и плохие клики измерение длины клика: быстрый возврат в выдачу значит, что ответ не найден. Проверяйте, закрывает ли страница запрос целиком.
• Сегментируйте по устройствам и регионам. По показаниям Наяка, NavBoost держит отдельные наборы данных для мобильных, десктопа и локалей. Средние цифры по сайту это скрывают.
• Следите за старыми страницами. Дата последнего хорошего клика хранится на уровне документа. Кинг связывает это с устареванием контента. Это гипотеза, а не описание алгоритма.
• Работайте на узнаваемость бренда. Универсальный совет Фишкина — строить заметный, узнаваемый бренд в своей нише вне поиска Google. Весов в документах нет, это его интерпретация.
• Не читайте утечку как довод за накрутку. Фишкин отмечает: у Google, по всей видимости, есть способы не засчитывать клики, которые он считать не хочет. Автоматические запросы к поиску Google прямо относит к спаму, а нарушителей правил может понизить или убрать из выдачи. Яндекс выделяет имитацию действий пользователей в отдельный вид нарушения и может ограничить такой сайт в ранжировании.

Источники

1. SparkToro, Rand Fishkin: An Anonymous Source Shared Thousands of Leaked Google Search API Documents with Me
2. iPullRank, Mike King: Secrets from the Google Algorithm Leak
3. The Verge, Mia Sato: Google confirms the leaked Search documents are real
4. The Register: Google's technical info about search ranking leaks online
5. US v. Google, стенограмма заседания 18 октября 2023 года (день 24, дневная сессия, показания Панду Наяка)
6. US v. Google, Memorandum Opinion судьи Амита Мехты от 5 августа 2024 года
7. Content Warehouse API (HexDocs): QualityNavboostCrapsCrapsClickSignals
8. Content Warehouse API (HexDocs): QualityNavboostCrapsCrapsData
9. Content Warehouse API (HexDocs): IndexingSignalAggregatorAgeWeightedCoverageData
10. Content Warehouse API (HexDocs): QualityNsrNsrData
11. Content Warehouse API (HexDocs): QualitySitemapTargetGroup
12. Google Patents: US8046371B2 — Scoring local search results based on location prominence
13. Search Engine Roundtable: Matt Cutts о данных Chrome в органическом поиске (27 августа 2012)
14. Google: How Search Works — Ranking results
15. Google Search Central: Spam policies for Google web search
16. Search Engine Journal, Dan Taylor: Yandex Data Leak — The Ranking Factors & The Myths We Found
17. Яндекс: Публикация кода — первые результаты расследования (30 января 2023)
18. Справка Яндекс Вебмастера: Безопасность сайта и нарушения