스냅샷과 이벤트 스트림 비교

데이터는 스냅샷(상태)과 이벤트 스트림(발생한 일)이라는 두 가지 기본 범주 중 하나에 속합니다. 이 구분을 이해하고 올바르게 적용하는 것은 Decisioning Studio Pro 에이전트가 효과적으로 학습하도록 하기 위해 할 수 있는 가장 중요한 일 중 하나입니다.

스냅샷 데이터(상태)

스냅샷은 특정 시점의 고객 상태를 나타냅니다. “지금 이 고객은 어떤 모습인가?”라는 질문에 답합니다.

스냅샷은 정적이며 집계된 데이터입니다. 해당 시점까지 발생한 모든 변경 사항의 누적 결과를 반영합니다. 고객 프로필이나 계산된 기능(예: “마지막 구매 이후 경과 일수”, “로열티 등급”, “고객이탈 점수”)에 가장 적합합니다.

필수 필드

스냅샷 업데이트 방법

• 트리거: 시간 기반입니다. 고정된 스케줄(예: 매일)에 따라 스냅샷을 생성하며, 해당 날짜에 활동이 없었던 고객도 포함합니다.
• 범위: 모든 업데이트에는 이벤트가 없었던 고객을 포함하여 관련된 모든 고객이 포함되어야 합니다.
• 방법: 이전 값을 덮어쓰지 말고 새 스냅샷 레코드를 데이터 세트에 추가하세요. 이렇게 하면 모델 교육을 위한 과거 상태가 보존됩니다.

일일 전달을 위한 스냅샷 데이터 쿼리

Decisioning Studio Pro는 하루에 한 번 추천 파이프라인을 실행합니다. 스냅샷 데이터를 전달할 때는 각 파이프라인 실행 시 전날의 스냅샷을 내보내세요.

1
2
3

SELECT *
FROM snapshot_data
WHERE snapshot_date = {t-1} -- on pipeline run date t, export the snapshot from t-1

이벤트 스트림 데이터(흐름)

이벤트 스트림은 개별 행동이 발생하는 즉시 기록합니다. 이벤트 스트림은 “이 고객이 무엇을, 언제 했는가?”라는 질문에 답합니다. 원시 데이터, 변경 불가능한 데이터, 증분 데이터, 시간순 데이터에 적합합니다. 각 레코드는 특정 시점에 일어난 하나의 일을 나타냅니다. 예를 들어 활성화 기록, 인게이지먼트 로그(열람, 클릭), 전환 이벤트, 쿠폰 사용 내역에 이 데이터 스트림을 사용할 수 있습니다.

필수 필드

중요

이벤트 타임스탬프와 생성 타임스탬프는 서로 다른 필드이며 둘 다 필수입니다. 이벤트 타임스탬프는 행동이 실제로 발생한 시점을 기록합니다. 생성 타임스탬프는 데이터 항목이 시스템에 기록된 시점을 기록하며, 처리 지연으로 인해 더 늦을 수 있습니다. 두 필드를 혼동하지 마세요.

이벤트 스트림 업데이트 방법

• 트리거: 이벤트 기반입니다. 새 이벤트가 발생하면 새 레코드가 추가됩니다.
• 범위: 이벤트가 발생한 고객에게만 새 레코드가 생성됩니다.
• 방법: 기존 레코드는 변경할 수 없습니다. 업데이트는 항상 새 레코드를 삽입하는 방식으로 이루어집니다.

일일 전송을 위한 이벤트 데이터 쿼리

일일 내보내기는 create_timestamp를 기준으로 분할하세요. 이벤트는 발생한 후에 시스템에 기록되는 경우가 있습니다(지연 도착). event_timestamp를 기준으로 분할하면 이렇게 늦게 도착한 레코드는 영구적으로 누락됩니다.

1
2
3
4

-- Correct: use create_timestamp to ensure late-arriving events are captured
SELECT *
FROM events_data
WHERE DATE(create_timestamp) = {t-1} -- on run date t, export all records created yesterday

1
2
3
4

-- Incorrect: slicing on event_timestamp will permanently lose late-arriving events
SELECT *
FROM events_data
WHERE DATE(event_timestamp) = {t-1}

예를 들어 이벤트가 1월 1일에 발생했지만 1월 2일이 되어서야 시스템에 기록되었다면, 1월 2일에 event_timestamp를 기준으로 분할하면 해당 이벤트가 완전히 누락됩니다. create_timestamp를 기준으로 분할하면 이벤트를 올바르게 포착할 수 있습니다.

네이티브 Braze 통합의 경우

Braze는 이 두 가지 데이터 유형에 직접 대응하는 두 가지 기본 제공 메커니즘을 제공합니다.

커스텀 속성: 스냅샷 데이터

커스텀 속성은 특정 시점의 사용자 수준 상태를 저장합니다. 고객 프로필과 계산된 기능(예: churn_score, total_purchases_last_30d)에 사용하세요. 업데이트할 때마다 이전 값을 덮어쓰므로 속성에는 최신 상태만 남고 이전 이벤트는 사라집니다.

Braze 커런츠: 이벤트 스트림 데이터

Braze 커런츠는 변경할 수 없는 원시 이벤트 흐름 데이터를 제공합니다. USER_BEHAVIOR_CUSTOM_EVENTS 테이블은 커스텀 이벤트가 발생할 때마다 모든 인스턴스를 캡처하므로 활성화, 인게이지먼트, 전환 이벤트에 적합한 소스입니다.

팁

커스텀 속성은 고객 상태의 소스로, Braze 커런츠는 고객 행동 이벤트의 소스로 취급하세요. 커스텀 속성을 사용하여 원시 이벤트 데이터를 Decisioning Studio Pro로 전달하지 마세요.

일반적인 문제

이벤트 데이터를 스냅샷으로 전달하는 경우

이벤트 데이터를 Decisioning Studio Pro로 보내기 전에 스냅샷 필드로 집계하면 여러 가지 문제가 발생합니다.

• 세분성 손실: 데이터가 일별 고객 수준 요약으로 집계되면 개별 이벤트 레코드는 사라집니다. Decisioning Studio Pro는 이를 다시 재구성할 수 없습니다.
• 부정확한 타임스탬프: “last_email_sent”와 같은 필드는 가장 최근 발생 시점은 알려 주지만 전체 이벤트 기록이 사라지기 때문에 정확한 기여도 분석이 불가능해집니다.
• 유령 업데이트: 이벤트가 발생하지 않은 날에도 스냅샷 레코드가 업데이트되어 중복 항목이 생기며, 이러한 중복은 제거하기 어렵습니다.

Braze를 사용하는 경우 Currents 내보내기를 통해 원시 이벤트 데이터를 Decisioning Studio Pro로 전달하세요.

이벤트 트리거 시에만 스냅샷 데이터를 업데이트하는 경우

일부 구현에서는 이벤트가 발생할 때만 스냅샷 데이터를 업데이트합니다. 예를 들어 고객이 구매할 때만 기능을 다시 계산하는 방식입니다. 이렇게 하면 시간 경과에 따라 달라지는 기능이 최근 이벤트가 없는 고객에 대해 오래된 값으로 남게 됩니다.

예를 들어 days_since_last_purchase와 같은 기능은 매일 올바른 값이 달라집니다. 구매가 발생할 때만 다시 계산하면 최근에 구매하지 않은 모든 고객에 대해 잘못된 값으로 고정됩니다. 스냅샷 데이터는 항상 모든 고객을 대상으로 매일 시간 기반 스케줄에 따라 업데이트하세요.