Введение в отчеты по атрибуции (измерение конверсий)

Основные сведения и ключевые концепции для понимания Attribution Reporting API.

Published on Updated on

Translated to: Español, Português, 한국어, 中文, 日本語, Français, Deutsch

Данный API является предложением и со временем будет расширяться. Эта публикация в блоге описывает его текущее состояние и обновляется по мере развития API.

Обновления:

  • Начало 2021 года: в предложение добавлены сводные отчеты и отслеживание просмотров.
  • Начало 2021 года: API переименован в Attribution Reporting API.
Caution
  • Эта публикация посвящена сценариям использования для рекламы, однако Attribution Reporting API может также применяться и в сценариях, не связанных с рекламой.
  • В сценариях использования этого API для рекламы основное внимание уделяется привязке кликов и просмотров объявлений к конверсиям (измерению конверсии).

Введение

Attribution Reporting API позволяет отслеживать, когда клик или просмотр объявления приводит к конверсии на сайте рекламодателя, например к продаже или решению о регистрации аккаунта. API не полагается на сторонние cookie или механизмы, которые могут использоваться для идентификации отдельных пользователей при их перемещении между сайтами.

Разработка этого предложения ведется открыто. Само предложение и его обсуждения доступны в репозитории WICG GitHub.

Этот API входит в тестовую среду конфиденциальности (Privacy Sandbox)—серию предложений для третьих лиц без использования сторонних cookie и других механизмов межсайтового отслеживания. Подробнее см. в разделе документации «Предложения для тестовой среды конфиденциальности».

Зачем нужен этот API?

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

Кому нужно знать об этом API?

  • Adtech-платформам, таким как автоматизированные платформы покупки рекламы (DSP) или платформы управления данными (DMP), этот API поможет поддерживать функции, которые сейчас зависят от сторонних cookie.
  • Рекламодатели и издатели, использующие собственный код для показа рекламы или измерения конверсии, могут применять этот API вместо существующих методов.
  • Рекламодателям и издателям, которые используют adtech-платформы для измерения конверсии, не придется применять этот API напрямую, однако разъяснение принципов этого API может представлять для них интерес, особенно если их adtech-платформы захотят интегрировать этот API.

Отлаживайте ошибки API с помощью Chrome DevTools

Доступно в Chrome 93. Ошибки Attribution Reporting API теперь отображаются в DevTools на вкладке Issues.

Ошибки Attribution Reporting API на вкладке Issues

Участие

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

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

Присоединяйтесь к обсуждению

  • Участвуйте в конференциях раз в две недели (каждую вторую неделю), где участники обсуждают предложения по дизайну API и то, как реализовать различные варианты измерений в этом API. Вы можете добавить темы для следующей конференции в любое время. Приглашаем всех присоединиться к этим обсуждениям, но сначала убедитесь, что вы вступили в WICG.
  • Откройте вопрос, чтобы задать вопросы, предложить функции или обсудить варианты использования. Если вы не знаете, как сформулировать вопрос, просмотрите этот вопрос и вот этот. Кроме того, вы можете присоединиться к обсуждению уже существующих вопросов.

Поработайте с API

Caution

Если вы экспериментируете с API в Chrome, у вас будет доступ ко всем функциям, которые сейчас реализованы. Однако не все функции, обсуждаемые в репозитории и на конференциях, реализованы в пробной версии Chrome. Текущий статус реализации функций можно найти в разделе «Статус». Функции, доступные для экспериментов, также являются подмножеством функциональности, которую в конечном итоге будет поддерживать API, и могут быть изменены в ходе открытой разработки API и на основе отзывов от участников экосистемы.

Экспериментируйте локально или с демоверсией

  1. Чтобы задействовать API локально в браузере, включите флаг #enable-experimental-web-platform-features. Флаг Chrome-это переключатель, который дает браузеру команду задействовать определенные экспериментальные функции. Чтобы включить этот флаг, вставьте chrome://flags/#enable-experimental-web-platform-features в строку поиска Chrome и нажмите Enable (Включить).
  2. Запустите демоверсию локально (или попробуйте живую демонстрацию).
  3. Создайте ветку демонстрационного кода и настройте его для своих задач или создайте свою демонстрацию с нуля.

Экспериментируйте с конечными пользователями на развернутом сайте

  1. Включите API для конечных пользователей, зарегистрировавшись в пробной версии источника, если она доступна. Пробная версия источника временно открывает доступ к экспериментальной функции, на основе которой можно создать свою функциональность. Обратите внимание, что сторонние пробные версии источника позволяют сторонним участникам, таким как поставщики услуг показа и измерения рекламы, тестировать API на нескольких сайтах. Чтобы увидеть, какие пробные версии источника для этого API сейчас доступны, перейдите в раздел «Статус». А чтобы узнавать о будущих пробных версиях источника, присоединяйтесь к списку рассылки Attribution Reporting для разработчиков.

  2. Интегрируйте API в свои сайты и системы.

Если у вас есть вопросы по реализации, присоединяйтесь к списку рассылки Attribution Reporting для разработчиков и задавайте их.

Если у вас есть общетехнические вопросы о своем варианте использования, откройте новый вопрос в репозитории поддержки разработчиков Privacy Sandbox.

Демоверсия

Вы можете попробовать несколько демоверсий.

Варианты использования и возможности

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

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

Этот API разрабатывается открыто. Вы всегда можете поучаствовать в его обсуждении.

Этот API позволяет измерять конверсии на сайтах в следующих случаях:

  • клики и просмотры объявлений;
  • объявления в стороннем блоке iframe, например объявления на сайте издателя, который использует стороннего adtech-поставщика;
  • объявления в контексте первой стороны: реклама в социальной сети, на странице результатов поиска или на сайте издателя, показывающего свои объявления.

Поддерживается гибкая модель атрибуции. Подробнее об этом см. в разделе «Статус».

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

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

отчет на уровне событий
Пример отчета на уровне события: Клик с ID 200400600 на сайте news.example (привязан к идентификатору пользователя Bob_Doe на сайте news.example) привел к покупке на сайте shop.example.

Отчеты на уровне событий подходят для следующих случаев:

  • Варианты использования, связанные с оптимизацией. Отчеты на уровне событий помогают ответить на вопросы вроде «как повысить рентабельность инвестиций?». В частности, такие отчеты подходят для оптимизации размещения рекламы, поскольку в них можно сделать доступным уникальный идентификатор на стороне объявления. Данные из отчетов на уровне событий также подойдут для моделей машинного обучения.
  • Варианты использования, для которых не требуется высокая точность данных и достаточно лишь минимальной информации о конверсии. Текущее ограничение составляет 3 бита данных конверсии для кликов (т. е. каждой конверсии можно присвоить одну из восьми категорий) и 1 бит для просмотров. Соответственно, кодирование подробных данных на стороне конверсии, таких как конкретная цена или время конверсии, не поддерживается в отчетах на уровне событий.
  • Варианты использования, связанные с выявлением мошенничества. Данные в некоторых отчетах помогают выявлять и анализировать случаи мошенничества с рекламой, позволяя понять закономерности, которые можно использовать для обнаружения спама или недопустимых действий.

При этом сводные отчеты предлагают более подробные данные о конверсиях и повышенную гибкость для объединения данных о кликах/просмотрах и данных о конверсиях.

сводный отчет
Пример данных из сводного отчета: Кампания с ID 1234567 на сайте news.example привела к 518 конверсиям на сайте shoes.example и покупкам на общую сумму $38174. Половину конверсий обеспечили пользователи из города Нью-Йорк, США.

Сводные отчеты лучше всего подходят для отчетности о сценариях использования. Они помогают ответить на вопросы вроде «какова рентабельность моих инвестиций?».
Сейчас активно изучается возможность применения сводных отчетов для вариантов использования, связанных с оптимизацией, например, для оптимизации стоимости покупки, что не поддерживается в отчетах на уровне событий из-за недостаточной точности данных о конверсиях. Подробнее об этом см. в разделе «Открытые вопросы».

Зачем нужны два типа отчетов?

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

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

Именно поэтому были разработаны сводные отчеты.

Помимо этих функций, API предлагает атрибуцию из приложения в Интернет (просмотр или клик на объявлении в приложении с последующей конверсией в Интернете) и атрибуцию между устройствами (просмотр или клик на объявлении на мобильном устройстве с последующей конверсией на компьютере).

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

  • ремаркетинг: см. FLEDGE;
  • отбор объявлений на основе интересов: см. FLoC.

Статус

🕙 Последнее обновление: август 2021 г.

Статусы:

  • 🤿 Under exploration: эта идея находится на ранних стадиях обсуждения;
  • 🥚 Proposal: первоначальный дизайн готов и находится в стадии публичной разработки;
  • 🏗️ Under development (BROWSER_NAME): функция реализуется в BROWSER_NAME;
  • 🧪 Experiment (BROWSER_NAME): функция доступна для экспериментов в BROWSER_NAME. В Chrome такая экспериментальная функция называется пробной версией источника;
  • 🚀 Stable (BROWSER_NAME): функция по умолчанию интегрирована в BROWSER_NAME.

Текущая пробная версия источника (экспериментальная функция Chrome 🧪)

Caution

Испытания (эксперименты) будут проводиться с несколькими пробными версиями источника. В каждом раунде в API будут вноситься улучшения и корректировки на основе отзывов от участников экосистемы.

ПредложениеСтатус
Отчеты по кликам на уровне событий
Подробнее
🧪 Experiment (Chrome)
Отчеты по показам на уровне событий
Подробнее
🏗️ Under development (Chrome)
Сводные отчеты по кликам и просмотрам
Подробнее
🥚 Proposal
Маршрут конверсии между устройствами
Подробнее
🥚 Proposal
Маршрут конверсии из приложения в Интернет
Подробнее
🥚 Proposal
Модель атрибуции: последний клик
Подробнее
🧪 Experiment (Chrome)
Модель атрибуции: на основе приоритета
Подробнее
🏗️ Under development (Chrome)
Модель атрибуции: гибкая🤿 Under exploration

О моделях атрибуции

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

  • для определения того, был ли клик или просмотр наиболее вероятной причиной конверсии (клик обычно считается более четким сигналом интереса от пользователя);
  • для установки модели атрибуции по первому контакту, т. е. установки attributionsourcepriority относительно времени;
  • для установки (вероятностной) модели линейной атрибуции, т. е. выбора приоритета случайным образом с равномерным распределением.

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

Поддержка браузеров

Хотя эти два API заметно отличаются друг от друга, Chrome и WebKit активно сотрудничают ради удобства разработчиков, например, согласовывают названия атрибутов и структуру JSON для отчетов.

Различия между API от Chrome и API от WebKit

Функциональность Attribution Reporting API от Chrome не совпадает с функциональностью Private Click Measurement API от Safari/WebKit.
Так, в Attribution Reporting API от Chrome:

  • поддерживается отслеживание просмотров;
  • могут предоставляться отчеты на уровне событий;
  • поддерживаются как объявления в контексте первой стороны (например, реклама в социальной сети, на странице результатов поиска или на сайте издателя, показывающего свои объявления), так и объявления в стороннем блоке iframe (например, объявления на сайте издателя, который использует стороннего adtech-поставщика);
  • adtech-платформы и другие третьи стороны могут получать отчеты от имени издателей и рекламодателей.

Принцип работы

Отчеты на уровне событий

отчет на уровне событий
Отчеты на уровне событий формируются следующим образом: браузер связывает клики или просмотры («события источника атрибуции») с данными о конверсии («данными триггера атрибуции»), которые заданы adtech-платформой, а затем отправляет полученные отчеты в заранее определенную конечную точку с некоторой задержкой и зашумлением.

Подробнее о принципе работы: отчеты на уровне событий

Ссылки в объявлениях можно настроить со специальными атрибутами для рекламных конверсий:

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

Примечание. Можно также зарегистрировать источник атрибуции для навигации, инициированной window.open(), или (для просмотров) через API JavaScript.

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

Далее пользователь посещает сайт рекламодателя и выполняет действие, которое рекламодатель или его adtech-поставщик классифицирует как конверсию, например покупку. Когда это происходит, рекламодатель или adtech-поставщик запускает процесс атрибуции и дает браузеру команду зарегистрировать конверсию с определенным значением trigger-data, после чего браузер пользователя связывает клик (или просмотр) объявления и событие конверсии.

И наконец, браузер планирует отправку отчета на конечную точку, указанную на стороне объявления. Этот отчет включает в себя:

  • особые данные на стороне объявления, связанные с кликом или просмотром объявления, который привел к этой конверсии;
  • особые данные на стороне конверсии с некоторым зашумлением.

Если для одного клика (или просмотра) объявления зарегистрировано несколько конверсий, то планируется отправка соответствующих отчетов. Для просмотров можно отправить один отчет, а для кликов-до трех отчетов.

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

Сводные отчеты

ALT_TEXT_HERE
Сводные отчеты формируются следующим образом: браузер связывает подробные сведения о кликах или просмотрах («событиях источника атрибуции») с подробными данными о конверсиях («данными триггера атрибуции»), которые заданы adtech-платформой. Код, определенный adtech-платформой, запускается в рабочем наборе для определения значений вклада каждого события, которые затем отправляются браузером для формирования сводных отчетов. При этом ответственность за конфиденциальное формирование сводных отчетов для adtech-платформ несут службы агрегирования данных.

Подробнее о принципе работы: сводные отчеты

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

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

Далее код, заданный adtech-платформой, выполняется в рабочем наборе для определения вкладов, а именно связей между данными на стороне объявления и данными на стороне конверсии.

Эти вклады (необработанные отчеты) отправляются в зашифрованном виде на adtech-сервер, а затем передаются службам агрегирования, которые будут конфиденциально формировать сводные отчеты.

Обратите внимание, что отправка сводных отчетов не задерживается так, как отправка отчетов на уровне событий.

Конфиденциальность

Общие сведения

Возьмем человека по имени Боб, который просматривает рекламу, читая новости на сайте news.com, а через неделю покупает обувь на сайте shoes.example.

Сегодня эта конверсия будет отслеживаться сторонним файлом cookie, который служит межсайтовым идентификатором. С помощью сторонних cookie adtech-компания может получить доступ ко множеству сведений о действиях Боба на сайтах news.example и shoes.example, а затем обобщить эти сведения и создать подробный профиль Боба. Adtech-компания может в конечном итоге узнать местонахождение Боба, его привычки и предпочтения при чтении на сайте news.com,а также информацию о покупках, действиях и кредитной карте на сайте shoes.com. Такое межсайтовое отслеживание удобно для измерения конверсии рекламы, но нарушает конфиденциальность пользователей: действия Боба на разных сайтах можно отследить почти во всех подробностях.

При этом Attribution Reporting API позволяет рекламным компаниям получать информацию о конверсиях, не отслеживая активность отдельных лиц на сайтах. Небольшого объема информации между сайтами, который получается на выходе, вполне достаточно для измерения конверсий, но недостаточно для подробного отслеживания действий Боба на разных сайтах. Действия Боба на сайте news.example и на сайте shoes.example не будут связаны между собой.

Диаграмма: сравнение нынешней сети (объединенная идентичность) и будущей сети (разделенная идентичность)

Подробности

ALT_TEXT_HERE
В отличие от сторонних cookie, Attribution Reporting API предоставляет аналитическую информацию без межсайтовых идентификаторов, сохраняя раздельные идентификаторы для каждого сайта.
Отчеты на уровне событий связывают идентификатор на стороне объявления только с небольшим объемом данных о конверсии, тем самым предоставляя лишь приблизительную межсайтовую информацию о конверсии, которой недостаточно для обобщения идентификационных данных пользователя на разных сайтах.
Сводные отчеты предоставляют подробную информацию, но только на агрегированном уровне: из-за разных методов обеспечения конфиденциальности, конфиденциальных вычислений и криптографии сводные отчеты не подходят для отслеживания действий отдельного пользователя между сайтами.
Дополнительные меры защиты конфиденциальности, в том числе ограничение частоты отправки, применяются как к отчетам на уровне событий, так и к сводным отчетам.

Подробности: отчеты на уровне событий и конфиденциальность

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

  • Отсутствию межсайтовых идентификаторов и передачи из пользовательского устройства каких-либо подробных данных о переходах между сайтами. Отчеты на уровне событий связывают 64 бита информации на стороне объявления (news.example) только с 1 или 3 битами на стороне конверсии (shop.example). 64 битов вполне достаточно для сопоставления с идентификатором конкретного пользователя, но эти 64 бита могут быть связаны только с очень небольшим объемом межсайтовой информации (1 битом или 3 битами), которого недостаточно для хранения идентификатора. Примечание: 64 бита на стороне объявления не являются новой информацией. Идентификатор пользователя уже может быть доступен на стороне объявления. Сайт news.example или adtech.example уже знает о действиях определенного пользователя на news.example.

  • Для предотвращения злоупотреблений и межсайтового отслеживания применяются дополнительные меры защиты:

    • отчеты отправляются с задержкой;
    • данные о конверсии зашумлены: некоторую часть времени (5% в Chrome) реальные данные о конверсии заменяются на случайные значения;
    • количество отчетов о конверсиях с атрибуцией ограничено для каждого клика и просмотра.

Истинное количество конверсий можно восстановить с сохранением конфиденциальности. Подробнее см. в примере скрипта.

Подробности: сводные отчеты и конфиденциальность

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

  • Отсутствию межсайтового идентификатора.

  • Каждая атрибуция может вносить несколько вкладов в итоговый сводный отчет, а конкретный пользователь может инициировать множественную атрибуцию для определенного клика (или просмотра) и конверсии. Однако вклады, которые любой пользователь может сделать в заданное временное окно, ограничены.

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

  • Необработанные отчеты, которые связывают подробные данные о клике или просмотре с подробными данными о конверсии, зашифрованы и не могут быть прочитаны adtech-компанией. Затем на основе этих отчетов доверенный сервер конфиденциально вычисляет сводные данные. Рассматриваются несколько вариантов вычислений:

    • Безопасные многосторонние вычисления (Multi-Party Computation, MPC). Уровень доверия распределяется между несколькими серверами. Каждый сервер получает один фрагмент данных, который сам по себе не имеет смысла. После того как каждый вспомогательный сервер выполнил вычисления, выходные данные этих помощников объединяются, превращаясь в осмысленный массив данных.
    • Односерверные вычисления. Выходные данные вычисляет один вспомогательный сервер. Этот вариант менее безопасен и менее конфиденциален, однако его проще реализовать, что позволит большему числу участников экосистемы поэкспериментировать с этим API и оставить отзывы. Этот вариант не рассматривается как долгосрочное решение. Со временем, по мере сбора отзывов от участников экосистемы и развития API в сторону более безопасных подходов, он будет признан устаревшим и заменен на безопасные многосторонние или односерверные вычисления.
    • Безопасные односерверные вычисления. Все вычисления выполняет один сервер, имеющий, однако, примерно такой же (но не эквивалентный) уровень конфиденциальности, как у MPC.
    • В долгосрочной перспективе серверам необходимо будет обрабатывать данные только с помощью безопасных многосторонних вычислений (безопасных односерверных или безопасных многосторонних).
  • Для предотвращения злоупотреблений и межсайтового отслеживания применяются дополнительные меры защиты:

    • отчеты отправляются со случайной задержкой;
    • частота запросов на разных срезах данных ограничена.

Сайты и пользовательский контроль

  • Пользователи могут отключить эту функцию в пользовательских настройках: chrome://settings/privacySandbox.
  • По умолчанию функция включена в контекстах верхнего уровня. Произвольные третьи стороны не могут использовать API без ведома издателя, потому что Attribution Reporting API необходимо включать в дочерних блоках iframe с помощью политики разрешений.

Открытые вопросы

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

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

Данный API сочетает в себе несколько методов обеспечения конфиденциальности и сохранения полезности. Это означает, что ограничение данных в 3 бита (или 1 бит для просмотров) и другие механизмы обеспечения конфиденциальности в API служат для достижения этой цели и при необходимости могут быть изменены. Если появится возможность предоставить adtech-компаниям больше полезных данных без ущерба для конфиденциальности, то API будет развиваться соответствующим образом.

Updated on Improve article

This site uses cookies to deliver and enhance the quality of its services and to analyze traffic. If you agree, cookies are also used to serve advertising and to personalize the content and advertisements that you see. Learn more about our use of cookies.