이 페이지는 AI로 자동 번역되었으며 부정확한 내용이 포함될 수 있습니다. 번역 오류를 신고하려면 페이지 오른쪽 목차 아래에 있는 피드백 기능을 사용하세요.
일반 원칙
잘 구조화된 데이터는 효과적인 Decisioning Studio Pro 에이전트의 기반입니다. 구체적인 자산 요구 사항을 살펴보기 전에, Decisioning Studio Pro로 전송하는 모든 데이터에 적용되는 네 가지 핵심 원칙을 이해해 두면 도움이 됩니다. 이러한 원칙 중 하나라도 위반하면 모델 성능이 저하되는 경우가 많으며, 이는 가장 흔한 원인 중 하나입니다.
모든 자산에서 일관된 단일 고객 식별자
모든 데이터 자산(고객 프로필, 활성화, 인게이지먼트, 전환)은 동일한 고객 식별자를 참조해야 합니다. 모든 자산에서 각 고객을 고유하고 일관되게 식별하는 기본 식별자는 정확히 하나여야 합니다.
| 요구 사항 | 위반 시 영향 |
|---|---|
| 모든 자산에 단일 고유 고객 식별자가 있어야 합니다. | 자산마다 서로 다른 ID 체계를 사용하면(예: 기능에는 웨어하우스 ID를, 활성화에는 플랫폼 ID를 사용하는 경우) Decisioning Studio Pro 엔진이 이를 안정적으로 조인할 수 없습니다. 이로 인해 피드백 루프가 끊기고 모델 교육과 보고 정확도가 모두 저하됩니다. 두 ID 체계 간의 매핑이 일대다가 아니라 다대다인 것으로 밝혀지면 그에 따른 데이터 무결성 문제가 심각해질 수 있습니다. |
사용할 식별자에 대한 안내는 Braze 외부 ID 사용을 참조하세요.
이벤트 데이터는 증분 스트림으로 전달해야 합니다
전환, 인게이지먼트, 활성화와 같은 이벤트는 특정 시점에 발생한 개별 사건을 나타냅니다. 각 이벤트는 증분(추가 전용) 스트림의 개별 레코드로 Decisioning Studio Pro에 전달하세요.
| 요구 사항 | 위반 시 영향 |
|---|---|
| 이벤트 데이터는 타임스탬프가 포함된 개별 레코드로 구조화하여 증분 방식으로 전달해야 합니다 | 이벤트 데이터를 스냅샷으로 집계하면(예: 개별 발송 레코드 대신 “마지막 발송 시간” 속성을 저장하는 경우) 각 이벤트의 정확한 발생 시점을 잃게 됩니다. 이로 인해 성과를 특정 의사 결정에 정확하게 연결할 수 없게 되고, 모델이 학습하는 데 필요한 피드백 루프가 끊어집니다. 정확한 이벤트 타임스탬프가 없으면 전환이 정확히 언제 발생했는지, 어떤 추천이 이를 트리거했는지 알 수 없습니다. |
이 차이에 대한 전체 설명과 올바른 패턴 및 잘못된 패턴의 예시는 스냅샷과 이벤트 스트림 비교를 참조하세요.
스냅샷 데이터는 정기적인 시간 기반 스케줄에 따라 업데이트해야 합니다
스냅샷 데이터(예: 고객 프로필 및 기능)는 특정 시점의 고객 현재 상태를 나타냅니다. 새 이벤트가 없는 고객을 포함한 모든 고객의 스냅샷 데이터를 정기적인 스케줄(예: 매일)에 따라 업데이트하세요.
| 요구 사항 | 위반 시 영향 |
|---|---|
| 해당 날짜에 고객에게 이벤트가 있었는지 여부와 관계없이 모든 고객의 스냅샷을 정기적인 스케줄에 따라 업데이트해야 합니다 | 이벤트가 발생할 때만 스냅샷 업데이트가 트리거되면, 시간 경과에 따라 달라지는 기능(예: ‘마지막 구매 이후 경과 일수’ 또는 ‘등록 이후 경과 일수’)이 최근 이벤트가 없는 고객에 대해 오래된 값으로 남게 됩니다. 그러면 모델이 오래된 기능 값으로 교육되어 정확하고 시의적절한 추천을 하는 능력이 떨어집니다. |
모든 자산은 최소 데이터 품질 및 무결성 요구 사항을 충족해야 합니다
구조 외에도 데이터 자체가 내부적으로 일관되고 유용하게 쓰일 만큼 완전해야 합니다.
| 요구 사항 | 위반 시 영향 |
|---|---|
| 각 자산에는 기본 키를 설정하는 데 필요한 필드와, 해당되는 경우 다른 자산과 연결할 조인 키가 포함되어야 합니다. 중복 레코드는 수집 전에 제거하거나 중복 제거해야 합니다. | 중복되거나 매칭할 수 없는 레코드는 모델 교육에 노이즈를 더하고 잘못된 기여도를 유발할 수 있습니다. 키가 누락되면 엔진이 추천부터 전환까지 고객 여정 전반의 이벤트를 연결할 수 없습니다. |
특히 이벤트 스트림 데이터의 경우 각 레코드에는 최소한 다음이 포함되어야 합니다.
필수 필드:
- 고객 식별자
- 이벤트가 발생한 시점의 타임스탬프(작업 자체가 일어난 시간입니다. 레코드 생성 타임스탬프와 어떻게 다른지는 스냅샷과 이벤트 스트림 비교를 참조하세요)
- 시스템에서 레코드가 생성된 시점의 타임스탬프(증분 내보내기를 안정적으로 분할하는 데 사용됨)
- 이벤트 유형
- 관심 있는 특정 이벤트로 필터링하기에 충분한 필드
권장 필드:
- 이벤트 유형 간 안정적인 매칭을 가능하게 하는 추가 이벤트 메타데이터(예: 전환 이벤트를 그 이전에 발생한 특정 활성화와 연결)
New Stuff!