이벤트 및 잠재고객 업로드의 상태를 확인하고 데이터 문제를 식별하기 위한 권장 워크플로는 다음과 같습니다.
각 요청의 전반적인 상태를 확인합니다. 요청이 성공하면
Status의code가0(enum 값OK, HTTP 응답200 OK)와 같고IngestEventsResponse,IngestAudienceMembersResponse또는RemoveAudienceMembersResponse를 반환합니다.요청이 실패하면 요청을 수정하여 오류를 해결하고 요청을 다시 전송합니다.
요청이 성공하면 다음 단계에서 진단 프로그램을 가져오는 데 사용할 수 있도록 응답의
request_id를 캡처합니다.30분 동안 기다린 후 성공한 각
request_id에 대해RetrieveRequestStatus요청을 보냅니다.각 대상의 대상 상태가
SUCCESS,PARTIAL_SUCCESS또는FAILURE에 도달할 때까지 각request_id에 대해 이 단계를 주기적으로 반복합니다. 지수 백오프 알고리즘을 사용하여 각 요청 사이에 대기합니다.각
RetrieveRequestStatusResponse을 검토하여 업로드가 제대로 작동하는지 확인하고 데이터 문제를 파악합니다.데이터 문제를 수정합니다.
1단계로 돌아가 업로드 관련 문제를 모두 해결할 때까지 반복합니다.
요청 보내기
RetrieveRequestStatusRequest에는 단일 request_id 값이 필요합니다. 성공적인 처리 요청에서 캡처한 각 요청 ID에 대해 별도의 상태 요청을 전송합니다.
승인
RetrieveRequestStatusRequest는 대상 계정이나 요청 헤더를 허용하지 않습니다. 대신 Data Manager API는 request_id와 연결된 원래 수집 요청에서 대상을 식별하고 호출자가 각 Destination에서 operating_account에 액세스할 수 있는지 확인합니다.
요청 상태를 확인하려면 RetrieveRequestStatusRequest에 사용된 사용자 인증 정보가 원래 수집 요청의 각 대상 operating_account에 대해 다음 요구사항을 충족해야 합니다.
동일한 액세스 경로: 사용자 인증 정보는 원래 수집 요청에 지정된 정확히 동일한 액세스 경로를 사용하여 각
operating_account에 액세스할 수 있어야 합니다.예를 들어 Google Ads
operating_account의 수집 요청에서 상위 관리자 계정을login_account로 지정한 경우 사용자 인증 정보는 동일한 관리자 계정을 통해operating_account에 액세스할 수 있어야 합니다. 사용자 인증 정보와 연결된 Google 계정에 하위operating_account에 대한 직접 액세스 권한이 있더라도 해당 계정에 수집 중에 지정된login_account관리자 계정을 통한 액세스 권한이 없으면 요청이PERMISSION_DENIED오류와 함께 실패합니다.충분한 액세스 수준: 사용자 인증 정보와 연결된 Google 계정에
operating_account에 데이터를 수집할 수 있는 권한이 있는 액세스 수준 또는 역할이 있어야 합니다.예를 들어 Google Ads에서 Google 계정의 액세스 수준이 관리자 또는 일반이어야 합니다. 읽기 전용 액세스 수준이 있는 계정의 사용자 인증 정보가 포함된 요청은
PERMISSION_DENIED오류와 함께 실패합니다.
폴링 전략
원래 요청의 모든 대상에 대해 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의 destinations 목록에 3개의 항목이 포함되어 데이터를 3개의 다른 잠재고객에게 전송하는 경우 상태 응답의 request_status_per_destination에 3개의 항목이 포함됩니다 (잠재고객당 항목 1개).
전체 대상 상태 확인
첫 번째 단계로 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 필드는 다음과 같습니다. 이러한 필드 중 하나만 설정됩니다.
composite_data_ingestion_statusIngestCompositeDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.data_type_counts를 확인하여 식별자 수가 예상과 일치하는지 확인합니다. 이 목록은DataType에서 수신한 모든 식별자 (예: 이메일 주소, 전화번호, 실제 주소, IP 주소)의 세부정보를 제공합니다.요청에 충분한 수의 레코드가 있는 경우
upload_match_rate_range에는 요청의 레코드에 대한 일치율 범위가 포함됩니다.google_user_id_data_ingestion_statusIngestGoogleUserIdDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.google_user_id_count를 확인하여 수신된 Google 사용자 ID 수가 예상과 일치하는지 확인합니다.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 수가 예상과 일치하는지 확인합니다.partner_provided_id_data_ingestion_statusIngestPartnerProvidedIdDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.partner_provided_id_count를 확인하여 수신된 파트너 제공 ID 수가 예상과 일치하는지 확인합니다.ppid_data_ingestion_statusIngestPpidDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.ppid_count를 확인하여 수신된 PPID 수가 예상과 일치하는지 확인합니다.user_data_ingestion_statusIngestUserDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.user_identifier_count를 확인하여 수신된 사용자 식별자 수가 예상과 일치하는지 확인합니다.요청에 충분한 수의 레코드가 있는 경우
upload_match_rate_range에는 요청의 레코드에 대한 일치율 범위가 포함됩니다.user_id_data_ingestion_statusIngestUserIdDataStatus의record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다.record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.user_id_count를 확인하여 수신된 사용자 ID 수가 예상과 일치하는지 확인합니다.
잠재고객 구성원 삭제 상태
요청이 RemoveAudienceMembersRequest인 경우 audience_members_removal_status 필드가 채워집니다. 다음은 각 유형의 잠재고객 데이터를 확인할 수 있는 RemoveAudienceMembersStatus 필드입니다. 이러한 필드 중 하나만 설정됩니다.
composite_data_removal_status- 복합 데이터 삭제 상태
google_user_id_data_removal_status- Google 사용자 ID 데이터의 삭제 상태
mobile_data_removal_status- 모바일 데이터 삭제 상태
pair_data_removal_status- PAIR 데이터의 삭제 상태입니다.
partner_provided_id_data_removal_status- 파트너 제공 ID 데이터의 삭제 상태
ppid_data_removal_status- PPID 데이터의 삭제 상태입니다.
user_data_removal_status- 사용자 데이터의 삭제 상태입니다.
user_id_data_removal_status- 사용자 ID 데이터 삭제 상태
record_count를 확인하여 수신된 총 레코드 수가 예상과 일치하는지 확인합니다. record_count에는 성공한 레코드와 실패한 레코드가 모두 포함됩니다.
또한 user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count 또는 partner_provided_id_count를 확인하여 수신된 식별자의 총 개수를 확인합니다.
복합 데이터의 경우 data_type_counts를 확인하여 식별자 수가 예상과 일치하는지 확인합니다. 이 목록은 DataType에서 수신한 모든 식별자 (예: 이메일 주소, 전화번호, 실제 주소, IP 주소)의 세부정보를 제공합니다.
경고 및 오류 확인
대상 및 요청 유형의 상태 필드 외에도 RetrieveRequestStatusResponse에는 요청에 대한 경고 및 오류 분석이 포함됩니다.
- 오류는 API가 레코드를 완전히 거부했음을 나타냅니다.
- 경고는 API가 레코드를 거부하지 않았지만 레코드 데이터의 일부를 무시해야 했음을 나타냅니다.
예를 들어 Event에 암호화된 UserIdentifier 데이터와 gclid와 같은 AdIdentifiers가 포함되어 있고 UserIdentifier 데이터를 복호화할 수 없는 경우 Data Manager API는 여전히 AdIdentifiers를 사용하여 레코드를 처리하지만 PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR 경고를 반환합니다.
그러나 Event에 AdIdentifiers가 포함되어 있지 않고 UserIdentifier 데이터를 복호화할 수 없는 경우 Data Manager API는 전체 레코드를 거부하고 PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR 오류를 보고합니다. 유효한 Event에는 ad_identifiers 또는 user_data 중 하나 이상이 있어야 하기 때문입니다.
경고 및 오류 정보가 포함된 응답 필드는 다음과 같습니다. 이러한 필드는 전체 대상 상태가 SUCCESS, PARTIAL_SUCCESS 또는 FAILURE에 도달할 때 채워집니다.
warning_infoWarningInfo객체warning_counts필드에는WarningCount객체 목록이 포함됩니다. 각WarningCount에는 경고 유형이 있는reason와 해당 유형의 경고가 있는 레코드 수를 나타내는record_count가 포함됩니다.전체 대상 상태가
SUCCESS인 경우에도warning_info를 확인합니다.error_infoErrorInfo객체error_counts필드에는ErrorCount객체 목록이 포함됩니다. 각ErrorCount에는 오류 유형이 있는reason와 해당 오류 유형으로 인해 실패한 레코드 수를 나타내는record_count가 포함됩니다.