10분
style
article-header-section

Adobe Analytics에서 Customer Journey Analytics(CJA)로 마이그레이션하려면 데이터 수집, 플랫폼 설정, 통합 전반에 걸쳐 신중하게 준비해야 합니다. 이 안내서에서는 원활한 전환을 보장하고 Adobe Experience Platform 내에서 CJA의 잠재력을 최대한 발휘하기 위한 주요 단계를 간략하게 설명합니다.

Adobe Analytics(AA)에서 Customer Journey Analytics(CJA)로의 마이그레이션은 기업이 Adobe Experience Platform(AEP) 내에서 보다 발전된 분석 기능을 활용할 수 있도록 하는 복잡하지만 중요한 전환입니다. 마이그레이션 전 프로세스는 주로 데이터 수집 방식과 현재 Adobe Analytics 설정 및 기존 통합에 따라 달라집니다.

이 안내서에서는 원활한 마이그레이션 계획 프로세스, 또는 CJA 준비 단계를 보장하기 위한 세 가지 주요 고려 사항을 살펴봅니다.

1. 데이터 수집 요구 사항 이해

데이터 품질의 중요성

"쓰레기를 입력하면 쓰레기가 출력됩니다." 데이터 수집은 분석의 기초가 되므로 고품질 데이터 수집을 보장하는 것은 필수 요건입니다. 마이그레이션 전에 추적 구현에 대해 철저히 검토하여 정확성과 일관성을 보장해야 합니다.

웹 SDK와 AppMeasurement 비교

마이그레이션의 가장 중요한 측면 중 하나는 현재 데이터 수집 설정을 평가하는 것입니다.

데이터 레이어 및 태그 관리 시스템 검토

마이그레이션은 데이터 수집 접근 방식을 다시 살펴보며 최적화할 수 있는 기회를 제공합니다.

접근 방법

다행히 저희 회사의 경우 이미 모든 플랫폼을 Web SDK로 마이그레이션했고 AEP 개념에도 익숙했습니다. 또한 데이터 레이어 및 태그 관리 설정이 모든 플랫폼에서 표준화되어 있었습니다(저희 회사는 CEDDL과 EDDL을 결합한 하이브리드 데이터 레이어 접근 방식을 사용합니다). 하지만 저희는 Launch 속성 및 SDR에 대해 철저한 감사를 실시했습니다. 페이지 및 이벤트 데이터와 같은 주요 속성이 높은 데이터 품질로 일관되게 추적되었는지 확인했습니다. SDR 내에서는 모든 속성을 비판적으로 평가했습니다. 즉, 각 속성의 필요성에 의문을 제기하고 CJA의 새로운 기능(파생 필드 등 구성 요소를 구성할 수 있는 기능)을 사용하여 해당 속성을 개선할 수 있는 방법을 평가했습니다.

2. Adobe Analytics 설정 평가

조직의 현재 Adobe Analytics 환경은 마이그레이션의 복잡성에 중요한 역할을 합니다. 주요 고려 사항에는 다음이 포함됩니다.

데이터 마이그레이션 전략

Adobe Analytics에서 CJA로 데이터를 마이그레이션할 때는 마이그레이션해야 하는 데이터와 적절한 기간(채우기 기간의 길이)을 결정하는 것이 중요합니다. 모든 것을 전송하기보다 이 기회를 활용하여 분석 설정 및 추적 계획을 다듬고 관련 있는 데이터만 포함하도록 하십시오.

기본적으로 Adobe에서는 13개월 동안 CJA로 내역 데이터를 가져오도록 지원합니다. 그러나 비즈니스 요구 사항에 따라 더 긴 데이터 보존 기간이 필요할 수 있습니다. 예시:

CJA 설정을 최적화하려면 데이터 보존 요구 사항과 스토리지 고려 사항의 균형을 맞추는 것이 중요합니다.

데이터 마이그레이션 방법 선택

데이터를 CJA에 전송하는 방법을 결정하는 것도 중요한 단계입니다. 주요 옵션으로는 다음 두 가지가 있습니다.

적합한 방법의 선택은 특정 데이터 요구 사항과 인프라에 따라 다릅니다. 데이터 마이그레이션 관련 교훈을 이 문서에서 확인하실 수 있습니다.

구성 요소 마이그레이션

이 전환은 구성 요소를 AA에서 CJA으로 일대일로 마이그레이션하지 않고 아예 새로 시작할 수 있는 기회를 제공합니다. 시간이 지남에 따라 Adobe Analytics 구현에 중복되었거나 오래되었거나 제대로 문서화되지 않은 구성 요소가 누적되는 경우가 많습니다.

접근 방법

저희 회사의 경우 구성 요소 마이그레이션 도구를 사용하지 않고 대신 간소화된 새 설정을 작성했습니다. 원활한 전환을 보장하기 위해 이해 관계자 분석으로 필수 대시보드가 무엇인지 파악했습니다. 이 작업으로 전체 보고서 및 구성 요소의 수를 50% 이상 줄이며 중복되거나 사용되지 않는 보고서 및 구성 요소를 제거했습니다. 이전에만 사용하던 요소가 넘어가지 않도록 세그먼트, 지표, 기타 구성 요소를 검토하고 세부 조정했습니다.

데이터 마이그레이션 방법으로는 Adobe 소스 커넥터의 제한 사항 때문에(저희 회사의 경우 새로운 CJA 설정에 eVar 및 속성을 원하지 않았습니다) 소스 커넥터가 아닌 데이터 피드를 선택했습니다. 저희는 단순히 기존의 복잡한 상태를 그대로 새 시스템으로 전송하기보다는 마이그레이션을 정리와 최적화를 위한 기회로 간주하여 결국 보다 효율적인 분석 환경을 만들었고, 그 결과 셀프 서비스 분석도 향상되었습니다.

3. 사용자 정의 통합 및 데이터 변환

이 단계가 마이그레이션에서 가장 어려운 부분인 경우가 많습니다. 많은 조직이 Adobe Analytics를 다음과 같은 서드파티 시스템과 통합합니다.

CJA는 AEP 내에서 작동하며 내보내기와 관련하여 몇 가지 제한 사항이 있으므로 다음과 같은 가능한 옵션을 활용해 통합을 재구성해야 합니다.

데이터 변환 과제

데이터 변환은 마이그레이션 과정에서 중요한 과제입니다. 표준 커넥터도 일정 수준의 변환을 제공하는 한편, API 기반 접근 방식(예: 쿼리 서비스)을 사용할 때는 관계형 구조(예: 테이블, 보기 또는 데이터 레이크)로 변환할 때 오브젝트 지향형 AEP 데이터를 신중하게 처리해야 합니다. 이 프로세스를 적절하게 구조화하고 최적화하는 것은 데이터를 여러 플랫폼에 걸쳐 사용할 수 있도록 하기 위해 필수적입니다.

접근 방법

저희 회사의 경우 일부 데이터를 내부 데이터 레이크로 전송하기는 했지만 데이터 가져오기 및 내보내기 설정은 비교적 간단했습니다. 이를 위해 FTP를 통한 일간 Data Warehouse 내보내기와 Data Warehouse API를 사용했습니다. 현재 CJA에서는 이러한 내보내기에 대한 옵션이 제한되어 있으므로(예: 전체 테이블 내보내기는 차원 10개 및 지표 10개까지 지원) AEP에서 데이터 세트를 기준으로 데이터를 내보내는 방법을 선택했습니다.

저희 회사에 필요한 결과에는 쿼리 서비스 API를 AEPP와 결합하는 것이 가장 효과적인 접근 방법임을 확인했습니다. 이 방법으로 회사 내부 데이터 레이크에서 데이터 세트에 액세스하고 필요에 따라 유지할 수 있었습니다. 하지만 데이터를 CJA가 아닌 AEP에서 가져왔기 때문에 마지막 클릭 속성이나 방문 기반 지표 등 유지되는 속성이 없었습니다. 이 간격을 메우기 위해 SQL과 Python을 사용하여 해당 요소를 다시 만들었습니다. 다행히도 Adobe에서는 방문 식별을 위해 사전 정의된 함수를 제공하고, 표준 SQL 창 함수를 사용하면 CJA에서 사용 가능한 모든 기능을 재구성할 수 있습니다.

이 프로세스를 수정하려면 내부 IT 리소스가 필요하므로 데이터 파이프라인을 미리 계획하는 것이 중요합니다. 가져오기/내보내기 작업이 많을수록 복잡도가 높아져 유지 관리 노력과 리소스 필요성이 모두 증가합니다. 프로세스를 최대한 간소화하면 데이터 일관성을 유지하면서 오버헤드를 최소화할 수 있습니다.

마무리

Adobe Analytics에서 Customer Journey Analytics으로 마이그레이션하는 것은 단순히 들어다 옮기면 끝나는 프로세스가 아니며, 신중한 계획 수립과 데이터 최적화 및 전략적 의사 결정이 필요합니다. 데이터 수집을 검토하고 구성 요소를 다듬고 신중하게 통합을 관리하면 비즈니스에서 불필요한 복잡성을 피하면서 CJA의 잠재력을 최대한 활용할 수 있습니다.

성공적인 마이그레이션은 AEP 내에서 더욱 강력하고 유연하며 미래에 대비한 분석 환경을 구축하는 기반을 마련합니다.

style
article-content-section