При пакетной обработке агрегированных отчетов важно оптимизировать стратегии пакетной обработки, чтобы не были превышены ограничения конфиденциальности. Ниже приведены несколько рекомендуемых стратегий отправки пакетов отчетов в службу агрегирования.
Собирайте отчеты
При сборе отчетов для включения в пакет имейте в виду следующее:
Отчет о повторных попытках загрузки
Примечание. Критерии повторной попытки могут быть изменены. В этом случае информация в этом разделе будет обновляться.
Как на веб-платформе, так и на операционной системе платформа попытается отправить отчет три раза, но если отчет не удастся отправить после третьей попытки, он не будет отправлен. Исходное значение 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 не разрешен и завершается с ошибкой.
Пакетные отчеты
Ниже приведены рекомендуемые способы пакетной обработки отчетов, чтобы избежать дублирования и оптимизировать учет совокупных отчетов.
Пакет по рекламодателю
Примечание. Эту стратегию рекомендуется использовать только для агрегирования отчетов об атрибуции.
Частное агрегирование не имеет поля attribution_destination , которое указывает рекламодателя. Рекомендуется группировать по рекламодателям, то есть включать отчеты, принадлежащие одному рекламодателю, в один и тот же пакет, чтобы избежать превышения лимита учетной записи агрегированного отчета для каждого пакета. Рекламодатель — это поле, которое учитывается при создании общего идентификатора, поэтому отчеты с одним и тем же рекламодателем могут также иметь один и тот же общий идентификатор, что потребует их включения в один пакет во избежание ошибок.
Пакет по времени
При пакетной обработке рекомендуется учитывать запланированное время отчета ( shared_info.scheduled_report_time ). Запланированное время отчета усекается до часа при создании общего идентификатора, поэтому отчеты должны группироваться как минимум с часовыми интервалами. Это означает, что все отчеты с запланированным временем отчета в течение одного и того же часа должны идти в одном пакете, чтобы избежать создания отчетов с одинаковыми общими Идентификатор в нескольких пакетах, что приведет к ошибкам в задании.
Частота пакетов и шум
Рекомендуется учитывать влияние шума на частоту обработки агрегированных отчетов. Если агрегированные отчеты группируются чаще, например, отчеты обрабатываются после того, как в них будут включены события конверсии, требующие меньшего количества часов, и шум будет иметь большее относительное влияние. Если частоту уменьшить и отчеты обрабатываются раз в неделю, относительное влияние шума будет меньшим. Чтобы лучше понять влияние шума на пакеты, поэкспериментируйте с Noise Lab .