다음은 이벤트 및 잠재고객 업로드의 상태를 확인하고 데이터 문제를 식별하는 데 권장되는 워크플로입니다.
각 요청의 전반적인 상태를 확인합니다. 요청이 성공하면
Status가code와(과) 같고0(enum 값OK, HTTP 응답200 OK)이며IngestEventsResponse,IngestAudienceMembersResponse또는RemoveAudienceMembersResponse를 반환합니다.요청이 성공하지 못하면 오류를 해결하도록 요청을 수정하고 요청을 다시 전송합니다.
요청이 성공하면 다음 단계에서 진단 정보를 가져오는 데 사용할 수 있도록 응답의
request_id를 캡처합니다.validate_onlytrue30분 정도 기다린 후 성공한 각
request_id에 대해RetrieveRequestStatus요청을 전송합니다.각 대상의 대상 상태가
SUCCESS,PARTIAL_SUCCESS또는FAILURE에 도달할 때까지 각request_id에 대해 이 단계를 주기적으로 반복합니다. 지수 백오프 알고리즘을 사용하여 각 요청 사이에 대기합니다.각
RetrieveRequestStatusResponse를 검토하여 업로드가 제대로 작동하는지 확인하고 데이터 문제를 식별합니다.데이터 문제를 수정합니다.
1단계로 돌아가 업로드와 관련된 모든 문제를 해결할 때까지 반복합니다.
요청 보내기
A RetrieveRequestStatusRequest에는 단일
request_id 값이 필요합니다. 성공한 수집 요청에서 캡처한 각 요청 ID에 대해 별도의 상태 요청을 전송합니다.
원래
요청의 모든 대상에 대해 request_status가
SUCCESS, FAILURE, 또는 PARTIAL_SUCCESS에 도달할 때까지 지수 백오프 알고리즘을 사용하여 RetrieveRequestStatusRequest
를 주기적으로 전송합니다. 데이터 관리자 API가 일부 요청을 30분 이내에 처리할 수 있지만 최대 24시간이 걸릴 수 있습니다.
다음은 활성 상태와 할당량 사용량의 균형을 맞추는 적절한 초기 대기 시간 및 재시도 구성의 예입니다.
| 설정 | 값 |
|---|---|
| 첫 번째 진단 요청 전 대기 시간 (분) | 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' 문제를 방지하기 위해 백오프 지연에 작은 임의의 지터를 추가합니다.
대답 검토
request_status_per_destination의
RetrieveRequestStatusResponse에는 해당 수집 요청의 각 대상에 대한 별도의 항목이 포함됩니다.
예를 들어 IngestAudienceMembersRequest
에 3개의 다른
잠재고객에 데이터를 전송하기 위한 destinations 목록에 3개의 항목이 포함되어 있는 경우 상태 응답에는
request_status_per_destination에 3개의 항목 (잠재고객당 1개의 항목)이 포함됩니다.
전반적인 대상 상태 확인
첫 번째 단계로 request_status 필드를 확인하여 Data Manager API가 destination의 RequestStatusPerDestination에 대한 데이터 처리를 완료했는지 확인합니다.
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_status수신된 총 레코드 수가 예상과 일치하는지 확인하려면
IngestUserDataStatus의record_count를 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.user_identifier_count를 확인하여 수신된 사용자 식별자 수가 예상과 일치하는지 확인합니다.요청에 충분한 수의 레코드가 있는 경우
upload_match_rate_range에는 요청의 레코드에 대한 일치율 범위가 포함됩니다.mobile_data_ingestion_statusrecord_count의IngestMobileDataStatus를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.mobile_id_count를 확인하여 수신된 모바일 ID 수가 예상과 일치하는지 확인합니다.pair_data_ingestion_status수신된 총 레코드 수가 예상과 일치하는지 확인하려면
IngestPairDataStatus의record_count을 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.pair_id_count를 확인하여 수신된 PAIR ID 수가 예상과 일치하는지 확인합니다.ppid_data_ingestion_statusrecord_count의IngestPpidDataStatus를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.ppid_count를 확인하여 수신된 PPID 수가 예상과 일치하는지 확인합니다.user_id_data_ingestion_status수신된 총 레코드 수가 예상과 일치하는지 확인하려면
IngestUserIdDataStatus의record_count을 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.user_id_count를 확인하여 수신된 사용자 ID 수가 예상과 일치하는지 확인합니다.composite_data_ingestion_statusrecord_count의IngestCompositeDataStatus를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.data_type_counts를 확인하여 식별자 수가 예상과 일치하는지 확인합니다. 이 목록은 수신된 모든 식별자 (예: 이메일 주소, 전화번호, 실제 주소, IP 주소)를DataType별로 분류하여 제공합니다.요청에 충분한 수의 레코드가 있는 경우
upload_match_rate_range에는 요청의 레코드에 대한 일치율 범위가 포함됩니다.
잠재고객 구성원 삭제 상태
요청이
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 데이터 삭제 상태
composite_data_removal_status- 복합 데이터
record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다. record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.
또한 user_identifier_count, mobile_id_count, pair_id_count, ppid_count 또는 user_id_count를 확인하여 수신된 총 식별자 수를 확인합니다.
복합 데이터의 경우 data_type_counts를 확인하여 식별자 수가 예상과 일치하는지 확인합니다. 이 목록은 수신된 모든
식별자 (예: 이메일 주소, 전화번호, 실제 주소, IP 주소)를 DataType별로 분류하여 제공합니다.
경고 및 오류 확인
대상 및 요청 유형의 상태 필드 외에도
RetrieveRequestStatusResponse에는 요청의
경고 및 오류 분류가 포함됩니다.
- 오류는 API가 레코드를 완전히 거부했음을 나타냅니다.
- 경고는 API가 레코드를 거부하지 않았지만 레코드 데이터의 일부를 무시해야 했음을 나타냅니다.
예를 들어 Event에 암호화된
UserIdentifier 데이터와
AdIdentifiers (예: gclid)가 포함되어 있고
UserIdentifier 데이터를 복호화할 수 없는 경우 Data Manager API는
레코드를 계속 처리하지만
PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR 경고를 반환합니다.AdIdentifiers
그러나 Event에 AdIdentifiers가 포함되어 있지 않고 UserIdentifier 데이터를 복호화할 수 없는 경우 Data Manager API는 전체 레코드를 거부하고 PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR 오류를 보고합니다. 유효한 Event에는 ad_identifiers 또는 user_data 중 하나 이상이 있어야 하기 때문입니다.
다음은 경고 및 오류 정보가 포함된 응답 필드입니다. 이러한
필드는 전반적인 대상 상태
가 SUCCESS, PARTIAL_SUCCESS, 또는 FAILURE에 도달하면 채워집니다.
warning_infoWarningCount객체 목록입니다. 각WarningCount에는 경고 유형이 포함된reason과 해당 유형의 경고가 있는 레코드 수를 나타내는record_count가 포함됩니다.error_infoErrorCount객체 목록입니다. 각ErrorCount에는 오류 유형이 포함된reason과 해당 유형의 오류로 인해 실패한 레코드 수를 나타내는record_count가 포함됩니다.