Служба агрегирования генерирует сводные отчеты с подробными данными о конверсиях и измерениями охвата на основе необработанных агрегированных отчетов. Чтобы обеспечить конфиденциальность и безопасность пользовательских данных, служба агрегации использует структуру, которая поддерживает дифференциальную конфиденциальность (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 , вместе с идентификатором фильтрации из запроса задания, вносят вклад в общий идентификатор.
"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» для Report1 и «19 февраля 2024 г., 21:55:10» для Report2 . Поскольку значение поля scheduled_report_time усекается до часа, оба отчета имеют 1708376890 (закодированное значение для «19 февраля 2024 г., 21:00») в качестве значения поля scheduled_report_time .
Поскольку все остальные поля и идентификатор фильтрации одинаковы, оба отчета имеют один и тот же общий идентификатор. А поскольку оба отчета имеют один и тот же общий идентификатор, они оба должны быть включены в один и тот же пакет.
Если отчет 1 был помещен в ранее успешный пакет, а отчет 2 обрабатывается в последующем пакете, пакет с отчетом 2 завершится сбоем с ошибкой PRIVACY_BUDGET_EXHAUSTED . В этом случае удалите отчеты с общим идентификатором, которые были успешно объединены в предыдущие пакеты, и повторите попытку. Дополнительные сведения об этой ошибке см. в разделе Коды ошибок и способы их устранения для службы агрегации .
Предварительно объявленные ключи агрегации
Когда вы отправляете пакет в службу агрегации, он должен включать как агрегируемые отчеты, полученные от источника отчетов, так и выходной файл домена. Выходной домен содержит ключи или сегменты, полученные из агрегированных отчетов.
С точки зрения конфиденциальности ко всем ключам, заранее объявленным в выходном домене, добавляется шум, даже если ни один реальный отчет не соответствует конкретному ключу. Указание выходного домена защищает от атаки, при которой наличие ключа в выходных данных раскрывает что-то об отдельном пользователе или событии. Например, если вы показали кампанию только одному пользователю, получение ключа в выходных данных покажет, что пользователь позже совершил конверсию, даже с добавлением шума. Указав этот домен первым, вы можете быть уверены, что он ничего не расскажет о вкладе пользователей.
Вы можете объявить эти 128-битные ключи либо в API отчетов об атрибуции , либо в API частной агрегации и использовать их для кодирования измерений, которые вы хотите отслеживать.
Только предварительно объявленные ключи рассматриваются для агрегирования и включаются в сводный отчет. К агрегированным значениям сегментов сводного отчета добавляется статистический шум, который отражается в созданном сводном отчете.
Если ключ агрегирования включен в выходной файл домена, но не находится в пакетном отчете, даже если агрегированное значение равно нулю, окончательный сводный отчет, скорее всего, будет ненулевым из-за добавленного шума для сохранения конфиденциальности.