Классификация тем

Узнайте, как определяются темы, как они назначаются браузерам пользователей и как пользователи могут управлять своим списком тем.

Статус реализации

  • API Topics прошел стадию публичного обсуждения и в настоящее время доступен 99 процентам пользователей с возможностью масштабирования до 100 процентов.
  • Чтобы оставить свой отзыв об API тем, создайте проблему в объяснителе тем или примите участие в обсуждениях в бизнес-группе улучшения веб-рекламы . У объяснителя остается ряд открытых вопросов, которые еще требуют дальнейшего уточнения.
  • В графике Privacy Sandbox указаны сроки реализации Topics API и других предложений Privacy Sandbox.
  • API Topics: в последних обновлениях подробно описаны изменения и улучшения API Topics и их реализации.

Что такое тема?

Тема в API тем — это тема, которая интересует пользователя, о чем свидетельствуют веб-сайты, которые он посещает.

Темы — это сигнал, помогающий платформам рекламных технологий выбирать релевантные объявления. В отличие от сторонних файлов cookie, эта информация передается без раскрытия дополнительной информации о самом пользователе или его активности в Интернете.

API Topics позволяет третьим сторонам, таким как платформы рекламных технологий, наблюдать и затем получать доступ к темам, интересующим пользователя. Например, API может предложить тему «Волокно и текстильное искусство» пользователю, который посещает веб-сайт knitting.example .

Список тем, используемый API тем, является общедоступным, курируемым человеком, удобочитаемым и предназначен для исключения деликатных категорий. Это текущий список , который со временем будет расширяться. Список структурирован в виде таксономии . Темы могут быть общими или более конкретными. Например, Food & Drink — это широкая категория с подкатегорией « Cooking & Recipes . Подкатегории могут быть дополнительно разделены на дополнительные подкатегории.

Такая таксономия тем должна обеспечивать компромисс между полезностью и конфиденциальностью. Если темы слишком специфичны, их можно использовать для идентификации отдельного пользователя. Если они слишком общие, они бесполезны для выбора рекламы или другого контента.

Таксономия тем построена с учетом двух основных требований:

  • Поддержка рекламы на основе интересов
  • Обеспечьте безопасность пользователей и защитите их конфиденциальность

Это вызывает несколько вопросов. Например:

  • Какой лучший способ для API определить темы, интересующие пользователя, на основе его активности в Интернете, сохраняя при этом конфиденциальность пользователя?
  • Как можно структурировать таксономию, чтобы сделать ее более полезной?
  • Какие конкретные элементы должна включать таксономия?

Как API определяет темы для сайта

Темы создаются на основе модели классификатора , которая сопоставляет имена хостов веб-сайтов с нулевым или более темами. Анализ дополнительной информации (например, полных URL-адресов или содержимого страниц) может обеспечить более релевантную рекламу, но также может снизить конфиденциальность.

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

Только сайты, содержащие код, вызывающий API тем, включаются в историю просмотров, подлежащую расчету частоты тем, а вызывающие API получают только темы, которые они наблюдали. Другими словами, сайты не могут рассчитывать частоту тем, если сайт или встроенная служба не вызывает API.

Кроме того, вызывающий абонент может получать только те темы, которые «просмотрел» его код. Таким образом, если код другого вызывающего абонента зарегистрировал тему, скажем /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks , для браузера пользователя, и ваш код не вызвал регистрацию этой темы для браузера этого пользователя, вы не сможете узнайте об этой теме, интересующей браузер этого пользователя, когда вы вызываете API из встроенного кода. Обратите внимание: поскольку API теперь включает наблюдаемых предков, в приведенном выше примере /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks также будет наблюдаться Autos & Vehicles и Motor Vehicles .

Темы, возвращаемые пользователю, пересчитываются для вызывающего абонента в зависимости от сайта верхнего уровня. Например, если adtech.example запрашивает темы пользователя на news-a.example , затем на news-b.example , а затем на news-c.example , то возвращаемые им темы будут пересчитываться на каждом сайте. Это означает, что вызывающий абонент, скорее всего, получит разные темы для пользователя на разных сайтах верхнего уровня, поскольку (максимум) три темы, возвращаемые пользователю, выбираются случайным образом из пяти лучших за последние три эпохи (с вероятностью 5%). получения случайной темы). Из-за этого вызывающему абоненту сложнее идентифицировать пользователя по его темам, поскольку они могут быть разными на разных сайтах верхнего уровня (даже для одного и того же пользователя, вызывающего абонента и эпохи).

Модель классификатора

Темы вручную курируются для 50 000 ведущих доменов, и это курирование используется для обучения классификатора. Этот список можно найти в override_list.pb.gz , который доступен по адресу chrome://topics-internals/ в разделе текущей модели на вкладке Классификатор . Ассоциации домен-темы в списке используются API вместо выходных данных самой модели.

Страница chrome://topics-internals с выбранной панелью «Классификатор».
На панели классификатора страницы chrome://topics-internals указана версия модели, ее путь и темы, связанные с каждым перечисленным хостом.

Чтобы запустить модель напрямую, обратитесь к руководству TensorFlow по запуску модели .

Чтобы проверить файл override_list.pb.gz , сначала распакуйте его:

gunzip -c override_list.pb.gz > override_list.pb

Используйте protoc , чтобы проверить его как текст:

protoc --decode_raw < override_list.pb > output.txt

Полная систематика тем с идентификаторами доступна на GitHub.

Предоставление отзывов или предложений по модели классификатора

Существует несколько каналов для отправки отзывов об API тем. Чтобы получить отзыв о модели классификатора, мы рекомендуем отправить вопрос на GitHub или ответить на существующий вопрос. Например:

Как выбираются пять самых популярных тем пользователя

API возвращает одну тему для каждой эпохи (максимум три). Если возвращаются три, это включает темы для текущей эпохи и двух предыдущих.

  1. В конце каждой эпохи браузер составляет список страниц, соответствующих следующим критериям:
    • Страница была посещена пользователем в указанную эпоху.
    • Страница содержит код, который вызывает document.browsingTopics() .
    • API был включен (например, не заблокирован пользователем или через заголовок ответа ).
  2. Браузер на устройстве пользователя использует модель классификатора, предоставляемую API тем, для сопоставления имени хоста каждой страницы со списком тем.
  3. Браузер накапливает список тем.
  4. Браузер генерирует список из пяти самых популярных тем по частоте.

Затем метод document.browsingTopics() возвращает случайную тему из пяти лучших для каждой эпохи с вероятностью 5%, что любая из них может быть случайно выбрана из полной таксономии тем. В Chrome пользователи также могут удалять отдельные темы или очищать историю просмотров, чтобы уменьшить количество тем, возвращаемых API. Пользователи также могут отказаться от API.

Вы можете просмотреть информацию о темах, наблюдаемых в текущую эпоху, на странице chrome://topics-internals .

Как API решает, какие абоненты видят какие темы

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

В таблице ниже приведен пример (хотя и нереалистично небольшой) гипотетической истории посещений пользователя в течение одной эпохи, показаны темы, связанные с сайтами, которые он посетил, и вызывающие API, присутствующие на каждом сайте (сущности, вызывающие document.browsingTopics() в коде JavaScript, включенном в сайт).

Сайт Темы Вызывающие API на сайте
йога.пример Фитнес adtech1.пример adtech2.пример
вязание.пример Ремесла adtech1.пример
поход-праздник.пример Фитнес, путешествия и транспорт adtech2.пример
одежда своими руками.пример Ремесла, Мода и Стиль [никто]

В конце эпохи (в настоящее время одна неделя) API тем генерирует самые популярные темы браузера за неделю.

  • adtech1.example теперь имеет право получать темы «Фитнес» и «Ремесла», поскольку он наблюдал их на сайте Yoga.example, а также на сайте Knitting.example.
  • adtech1.example не имеет права получать тему «Путешествия и транспорт» для этого пользователя, поскольку она отсутствует ни на одном недавно посещенном пользователем сайте, связанном с этой темой.
  • adtech2.example просматривал темы «Фитнес» и «Путешествия и транспорт», но не видел тему «Ремесла».

Пользователь посетил сайт diy-clothing.example, на котором есть тема «Мода и стиль», но на этом сайте не было обращений к API тем. На данный момент это означает, что тема «Мода и стиль» не будет возвращена API ни для одного вызывающего объекта.

На второй неделе пользователь посещает другой сайт:

Сайт Темы Вызывающие API на сайте
шитье.пример Ремесла adtech2.пример

Кроме того, в diy-clothing.example добавлен код из adtech2.example:

Сайт Темы Вызывающие API на сайте
одежда своими руками.пример Ремесла, Мода и Стиль adtech2.пример

Помимо «Фитнеса» и «Путешествия и транспорт» с первой недели, это означает, что adtech2.example теперь сможет получить темы «Ремесла» и «Мода и стиль», но не раньше следующей эпохи, недели 3. Это гарантирует, что третьи стороны не смогут узнать больше о прошлом пользователя (в данном случае об интересе к моде), чем они могли бы узнать с помощью файлов cookie.

Еще через две недели «Фитнес» и «Путешествия и транспорт» могут исключиться из списка подходящих тем adtech2.example, если пользователь не посещает сайты с этими темами, которые содержат код из adtech2.example.

Пользовательский контроль, прозрачность и отказ от участия

Пользователи должны иметь возможность:

  • Поймите цель API тем.
  • Узнайте, какие темы связаны с их активностью в Интернете.
  • Знайте, когда API используется.
  • Иметь элементы управления для включения или отключения API.
  • Контролируйте, какие темы доступны пользователям, вызывающим API.

Удобочитаемая таксономия тем позволяет пользователям узнавать и контролировать темы, которые могут быть предложены им их браузером. Chrome предоставляет информацию и настройки для Topics API по адресу chrome://settings/adPrivacy/interests .

Пользователь может рекламировать категории тем, которые он не хочет передавать пользователям, вызывающим API:

  • Блокируя тему, которая уже была назначена им браузером.
  • Активно блокируя широкую категорию тем, которые им не интересны, на chrome://settings/adPrivacy/interests/manage . В этом случае пользователю не нужно ждать назначения темы, прежде чем ее заблокировать.
API тем: пример пользовательского интерфейса упреждающей блокировки тем.
В этом примере пользователь решил заблокировать темы «Красота и фитнес» и «Еда и напитки». Эти интересующие темы не будут переданы издателям.

Темы недоступны для вызывающих API в режиме инкогнито, а темы очищаются при очистке истории просмотров.

Возвращаемый список тем будет пустым, если:

  • Пользователь отказывается от использования Topics API в настройках браузера по адресу chrome://settings/adPrivacy/interests .
  • Пользователь удалил свои темы (используя настройки браузера по адресу chrome://settings/adPrivacy/interests ) или очистил файлы cookie.
  • Браузер находится в режиме инкогнито.
  • Пользователь блокирует все возможные темы.

Объяснитель предоставляет более подробную информацию о целях конфиденциальности и о том, как API пытается их решить.

Отказ от участия на сайте

В дополнение к возможности пользователя отказаться от участия в темах вашего сайта или страниц на нем. Руководство разработчика объясняет, как это сделать.

Использование API тем на веб-сайтах с prebid.js

Как отмечается в релизе Prebid 7 , сообщество активно развивало интеграцию с Topics API через новый модуль. Этот модуль был объединен в декабре 2022 года.

Узнайте больше здесь:

Следующие шаги

Привлекайте и делитесь отзывами

,

Узнайте, как определяются темы, как они назначаются браузерам пользователей и как пользователи могут управлять своим списком тем.

Статус реализации

  • API Topics прошел стадию публичного обсуждения и в настоящее время доступен 99 процентам пользователей с возможностью масштабирования до 100 процентов.
  • Чтобы оставить свой отзыв об API тем, создайте проблему в объяснителе тем или примите участие в обсуждениях в бизнес-группе улучшения веб-рекламы . У объяснителя остается ряд открытых вопросов, которые еще требуют дальнейшего уточнения.
  • В графике Privacy Sandbox указаны сроки реализации Topics API и других предложений Privacy Sandbox.
  • API Topics: в последних обновлениях подробно описаны изменения и улучшения API Topics и их реализации.

Что такое тема?

Тема в API тем — это тема, которая интересует пользователя, о чем свидетельствуют веб-сайты, которые он посещает.

Темы — это сигнал, помогающий платформам рекламных технологий выбирать релевантные объявления. В отличие от сторонних файлов cookie, эта информация передается без раскрытия дополнительной информации о самом пользователе или его активности в Интернете.

API Topics позволяет третьим сторонам, таким как платформы рекламных технологий, наблюдать и затем получать доступ к темам, интересующим пользователя. Например, API может предложить тему «Волокно и текстильное искусство» пользователю, который посещает веб-сайт knitting.example .

Список тем, используемый API тем, является общедоступным, курируемым человеком, удобочитаемым и предназначен для исключения деликатных категорий. Это текущий список , который со временем будет расширяться. Список структурирован в виде таксономии . Темы могут быть общими или более конкретными. Например, Food & Drink — это широкая категория с подкатегорией « Cooking & Recipes . Подкатегории могут быть дополнительно разделены на дополнительные подкатегории.

Такая таксономия тем должна обеспечивать компромисс между полезностью и конфиденциальностью. Если темы слишком специфичны, их можно использовать для идентификации отдельного пользователя. Если они слишком общие, они бесполезны для выбора рекламы или другого контента.

Таксономия тем построена с учетом двух основных требований:

  • Поддержка рекламы на основе интересов
  • Обеспечьте безопасность пользователей и защитите их конфиденциальность

Это вызывает несколько вопросов. Например:

  • Какой лучший способ для API определить темы, интересующие пользователя, на основе его активности в Интернете, сохраняя при этом конфиденциальность пользователя?
  • Как можно структурировать таксономию, чтобы сделать ее более полезной?
  • Какие конкретные элементы должна включать таксономия?

Как API определяет темы для сайта

Темы создаются на основе модели классификатора , которая сопоставляет имена хостов веб-сайтов с нулем или более темами. Анализ дополнительной информации (например, полных URL-адресов или содержимого страниц) может обеспечить более релевантную рекламу, но также может снизить конфиденциальность.

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

Только сайты, содержащие код, вызывающий API тем, включаются в историю просмотров, подлежащую расчету частоты тем, а вызывающие API получают только темы, которые они наблюдали. Другими словами, сайты не могут рассчитывать частоту тем, если сайт или встроенная служба не вызывает API.

Кроме того, вызывающий абонент может получать только те темы, которые «просмотрел» его код. Таким образом, если код другого вызывающего абонента зарегистрировал тему, скажем /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks , для браузера пользователя, и ваш код не вызвал регистрацию этой темы для браузера этого пользователя, вы не сможете узнайте об этой теме, интересующей браузер этого пользователя, когда вы вызываете API из встроенного кода. Обратите внимание: поскольку API теперь включает наблюдаемых предков, в приведенном выше примере /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks также будет наблюдаться Autos & Vehicles и Motor Vehicles .

Темы, возвращаемые пользователю, пересчитываются для вызывающего абонента в зависимости от сайта верхнего уровня. Например, если adtech.example запрашивает темы пользователя на news-a.example , затем на news-b.example , а затем на news-c.example , то возвращаемые им темы будут пересчитываться на каждом сайте. Это означает, что вызывающий абонент, скорее всего, получит разные темы для пользователя на разных сайтах верхнего уровня, поскольку (максимум) три темы, возвращаемые пользователю, выбираются случайным образом из пяти лучших за последние три эпохи (с вероятностью 5%). получения случайной темы). Из-за этого вызывающему абоненту сложнее идентифицировать пользователя по его темам, поскольку они могут быть разными на разных сайтах верхнего уровня (даже для одного и того же пользователя, вызывающего абонента и эпохи).

Модель классификатора

Темы вручную курируются для 50 000 ведущих доменов, и это курирование используется для обучения классификатора. Этот список можно найти в override_list.pb.gz , который доступен по адресу chrome://topics-internals/ в разделе текущей модели на вкладке Классификатор . Ассоциации домен-темы в списке используются API вместо выходных данных самой модели.

Страница chrome://topics-internals с выбранной панелью «Классификатор».
На панели классификатора страницы chrome://topics-internals указана версия модели, ее путь и темы, связанные с каждым перечисленным хостом.

Чтобы запустить модель напрямую, обратитесь к руководству TensorFlow по запуску модели .

Чтобы проверить файл override_list.pb.gz , сначала распакуйте его:

gunzip -c override_list.pb.gz > override_list.pb

Используйте protoc , чтобы проверить его как текст:

protoc --decode_raw < override_list.pb > output.txt

Полная систематика тем с идентификаторами доступна на GitHub.

Предоставление отзывов или предложений по модели классификатора

Существует несколько каналов для отправки отзывов об API тем. Чтобы получить отзыв о модели классификатора, мы рекомендуем отправить вопрос на GitHub или ответить на существующий вопрос. Например:

Как выбираются пять самых популярных тем пользователя

API возвращает одну тему для каждой эпохи (максимум три). Если возвращаются три, это включает темы для текущей эпохи и двух предыдущих.

  1. В конце каждой эпохи браузер составляет список страниц, соответствующих следующим критериям:
    • Страница была посещена пользователем в указанную эпоху.
    • Страница содержит код, который вызывает document.browsingTopics() .
    • API был включен (например, не заблокирован пользователем или через заголовок ответа ).
  2. Браузер на устройстве пользователя использует модель классификатора, предоставляемую API тем, для сопоставления имени хоста каждой страницы со списком тем.
  3. Браузер накапливает список тем.
  4. Браузер генерирует список из пяти самых популярных тем по частоте.

Затем метод document.browsingTopics() возвращает случайную тему из пяти лучших для каждой эпохи с вероятностью 5%, что любая из них может быть случайно выбрана из полной таксономии тем. В Chrome пользователи также могут удалять отдельные темы или очищать историю просмотров, чтобы уменьшить количество тем, возвращаемых API. Пользователи также могут отказаться от API.

Вы можете просмотреть информацию о темах, наблюдаемых в текущую эпоху, на странице chrome://topics-internals .

Как API решает, какие абоненты видят какие темы

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

В таблице ниже приведен пример (хотя и нереалистично небольшой) гипотетической истории посещений пользователя в течение одной эпохи, показаны темы, связанные с сайтами, которые он посетил, и вызывающие API, присутствующие на каждом сайте (сущности, вызывающие document.browsingTopics() в коде JavaScript, включенном в сайт).

Сайт Темы Вызывающие API на сайте
йога.пример Фитнес adtech1.пример adtech2.пример
вязание.пример Ремесла adtech1.пример
поход-праздник.пример Фитнес, путешествия и транспорт adtech2.пример
одежда своими руками.пример Ремесла, Мода и Стиль [никто]

В конце эпохи (в настоящее время одна неделя) API тем генерирует самые популярные темы браузера за неделю.

  • adtech1.example теперь имеет право получать темы «Фитнес» и «Ремесла», поскольку он наблюдал их на сайте Yoga.example, а также на сайте Knitting.example.
  • adtech1.example не имеет права получать тему «Путешествия и транспорт» для этого пользователя, поскольку она отсутствует ни на одном недавно посещенном пользователем сайте, связанном с этой темой.
  • adtech2.example просматривал темы «Фитнес» и «Путешествия и транспорт», но не видел тему «Ремесла».

Пользователь посетил сайт diy-clothing.example, на котором есть тема «Мода и стиль», но на этом сайте не было обращений к API тем. На данный момент это означает, что тема «Мода и стиль» не будет возвращена API ни для одного вызывающего объекта.

На второй неделе пользователь посещает другой сайт:

Сайт Темы Вызывающие API на сайте
шитье.пример Ремесла adtech2.пример

Кроме того, в diy-clothing.example добавлен код из adtech2.example:

Сайт Темы Вызывающие API на сайте
одежда своими руками.пример Ремесла, Мода и Стиль adtech2.пример

Помимо тем «Фитнес» и «Путешествия и транспорт» с первой недели, это означает, что adtech2.example теперь сможет получить темы «Ремесла» и «Мода и стиль», но не раньше следующей эпохи, недели 3. Это гарантирует, что третьи лица не смогут узнать больше о прошлом пользователя (в данном случае об интересе к моде), чем они могли бы получить с помощью файлов cookie.

Еще через две недели «Фитнес» и «Путешествия и транспорт» могут исключиться из списка подходящих тем adtech2.example, если пользователь не посещает сайты с этими темами, которые содержат код из adtech2.example.

Пользовательский контроль, прозрачность и отказ от участия

Пользователи должны иметь возможность:

  • Поймите цель API тем.
  • Узнайте, какие темы связаны с их активностью в Интернете.
  • Знайте, когда API используется.
  • Иметь элементы управления для включения или отключения API.
  • Контролируйте, какие темы доступны пользователям, вызывающим API.

Удобочитаемая таксономия тем позволяет пользователям узнавать и контролировать темы, которые могут быть предложены им их браузером. Chrome предоставляет информацию и настройки для Topics API по адресу chrome://settings/adPrivacy/interests .

Пользователь может рекламировать категории тем, которые он не хочет передавать пользователям, вызывающим API:

  • Блокируя тему, которая уже была назначена им браузером.
  • Активно блокируя широкую категорию тем, которые им не интересны, на chrome://settings/adPrivacy/interests/manage . В этом случае пользователю не нужно ждать назначения темы, прежде чем ее заблокировать.
API тем: пример пользовательского интерфейса упреждающей блокировки тем.
В этом примере пользователь решил заблокировать темы «Красота и фитнес» и «Еда и напитки». Эти интересующие темы не будут переданы издателям.

Темы недоступны для вызывающих API в режиме инкогнито, а темы очищаются при очистке истории просмотров.

Возвращаемый список тем будет пустым, если:

  • Пользователь отказывается от использования Topics API в настройках браузера по адресу chrome://settings/adPrivacy/interests .
  • Пользователь удалил свои темы (используя настройки браузера по адресу chrome://settings/adPrivacy/interests ) или очистил файлы cookie.
  • Браузер находится в режиме инкогнито.
  • Пользователь блокирует все возможные темы.

Объяснитель предоставляет более подробную информацию о целях конфиденциальности и о том, как API пытается их решить.

Отказ от участия на сайте

В дополнение к возможности пользователя отказаться от участия в темах вашего сайта или страниц на нем. Руководство разработчика объясняет, как это сделать.

Использование API тем на веб-сайтах с prebid.js

Как отмечается в релизе Prebid 7 , сообщество активно развивало интеграцию с Topics API через новый модуль. Этот модуль был объединен в декабре 2022 года.

Узнайте больше здесь:

Следующие шаги

Привлекайте и делитесь отзывами

,

Узнайте, как определяются темы, как они назначаются браузерам пользователей и как пользователи могут управлять своим списком тем.

Статус реализации

  • API Topics прошел стадию публичного обсуждения и в настоящее время доступен 99 процентам пользователей с возможностью масштабирования до 100 процентов.
  • Чтобы оставить свой отзыв об API тем, создайте проблему в объяснителе тем или примите участие в обсуждениях в бизнес-группе улучшения веб-рекламы . У объяснителя остается ряд открытых вопросов, которые еще требуют дальнейшего уточнения.
  • В графике Privacy Sandbox указаны сроки реализации Topics API и других предложений Privacy Sandbox.
  • API Topics: в последних обновлениях подробно описаны изменения и улучшения API Topics и их реализации.

Что такое тема?

Тема в API тем — это тема, которая интересует пользователя, о чем свидетельствуют веб-сайты, которые он посещает.

Темы — это сигнал, помогающий платформам рекламных технологий выбирать релевантные объявления. В отличие от сторонних файлов cookie, эта информация передается без раскрытия дополнительной информации о самом пользователе или его активности в Интернете.

API Topics позволяет третьим сторонам, таким как платформы рекламных технологий, наблюдать и затем получать доступ к темам, интересующим пользователя. Например, API может предложить тему «Волокно и текстильное искусство» пользователю, который посещает веб-сайт knitting.example .

Список тем, используемый API тем, является общедоступным, курируемым человеком, удобочитаемым и предназначен для исключения деликатных категорий. Это текущий список , который со временем будет расширяться. Список структурирован в виде таксономии . Темы могут быть общими или более конкретными. Например, Food & Drink — это широкая категория с подкатегорией « Cooking & Recipes . Подкатегории могут быть дополнительно разделены на дополнительные подкатегории.

Такая таксономия тем должна обеспечивать компромисс между полезностью и конфиденциальностью. Если темы слишком специфичны, их можно использовать для идентификации отдельного пользователя. Если они слишком общие, они бесполезны для выбора рекламы или другого контента.

Таксономия тем построена с учетом двух основных требований:

  • Поддержка рекламы на основе интересов
  • Обеспечьте безопасность пользователей и защитите их конфиденциальность

Это вызывает несколько вопросов. Например:

  • Какой лучший способ для API определить темы, интересующие пользователя, на основе его активности в Интернете, сохраняя при этом конфиденциальность пользователя?
  • Как можно структурировать таксономию, чтобы сделать ее более полезной?
  • Какие конкретные элементы должна включать таксономия?

Как API определяет темы для сайта

Темы создаются на основе модели классификатора , которая сопоставляет имена хостов веб-сайтов с нулем или более темами. Анализ дополнительной информации (например, полных URL-адресов или содержимого страниц) может обеспечить более релевантную рекламу, но также может снизить конфиденциальность.

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

Только сайты, содержащие код, вызывающий API тем, включаются в историю просмотров, подлежащую расчету частоты тем, а вызывающие API получают только темы, которые они наблюдали. Другими словами, сайты не могут рассчитывать частоту тем без сайта или встроенной службы, вызывающей API.

Кроме того, вызывающий абонент может получать только те темы, которые «просмотрел» его код. Таким образом, если код другого вызывающего абонента зарегистрировал тему, скажем /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks , для браузера пользователя, и ваш код не вызвал регистрацию этой темы для браузера этого пользователя, вы не сможете узнайте об этой теме, интересующей браузер этого пользователя, когда вы вызываете API из встроенного кода. Обратите внимание: поскольку API теперь включает наблюдаемых предков, в приведенном выше примере /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks также будет наблюдаться Autos & Vehicles и Motor Vehicles .

Темы, возвращаемые пользователю, пересчитываются для вызывающего абонента в зависимости от сайта верхнего уровня. Например, если adtech.example запрашивает темы пользователя на news-a.example , затем на news-b.example , а затем на news-c.example , то возвращаемые им темы будут пересчитываться на каждом сайте. Это означает, что вызывающий абонент, скорее всего, получит разные темы для пользователя на разных сайтах верхнего уровня, поскольку (максимум) три темы, возвращаемые пользователю, выбираются случайным образом из пяти лучших за последние три эпохи (с вероятностью 5%). получения случайной темы). Из-за этого вызывающему абоненту сложнее идентифицировать пользователя по его темам, поскольку они могут быть разными на разных сайтах верхнего уровня (даже для одного и того же пользователя, вызывающего абонента и эпохи).

Модель классификатора

Темы вручную курируются для 50 000 ведущих доменов, и это курирование используется для обучения классификатора. Этот список можно найти в override_list.pb.gz , который доступен по адресу chrome://topics-internals/ в разделе текущей модели на вкладке Классификатор . Ассоциации домен-темы в списке используются API вместо выходных данных самой модели.

Страница chrome://topics-internals с выбранной панелью «Классификатор».
На панели классификатора страницы chrome://topics-internals указана версия модели, ее путь и темы, связанные с каждым перечисленным хостом.

Чтобы запустить модель напрямую, обратитесь к руководству TensorFlow по запуску модели .

Чтобы проверить файл override_list.pb.gz , сначала распакуйте его:

gunzip -c override_list.pb.gz > override_list.pb

Используйте protoc , чтобы проверить его как текст:

protoc --decode_raw < override_list.pb > output.txt

Полная систематика тем с идентификаторами доступна на GitHub.

Предоставление отзывов или предложений по модели классификатора

Существует несколько каналов для отправки отзывов об API тем. Чтобы получить отзыв о модели классификатора, мы рекомендуем отправить вопрос на GitHub или ответить на существующий вопрос. Например:

Как выбираются пять самых популярных тем пользователя

API возвращает одну тему для каждой эпохи (максимум три). Если возвращаются три, это включает темы для текущей эпохи и двух предыдущих.

  1. В конце каждой эпохи браузер составляет список страниц, соответствующих следующим критериям:
    • Страница была посещена пользователем в указанную эпоху.
    • Страница содержит код, который вызывает document.browsingTopics() .
    • API был включен (например, не заблокирован пользователем или через заголовок ответа ).
  2. Браузер на устройстве пользователя использует модель классификатора, предоставленную API тем, чтобы отобразить имя хоста для каждой страницы в список тем.
  3. Браузер накапливает список тем.
  4. Браузер генерирует список из пяти лучших тем по частоте.

Метод document.browsingTopics() затем возвращает случайную тему из пяти лучших для каждой эпохи, с вероятностью 5%, что любой из них может быть выбран случайным образом из полной таксономии тем. В Chrome пользователи также могут удалять отдельные темы или очистить историю просмотра, чтобы уменьшить количество тем, возвращаемых API. Пользователи также могут отказаться от API.

Вы можете просмотреть информацию о темах, наблюдаемых в текущую эпоху со страницы chrome://topics-internals .

Как API решает, какие вызывающие вызывающие абоненты видят, какие темы

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

В таблице ниже изложен пример (хотя и нереалистично маленький) гипотетической истории просмотра для пользователя в одну эпоху, показывающие темы, связанные с сайтами, которые они посещали, и абонентов API, присутствующих на каждом сайте (объекты, которые вызывают document.browsingTopics() в коде JavaScript, включенном на сайт).

Сайт Темы Абоненты API на сайте
йога. Пример Фитнес adtech1.example adtech2.example
вязание. Пример Ремесла adtech1.example
Походы-Holiday.example Фитнес, путешествия и транспорт adtech2.Example
DIY-CLOTHING.Example Ремесла, мода и стиль [никто]

В конце эпохи (в настоящее время одна неделя) API темы генерирует главные темы браузера за неделю.

  • AdTech1.Example теперь имеет право на получение тем «пригодности» и «ремесел», поскольку он наблюдал их на йоге. Пример, а также на вязании. Пример.
  • AdTech1.Example не имеет права на получение темы «путешествия и транспорта» для этого пользователя, поскольку она не присутствует на каких -либо сайтах, которые пользователь посетил недавно, которые связаны с этой темой.
  • AdTech2.Example увидел темы «фитнес» и «путешествия и транспорта», но не видел тему «ремесла».

Пользователь посетил DIY-Clothing.example, у которого есть тема «мода и стиль», но на этом сайте не было никаких призывов к API. На этом этапе это означает, что API не будет возвращена тема «моды и стиля».

Во второй неделе пользователь посещает другой сайт:

Сайт Темы Абоненты API на сайте
Шить. Пример Ремесла adtech2.Example

Кроме того, код из adtech2.example добавляется в DIY-Clothing.Example:

Сайт Темы Абоненты API на сайте
DIY-CLOTHING.Example Ремесла, мода и стиль adtech2.Example

Помимо «фитнеса» и «путешествия и транспорта» с 1 недели, это означает, что Adtech2.Example теперь сможет получить тему «ремесла» и «Fashion & Style» - но только до следующей эпохи, неделя 3. Это гарантирует, что третьи стороны не могут узнать больше о прошлом пользователя (в данном случае интерес к моде), чем они могли бы с файлами cookie.

Через две недели «фитнес» и «путешествия и транспорт» могут выпадать из списка подходящих тем Adtech2.example, если пользователь не посещает какие -либо сайты с тем темами, которые включают код из AdTech2.Example.

Управление пользователями, прозрачность и отказ

Пользователи должны иметь возможность:

  • Поймите цель темы API.
  • Признайте, какие темы связаны с их деятельностью просмотра.
  • Знайте, когда используется API.
  • Иметь элементы управления, чтобы включить или отключить API.
  • Контроль, какие темы разделены с абонентами API.

Человеческая таксономия темы позволяет пользователям узнавать и контролировать темы, которые могут быть предложены для них своим браузером. Chrome предоставляет информацию и настройки для API тем на chrome://settings/adPrivacy/interests .

Пользователь может рекламировать категории тем, которые им не хотят общаться с абонентами API:

  • Блокируя тему, которая уже была назначена им браузером.
  • Установозившись, блокируя широкую категорию тем, которые они не заинтересованы в chrome://settings/adPrivacy/interests/manage . В этом случае пользователю не нужно ждать, пока будет назначена тема, прежде чем блокировать ее.
Темы API: проактивная тема блокировки пользовательского интерфейса.
В этом примере пользователь решил заблокировать темы «красота и фитнес» и «еда и напитки». Эти темы, представляющие интерес, не будут переданы издателям.

Темы недоступны для абонентов API в режиме инкогнито, а темы очищаются при очистке истории просмотра.

Список возвращенных тем будет пуст, если:

  • Пользователь выходит из API тем в настройках браузера в chrome://settings/adPrivacy/interests .
  • Пользователь очистил свои темы (используя настройки браузера в chrome://settings/adPrivacy/interests ) или очистил свои файлы cookie.
  • Браузер находится в режиме инкогнито.
  • Пользователь блокирует все возможные темы.

Объяснитель предоставляет более подробную информацию о целях конфиденциальности и о том, как API стремится их решить.

Сайт отказался

В дополнение к способности пользователя отказаться, вы можете отказаться от тематических тем или страниц. Гид разработчика объясняет, как.

Использование API тем на веб -сайтах с prebid.js

Как отмечено в выпуске Prebid 7 , сообщество активно развивало интеграцию с API тем по новым модулям. Этот модуль был объединен в декабре 2022 года.

Узнайте больше здесь:

  • Прочитайте документацию API -модуля PEBID.
  • Для получения дополнительной информации обратитесь к Prebible.js через любой стандартный канал, который они предлагают.

Следующие шаги

Привлекайте и делитесь отзывами