데이터 웨어하우스를 CDP로 사용해야 합니까?

클라우드 기반 데이터 웨어하우스(DWH)의 출현으로 점점 더 많은 데이터 기반 사용 사례에 더 간단한 배포, 더 큰 규모 및 더 나은 성능을 제공했습니다. DWH는 마테크 스택을 포함하여 엔터프라이즈 기술 스택에서 더욱 보편화되었습니다.

필연적으로 이것은 질문을 던집니다. 기존 DWH를 고객 데이터 플랫폼(CDP)으로 사용해야 합니까? 결국 스택의 기존 구성 요소를 재사용하면 리소스를 절약하고 새로운 위험을 피할 수 있습니다.

그러나 이야기는 그렇게 간단하지 않으며 다양한 잠재적인 디자인 패턴이 기다리고 있습니다. 궁극적으로 DWH를 CDP로 사용하는 경우와 반대하는 경우가 있습니다. 더 깊이 파고들자.

CDP로서의 DWH는 귀하에게 적합하지 않을 수 있습니다.

DWH를 CDP로 사용하는 데는 몇 가지 고유한 문제가 있습니다. 첫 번째는 분명합니다. 모든 조직에 DWH가 있는 것은 아닙니다. 때로는 엔터프라이즈 DWH 팀에 고객 중심 사용 사례를 지원할 시간이나 리소스가 없습니다. 다른 기업에서는 CDP를 유사 데이터 웨어하우스로 효과적으로 배포합니다. (모든 CDP가 이 작업을 수행할 수 있는 것은 아니지만 요점은 알 수 있습니다.)

DWH에 대부분 또는 모든 고객 데이터가 있다고 가정해 보겠습니다. 대부분은 아니지만 많은 기업의 문제는 데이터에 마케터 친화적인 방식으로 액세스할 수 없다는 것입니다. 일반적으로 엔터프라이즈 DWH는 활성화 사용 사례가 아닌 분석 사용 사례를 지원하도록 구성됩니다. 이는 데이터가 내부적으로 레이블 지정, 관리, 관련 및 관리되는 방식에 영향을 미칩니다.

DWH는 본질적으로 저장 및 컴퓨팅을 위한 것입니다. 즉, 데이터는 속성으로 열 이름이 있는 데이터베이스 테이블에 저장됩니다. 그런 다음 복잡한 SQL 문을 작성하여 해당 데이터에 액세스합니다. 마케팅 담당자가 활성화를 위한 세그먼트를 생성하기 전에 테이블 및 열 이름을 기억하는 것은 비현실적입니다. 즉, DWH는 일반적으로 대부분의 CDP처럼 마케터 셀프 서비스를 지원하지 않습니다.

이것은 또한 더 광범위한 구조적 문제를 다룹니다. DWH는 일반적으로 많은 CDP가 목표로 하는 실시간 마케팅 사용 사례를 지원하도록 설계되지 않았습니다. 빠른 계산을 수행할 수 있고 수집 및 처리가 빈번한 간격으로 발생하도록 예약할 수 있지만 여전히 실시간은 아닙니다. 마찬가지로 일부 예외를 제외하고 DWH는 원시 데이터에 따라 행동하기를 원하지 않는 반면 마케터는 종종 특정 활성화를 트리거하기 위해 원시 데이터(일반적으로 이벤트)를 사용하기를 원합니다.

마지막으로, 데이터와 이에 액세스하는 기능이 CDP를 만들지 않는다는 점을 기억하십시오. 대부분의 CDP는 다음과 같이 DWH에서 찾을 수 없는 일부 추가 기능을 제공합니다.

• 트리거링이 있는 이벤트 하위 시스템.
• 익명 신원 확인.
• 세분화를 위한 마케터 친화적인 인터페이스.
• 커넥터가 있는 세그먼트 활성화 프로필.
• 잠재적으로 테스트, 개인화 및 추천 서비스.

DWH만으로는 이러한 기능을 제공하지 않으므로 다른 곳에서 소싱해야 합니다. 물론 DWH 공급업체는 상당한 규모의 파트너 마켓플레이스를 보유하고 있습니다. 많은 대안을 찾을 수 있지만 기본이 아니며 통합 및 지원 노력이 필요합니다.

당연히 "컴포저블 CDP"와 그 맥락에서 DWH의 잠재적인 역할에 대해 많은 대화가 있습니다. 나는 이전에 결합 가능성이 스펙트럼이며 특정 지점을 넘어서면 이점을 잃기 시작한다고 주장했습니다.

이러한 모든 경고를 발행한 DWH는 다음을 포함하여 고객 데이터 스택의 일부로 역할을 수행할 수 있습니다.

• DWH에서 직접 활성화하여 CDP를 제거합니다.
• DWH를 역방향 ETL 플랫폼과 함께 준 CDP로 사용합니다.
• CDP와 공존.

이 세 가지 디자인 패턴을 살펴보겠습니다.

1. 마케팅 플랫폼을 DWH에 직접 연결

이것은 내가 위에서 비판한 가장 극단적인 경우일 수 있지만 일부 기업은 특히 CDP 이전 시대에 이 작업을 수행했으며 플랫폼(광범위한 생태계가 있는 Snowflake와 같은)은 이 문제를 해결하려고 합니다.

여기서 아이디어는 참여 플랫폼이 DWH를 사용하여 푸시-풀 데이터에 직접 연결된다는 것입니다. 많은 성숙한 이메일 및 마케팅 자동화 플랫폼은 기본적으로 일괄 푸시를 통해 이를 수행하도록 연결되어 있습니다. 그런 다음 마케팅 담당자는 메시징 플랫폼을 사용하여 세그먼트를 만들고 아웃바운드 마케팅의 경우 해당 세그먼트에 메시지를 보냅니다.

다른 마케팅 또는 참여 플랫폼, 개인화된 웹사이트 또는 전자상거래 플랫폼이 있다고 상상해 보십시오. 다시 DWH에서 데이터를 가져온 다음 웹 응용 프로그램 플랫폼을 사용하여 보다 표적화된 참여를 위한 또 다른 세그먼트 집합을 만듭니다.

아직 문제가 보이지 않습니까? 이미 두 세트의 세분화 인터페이스가 있습니다. 10개의 마케팅 플랫폼이 있다면 어떻게 될까요? 20? 모든 곳에서 세그먼트를 계속 생성하므로 옴니채널 약속이 사라집니다.

마지막으로 DWH에서 직접 수집을 지원하지 않는 다른 마케팅 플랫폼을 추가해야 한다면 어떻게 될까요?

2. 역 ETL 도구로 DWH 사용

이 접근 방식은 위의 첫 번째 패턴과 관련된 몇 가지 문제를 해결합니다. 특히, (이론적으로) 비 DWH 전문가가 DWH 위에 가상으로 범용 세그먼트를 생성하고 여러 플랫폼을 활성화할 수 있습니다. 변환 및 더 나은 커넥터 프레임워크를 통해 다양한 레이블 매핑과 마케팅 담당자에게 친숙한 데이터 구조를 다양한 엔드포인트에 적용할 수 있습니다.

작동 방식은 다음과 같습니다. 역방향 ETL 플랫폼은 DWH에서 데이터를 가져와 변환 후 마케팅 플랫폼으로 보냅니다. 여러 변환을 수행하고 해당 데이터를 여러 대상으로 동시에 보낼 수 있습니다. 이를 자동화하고 사전 정의된 일정에 따라 정기적으로 내보내기를 실행할 수도 있습니다.

그러나 해당 데이터의 복사본(또는 그 하위 집합)은 실제로 대상 플랫폼에 복사되므로 데이터 복사본이 하나만 있는 것은 아닙니다. 역방향 ETL 플랫폼에는 데이터 사본이 없기 때문에 필수 세그먼트 또는 대상은 항상 쿼리 시간에 생성됩니다(일반적으로 일괄 처리). 그런 다음 대상으로 내보냅니다.

이벤트를 기반으로 하는 실시간 트리거 또는 상시 캠페인을 원하는 경우에는 적합한 접근 방식이 아닙니다. 물론 높은 빈도로 내보내기를 자동화할 수 있지만 실시간은 아닙니다. 수출 빈도를 높이면 비용이 기하급수적으로 증가합니다.

또한 역 ETL 도구는 세분화 인터페이스를 제공하지만 MOps 중심보다는 기술 및 DataOps 중심인 경향이 있습니다. 마케터 셀프 서비스에 적합한 "비즈니스 친화적" 솔루션이라고 선언하기 전에 신중하게 테스트해야 합니다.

3. CDP와 DWH의 공존

엔터프라이즈 DWH는 데이터를 CDP(다른 엔드포인트 중에서)에 제공하는 고객 데이터 인프라 계층 역할을 합니다. 대부분은 아니더라도 많은 CDP는 이제 DWH 플랫폼, 특히 Snowflake에서 동기화할 수 있는 몇 가지 기능을 제공합니다.

이러한 CDP가 DWH와 공존할 수 있는 방법에는 차이가 있습니다. 대부분의 CDP는 데이터를 리포지토리에 동기화하고 복제하지만 다른 CDP(역 ETL 공급업체 포함)는 복사본을 만들지 않습니다. 그러나 귀하에게 적합한 것을 최종 결정하기 전에 고려해야 할 장단점이 있을 수 있습니다.

일반적으로 고객 신원 확인과 같은 중요한 서비스가 궁극적으로 상주하는 위치에 따라 큰 차이가 있지만 대기업이 이 디자인 패턴을 선호하는 경향이 있습니다.

자세히 알아보기: 마테크 스택에서 CDP는 어디에 적합해야 합니까?

마무리

DWH 플랫폼은 마테크 스택에서 점점 더 중요한 역할을 합니다. 그러나 데이터 에코시스템 내에서 렌더링하는 서비스에 대한 여러 아키텍처 선택 사항이 계속해서 있습니다.

앞으로 CDP를 배제하는 것은 시기상조라고 생각합니다. 각 패턴에는 옵션을 평가할 때 염두에 두어야 할 장단점이 있습니다.