При пакетировании агрегируемых отчетов важно оптимизировать стратегии пакетирования, чтобы не превышать пределы конфиденциальности. Ниже приведены несколько рекомендуемых стратегий для отправки пакетов отчетов в Aggregation Service.
Собирать отчеты
При сборе отчетов для включения в пакет помните следующее:
Отчет о повторных попытках загрузки
Примечание: Критерии повтора могут быть изменены. Информация в этом разделе будет обновлена в этом случае.
На обеих платформах, веб и ОС, платформа попытается отправить отчет три раза, но если отчет не будет отправлен после третьей попытки, он не будет отправлен. Исходное значение scheduled_report_time сохраняется независимо от того, когда отчет может быть отправлен. Временная шкала для повторных попыток отличается для каждой платформы:
- Веб-браузер отправляет отчеты, когда браузер находится в сети. Если отчет не отправляется, он будет ждать пять минут для второй попытки, а затем 15 минут для третьей. Если браузер переходит в автономный режим, следующая попытка будет через одну минуту после того, как он снова появится в сети. Максимальная задержка отправки отчетов в сети отсутствует; это означает, что если браузер переходит в автономный режим, независимо от того, как давно был сгенерирован отчет, как только браузер снова появится в сети, он попытается отправить отчет в соответствии с политикой повторных попыток.
- Телефон Android имеет постоянное сетевое подключение. Таким образом, он будет запускать задание по отправке отчетов один раз в час. Это означает, что если отчет не будет отправлен, он будет отправлен повторно в следующий час, а затем еще через час. Если у устройства нет подключения, устройство попытается отправить отчет повторно с помощью следующего задания по отправке отчетов, которое запустится после того, как устройство снова подключится к сети. Максимальная задержка составляет 28 дней, что означает, что устройство не отправит отчет, который был создан более 28 дней назад.
Ждать отчетов
Рекомендуется дождаться поздних отчетов при сборе отчетов для пакетирования. Просроченные отчеты можно определить, сверив значение scheduled_report_time с временем получения отчета. Разница во времени между этими отчетами поможет определить, как долго вы можете ожидать поздние отчеты. Например, по мере сбора поздних отчетов проверьте поле scheduled_report_time и отметьте задержку в часах, как 90%, 95% и 99% отчетов получены. Эти данные можно использовать для определения того, как долго ждать поздние отчеты. Мгновенные агрегированные отчеты можно использовать для снижения вероятности поздних отчетов.
На следующем рисунке показаны отчеты, поступившие с опозданием и сохраненные в соответствующих пакетах в соответствии с запланированным временем отчета. Пакет T представляет scheduled_report_time , а T+X представляет время ожидания отложенных отчетов. Это приводит к сводному отчету, который включает большинство отчетов, включенных в пакет, который соответствует их запланированному времени отчета.
Агрегированный отчетный учет
Служба агрегации поддерживает правило «никаких дубликатов» . Это правило требует, чтобы все агрегируемые отчеты с одинаковым общим идентификатором были включены в один и тот же пакет.
После сбора отчетов их следует объединить в пакет таким образом, чтобы все отчеты с одинаковым общим идентификатором были частью одного пакета.
Если отчет уже был обработан в другом пакете, обработка может привести к ошибке исчерпания бюджета конфиденциальности . Правильная пакетная обработка отчетов помогает предотвратить отклонение пакетов из-за правила «без дубликатов».
Общий идентификатор — это ключ, который генерируется для каждого отчета для отслеживания агрегируемого учета отчетов. Общий идентификатор гарантирует, что отчеты с одним и тем же общим идентификатором будут вносить вклад только в один сводный отчет. Это означает, что отчеты, которые сопоставляются с одним общим идентификатором, должны быть включены в один пакет. Например, если отчет X и отчет Y имеют один и тот же общий идентификатор, они должны быть включены в один пакет, чтобы избежать отбрасывания отчетов из-за дублирования.
На следующем изображении показаны компоненты shared_info , которые хэшируются вместе для генерации общего идентификатора.
На следующем рисунке показано, как два разных отчета могут иметь один и тот же общий идентификатор:
Примечание: scheduled_report_time усекается по часам, а source_registration_time усекается по дням. Кроме того, report_id не используется при создании общего идентификатора. Детализация времени может быть обновлена в будущем.
Дублирование отчетов в пакетах
Поле shared_info в агрегируемом отчете содержит UUID в поле report_id , которое используется для идентификации дубликатов отчетов в пакете. Если в пакете есть более одного отчета с одинаковым report_id , будет агрегирован только первый отчет, а остальные будут считаться дубликатами и молча отброшены; агрегация будет проходить в обычном режиме, и никаких ошибок не будет отправлено. Хотя это и не обязательно, рекламные технологии могут ожидать некоторого прироста производительности, отфильтровывая дубликаты отчетов с одинаковыми идентификаторами отчетов перед агрегацией.
report_id уникален для каждого отчета.
Дублирующиеся отчеты в разных партиях
Каждому отчету назначается общий идентификатор, который является идентификатором, сгенерированным из объединенных точек данных, которые берутся из поля shared_info отчета. Несколько отчетов могут иметь один и тот же общий идентификатор, и каждый пакет может содержать несколько общих идентификаторов. Все отчеты с одним и тем же общим идентификатором должны быть в одном пакете. Если отчеты с одним и тем же общим идентификатором попадают в несколько пакетов, будет принят только первый пакет, а остальные будут отклонены как дубликаты. Чтобы предотвратить это, пакеты должны быть созданы соответствующим образом .
На следующем изображении показан пример, когда отчеты с одинаковым общим идентификатором в разных пакетах могут привести к сбою более позднего пакета. На изображении вы можете видеть, что два или более отчетов с одинаковым общим идентификатором e679aa объединены в разные пакеты № 1 и № 2. Поскольку бюджет для всех отчетов с общим идентификатором e679aa расходуется во время генерации сводного отчета пакета № 1, пакет № 2 не допускается и завершается ошибкой.
Пакетные отчеты
Ниже приведены рекомендуемые способы пакетной обработки отчетов, позволяющие избежать дублирования и оптимизировать учет сводных отчетов.
Пакет по рекламодателю
Примечание: эта стратегия рекомендуется только для агрегации отчетов об атрибуции.
В Private Aggregation нет поля attribution_destination , которое является рекламодателем. Рекомендуется пакетировать по рекламодателю, то есть включать отчеты, принадлежащие одному рекламодателю, в один и тот же пакет, чтобы избежать превышения лимита учетной записи агрегируемого отчета для каждого пакета. Рекламодатель — это поле, рассматриваемое при генерации общего идентификатора, поэтому отчеты с одним и тем же рекламодателем также могут иметь один и тот же общий идентификатор, что потребует их нахождения в одном пакете для избежания ошибок.
Партия по времени
Рекомендуется учитывать запланированное время отчета ( shared_info.scheduled_report_time ) при пакетировании. Время запланированного отчета усекается до часа при генерации общего идентификатора, поэтому отчеты должны быть пакетированы как минимум с часовыми интервалами, то есть все отчеты с запланированным временем отчета в пределах одного часа должны быть включены в один и тот же пакет, чтобы избежать отчетов с одинаковым общим идентификатором в нескольких пакетах, что приведет к ошибкам в работе.
Частота партии и шум
Рекомендуется учитывать влияние шума на частоту обработки агрегируемых отчетов. Если агрегируемые отчеты пакетируются чаще, например, отчеты обрабатываются раз в час, будет включено меньше событий конверсии, а шум будет иметь большее относительное влияние. Если частота уменьшается и отчеты обрабатываются раз в неделю, шум будет иметь меньшее относительное влияние. Чтобы лучше понять влияние шума на пакеты, поэкспериментируйте с Noise Lab .