집계 가능한 보고서를 일괄 처리할 때는 개인 정보 보호 한도를 초과하지 않도록 일괄 처리 전략을 최적화하는 것이 중요합니다. 다음은 집계 서비스에 보고서 배치를 전송할 때 권장되는 몇 가지 전략입니다.
보고서 수집
일괄 처리에 포함할 보고서를 수집할 때는 다음 사항에 유의하세요.
보고서 업로드 재시도
참고: 재시도 기준은 변경될 수 있습니다. 이 경우 이 섹션의 정보가 업데이트됩니다.
웹 및 OS 플랫폼 모두에서 플랫폼은 보고서를 세 번 전송하려고 시도하지만 세 번째 시도 후에도 보고서를 전송하지 못하면 전송되지 않습니다. 보고서를 언제 보낼 수 있는지와 관계없이 원래 scheduled_report_time 값이 유지됩니다. 재시도 타임라인은 플랫폼마다 다릅니다.
- 웹브라우저는 브라우저가 온라인 상태일 때 보고서를 전송합니다. 보고서 전송에 실패하면 두 번째 재시도를 위해 5분, 세 번째 재시도를 위해 15분을 기다립니다. 브라우저가 오프라인 상태가 되면 다음 재시도는 브라우저가 다시 온라인 상태가 된 후 1분 후에 이루어집니다. 웹에서 보고서를 전송하는 데는 최대 지연 시간이 없습니다. 즉, 브라우저가 오프라인 상태가 되면 보고서가 생성된 시점과 관계없이 브라우저가 다시 온라인 상태가 되면 재시도 정책에 따라 보고서를 전송하려고 시도합니다.
- Android 휴대전화의 네트워크 연결이 안정적입니다. 따라서 보고서를 전송하는 작업을 시간당 한 번 실행합니다. 즉, 보고서 전송에 실패하면 다음 시간에 다시 시도하고 그 다음 시간에도 다시 시도합니다. 기기가 연결되어 있지 않으면 기기는 기기가 네트워크에 다시 연결된 후 실행되는 다음 보고 작업으로 보고서를 다시 전송합니다. 최대 지연 시간은 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 필드에는 report_id 필드의 UUID가 포함되어 있으며, 이는 배치 내 중복 보고서를 식별하는 데 사용됩니다. 배치에 동일한 report_id가 있는 보고서가 두 개 이상 있으면 첫 번째 보고서만 집계되고 나머지는 중복으로 간주되어 자동으로 삭제됩니다. 집계는 정상적으로 진행되며 오류는 전송되지 않습니다.
필수는 아니지만 광고 기술은 집계 전에 동일한 보고서 ID가 있는 중복 보고서를 필터링하여 실적을 개선할 수 있습니다.
report_id은 각 보고서마다 고유합니다.
배치 간 중복 보고서
각 보고서에는 공유 ID가 할당됩니다. 공유 ID는 보고서의 shared_info 필드에서 가져온 결합된 데이터 포인트에서 생성된 ID입니다. 여러 보고서가 동일한 공유 ID를 가질 수 있으며 각 배치에는 여러 공유 ID가 포함될 수 있습니다. 공유 ID가 동일한 모든 보고서는 동일한 배치에 포함되어야 합니다. 동일한 공유 ID가 포함된 보고서가 여러 배치에 포함되는 경우 첫 번째 배치만 허용되고 나머지는 중복으로 거부됩니다. 이를 방지하려면 배치를 적절하게 만들어야 합니다.
다음 이미지는 배치 간에 공유 ID가 동일한 보고서로 인해 후속 배치가 실패할 수 있는 예를 보여줍니다. 이미지에서 동일한 공유 ID e679aa를 가진 두 개 이상의 보고서가 서로 다른 배치 #1과 #2로 일괄 처리되는 것을 확인할 수 있습니다. 공유 ID e679aa가 있는 모든 보고서의 예산은 배치 1 요약 보고서 생성 중에 사용되므로 배치 2는 허용되지 않으며 오류와 함께 실패합니다.
일괄 보고서
다음은 중복을 방지하고 집계 보고서 회계를 최적화하기 위해 보고서를 일괄 처리하는 권장 방법입니다.
광고주별 일괄처리
참고: 이 전략은 기여 분석 보고 집계에만 권장됩니다.
Private Aggregation에는 광고주인 attribution_destination 필드가 없습니다. 각 배치에 대해 집계 가능한 보고서 계정 한도에 도달하지 않도록 광고주별로 일괄처리하는 것이 좋습니다. 즉, 동일한 광고주에 속하는 보고서를 동일한 배치에 포함해야 합니다. 광고주는 공유 ID 생성 시 고려되는 필드이므로 동일한 광고주가 있는 보고서도 동일한 공유 ID를 가질 수 있으며, 오류를 방지하려면 동일한 일괄 처리에 있어야 합니다.
시간별 일괄 처리
일괄 처리할 때는 보고서의 예약된 보고서 시간(shared_info.scheduled_report_time)을 고려하는 것이 좋습니다. 공유 ID 생성에서 예약된 보고서 시간이 시간 단위로 잘리므로 최소한 보고서를 시간 간격으로 일괄 처리해야 합니다. 즉, 동일한 시간 내에 예약된 보고서 시간이 있는 모든 보고서는 여러 배치에 걸쳐 동일한 공유 ID가 있는 보고서가 발생하지 않도록 동일한 배치에 포함되어야 하며, 이는 작업 오류로 이어집니다.
배치 빈도 및 노이즈
집계 가능한 보고서가 처리되는 빈도에 대한 노이즈의 영향을 고려하는 것이 좋습니다. 집계 가능 보고서가 더 자주 일괄 처리되는 경우(예: 보고서가 한 시간에 한 번 처리됨) 포함되는 전환 이벤트 수가 적어지고 노이즈의 상대적 영향이 커집니다. 빈도가 감소하고 보고서가 일주일에 한 번 처리되면 노이즈의 상대적 영향이 줄어듭니다. 배치에 노이즈가 미치는 영향을 더 잘 이해하려면 노이즈 실험실을 사용해 보세요.