Data Manager API를 사용할 때는 다음 권장사항에 유의하세요.
모든 사용자 식별자 전송
UserData를 사용하여 잠재고객 구성원 또는 이벤트를 전송하는 경우 동일한 유형의 여러 식별자를 전송하는 등 최대한 많은 user_identifiers를 포함하세요.
예를 들어 사용자의 이메일 주소가 여러 개인 경우 각 이메일 주소에 별도의 UserIdentifier를 포함합니다. 마찬가지로 이메일 주소, 전화번호, 주소와 같이 사용자에게 다양한 유형의 식별자가 있는 경우 각 식별자에 대해 별도의 UserIdentifier를 최대 식별자 수까지 추가합니다.
요청 최적화
일일 요청 한도를 초과할 가능성을 줄이려면 각 요청에서 가능한 한 많은 항목을 요청당 한도까지 일괄 처리하세요.
예를 들어 잠재고객에 잠재고객 구성원 10,000명을 추가하려면 하나의 IngestAudienceMembersRequest에서 audience_members 목록에 구성원 10,000명을 모두 추가합니다. 10,000명의 구성원을 모두 단일 요청으로 일괄 처리하는 것이 각 잠재고객 구성원을 추가하기 위해 별도의 요청을 전송하는 것보다 더 효율적입니다.
동시 요청 전송
데이터를 수집하는 데 필요한 전체 시간을 줄이려면 IngestionService에 동시 요청을 보냅니다. 분당 요청 한도를 초과할 가능성을 줄이려면 최대 10개의 요청을 동시에 전송하는 것이 좋습니다.
요청에 동일한 destinations가 있더라도 동시 요청을 보낼 수 있습니다.
클라이언트 측에서 데이터 검증
Data Manager API는 빠른 실패 모델을 사용합니다. 요청의 레코드 중 하나라도 동기 검증에 실패하면 전체 요청이 실패하고 레코드가 처리되지 않습니다. 또한 API는 순차적 레이어에서 요청을 검증하므로 한 오류를 수정하면 후속 검증 레이어에서 오류가 표시될 수 있습니다.
반복적인 왕복 및 거부된 요청을 방지하려면 데이터를 전송하기 전에 검증하고 정제하세요.
해싱 전에 빈 값 삭제: SHA-256 해시를 계산하기 전에
email_address및phone_number와 같은 필드에 빈 문자열 또는 공백만 있는 문자열이 있는지 확인합니다. 빈 문자열을 해싱하면 문법 검사를 통과하는 유효한 해시가 생성되지만 일치율이 저하됩니다.불완전한 복합 객체 삭제: 복합 객체를 레코드에 추가하기 전에 모든 필수 필드가 있는지 확인합니다. 예를 들어
AddressInfo객체에 필수 필드 4개 (given_name,family_name,region_code,postal_code) 중 하나가 누락된 경우 전체address식별자를 삭제하여REQUIRED_FIELD_MISSING오류를 방지합니다.인코딩 및 일반 텍스트 필드 검증: 해싱된 필드가 원시 일반 텍스트를 전송하는 대신 선언된
encoding와 일치하는지 확인하고 일반 텍스트로 유지되어야 하는 필드 (예:mobile_ids)가 해싱되지 않았는지 확인합니다.범위를 벗어난 타임스탬프 필터링: 타임스탬프가 미래 시점이거나 도착 페이지의 전환 확인 기간보다 오래되지 않았는지 확인합니다.
JSON을 사용하여 요청을 전송하는 경우 타임스탬프 문자열이 시간대 오프셋과 함께 RFC 3339 형식을 사용하는지 확인합니다.
전화번호 정리: 해싱 전에 전화번호에 국가 코드가 포함되어 있는지 확인하고 E.164 형식을 사용합니다.
비어 있거나 크기가 초과된 레코드 프루닝:
user_identifiers를 레코드당 한도 (식별자 10개)로 제한하고, 비어 있는 맞춤 매개변수를 삭제하고, 유효한 식별자가 없는 레코드를 생략합니다.사용 사례 요구사항 확인: 각 이벤트에 대상 및 사용 사례의 모든 필수 필드가 포함되어 있는지 확인합니다 (예: Google Ads 온라인 전환의 경우
transaction_id). 사용 사례별 필수 입력란의 전체 목록은 이벤트 개요에서 도착 페이지의 이벤트 전송 가이드를 참고하세요.validateOnly를 사용하여 요청 테스트: 데이터를 수집하거나 삭제하지 않고 빠른 실패 오류를 포착하려면validateOnly를true로 설정하여 요청을 전송합니다. 검증 전용 요청이 성공하더라도 비동기 처리 중에 오류가 발생하지 않는다고 보장할 수 없으므로 일반 요청을 보낸 후에도 계속해서 요청 상태 및 진단을 확인하세요.
자세한 정규화 및 해싱 규칙은 사용자 데이터 형식 지정을 참고하세요.
요청 상태 및 진단 확인
각 IngestAudienceMembersResponse 또는 IngestEventsResponse에서 request_id를 캡처하고 수집하고 요청 ID를 사용하여 요청 상태 및 진단을 확인합니다.
할당량 모니터링 및 알림
예기치 않은 요청 거부를 방지하려면 Google Cloud 콘솔에서 할당량 알림 및 모니터링을 설정하세요. 할당량 사용량을 모니터링하면 애플리케이션이 일일 또는 분당 한도에 도달하기 전에 소비 패턴을 추적하고 요청 일괄 처리를 최적화할 수 있습니다.
프로덕션에 배포
로컬 테스트에서 프로덕션 워크로드로 이동할 때는 연결된 서비스 계정 또는 워크로드 아이덴티티 제휴와 함께 애플리케이션 기본 사용자 인증 정보를 사용하여 비대화형으로 안전하게 인증합니다.
다양한 프로덕션 환경의 인증 구성에 대한 자세한 내용은 프로덕션에 배포를 참조하세요.