다음은 이벤트 및 잠재고객 업로드의 상태를 확인하고 데이터 문제를 식별하는 데 권장되는 워크플로입니다.
이벤트를 전송하거나 공유 대상 그룹 구성원을 전송 또는 삭제하는 요청을 실행합니다.
각 요청의 전체 상태를 확인합니다. 성공한 요청에는
code가0(열거형 값OK, HTTP 응답200 OK)과 같은Status이 있으며IngestEventsResponse,IngestAudienceMembersResponse또는RemoveAudienceMembersResponse를 반환합니다.요청이 성공하지 못하면 오류를 해결하도록 요청을 수정하고 요청을 다시 전송하세요.
요청이 성공하면 다음 단계에서 진단 프로그램을 검색하는 데 사용할 수 있도록 응답의
request_id를 캡처합니다.30분 동안 기다린 후 성공한 각
request_id에 대해RetrieveRequestStatus요청을 보냅니다.각 대상의 대상 상태가
SUCCESS,PARTIAL_SUCCESS또는FAILURE에 도달할 때까지 각request_id에 대해 이 단계를 주기적으로 반복합니다. 지수 백오프 알고리즘을 사용하여 각 요청 사이에 대기합니다.각
RetrieveRequestStatusResponse를 검토하여 업로드가 제대로 작동하는지 확인하고 데이터 문제를 파악합니다.데이터 문제를 수정합니다.
1단계로 돌아가 업로드와 관련된 모든 문제를 해결할 때까지 반복합니다.
요청 보내기
RetrieveRequestStatusRequest에는 단일 request_id 값이 필요합니다. 성공적인 인제스트 요청에서 캡처한 각 요청 ID에 대해 별도의 상태 요청을 보냅니다.
원래 요청의 모든 대상에 대해 request_status가 SUCCESS, FAILURE 또는 PARTIAL_SUCCESS에 도달할 때까지 지수 백오프 알고리즘을 사용하여 RetrieveRequestStatusRequest를 주기적으로 전송합니다. 최대 24시간이 걸릴 수 있지만 Data Manager API는 일부 요청을 30분 만에 처리할 수 있습니다.
다음은 활성 상태와 할당량 사용량의 균형을 맞추는 적절한 초기 대기 시간과 재시도 구성의 예입니다.
| 설정 | 값 |
|---|---|
| 첫 번째 진단 요청 전 대기 시간 (분) | 30 |
| 백오프 승수 | 1.3 |
| 최대 백오프 (분) | 60 (1시간) |
| 최대 총 시간 (분) | 1440 (24시간) |
이 구성을 사용한 요청과 경과 시간은 다음과 같습니다.
그래프
데이터
| 시도 | 수집 요청 후 경과 시간 (hh:mm) | 시도 전 지연 | 참고 |
|---|---|---|---|
| 1 | 00:30 | 30.0분 | 먼저 상태 사용 가능 여부를 확인합니다. |
| 2 | 01:09 | 39.0분 | |
| 3 | 01:59 | 50.7분 | |
| 4 | 02:59 | 60.0분 | 이제 지연 시간이 1시간으로 제한됨 |
| 5 | 03:59 | 60.0분 | |
| 6 | 04:59 | 60.0분 | |
| 7 | 05:59 | 60.0분 | |
| 8 | 06:59 | 60.0분 | |
| 9 | 07:59 | 60.0분 | |
| 10 | 08:59 | 60.0분 | |
| 11 | 09:59 | 60.0분 | |
| 12 | 10:59 | 60.0분 | |
| 13 | 11:59 | 60.0분 | 12시간 표시 |
| 14 | 12:59 | 60.0분 | |
| 15 | 13:59 | 60.0분 | |
| 16 | 14:59 | 60.0분 | |
| 17 | 15:59 | 60.0분 | |
| 18 | 16:59 | 60.0분 | |
| 19 | 17:59 | 60.0분 | |
| 20 | 18:59 | 60.0분 | |
| 21 | 19:59 | 60.0분 | |
| 22 | 20:59 | 60.0분 | |
| 23 | 21:59 | 60.0분 | |
| 24 | 22:59 | 60.0분 | |
| 25 | 23:59 | 60.0분 | 24시간 최대 총 시간 전 마지막 요청 |
많은 클라이언트가 동시에 재시도하는 'thundering herd' 문제를 방지하기 위해 백오프 지연에 작은 임의의 지터를 추가합니다.
대답 검토
RetrieveRequestStatusResponse의 request_status_per_destination에는 해당 수집 요청의 각 대상에 대한 별도의 항목이 포함됩니다.
예를 들어 IngestAudienceMembersRequest에 3개의 항목이 포함되어 3개의 서로 다른 잠재고객에게 데이터를 전송하는 경우 상태 응답에는 request_status_per_destination에 3개의 항목이 포함됩니다 (잠재고객당 항목 하나).destinations
전반적인 대상 상태 확인
첫 번째 단계로 request_status 필드를 확인하여 Data Manager API가 RequestStatusPerDestination의 destination 데이터를 처리했는지 확인합니다.
request_status의 가능한 값은 다음과 같습니다.
PROCESSING: 대상의 데이터가 아직 처리 중입니다. 이 단계에서는 대상에 경고 및 오류가 채워지지 않습니다.SUCCESS: 대상의 요청 처리가 오류 없이 완료되었습니다. 처리 중에 표시된 경고를 확인합니다.FAILURE: 오류로 인해 대상의 모든 레코드가 실패했습니다. 경고 및 오류를 확인하여 모든 레코드가 실패한 이유를 파악합니다. 처리 중에 표시된 경고도 확인합니다.PARTIAL_SUCCESS: 대상의 일부 레코드는 성공했지만 오류로 인해 다른 레코드는 실패했습니다. 오류를 확인하여 일부 레코드가 실패한 이유를 파악합니다. 처리 중에 플래그가 지정된 경고도 확인합니다.
대상별 이벤트 또는 잠재고객 상태 확인
수집 요청 유형에 해당하는 상태 필드를 검사합니다. 각 RequestStatusPerDestination에는 다음 필드 중 하나만 설정됩니다.
이벤트 수집 상태
요청이 IngestEventsRequest인 경우 events_ingestion_status 필드가 채워집니다.
IngestEventStatus의 record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다. record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.
잠재고객 구성원 수집 상태
요청이 IngestAudienceMembersRequest인 경우 audience_members_ingestion_status 필드가 채워집니다. 다음은 각 유형의 잠재고객 데이터를 확인할 수 있는 IngestAudienceMembersStatus 필드입니다. 이 필드 중 하나만 설정됩니다.
user_data_ingestion_statusIngestUserDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.user_identifier_count를 확인하여 수신된 사용자 식별자 수가 예상과 일치하는지 확인합니다.요청에 충분한 수의 레코드가 있는 경우
upload_match_rate_range에는 요청의 레코드에 대한 일치율 범위가 포함됩니다.mobile_data_ingestion_statusIngestMobileDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.mobile_id_count를 확인하여 수신된 모바일 ID 수가 예상과 일치하는지 확인합니다.pair_data_ingestion_statusIngestPairDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.pair_id_count를 확인하여 수신된 PAIR ID 수가 예상과 일치하는지 확인합니다.ppid_data_ingestion_statusIngestPpidDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.ppid_count를 확인하여 수신된 PPID 수가 예상과 일치하는지 확인합니다.user_id_data_ingestion_statusIngestUserIdDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.user_id_count를 확인하여 수신된 사용자 ID 수가 예상과 일치하는지 확인합니다.
잠재고객 구성원 삭제 상태
요청이 RemoveAudienceMembersRequest인 경우 audience_members_removal_status 필드가 채워집니다. 각 유형의 잠재고객 데이터를 확인할 수 있는 RemoveAudienceMembersStatus 필드는 다음과 같습니다. 이 필드 중 하나만 설정됩니다.
user_data_removal_status- 사용자 데이터의 삭제 상태입니다.
mobile_data_removal_status- 모바일 데이터의 삭제 상태입니다.
pair_data_removal_status- PAIR 데이터의 삭제 상태입니다.
ppid_data_removal_status- PPID 데이터의 삭제 상태입니다.
user_id_data_removal_status- 사용자 ID 데이터의 삭제 상태
record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다. record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.
또한 user_identifier_count, mobile_id_count 또는 pair_id_count를 확인하여 수신된 사용자 식별자, 모바일 ID 또는 PAIR ID의 총 개수를 확인합니다.
경고 및 오류 확인
대상 및 요청 유형의 상태 필드 외에도 RetrieveRequestStatusResponse에는 요청의 경고 및 오류 분류가 포함됩니다.
- 오류는 API가 레코드를 완전히 거부했음을 나타냅니다.
- 경고는 API가 레코드를 거부하지는 않았지만 레코드 데이터의 일부를 무시해야 했음을 나타냅니다.
예를 들어 Google Ads 오프라인 전환의 Event에 암호화된 UserIdentifier 데이터와 AdIdentifiers(예: gclid)이 포함되어 있고 UserIdentifier 데이터를 복호화할 수 없는 경우 Data Manager API는 여전히 AdIdentifiers를 사용하여 레코드를 처리하지만 PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR 경고를 반환합니다.
하지만 Event에 AdIdentifiers이 포함되지 않고 UserIdentifier 데이터를 복호화할 수 없는 경우 유효한 Google Ads 오프라인 전환 Event에는 ad_identifiers 또는 user_data 중 하나 이상이 있어야 하므로 Data Manager API는 전체 레코드를 거부하고 PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR 오류를 보고합니다.
다음은 경고 및 오류 정보가 포함된 응답 필드입니다. 이러한 필드는 전체 대상 상태가 SUCCESS, PARTIAL_SUCCESS 또는 FAILURE에 도달하면 채워집니다.
warning_infoWarningCount객체 목록입니다. 각WarningCount에는 경고 유형이 포함된reason과 해당 유형의 경고가 있는 레코드 수를 나타내는record_count이 포함됩니다.전체 대상 상태가
SUCCESS인 경우에도warning_info를 확인합니다.error_infoErrorCount객체 목록입니다. 각ErrorCount에는 오류 유형이 포함된reason와 해당 오류 유형으로 인해 실패한 레코드 수를 나타내는record_count가 포함됩니다.