일반 원칙

잘 구조화된 데이터는 효과적인 Decisioning Studio 에이전트의 기반입니다. 특정 자산 요구 사항을 자세히 살펴보기 전에, Decisioning Studio에 전송하는 모든 데이터에 적용되는 네 가지 핵심 원칙을 이해하는 것이 도움이 됩니다. 이러한 원칙을 위반하는 것은 모델 성능 저하의 가장 흔한 원인 중 하나입니다.

모든 자산에 걸쳐 하나의 일관된 고객 식별자 사용

모든 데이터 자산(고객 프로필, 활성화, 참여, 전환)은 동일한 고객 식별자를 참조해야 합니다. 모든 자산에서 각 고객을 고유하고 일관되게 식별하는 하나의 기본 식별자가 있어야 합니다.

어떤 식별자를 사용해야 하는지에 대한 안내는 Braze 외부 ID 사용을 참조하세요.

이벤트 데이터는 스냅샷이 아닌 증분 스트림으로 전달해야 합니다

전환, 참여, 활성화와 같은 이벤트는 특정 시점에 발생한 개별 사건을 나타냅니다. 이러한 이벤트는 집계된 스냅샷이 아닌 개별 레코드의 증분(추가 전용) 스트림으로 Decisioning Studio에 전달해야 합니다.

이 구분에 대한 전체 설명과 올바른 패턴 및 잘못된 패턴의 예시는 스냅샷과 이벤트 스트림 비교를 참조하세요.

스냅샷 데이터는 정기적인 시간 기반 스케줄에 따라 업데이트해야 합니다

스냅샷 데이터(예: 고객 프로필 및 기능)는 특정 시점에서의 고객의 현재 상태를 나타냅니다. 스냅샷 데이터의 업데이트는 이벤트 트리거가 아닌 정기적인 스케줄(예: 매일)에 의해 수행되어야 합니다.

모든 자산은 최소 데이터 품질 및 무결성 요구 사항을 충족해야 합니다

구조 외에도, 데이터 자체가 내부적으로 일관되고 유용할 만큼 충분히 완전해야 합니다.

특히 이벤트 스트림 데이터의 경우, 각 레코드에는 최소한 다음이 포함되어야 합니다:

필수 필드:

• 고객 식별자
• 이벤트가 발생한 타임스탬프(시스템에서 레코드가 생성된 시점이 아님; 이 둘은 다릅니다. 이것이 중요한 이유는 스냅샷과 이벤트 스트림 비교를 참조하세요)
• 시스템에서 레코드가 생성된 타임스탬프(증분 내보내기를 안정적으로 분할하는 데 사용됨)
• 이벤트 유형
• 관심 있는 특정 이벤트로 필터링하기에 충분한 필드

권장 필드:

• 이벤트 유형 간의 안정적인 매칭을 가능하게 하는 추가 이벤트 메타데이터(예: 전환 이벤트를 해당 전환에 선행한 특정 활성화에 다시 연결)