Сервис агрегации генерирует сводные отчеты, содержащие подробные данные о конверсиях и показателях охвата, на основе исходных агрегируемых отчетов. Для обеспечения конфиденциальности и безопасности пользовательских данных сервис агрегации использует структуру, поддерживающую дифференциальную конфиденциальность (DP), для количественной оценки и ограничения объема информации, раскрываемой в этих отчетах об отдельных пользователях.
В этом руководстве рассматриваются инструменты и стратегии для создания сводных отчетов, которые помогают обеспечить безопасность данных об отдельных пользователях:
- Создавайте сводные отчеты с добавлением шума.
- Установите бюджет взносов
- Стратегии пакетной обработки отчетов
- Обработка дублирующихся отчетов в пакетном режиме.
- Обрабатывайте отчеты с использованием общего идентификатора.
- Используйте предварительно объявленные ключи агрегации.
Сводные отчеты с добавлением шума
При пакетной обработке агрегируемых отчетов служба агрегации создает сводный отчет. Этот сводный отчет представляет собой совокупность всех вкладов всех предопределенных ключей домена с добавлением статистических погрешностей.
Добавляемый к отчетам шум не зависит от количества агрегированных отчетов, значений отдельных отчетов или значений агрегированных отчетов. Шум берется из дискретной версии распределения Лапласа и масштабируется в соответствии с бюджетом вклада (чувствительность L1 ), который устанавливается клиентом в зависимости от соответствующего API измерения и параметра конфиденциальности epsilon .
Чтобы узнать больше о шуме и его влиянии на данные отчетов, см. раздел «Понимание шума в сводных отчетах» .
Бюджет взносов
Для управления конфиденциальностью сводного отчета количество вкладов, передаваемых в запросе, привязано к определенному лимиту вкладов, также известному как бюджет вкладов. Бюджет вкладов различается в зависимости от того, используете ли вы API для формирования отчетов об атрибуции или API для частной агрегации .
Чтобы узнать больше о том, как устанавливать лимиты взносов для каждого API, см. следующие разделы документации по API:
- API для отчетности по атрибуции: ограничение и бюджетирование взносов.
- Ограничения на внесение вклада в API частной агрегации
- Ограничение и бюджетирование взносов в частный API агрегации
Стратегии пакетной обработки отчетов
При формировании агрегируемых отчетов в пакетном режиме важно оптимизировать стратегии пакетной обработки, чтобы не превышать лимиты конфиденциальности. Два важных принципа для правильной пакетной обработки отчетов — это правило «никаких дубликатов» и идея непересекающихся пакетов .
Правило «Без дубликатов»
Сервис агрегации применяет правило «без дубликатов». Это правило гласит, что агрегируемый отчет, однозначно идентифицируемый по report_id , может встречаться в одном пакете только один раз. Если агрегируемый отчет встречается в пакете более одного раза, в агрегацию включается первый отчет, последующие отчеты с тем же report_id отбрасываются, и пакет завершается успешно.
Правило также гласит, что один и тот же общий идентификатор не может встречаться более чем в одной партии. Если общий идентификатор уже был включен в предыдущую успешно обработанную партию, то последующая партия, включающая тот же общий идентификатор, завершится неудачей.
Без правила «без дубликатов» злоумышленник мог бы получить доступ к содержимому конкретной партии отчетов, манипулируя их содержимым путем включения дубликатов отчетов в одну или несколько партий.
Чтобы узнать больше о применении правила «никаких дубликатов» в рамках пакета отчетов или нескольких пакетов, см. раздел «Дублирующиеся отчеты в пакетах» .
Разрозненные партии
Чтобы избежать ситуаций, когда пакеты данных перекрываются, служба агрегации обеспечивает разделение пакетов. Это означает, что два или более пакета не могут содержать отчеты, имеющие общий идентификатор . Общий идентификатор представляет собой комбинацию данных, собранных из поля shared_info агрегируемого отчета, а также идентификатора фильтрации из запроса задания. Если идентификатор фильтрации не указан, используется значение по умолчанию 0.
В приведенном ниже примере поля shared_info вы можете увидеть API, attribution_destination (для отчетов по атрибуции), reporting_origin , scheduled_report_time , source_registration_time (для отчетов по атрибуции) и version . Эти поля, за исключением report_id , а также фильтрующий ID из запроса задания, влияют на общий ID.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Поскольку source_registration_time округляется до дня, а scheduled_report_time — до часа, существуют отчеты с одинаковым общим идентификатором. В этом примере у Report1 и Report2 общие информационные поля. Оба отчета имеют одинаковые API, версию, attribution_destination , reporting_origin и source_registration_time . Поскольку report_id не является частью общего идентификатора, это различие можно игнорировать.
В следующих примерах для Report1 и Report2 значение scheduled_report_time одинаково.
Report1 поделился информацией:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Report2 поделился информацией:
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://shop.dev",
"report_id": "5b052748-...",
"reporting_origin": "https://dsp.dev",
"scheduled_report_time": "1708376890",
"source_registration_time": "0",
"version": "0.1"
}
Запланированное время составления отчетов: "19 февраля 2024 г., 21:08:10" для Отчета 1 и "19 февраля 2024 г., 21:55:10" для Отчета 2. Поскольку значение поля scheduled_report_time усечено до часа, в обоих отчетах значение поля scheduled_report_time равно 1708376890 (закодированное значение для "19 февраля 2024 г., 21:00").
Поскольку все остальные поля и идентификатор фильтрации одинаковы, оба отчета имеют один и тот же общий идентификатор. А поскольку оба отчета имеют один и тот же общий идентификатор, они должны быть включены в один и тот же пакет.
Если отчет Report1 был обработан в ранее успешно выполненной партии, а отчет Report2 обрабатывается в последующей партии, то обработка партии с отчетом Report2 завершится с ошибкой PRIVACY_BUDGET_EXHAUSTED . В этом случае удалите отчеты с общим идентификатором, которые были успешно обработаны в предыдущих партиях, и повторите попытку. Дополнительную информацию об этой ошибке см. в разделе «Коды ошибок и способы их устранения для службы агрегации» .
Предварительно объявленные ключи агрегации
При отправке пакета данных в службу агрегации он должен включать как агрегируемые отчеты, полученные от источника отчетности, так и файл выходного домена. Выходной домен содержит ключи, или сегменты, которые извлекаются из агрегируемых отчетов.
С точки зрения конфиденциальности, к каждому ключу, предварительно указанному в выходном домене, добавляется шум, даже если ни один реальный отчет не соответствует конкретному ключу. Указание выходного домена защищает от атаки, при которой наличие ключа в выходных данных раскрывает информацию об отдельном пользователе или событии. Например, если вы показали кампанию только одному пользователю, получение ключа в выходных данных покажет, что пользователь впоследствии совершил конверсию, даже с учетом добавленного шума. Указав этот домен первым, вы можете быть уверены, что он ничего не раскрывает о вкладе пользователя.
Эти 128-битные ключи можно объявить либо в API для формирования отчетов об атрибуции , либо в API для частной агрегации и использовать для кодирования параметров, которые вы хотите отслеживать.
Для агрегирования и включения в сводный отчет учитываются только предварительно объявленные ключи. К агрегированным значениям сегментов в сводном отчете добавляется статистический шум, который отражается в созданном сводном отчете.
Если ключ агрегации включен в выходной файл домена, но отсутствует в пакетном отчете, то даже если агрегированное значение равно нулю, итоговый сводный отчет, скорее всего, будет ненулевым из-за добавленного шума, необходимого для сохранения конфиденциальности.