Experience Data Model (XDM)은 다운스트림 Adobe Experience Platform 서비스에서 사용할 수 있는 일반적인 구조 및 정의를 제공하여 고객 경험 데이터를 표준화하는 핵심 프레임워크입니다. XDM 표준을 준수함으로써 모든 고객 경험 데이터를 하나의 공통 표현으로 통합하여 고객의 행동을 통해 중요한 통찰력을 얻을 수 있고 세그먼트를 통해 고객 고객을 정의할 수 있으며 개인화를 위해 고객 속성을 표현할 수 있습니다.
XDM은 디자인에 의해 매우 유용하고 사용자 지정이 가능하므로 스키마를 디자인할 때 데이터 모델링에 대한 모범 사례를 따르는 것이 중요합니다. 이 문서에서는 고객 경험 데이터를 XDM에 매핑할 때 고려해야 할 주요 의사 결정 및 사항을 다룹니다.
이 안내서를 읽기 전에 XDM 시스템 개요에서 XDM에 대한 개요 및 Experience Platform 내의 역할을 검토하십시오.
또한 이 안내서는 스키마 디자인과 관련된 주요 고려 사항에만 중점을 둡니다. 따라서 이 안내서 전체에 언급된 개별 스키마 요소에 대한 자세한 설명은 스키마 구성의 기본 사항을 참조하는 것이 좋습니다.
Experience Platform에서 사용할 데이터 모델을 디자인하기 위한 권장 방법은 다음과 같이 요약할 수 있습니다.
비즈니스 사용 사례를 수행하는 데 필요한 해당 데이터 소스를 식별하는 것과 관련된 단계는 조직마다 다릅니다. 이 문서 전체의 나머지 부분은 데이터 소스가 식별된 후 ERD를 구성하고 구성하는 후자의 단계에 중점을 두고 있지만, 다이어그램의 다양한 구성 요소에 대한 설명은 데이터 소스를 Platform으로 마이그레이션해야 하는 결정에 알려줄 수 있습니다.
Platform에 가져올 데이터 소스를 결정했으면 데이터를 XDM 스키마에 매핑하는 프로세스를 안내하는 고급 ERD를 만드십시오.
아래 예제는 데이터를 Platform으로 가져오려는 회사에 대해 간소화된 ERD를 나타냅니다. 아래 그림에서는 고객 계정, 호텔, 주소 및 여러 가지 일반적인 전자 상거래 이벤트를 포함하여 XDM 클래스로 정렬해야 하는 기본 엔티티를 강조 표시합니다.
Platform에 가져올 필수 엔티티를 식별하기 위해 ERD를 만들었으면 이러한 엔티티는 프로필, 조회 및 이벤트 카테고리로 정렬되어야 합니다.
카테고리 | 설명 |
---|---|
프로필 엔티티 | 프로필 개체는 개인(일반적으로 고객)과 관련된 특성을 나타냅니다. 이 카테고리에 속하는 엔터티는 XDM Individual Profile클래스에 따라 스키마로 표시되어야 합니다. |
조회 엔티티 | 조회 엔티티는 개별 개인에게 관련될 수 있지만 개인을 식별하기 위해 직접 사용할 수는 없는 개념을 나타냅니다. 이 카테고리에 속하는 엔터티는 사용자 지정 클래스를 기준으로 스키마로 표시되어야 합니다. |
이벤트 엔티티 | 이벤트 엔티티는 고객이 수행할 수 있는 작업, 시스템 이벤트 또는 시간에 따른 변경 사항을 추적하려는 다른 개념과 관련된 개념을 나타냅니다. 이 카테고리에 속하는 엔터티는 XDM ExperienceEvent클래스에 따라 스키마로 표시되어야 합니다. |
아래 섹션에서는 위 카테고리로 개체를 정렬하는 방법에 대한 자세한 지침을 제공합니다.
엔티티에 개별 고객과 관련된 속성이 포함되어 있으면 프로필 엔티티일 가능성이 높습니다. 고객 속성의 예는 다음과 같습니다.
엔티티 내 특정 속성이 시간에 따라 변경되는 방식을 분석하려는 경우 이벤트 엔티티일 가능성이 높습니다. 예를 들어 장바구니에 제품 항목을 추가하는 것은 Platform에서 장바구니에 추가 이벤트로 추적할 수 있습니다.
고객 ID | 유형 | 제품 ID | 수량 | 타임스탬프 |
---|---|---|---|---|
1234567 | 이벤트가 복제되지 않도록 하면서 현재 이벤트 변수에 | 275098 | 2 | 10월 1일 오전 10:32 |
1234567 | 제거 | 275098 | 1 | 10월 1일 오전 10:33 |
1234567 | 이벤트가 복제되지 않도록 하면서 현재 이벤트 변수에 | 486502 | 1 | 10월 1일 오전 10:41 |
1234567 | 이벤트가 복제되지 않도록 하면서 현재 이벤트 변수에 | 910482 | 5 | 10월 3일 오후 2:15 |
개체를 분류할 때 특정 비즈니스 사용 사례를 해결하기 위해 빌드할 대상 세그먼트를 고려해야 합니다.
예를 들어, 회사는 작년 5회 이상 구매한 충성도 프로그램의 "골드" 또는 "플래티넘" 멤버들을 모두 알고 싶어합니다. 이 세그먼트 로직을 기반으로 관련 개체가 표시되어야 하는 방식에 대해 다음 결론을 내릴 수 있습니다.
세그멘테이션 사용 사례에 대한 고려 사항 외에도 관련 특성을 추가로 식별하기 위해 이러한 세그먼트의 활성화 사용 사례를 검토해야 합니다.
예를 들어, 회사는 country = US
규칙을 기반으로 고객 세그먼트를 만들었습니다. 그런 다음 해당 세그먼트를 특정 다운스트림 타겟으로 활성화할 때 회사는 홈 상태를 기반으로 내보낸 모든 프로파일을 필터링하려고 합니다. 따라서 해당 프로필 엔티티에서도 state
속성이 캡처되어야 합니다.
데이터의 사용 사례와 세부기간을 기반으로 특정 값을 프로필 또는 이벤트 엔티티에 포함하기 전에 미리 집계해야 하는지 여부를 결정해야 합니다.
예를 들어 회사는 장바구니 구매 수를 기반으로 세그먼트를 만들려고 합니다. 각 타임스탬프가 지정된 구매 이벤트를 자체 엔티티로 포함하여 이 데이터를 가장 낮은 세부기간에 통합하도록 선택할 수 있습니다. 하지만 경우에 따라 기록된 이벤트의 수가 기하급수적으로 증가할 수 있습니다. 인제스트된 이벤트 수를 줄이려면 1주일간 또는 1개월 동안 집계 값 numberOfPurchases
을(를) 만들도록 선택할 수 있습니다. MIN 및 MAX와 같은 기타 집계 기능도 이러한 상황에 적용할 수 있습니다.
Experience Platform은 현재 자동 값 집계를 수행하지 않지만, 이는 향후 릴리스에 대해 예정되어 있습니다. 집계된 값을 사용하도록 선택하는 경우 데이터를 Platform에 보내기 전에 외부에서 계산을 수행해야 합니다.
ERD에 설정된 카디널리티 또한 개체를 분류하는 방법에 대한 몇 가지 단서를 제공할 수 있습니다. 두 엔티티 간에 일대다 관계가 있는 경우 "many"를 나타내는 엔티티가 이벤트 엔티티일 가능성이 있습니다. 하지만 "many"가 프로필 엔티티 내에 배열로 제공되는 조회 엔티티 집합인 경우도 있습니다.
모든 사용 사례에 모두 맞는 보편적인 접근 방식은 없으므로 카디널리티를 기반으로 엔티티를 분류할 때 각 상황의 찬반 의견을 고려해야 합니다. 자세한 내용은 다음 섹션을 참조하십시오.
다음 표는 몇 가지 일반적인 엔티티 관계와 이러한 관계로부터 파생될 수 있는 카테고리에 대해 설명합니다.
관계 | 카디널리티 | 엔티티 카테고리 |
---|---|---|
고객 및 장바구니 체크아웃 | 1대 다수 | 단일 고객에게는 장바구니 체크아웃이 많이 있을 수 있으며, 이는 시간에 따라 추적할 수 있는 이벤트입니다. 따라서 고객은 프로필 엔티티이고 장바구니 체크아웃은 이벤트 엔티티입니다. |
고객 및 충성도 계정 | 1대1 | 단일 고객은 하나의 충성도 계정만 가질 수 있고 그 반대의 경우도 마찬가지입니다. 관계가 일대일로 설정되므로 고객과 충성도 계정은 프로필 개체를 나타냅니다. |
고객 및 구독 | 1대 다수 | 단일 고객에게는 많은 구독이 있을 수 있습니다. 회사는 고객의 현재 가입에만 관심이 있으므로, 고객은 프로필 엔티티이고 구독은 조회 실체입니다. |
이전 섹션에서는 개체를 분류하는 방법을 결정하기 위한 몇 가지 일반적인 지침을 제공했지만, 한 개체 카테고리를 다른 개체 카테고리에서 선택할 때 종종 장단점이 있을 수 있음을 이해하는 것이 중요합니다. 다음 사례 조사는 이러한 상황에서 옵션을 고려하는 방법을 설명하기 위한 것입니다.
한 고객은 많은 구독을 이용할 수 있는 고객의 활성 가입을 추적합니다. 또한 유효한 구독이 있는 모든 사용자 찾기 등 세그멘테이션 사용 사례에 대한 가입을 포함시키고자 합니다.
이 시나리오에서는 회사가 데이터 모델에서 고객의 가입을 나타낼 수 있는 2가지 잠재적 옵션이 있습니다.
첫 번째 방법은 고객을 위한 프로필 엔티티 내 속성으로 가입 배열을 포함하는 것입니다. 이 배열의 객체에는 category
, status
, planName
, startDate
및 endDate
에 대한 필드가 포함됩니다.
전문가
반대
두 번째 방법은 이벤트 스키마를 사용하여 구독을 나타내는 것입니다. 여기에는 구독 ID, 고객 ID 및 구독 이벤트가 발생한 타임스탬프를 추가하여 첫 번째 접근 방식과 동일한 구독 필드를 인제스트해야 합니다.
전문가
반대
개체를 프로필, 조회 및 이벤트 범주로 정렬하면 데이터 모델을 XDM 스키마로 변환할 수 있습니다. 데모용으로, 앞에 표시된 예제 데이터 모델은 다음 다이어그램의 해당 범주로 정렬됩니다.
엔티티가 정렬된 범주는 스키마를 기반으로 하는 XDM 클래스를 결정해야 합니다. 반복하려면:
이벤트 엔터티는 거의 항상 별도의 스키마로 표시되지만, 프로필 또는 조회 범주의 엔터티는 카디널리티에 따라 단일 XDM 스키마에서 함께 결합될 수 있습니다.
예를 들어 Customers 엔티티는 EntityAccounts 엔티티와 1대1 관계를 가지므로 Customers 엔티티에 대한 스키마에는 각 고객에 대한 적절한 로열티 필드가 포함된 LoyaltyAccount
객체도 포함될 수 있습니다. 하지만 관계가 여러 개일 경우 "many"를 나타내는 엔티티는 복잡도에 따라 별도의 스키마 또는 프로필 속성 배열로 표시될 수 있습니다.
아래 섹션에서는 ERD를 기반으로 스키마를 생성하는 방법에 대한 일반적인 지침을 제공합니다.
스키마 진화의 규칙에서는 스키마 구현이 구현되면 비파괴 변경 사항만 스키마에 적용할 수 있습니다. 즉, 스키마에 필드를 추가하고 해당 필드에 대해 데이터를 인제스트한 후에는 필드를 더 이상 제거할 수 없습니다. 따라서 스키마를 처음 만들 때 반복적인 모델링 방법을 채택하는 것이 중요합니다. 간소화된 구현부터 시작되므로 시간이 지남에 따라 복잡해질 수 있습니다.
스키마에 특정 필드를 포함해야 하는지 확실하지 않은 경우 이 필드를 제외하는 것이 좋습니다. 나중에 필드가 필요하다고 확인되면 언제든지 스키마의 다음 반복에서 필드를 추가할 수 있습니다.
Experience Platform에서 ID로 표시된 XDM 필드는 여러 데이터 소스에서 유입되는 개별 고객에 대한 정보를 통합하는 데 사용됩니다. 스키마에는 ID로 표시된 여러 필드가 있을 수 있지만, Real-time Customer Profile에서 스키마를 사용하도록 설정하려면 단일 기본 ID를 정의해야 합니다. 이러한 필드의 사용 사례에 대한 자세한 내용은 스키마 컴포지션의 기본 사항에 있는 ID 필드의 섹션을 참조하십시오.
스키마를 디자인할 때 관계형 데이터베이스 테이블의 모든 기본 키는 기본 ID에 대해 가능성이 높습니다. 해당 ID 필드의 다른 예로는 고객 이메일 주소, 전화번호, 계정 ID 및 ECID가 있습니다.
Experience Platform은 다음 Adobe 응용 프로그램과 관련된 데이터를 캡처하기 위해 즉시 사용 가능한 여러 XDM 믹스를 제공합니다.
예를 들어 Adobe Analytics ExperienceEvent Template Mixin에서는 Analytics 특정 필드를 XDM 스키마에 매핑할 수 있습니다. 작업 중인 Adobe 응용 프로그램에 따라 스키마에 Adobe 제공 믹스를 사용해야 합니다.
Adobe 응용 프로그램 믹스는 시스템 생성 읽기 전용 개체인 identityMap
필드를 사용하여 기본 ID를 자동으로 할당합니다. 이 개체는 개별 고객의 표준 ID 값을 매핑합니다.
Adobe Analytics의 경우 ECID가 기본 기본 ID입니다. 고객이 ECID 값을 제공하지 않으면 기본 ID가 대신 AAID로 기본 설정됩니다.
Adobe 응용 프로그램 혼합을 사용할 때는 다른 필드를 기본 ID로 표시하지 않아야 합니다. ID로 표시해야 하는 추가 속성이 있는 경우 이 필드를 보조 ID로 할당해야 합니다.
이 문서에서는 Experience Platform에 대한 데이터 모델을 디자인하기 위한 일반적인 지침과 모범 사례를 다룹니다. 요약하려면:
준비가 되면 UI에서 스키마 만들기에 대한 자습서를 참조하여 스키마를 만들고, 엔터티에 적합한 클래스를 지정하고, 데이터를 매핑할 필드를 추가하십시오.