사용자 데이터 형식 지정

Data Manager API는 여러 유형의 사용자 데이터 업로드를 지원합니다. 데이터가 성공적으로 수신되고 처리되도록 각 데이터 요소의 형식 지정, 해싱, 인코딩 요구사항을 따르세요.

UserData 요구사항

UserData 객체는 UserIdentifier 객체의 컬렉션입니다. 각 UserIdentifier에는 다음 표의 속성 중 정확히 하나가 있습니다.

UserIdentifier
email_address
형식
string
  • 소문자로 변환합니다.
  • 이메일 주소에 gmail.com 또는 googlemail.com 도메인이 있는 경우:
    • @ 기호 앞의 모든 점 (.)을 삭제합니다.
    • 로컬 부분에서 더하기 기호 (+)를 삭제하고 그 뒤에 오는 모든 문자를 삭제합니다.
    • 예: cloudy.sanfrancisco+shopping@gmail.com → cloudysanfrancisco@gmail.com
  • 이메일 주소에 gmail.com 또는 googlemail.com 이외의 도메인이 있는 경우 점이나 더하기 기호를 삭제하지 마세요.
    • 예: user.name+NYC@Example.com → user.name+nyc@example.com
공백 선행, 후행, 중간 공백을 자릅니다.
해싱 SHA-256 알고리즘을 사용하여 해싱하고 해시 바이트를 인코딩합니다.
phone_number
형식
string
E.164 형식을 사용합니다.
더하기 기호 (+)와 국가 코드를 포함합니다. 더하기 기호 뒤의 모든 문자는 숫자여야 합니다.
예를 들어 미국 전화번호 (800)555-0100는 +18005550100로 형식 지정 및 정규화되어야 합니다.
공백 선행 및 후행 공백을 자릅니다.
해싱 SHA-256 알고리즘을 사용하여 해싱하고 해시 바이트를 인코딩합니다.
address
AddressInfo 형식 사양을 참조하세요.

AddressInfo 형식

다음 형식 지정 가이드라인을 사용하여 UserIdentifier의 address 속성을 구성합니다.

AddressInfo
given_name
형식
string
소문자로 변환합니다.
Mrs.와 같은 프리픽스는 포함하지 마세요.
공백 선행 및 후행 공백을 자릅니다.
해싱 SHA-256 알고리즘을 사용하여 해싱하고 해시 바이트를 인코딩합니다.
family_name
형식
string
소문자로 변환합니다.
Jr.와 같은 접미사는 포함하지 마세요.
공백 선행 및 후행 공백을 자릅니다.
해싱 SHA-256 알고리즘을 사용하여 해싱하고 해시 바이트를 인코딩합니다.
region_code
형식
string
두 글자로 된 ISO-3166-1 alpha-2 코드입니다.
공백 선행 및 후행 공백을 자릅니다.
해싱 region_code를 해싱하지 마세요.
postal_code
형식
string
미국 및 국제 우편번호가 모두 허용됩니다.
미국 주소의 경우 5자리 또는 5자리 뒤에 4자리 확장자를 사용합니다. 4자리 코드를 사용하면 일치율을 향상시킬 수 있습니다.
기타 모든 국가의 경우 추가적인 우편번호는 사용하지 마세요.
공백 선행 및 후행 공백을 자릅니다.
해싱 postal_code를 해싱하지 마세요.
address_line
형식
string
Google 애널리틱스에만 사용됩니다.
사용자 주소의 도로 및 번지입니다.
소문자로 변환합니다.
기호 문자를 삭제합니다.
공백 선행 및 후행 공백을 자릅니다.
해싱 SHA-256 알고리즘을 사용하여 해싱하고 해시 바이트를 인코딩합니다.
city
형식
string
Google 애널리틱스에만 사용됩니다.
사용자 주소의 도시입니다.
소문자로 변환합니다.
기호 문자를 삭제합니다.
공백 선행 및 후행 공백을 자릅니다.
해싱 city를 해싱하지 마세요.
administrative_area
형식
string
Google 애널리틱스에만 사용됩니다.
사용자 주소의 행정 구역 (주 또는 도)입니다.
두 글자 약어 (예: ca) 또는 전체 이름 (예: california)을 사용합니다.
소문자로 변환합니다.
기호 문자를 삭제합니다.
공백 선행 및 후행 공백을 자릅니다.
해싱 administrative_area를 해싱하지 마세요.

IpData 요구사항

IpData 객체에는 다음과 같은 속성이 있습니다.

IpData
ip_address
형식
string
IPv4 또는 IPv6 주소
IPv6 주소의 경우 대소문자는 중요하지 않습니다 (대문자 또는 소문자 모두 사용 가능).
공백 선행 및 후행 공백을 자릅니다.
해싱 ip_address를 해싱하지 마세요.

PairData 요구사항

PairData 객체의 pair_ids 필드를 ID 목록으로 채웁니다. 다음 단계에 따라 목록의 각 요소에 서식을 지정합니다.

  1. SHA-256 알고리즘을 사용하여 데이터 클린룸에서 제공하는 PII 데이터를 해싱합니다.

  2. PAIR 사용자 목록의 게시자 키를 사용하여 EC 교환 암호로 해시 바이트를 암호화합니다.

  3. 16진수 또는 Base64 인코딩을 사용하여 암호화된 데이터를 인코딩합니다.

MobileData 요구사항

MobileData 객체의 mobile_ids 필드를 Mobile ID 목록으로 채웁니다. 모바일 ID는 해싱하지 마세요.

타임스탬프 형식

Event의 timestamp 및 last_updated_timestamp와 같은 Timestamp 필드에 JSON 형식을 사용하는 경우 RFC 3339 형식을 사용합니다. 다음은 RFC 3339 형식 및 다양한 시간대의 2025년 8월 8일 오후 5:18:44.291의 UTC 시간 예시입니다.

  • UTC 시간대: 2025-08-08T17:18:44.291Z

  • EDT 시간대(당시 UTC보다 4시간 전): 2025-08-08T13:18:44.291-04:00

  • PDT 시간대(당시 UTC보다 7시간 전): 2025-08-08T10:18:44.291-07:00

  • UTC보다 9시간 빠르고 일광 절약 시간을 준수하지 않는 일본 도쿄의 시간대: 2025-08-08T22:18:44.291+09:00

프로토콜 버퍼 형식을 사용하는 경우 Timestamp를 구성할 때 seconds 및 nanos(선택사항)을 설정합니다. 다음은 2025년 8월 8일 오후 5시 18분 44.291초(UTC)의 seconds 및 nanos 값입니다.

  • seconds: 1754683124

  • nanos: 291000000

인코딩

인코딩 요구사항은 사용자 데이터를 암호화하는지 여부에 따라 다릅니다.

인코딩 워크플로

  • 암호화되지 않은 사용자 데이터: 16진수 인코딩 (hex) 또는 Base64 인코딩을 사용하여 SHA-256 해시 바이트를 인코딩합니다.

  • 암호화된 사용자 데이터: 사용자 데이터를 암호화하는 경우 암호화하기 전에 원시 해시 바이트를 Base64로 인코딩해야 합니다. 암호화 전 해시에는 16진수 인코딩이 지원되지 않습니다. 그런 다음 16진수 또는 Base64 인코딩을 사용하여 결과 암호문을 인코딩할 수 있습니다.

이전
대상 및 헤더 구성
다음
사용자 데이터 암호화