DCP에서 최적의 데이터 수집과 최대의 결과를 얻으려면 소스 데이터를 다음과 같이 구성하십시오.

1. 소스 데이터 형식 요구 사항을 충족하는지 확인하십시오. 
2. 최상의 결과를 얻으려면, 사용자 식별 데이터를 사용자별로 한 행씩 구성하고 해당 사용자에 대해 사용 가능한 모든 식별자를 포함하십시오. 권장 식별자 구조를 참조하십시오.
   • 사용자가 여러 개의 이메일 주소나 전화번호를 가지고 있는 경우, Parquet, BigQuery 또는 Snowflake와 같은 배열 기반 형식을 사용하십시오.
3. 해싱 가이드라인을 준수했는지 확인하십시오.
4. 거래 데이터 세트(및 해당되는 경우 기타 데이터 유형)의 경우 DCP 데이터 보기 도구를 사용하여 협업에 최적화된 비즈니스 지향적이고 개인 정보 보호가 안전한 데이터 하위 집합을 생성하고 원시 테이블 대신 공유하세요. 데이터 뷰를 사용하는 것이 권장되는 이유 .

다른 구조를 사용할 수도 있지만, DCP를 최대한 활용하는 데에는 이상적이지 않을 수 있습니다. 권장하지 않는 데이터 구조를 참조하세요.

권장 식별자 구조

매칭률을 극대화하려면 가능한 한 사용자 수준의 신원 데이터를 사용자별로 단일 행으로 전송하고, 사용 가능한 모든 식별자를 사용자를 정확하게 표현하는 구조에 포함하는 것이 좋습니다.

옵션 3 사용자당 한 행, 식별자 유형당 하나의 가치

간단하고 효과적입니다.

각 사용자가 최대 하나의 해시된 이메일 주소, 하나의 해시된 전화번호 등을 보유할 때 이 방법을 사용하다 .

예시

추천되는 이유

• 가장 간편하게 준비하고 섭취할 수 있습니다.
• 검증 및 문제 해결이 용이합니다.
• 식별자가 완전하고 일관적일 경우 뛰어난 매칭 성과 (협력업체 데이터 세트와의 매칭 및 활성화 미디어 파트너 매칭 기준). 

가장 적합한

• CSV 기반 업로드에 적합합니다.
• Parquet/BigQuery/Snowflake에서도 잘 작동합니다.

옵션 3 다중값 필드에 대한 식별자 배열(목록)

사용자가 여러 개의 이메일 주소와 전화번호를 가지고 있을 때 정확도가 가장 높습니다.

사용자가 동일한 식별자 유형에 대해 여러 값을 가질 수 있는 경우(예:)에 사용하다 .

• 여러 개의 해시된 이메일
• 여러 개의 해시된 휴대폰

이 구조는 네이티브 배열 로 표현되어야 합니다.

예시

선호되는 이유

• 이는 신원 정보가 내부적으로 저장되는 방식을 반영합니다.
• "이메일 열"이 몇 개나 필요할지 추측할 필요가 없습니다.
• 지속적인 스키마 변경을 방지합니다.
• 사용자당 여러 식별자를 허용하여 (협력업체 데이터 세트 및 활성화 미디어 파트너 매칭을 위한) 매칭 가능성을 극대화합니다.

가장 적합한

• Parquet (S3/GCS)
• BigQuery
• Snowflake

신원(사용자 수준) 데이터 세트 체크리스트 

• 한 행은 한 명의 사용자를 나타냅니다. 
• 사용 가능한 모든 식별자(해시 처리된 이메일, 해시 처리된 전화번호, MAID 등)를 포함하십시오. 
• 여러 값이 존재하는 경우(예: 여러 이메일 주소) 가능한 한 네이티브 배열을 사용하십시오. 
• 셀에 목록을 넣지 마세요. 예를 들어 "email_1/email_2/email_3"과 같은 형식을 사용하지 말고, 여러 행에 걸쳐 동일한 주소를 사용하는 구조도 피하세요. 

거래(이벤트) 데이터 세트 체크리스트 

• 이벤트/트랜잭션 행은 그대로 유지하세요. 거래 데이터 예시를 참조하세요.
• 필요에 따라 데이터 뷰를 사용하다 공동 작업에 적합한 사용자 수준 요약을 생성하세요. 

데이터 보기 체크리스트 

• 비즈니스에 최적화된 데이터 보기 (대상 고객이 바로 이해할 수 있도록 요약되고 표준화된 형태)를 구축하세요. 
• 가능하면 민감한 정보가 포함된 원본 테이블 대신 데이터 뷰를 공유하세요. 
• 개인 정보 보호 및 비즈니스 보호를 위해 필요한 최소한의 공유 필드만 사용하세요. 
• 민감한 데이터에 대한 액세스 줄이고 효율성을 높이기 위해 데이터 집계를 고려하십시오.

DCP는 다음과 같은 여러 클라우드 서비스를 통한 데이터 수집을 지원합니다.

• AWS S3
• Google 클라우드 스토리지
• BigQuery
• Snowflake

형식 안내

• 각 사용자가 식별자 유형별로 하나의 가치 ( 이메일 하나, 전화번호 하나 등)만 가지고 있는 경우 CSV (쉼표로 구분된) 형식을 사용하다 .
• 사용자가 동일한 식별자 유형에 대해 여러 값을 가질 수 있는 경우(예: 여러 개의 해시된 이메일)에는 배열 지원 형식을 사용하는 것이 좋습니다.
  • 파케트(빅데이터에서 흔히 사용됨)
  • BigQuery(배열은 내장 기능입니다)
  • Snowflake(배열이 내장되어 있습니다)

참고: 

• "배열"은 단순히 "값들의 목록"을 의미합니다.
• BigQuery/Snowflake에서 Parquet과 배열은 표준적인 방식이며, 대부분의 데이터 팀은 이를 자연스럽게 지원 수 있습니다.

커넥터별 예제 자료(AWS S3, GCS, BigQuery, Snowflake)를 참조하세요.

거래/ 이벤트 데이터는 사용자별로 여러 행을 포함할 수 있습니다.

추천

• 거래 데이터를 원래 구조 그대로 수집합니다.
• 데이터 보기 도구를 사용하다 공동 작업에 적합한 사용자 수준 보기(예: 지난 30일간 지출 , 카테고리 선호도, 최근/빈도 요약)를 생성하세요.

“식별자 배열/목록”이란 무엇을 의미합니까?

경우에 따라 한 사용자가 여러 개의 이메일 나 전화번호를 가질 수 있습니다(예: 개인 이메일과 작업하다 이메일). 이러한 값들을 별도의 열이나 복잡한 텍스트 필드에 억지로 넣는 대신, 값들의 목록으로 표현합니다.

1. AWS S3 및 GCS 커넥터(Parquet)

신원 확인 샘플에 포함되어야 할 내용(스키마)

Parquet은 목록을 기본적으로 지원하므로 사용자가 여러 개의 이메일 주소나 전화번호를 사용하는 경우에 권장됩니다.

2. BigQuery 커넥터(표 미리보기 및 스키마 스크린샷)

예시 ID 스키마 (BigQuery)

BigQuery에서는 배열이 기본 기능입니다(반복 필드). 여러 개의 이메일 주소나 전화번호가 있는 경우 권장되는 접근 방식입니다.

3. Snowflake 커넥터(표 미리보기 및 스키마 스크린샷)

예시 ID 스키마(Snowflake)

Snowflake는 리스트와 유사한 필드(배열)를 지원합니다. 이는 email_1/email_2/mail_3 열을 생성하는 것보다 선호됩니다.

데이터 뷰는 기존 데이터 소스의 사용자 지정 하위 집합으로, 원본 데이터 세트를 변경하지 않고 생성할 수 있습니다. 이 기능들을 사용하면 데이터를 수정, 정제 및 요약하여 협업에서 관련성 있는 데이터만 공유할 수 있으므로 공유하는 데이터는 명확하고 핵심에 집중된 상태로 유지하고 나머지 데이터는 비공개로 안전하게 보호할 수 있습니다. 협업에서 데이터 뷰를 사용하다 이유는 다음과 같습니다.

비즈니스 지향적이며 협업이 더 용이합니다.

• 데이터 뷰를 사용하면 원시 로그나 복잡한 거래 스키마 대신 깔끔하고 비즈니스 친화적인 구조(예: "고객 ID 뷰", "대상 고객 뷰", "구매 요약 뷰")로 데이터를 표시할 수 있습니다.
• 이러한 표준화된 정의(예: "활성 고객", "지난 30일간 총 지출 ")를 통해 양측이 일관된 논리를 사용하도록 돕다 .

설계상 개인정보 보호에 더욱 안전합니다.

• 데이터 뷰는 데이터 최소화를 지원 . 전체 원시 데이터 세트를 노출하는 대신 공동 작업에 필요한 필드와 행만 공유할 수 있습니다.
• 다음과 같은 기능을 통해 개인정보 보호 위험을 줄일 수 있습니다.
  • 불필요한 속성을 제외하세요
  • 세부 정보 수준을 제한하세요(예: 개별 거래 내역 대신 집계된 지표를 공유하세요).
  • 매칭에 필요한 식별자만 공유하고, 추가적인 민감한 열은 공유하지 마세요.

중요한 비즈니스 데이터를 보호하세요

• 가공되지 않은 거래 테이블에는 매우 민감한 비즈니스 신호(예: 상세한 구매 행태, 가격 패턴, 가맹점 관계, 내부 ID)가 포함될 수 있습니다.
• 데이터 뷰를 사용하면 공동 작업에 필요한 정보만 공유할 수 있습니다.
  • 예시: 품목별 세부 정보 대신 카테고리별 집계 정보를 공유합니다.
  • 예: 정확한 항목별 지출 대신 지출 구간별 비율 또는 요약 지표를 공유하세요.
• 이는 경쟁사 정보나 자체 개발한 정보를 의도치 않게 공개할 위험을 줄여줍니다.

데이터를 더욱 비용 효율적이고 성능이 뛰어나게 만들 수 있습니다.

데이터 뷰는 더 가볍고 효율적으로 구성할 수 있으며, 이는 종종 다음과 같은 이점을 제공합니다.

• 스캔된 데이터
• 처리 시간
• 비용 계산

협업에 최적화된 보기(특히 집계된 보기)를 미리 구성해 두면 협업 속도를 높이고 운영상의 예측 가능성을 높일 수 있습니다.

DCP 식별자 업로드 

활성화 계획 수립을 위한 핵심 사항

• Meta 와 틱톡
  • 가지고 있는 모든 것을 보내주세요
  • 진정한 "any- ID" 동작
  • 아이덴티티가 풍부한 클린룸 활성화를 위한 최고의 플랫폼
• Google
  • 커버리지 확보를 위해 여러 개의 ID를 보내주세요.
  • 교차 ID 강화 효과를 기대하지 마십시오.
  • 이메일/전화의 지배력은 실제 입니다.
• TTD 및 충전
  • 매칭 품질은 아이덴티티 그래프 참여도에 더 크게 좌우됩니다.
  • UID2/OmniID 적용 범위가 단순 식별자 개수보다 더 중요합니다.
• Pinterest
  • Meta 보다는 구글 에 더 가깝게 동작합니다.
  • 이메일 + MAID 외에는 상승 여력이 제한적입니다.

핵심 요약

• Meta 와 TikTok만이 "이러한 모든 것"을 기본적으로 매칭해주는 기능을 제공합니다.
• 구글 은 결정론적이지만 단일 ID 해결됩니다.
• 개방형 웹 플랫폼은 원시 ID가 아닌 ID 그래프를 통해 매칭합니다.

유니버설 정규화 규칙:
데이터를 해싱하기 전에 거의 모든 플랫폼은 매칭 정확도를 보장하기 위해 다음과 같은 정규화 단계를 요구합니다.

• Text: 소문자로 변환하고 앞뒤 공백을 모두 제거합니다.
• phone E.164 형식으로 변환하세요 (예: +15551234567)
• 해싱 SHA-256은 업계 표준이지만 일부 플랫폼에서는 MD5 또는 SHA-1도 허용합니다.