집계 가능한 보고서를 일괄 처리할 때는 개인 정보 보호 한도가 초과되지 않도록 일괄 처리 전략을 최적화하는 것이 중요합니다. 다음은 집계 서비스에 보고서 일괄 전송을 위한 몇 가지 권장 전략입니다.
신고 수집
일괄 처리에 포함할 보고서를 수집할 때는 다음 사항에 유의하세요.
보고서 업로드 재시도
참고: 재시도 기준은 변경될 수 있습니다. 이 경우 이 섹션의 정보가 업데이트됩니다.
웹 및 OS 플랫폼 모두에서 플랫폼은 보고서를 세 번 전송하려고 시도하지만 세 번째 시도 후에도 보고서가 전송되지 않으면 전송되지 않습니다. 보고서를 보낼 수 있는 시점에 관계없이 원래 scheduled_report_time 값은 보존됩니다. 재시도 타임라인은 플랫폼마다 다릅니다.
- 웹브라우저는 브라우저가 온라인 상태일 때 보고서를 전송합니다. 보고서를 전송할 수 없는 경우 두 번째 재시도까지 5분, 세 번째 재시도까지 15분을 기다립니다. 브라우저가 오프라인 상태가 되면 다시 온라인 상태가 된 후 1분 후에 다음 재시도가 이루어집니다. 웹에서 보고서를 전송할 때는 최대 지연 시간이 없습니다. 즉, 브라우저가 오프라인 상태가 되었다가 다시 온라인 상태가 되면 보고서가 생성된 지 얼마나 지났든지 다시 시도 정책에 따라 보고서를 전송하려고 시도합니다.
- Android 휴대전화가 일관된 네트워크에 연결되어 있습니다. 따라서 보고서를 전송하는 작업이 시간당 한 번 실행됩니다. 즉, 보고서 전송에 실패하면 다음 시간에 다시 시도되고 그 후 1시간 후에 다시 시도됩니다. 기기가 연결되어 있지 않으면 기기가 네트워크에 다시 연결된 후 실행되는 다음 보고 작업으로 보고서 전송을 다시 시도합니다. 최대 지연은 28일이며, 이는 기기가 28일 전에 생성된 보고서를 전송하지 않는다는 의미입니다.
신고 대기 중
일괄 처리를 위해 보고서를 수집할 때는 지연된 보고서가 도착할 때까지 기다리는 것이 좋습니다. 지연된 신고는 scheduled_report_time 값을 신고가 접수된 시점과 비교하여 확인할 수 있습니다. 이러한 보고서 간의 시간 차이는 지연된 보고서를 기다릴 시간을 결정하는 데 도움이 됩니다. 예를 들어 지연된 신고가 수집되면 scheduled_report_time 필드를 확인하고 신고의 90%, 95%, 99% 가 수신된 시간 지연을 시간으로 기록합니다. 이 데이터를 사용하여 지연된 보고서를 기다릴 시간을 결정할 수 있습니다.
즉시 집계 보고서를 사용하면 보고서 지연 가능성을 줄일 수 있습니다.
다음 시각화는 지연된 보고서가 예약된 보고서 시간에 따라 적절한 일괄 처리에 저장되는 것을 보여줍니다. 일괄 T는 scheduled_report_time를 나타내고 T+X는 지연된 보고서를 기다린 시간을 나타냅니다. 이렇게 하면 예약된 보고서 시간에 해당하는 일괄 처리에 포함된 대부분의 보고서가 포함된 요약 보고서가 생성됩니다.
집계 가능한 보고서 회계
집계 서비스는 '중복 없음' 규칙을 유지합니다. 이 규칙은 공유 ID가 동일한 모든 집계 가능한 보고서가 동일한 일괄 처리에 포함되어야 한다고 적용합니다.
보고서가 수집된 후에는 공유 ID가 동일한 모든 보고서가 하나의 일괄 처리에 포함되도록 일괄 처리해야 합니다.
보고서가 이미 다른 일괄 처리에서 처리된 경우 처리 시 개인 정보 보호 예산 소진 오류가 발생할 수 있습니다. 보고서를 올바르게 일괄 처리하면 '중복 없음' 규칙으로 인해 일괄 항목이 거부되는 것을 방지할 수 있습니다.
공유 ID는 집계 가능한 보고서 회계를 추적하기 위해 각 보고서에 대해 생성되는 키입니다. 공유 ID를 사용하면 공유 ID가 동일한 보고서가 하나의 요약 보고서에만 기여하도록 할 수 있습니다. 즉, 하나의 공유 ID에 매핑되는 보고서는 모두 단일 일괄 처리에 포함되어야 합니다. 예를 들어 보고서 X와 보고서 Y의 공유 ID가 모두 동일한 경우 중복으로 인해 보고서가 삭제되지 않도록 동일한 일괄 처리에 포함해야 합니다.
다음 이미지는 공유 ID를 생성하기 위해 함께 해싱되는 shared_info 구성요소를 보여줍니다.
다음 이미지는 두 개의 서로 다른 보고서에 동일한 공유 ID가 있을 수 있는 방법을 보여줍니다.
참고: scheduled_report_time는 시간 단위로 자르고 source_registration_time는 일 단위로 자릅니다. 또한 report_id는 공유 ID 생성 시 사용되지 않습니다. 시간 세부사항은 향후 업데이트될 수 있습니다.
일괄 처리 내 중복 보고서
집계 가능한 보고서의 shared_info 필드에는 일괄 처리 내 중복 신고를 식별하는 데 사용되는 UUID가 report_id 필드에 포함되어 있습니다. 일괄 처리에 동일한 report_id가 있는 보고서가 두 개 이상 있는 경우 첫 번째 보고서만 집계되고 나머지는 중복으로 간주되어 자동으로 삭제됩니다. 집계는 정상적으로 진행되며 오류가 전송되지 않습니다.
필수는 아니지만 광고 기술은 집계하기 전에 동일한 보고서 ID를 가진 중복 보고서를 필터링하여 실적을 개선할 수 있습니다.
report_id는 보고서마다 고유합니다.
여러 일괄 처리에서 중복된 보고서
각 보고서에는 공유 ID가 할당됩니다. 공유 ID는 보고서의 shared_info 필드에서 가져온 결합된 데이터 포인트에서 생성된 ID입니다. 여러 보고서에 동일한 공유 ID가 있을 수 있으며 각 일괄 처리에는 여러 공유 ID가 포함될 수 있습니다. 공유 ID가 동일한 모든 보고서는 동일한 일괄 처리에 포함되어야 합니다. 공유 ID가 동일한 보고서가 여러 일괄 처리에 포함되는 경우 첫 번째 일괄 처리만 수락되고 나머지는 중복으로 거부됩니다. 이를 방지하려면 일괄 처리를 적절하게 만들어야 합니다.
다음 이미지는 여러 배치에서 공유 ID가 동일한 보고서로 인해 이후 배치가 실패할 수 있는 예를 보여줍니다. 이미지에서 공유 ID e679aa가 동일한 보고서 2개 이상이 서로 다른 일괄 처리 #1 및 #2로 일괄 처리된 것을 볼 수 있습니다. 공유 ID e679aa가 있는 모든 보고서의 예산은 일괄 처리 1의 요약 보고서 생성 중에 소진되므로 일괄 처리 2는 허용되지 않고 오류가 발생하여 실패합니다.
일괄 보고서
다음은 중복을 방지하고 집계 보고서 회계를 최적화하기 위해 보고서를 일괄 처리하는 권장 방법입니다.
광고주별 일괄 처리
참고: 이 전략은 기여 분석 보고서 집계에만 권장됩니다.
비공개 집계에는 광고주인 attribution_destination 필드가 없습니다. 각 배치의 집계 가능한 보고서 계정 한도가 초과되지 않도록 하려면 광고주별로 일괄 처리하는 것이 좋습니다. 즉, 단일 광고주에 속한 보고서를 동일한 배치에 포함합니다. 광고주는 공유 ID 생성 시 고려되는 필드이므로 동일한 광고주가 있는 보고서에는 동일한 공유 ID가 있을 수 있습니다. 따라서 오류를 방지하려면 동일한 일괄 처리에 포함되어야 합니다.
시간별 일괄 처리
일괄 처리할 때는 보고서의 예약된 보고서 시간(shared_info.scheduled_report_time)을 고려하는 것이 좋습니다. 예약된 보고서 시간은 공유 ID 생성 시 시간으로 잘리므로 최소한 보고서는 시간 간격으로 일괄 처리되어야 합니다. 즉, 동일한 시간 내에 예약된 보고서 시간이 있는 모든 보고서가 동일한 일괄 처리에 포함되어야 합니다. 그렇지 않으면 여러 일괄 처리에 동일한 공유 ID가 있는 보고서가 포함되어 작업 오류가 발생합니다.
일괄 처리 빈도 및 노이즈
집계 가능한 보고서가 처리되는 빈도에 미치는 노이즈의 영향을 고려하는 것이 좋습니다. 집계 가능한 보고서가 더 자주 일괄 처리되는 경우(예: 보고서가 1시간에 한 번 처리됨) 전환 이벤트가 더 적게 포함되고 노이즈가 상대적으로 더 큰 영향을 미칩니다. 빈도를 줄이고 보고서를 일주일에 한 번 처리하면 노이즈의 상대적 영향이 줄어듭니다. 노이즈가 일괄 처리에 미치는 영향을 더 잘 이해하려면 노이즈 실험실을 실험해 보세요.