데이터 모델링 우수 사례

Experience Data Model (XDM)은 다운스트림 Adobe Experience Platform 서비스에서 사용할 일반적인 구조 및 정의를 제공하여 고객 경험 데이터를 표준화하는 핵심 프레임워크입니다. XDM 표준을 준수하여 모든 고객 경험 데이터를 공통 표현으로 통합하여 고객 작업을 통해 유용한 통찰력을 얻을 수 있고 세그먼트를 통해 고객 대상을 정의할 수 있으며 개인화를 위한 고객 속성을 표현할 수 있습니다.

XDM은 디자인을 통해 매우 다양하게 사용자 지정할 수 있으므로 스키마를 디자인할 때 데이터 모델링에 대한 우수 사례를 따르는 것이 중요합니다. 이 문서에서는 고객 경험 데이터를 XDM에 매핑할 때 수행해야 하는 주요 의사 결정 및 고려 사항을 다룹니다.

시작하기

이 안내서를 읽기 전에 XDM 시스템 개요에서 XDM을 소개하고 Experience Platform 내에서 해당 역할을 자세히 살펴보십시오.

또한 이 안내서는 스키마 디자인에 대한 주요 고려 사항만 다룹니다. 따라서 이 안내서에서 언급된 개별 스키마 요소에 대한 자세한 설명은 스키마 구성의 기본 사항을 참조하는 것이 좋습니다.

모범 사례 요약

Experience Platform에서 사용할 데이터 모델을 디자인하는 데 권장되는 접근 방법은 다음과 같이 요약할 수 있습니다.

1. 데이터에 대한 비즈니스 사용 사례를 이해합니다.
2. 이러한 사용 사례를 해결하기 위해 Platform로 가져와야 하는 기본 데이터 소스를 식별합니다.
3. 관심이 있을 수도 있는 모든 보조 데이터 소스를 식별합니다. 예를 들어 현재 조직의 한 비즈니스 단위만 데이터를 Platform에 포팅하는 데 관심이 있는 경우, 유사한 비즈니스 단위도 향후 유사한 데이터를 포팅하는 데 관심이 있을 수 있습니다. 이러한 보조 소스를 고려하면 전체 조직의 데이터 모델을 표준화하는 데 도움이 됩니다.
4. 식별된 데이터 소스에 대한 높은 수준의 엔티티 관계 다이어그램(ERD)을 만듭니다.
5. 높은 수준 ERD를 Platform 중심의 ERD(프로필, 경험 이벤트 및 조회 엔티티 포함)로 변환합니다.

비즈니스 사용 사례를 수행하는 데 필요한 해당 데이터 소스를 식별하는 것과 관련된 단계는 조직마다 다릅니다. 이 문서 전체의 나머지 섹션은 데이터 소스가 식별된 후 ERD를 구성하고 구성하는 후기 단계에 중점을 두지만, 다이어그램의 다양한 구성 요소에 대한 설명은 데이터 소스를 Platform으로 마이그레이션해야 하는 결정에 알릴 수 있습니다.

높은 수준의 ERD 만들기

가져올 데이터 소스를 결정했으면 Platform에 데이터를 매핑하는 프로세스를 안내하는 높은 수준의 ERD를 만드십시오.

아래 예는 Platform으로 데이터를 가져오려는 회사에 대한 간소화된 ERD를 나타냅니다. 이 다이어그램에서는 고객 계정, 호텔, 주소 및 여러 가지 일반적인 전자 상거래 이벤트를 포함하여 XDM 클래스로 분류해야 하는 필수 엔터티를 소개합니다.

프로필, 조회 및 이벤트 카테고리로 엔티티 정렬

Platform에 가져올 필수 엔티티를 식별하기 위해 ERD를 생성한 후에는 이러한 엔티티를 프로필, 조회 및 이벤트 카테고리로 정렬해야 합니다.

엔티티 정렬에 대한 고려 사항

아래 섹션에서는 위의 카테고리로 엔티티를 정렬하는 방법에 대한 추가 지침을 제공합니다.

고객 속성

엔티티에 개별 고객과 관련된 속성이 포함되어 있는 경우 프로필 엔티티일 수 있습니다. 고객 속성의 예는 다음과 같습니다.

• 이름, 생년월일, 성별 및 계정 ID와 같은 개인 세부 사항입니다.
• 주소 및 GPS 정보와 같은 위치 정보.
• 전화 번호 및 이메일 주소와 같은 연락처 정보입니다.

시간에 따른 데이터 추적

시간에 따라 엔티티 내의 특정 속성이 변경되는 방법을 분석하려는 경우 이벤트 엔티티일 수 있습니다. 예를 들어 장바구니에 제품 항목을 추가하는 것은 Platform에서 장바구니에 추가 이벤트로 추적할 수 있습니다.

세그먼테이션 사용 사례

엔티티를 분류할 때 특정 비즈니스 사용 사례를 해결하기 위해 작성할 수 있는 대상 세그먼트에 대해 고려하는 것이 중요합니다.

예를 들어, 한 회사는 작년 5회 이상 구매한 충성도 프로그램의 "골드" 또는 "플래티넘" 멤버들을 모두 알고 싶어합니다. 이 세그먼트 로직을 기반으로 관련 엔티티가 표시되어야 하는 방식에 대해 다음 결론에 도달할 수 있습니다.

• "골드" 및 "플래티넘"은 개별 고객에게 적용되는 충성도 상태를 나타냅니다. 세그먼트 로직은 고객의 현재 충성도 상태와만 관련되므로 이 데이터를 프로필 스키마의 일부로 모델링할 수 있습니다. 시간이 지나면서 충성도 상태의 변경 사항을 추적하려는 경우 충성도 상태 변경에 대한 추가 이벤트 스키마를 생성할 수도 있습니다.
• 구매는 특정 시간에 발생하는 이벤트이며, 세그먼트 로직은 지정된 기간 내의 구매 이벤트와 관련이 있습니다. 따라서 이 데이터는 이벤트 스키마로 모델링해야 합니다.

활성화 사용 사례

세그먼테이션 사용 사례에 대한 고려 사항 외에 관련 속성을 추가로 식별하려면 해당 세그먼트에 대한 활성화 사용 사례를 검토해야 합니다.

예를 들어, 한 회사가 country = US 규칙을 기반으로 대상 세그먼트를 빌드했습니다. 그런 다음 해당 세그먼트를 특정 다운스트림 타겟으로 활성화할 때 회사는 홈 상태를 기반으로 내보낸 모든 프로필을 필터링하려고 합니다. 따라서 해당 프로필 엔티티에도 state 속성을 캡처해야 합니다.

집계된 값

데이터의 사용 사례와 세부기간을 기반으로, 프로필 또는 이벤트 엔티티에 포함되기 전에 특정 값을 미리 집계해야 하는지 여부를 결정해야 합니다.

예를 들어 한 회사에서 장바구니 구매 횟수를 기반으로 세그먼트를 구축하려고 합니다. 타임스탬프가 지정된 각 구매 이벤트를 자체 엔티티로 포함하여 가장 낮은 세부 기간에 이 데이터를 통합하도록 선택할 수 있습니다. 하지만, 경우에 따라 기록된 이벤트의 수가 기하급수적으로 증가할 수 있습니다. 수집된 이벤트 수를 줄이려면 1주 또는 1개월 동안 집계 값 numberOfPurchases을 만들도록 선택할 수 있습니다. MIN 및 MAX와 같은 기타 집계 기능도 이러한 상황에 적용할 수 있습니다.

카디널리티

ERD에서 확립된 카디널리티브는 개체를 분류하는 방법에 대한 몇 가지 단서를 제공할 수도 있습니다. 두 엔티티 간에 일대다 관계가 있는 경우 "다"를 나타내는 엔티티는 이벤트 엔티티가 될 수 있습니다. 하지만 "many"가 프로필 엔티티 내에 배열로 제공되는 조회 엔티티 세트인 경우도 있습니다.

다음 표에서는 몇 가지 공통 엔티티 관계와 이러한 관계를 파생시킬 수 있는 카테고리를 설명합니다.

다른 엔티티 클래스의 장단점

이전 섹션에서는 엔티티를 분류하는 방법을 결정하는 몇 가지 일반적인 지침을 제공했지만 한 엔티티 카테고리를 다른 카테고리에서 선택하는 장단점이 종종 있을 수 있음을 이해하는 것이 중요합니다. 다음 사례 연구는 이러한 상황에서 선택 사항을 고려하는 방법을 설명하기 위한 것입니다.

한 회사는 한 고객이 많은 구독을 가질 수 있는 고객의 활성 가입을 추적합니다. 또한 이 회사에서는 활성 구독이 있는 모든 사용자 찾기 등의 세그멘테이션 사용 사례 구독을 포함하려고 합니다.

이 시나리오에서는 데이터 모델에서 고객의 구독을 나타내는 두 가지 잠재적인 옵션이 있습니다.

1. 프로필 속성 사용
2. 이벤트 엔티티 사용

접근 방법 1:프로필 속성 사용

첫 번째 방법은 고객의 프로필 엔티티 내에 구독 배열을 속성으로 포함하는 것입니다. 이 배열의 개체에는 category, status, planName, startDate 및 endDate에 대한 필드가 포함됩니다.

장점

• 의도한 사용 사례에 대해 세그먼테이션을 사용할 수 있습니다.
• 이 스키마는 고객에 대한 최신 구독 레코드만 보존합니다.

단점

• 배열의 모든 필드가 변경될 때마다 전체 배열을 다시 설정해야 합니다.
• 다른 데이터 소스 또는 사업부가 데이터를 스토리지에 제공하는 경우 모든 채널에서 업데이트된 최신 스토리지를 계속 동기화해야 하는 문제가 발생할 수 있습니다.

방법 2:이벤트 엔터티 사용

두 번째 방법은 이벤트 스키마를 사용하여 구독을 나타내는 것입니다. 여기에는 구독 ID, 고객 ID 및 구독 이벤트가 발생한 시간의 타임스탬프를 추가하여 첫 번째 접근 방식과 동일한 구독 필드를 섭취하는 작업이 포함됩니다.

장점

• 세그먼테이션 규칙은 보다 유연하게 대처할 수 있습니다(예: 지난 30일 동안 구독을 변경한 모든 고객 찾기).
• 고객의 구독 상태가 변경되면 고객의 프로필 속성 내에서 길고 복잡한 배열을 더 이상 업데이트할 필요가 없습니다. 이 기능은 여러 소스에서 고객의 구독 목록을 동시에 변경하는 경우에 특히 유용합니다.

단점

• 세그먼테이션은 원래 의도한 사용 사례에 대해 더 복잡해집니다(고객의 가장 최근 구독 상태 확인). 이제 세그먼트에 고객의 상태를 확인하기 위해 고객에 대한 마지막 구독 이벤트에 플래그를 지정하는 추가 로직이 필요합니다.

분류된 엔터티를 기반으로 스키마 만들기

엔티티를 프로필, 조회 및 이벤트 카테고리로 정렬했으면 데이터 모델을 XDM 스키마로 변환하기 시작할 수 있습니다. 데모 목적으로 이전에 표시된 예제 데이터 모델은 다음 다이어그램에서 적절한 카테고리로 정렬되었습니다.

엔티티가 정렬된 카테고리는 스키마의 기반이 되는 XDM 클래스를 결정해야 합니다. 반복하려면:

• 프로필 엔터티는 XDM Individual Profile 클래스를 사용해야 합니다.
• 이벤트 엔터티는 XDM ExperienceEvent 클래스를 사용해야 합니다.
• 조회 엔티티는 조직에서 정의한 사용자 정의 XDM 클래스를 사용해야 합니다.

아래 섹션에서는 ERD를 기반으로 스키마를 구성하는 방법에 대한 일반적인 지침을 제공합니다.

반복적인 모델링 방법 적용

스키마 진화 규칙에서는 스키마 구현이 완료되면 비파괴 변경 사항만 스키마에 적용할 수 있도록 합니다. 즉, 스키마에 필드를 추가하고 해당 필드에 대해 데이터를 수집한 후에는 필드를 더 이상 제거할 수 없습니다. 따라서 스키마를 처음 만들 때 시간이 지남에 따라 복잡성을 점진적으로 늘리는 간소화된 구현부터 시작하여 반복적인 모델링 방법을 적용하는 것이 중요합니다.

스키마에 특정 필드를 포함해야 하는지 여부를 모를 경우 모범 사례는 제외합니다. 나중에 필드가 필요하다고 확인되면 항상 스키마의 다음 반복에 추가할 수 있습니다.

ID 필드

Experience Platform에서 ID로 표시된 XDM 필드는 여러 데이터 소스에서 온 개별 고객에 대한 정보를 결합하는 데 사용됩니다. 스키마에 ID로 표시된 여러 필드가 있을 수 있지만, Real-time Customer Profile에서 사용할 수 있도록 스키마를 활성화하려면 단일 기본 ID를 정의해야 합니다. 이러한 필드의 사용 사례에 대한 자세한 내용은 스키마 작성 기본 사항의 ID 필드의 섹션을 참조하십시오.

스키마를 디자인할 때 관계형 데이터베이스 테이블의 모든 기본 키는 기본 ID에 대한 후보가 될 수 있습니다. 적용 가능한 ID 필드의 다른 예로는 고객 이메일 주소, 전화번호, 계정 ID 및 ECID가 있습니다.

응용 프로그램 스키마 필드 그룹 Adobe

Experience Platform은 다음 Adobe 응용 프로그램과 관련된 데이터를 캡처하기 위한 몇 가지 기본 XDM 스키마 필드 그룹을 제공합니다.

• Adobe Analytics
• Adobe Audience Manager
• Adobe Campaign
• Adobe Target

예를 들어 Adobe Analytics ExperienceEvent Template 필드 그룹을 사용하면 Analytics 특정 필드를 XDM 스키마에 매핑할 수 있습니다. 작업 중인 Adobe 애플리케이션에 따라 스키마에서 이러한 Adobe 제공 필드 그룹을 사용해야 합니다.

Adobe 응용 프로그램 필드 그룹은 개별 고객에 대한 표준 ID 값을 매핑하는 시스템 생성 읽기 전용 객체인 identityMap 필드를 사용하여 기본 ID를 자동으로 할당합니다.

Adobe Analytics의 경우 ECID가 기본 기본 ID입니다. 고객이 ECID 값을 제공하지 않으면 기본 ID가 대신 AAID로 설정됩니다.

다음 단계

이 문서에서는 Experience Platform을 위한 데이터 모델을 디자인하기 위한 일반적인 지침 및 모범 사례에 대해 다룹니다. 요약하려면:

• 스키마를 생성하기 전에 데이터 테이블을 프로필, 조회 및 이벤트 카테고리로 정렬하여 하향식 접근 방식을 사용합니다.
• 다양한 용도로 스키마를 디자인할 때 다양한 접근 방식과 옵션이 있는 경우가 많습니다.
• 데이터 모델은 세그먼테이션 또는 고객 여정 분석과 같은 비즈니스 사용 사례를 지원해야 합니다.
• 스키마를 가능한 한 단순하게 만들고, 반드시 필요한 경우에만 새 필드를 추가합니다.

준비가 되면 스키마를 만들고, 엔티티에 적절한 클래스를 지정하고, 데이터를 매핑할 필드를 추가하는 방법에 대한 단계별 지침은 UI에서 스키마 만들기 자습서를 참조하십시오.