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