가장 흔히 오해하는 24가지 마케팅 데이터 용어

고객 유치(win-back) 캠페인을 계획 중인 마케터가 데이터 팀에 “비활성 고객” 목록을 요청하는 상황을 상상해 보세요. 여러분은 90일 동안 구매 이력이 없는 사람들을 예상하겠지만, 실제로 전달받은 목록은 30일 동안 앱을 열지 않은 사용자 기준일 수 있습니다. 데이터에서 “비활성”이 그렇게 정의되어 있기 때문입니다. 

또는 방금 주문을 완료한 사람에게 “보고 싶었어요”라는 메시지를 보내지 않기 위해 “실시간” 타겟 고객 업데이트를 요청할 수도 있습니다. 여러분은 15분마다 업데이트되는 목록을 머릿속에 그리고 있습니다. 하지만 데이터 팀은 이를 “수초 이내 업데이트”로 이해하고 새로운 인프라, 지속적인 비용, 더 길어진 일정에 대해 질문하기 시작합니다.

이러한 차이는 무엇을 구축할지, 비용이 얼마나 들지, 마케팅에서 언제 사용할 수 있는지에 영향을 미칩니다. '고객'이 무엇을 의미하는지, 어떤 상태가 되어야 타겟 고객이 준비된 것인지, 신호가 얼마나 최신이어야 하는지에 대해 초기에 합의하면 오해로 인해 캠페인을 처음부터 다시 작업해야 하는 상황을 방지할 수 있습니다.

이 가이드는 캠페인 실행에 관한 5가지 실용적인 질문을 중심으로 마케팅과 데이터 엔지니어링 부서가 종종 다르게 해석하는 24가지 용어를 다룹니다. 이 비교 정의를 대화의 시작점으로 활용해 보세요. 작업을 시작하기 전에 잠재적인 가정을 드러내고, 각 부서에 필요한 사항을 명확히 하며, 비즈니스에 적합한 의미에 합의할 수 있습니다.

인쇄 가능한 PDF 파일로 24가지 용어 전체 보기.

1. 캠페인 데이터는 어디에서 오나요?

마케팅 툴의 정보는 여러 시스템과 처리 단계에 따라 달라질 수 있습니다. 그 경로를 이해하면 필요한 사항을 더 잘 설명하고 변경 사항이 어디에 적용되어야 하는지 파악하는 데 도움이 됩니다. 예를 들어, “최종 구매일”이라는 필드가 있다고 가정해 보겠습니다. 이 필드를 사용해 이탈 고객을 식별하기 전에, 취소된 주문이 포함되는지, 어떤 시스템에서 해당 날짜를 제공하는지 먼저 합의해야 합니다.

합의할 사항: 값이 어디에서 오는지, 무엇을 포함하는지, 누가 관리하는지.

2. 고객 레코드는 누구를 나타내나요?

고객 식별 정보(identity)는 누가 포함되고 제외되는지, 혹은 더 최악의 경우 두 번 중복 집계되는지를 결정합니다. 먼저 하나의 레코드가 무엇을 나타내는지, 그리고 두 레코드가 동일한 대상에 속하는지 팀이 어떻게 판단할지 정의하는 것부터 시작하세요.

고객 관계에 대한 마케팅 부서의 지식은 엔지니어링 부서가 식별 정보에 대해 더 나은 결정을 내리는 데 도움이 됩니다. 고객 유치 예시에서 개인과 가구는 모두 고객 데이터를 정리하는 유용한 방법입니다. 캠페인을 진행할 때는 이 둘 중 하나를 명확히 선택해야 합니다. 가구 기준 뷰는 가구당 하나로 제한된 혜택을 제공할 때 적합할 수 있습니다. 개인 기준 뷰는 개인별 로열티 혜택에 적합할 수 있습니다.

공유 데이터 기반을 갖추면 팀이 이러한 목적에 맞게 명확하게 명명된 뷰를 유지하고 적절한 뷰를 재사용할 수 있습니다. 각 뷰에는 문서화된 정의, 레코드를 연결하는 데 사용되는 식별자, 매칭 규칙의 소유자가 필요합니다.

합의할 사항: 캠페인 타겟이 개인, 계정, 가구, 기기 중 무엇인지, 그리고 관련 레코드를 어떻게 매칭할지.

3. 어떤 상태가 되어야 타겟 고객을 활성화할 준비가 된 것인가요?

타겟 고객은 정의하는 규칙, 조건에 부합하는 레코드, 최종 목적지에서 사용할 수 있는 레코드 등 여러 단계를 거칩니다. 각 단계는 캠페인 준비 상태에 대한 서로 다른 질문에 답을 제공합니다.

예를 들어 50,000명이 세그먼트에 부합하지만 이메일 플랫폼에서는 이 중 47,000개의 레코드만 수락한다고 가정해 보겠습니다. 이 차이는 목적지 식별자 누락, 거부된 레코드 또는 전송 중에 적용된 제외 규칙 때문일 수 있습니다. 팀은 타겟 고객이 준비되었다고 판단하기 전에 이러한 차이가 발생하는 원인을 파악해야 합니다.

정의, 평가된 멤버십, 전송 결과를 명확히 구분하면 이 작업이 더 쉬워집니다. 마케팅 부서는 규칙이 의도한 타겟 고객을 제대로 표현하고 있는지 확인할 수 있습니다. 엔지니어링 부서는 올바른 레코드가 목적지에 도달했는지 확인할 수 있습니다. 양측 모두 예상된 제외 사항과 해결이 필요한 문제를 구분할 수 있게 됩니다.

예측을 수행할 때도 동일한 정밀함이 도움이 됩니다. 캠페인에 성향 점수(propensity score)가 필요한 경우, 예측의 이름과 그것이 무엇을 추정하고자 하는지 명확히 정의하세요. 그러면 팀이 단순히 “모델”을 만드는 것보다 더 구체적으로 구축하고 검증할 수 있습니다.

합의할 사항: 타겟 고객 선택 규칙, 필요한 예측 또는 속성, 그리고 전송 결과 검증 방법.

4. 데이터가 충분히 최신 상태인 때는 언제일까요?

최신성(Freshness)은 내리려는 고객 결정에 따라 달라집니다. 단일 캠페인이라도 데이터가 하나의 플랫폼에서 제공되더라도 여러 시간 요구사항이 있을 수 있습니다.

매일 밤 계산되어 15분마다 인게이지먼트 툴로 전송되는 이탈 점수(churn score)를 생각해 보세요. 더 자주 전송한다고 해서 예측이 15분 전의 것이 되는 것은 아닙니다. 여전히 야간 계산을 기반으로 합니다.

이제 오늘 아침에 구매한 고객을 추가해 보겠습니다. 캠페인은 다음 전송 전에 해당 고객을 윈백(win-back) 타겟에서 제외해야 할 수 있지만, 이탈 점수는 예약된 다음 계산까지 기다려도 됩니다. 이는 고객에게 서로 다른 영향을 미치는 별개의 요구사항입니다.

최신성을 의미 있게 만들려면 지연의 시작과 끝을 식별해야 합니다. 즉, 구매 발생부터 데이터 플랫폼에서 사용 가능해질 때까지, 사용 가능 시점부터 멤버십 변경까지, 또는 멤버십 변경부터 대상 시스템이 이를 처리할 수 있을 때까지의 지연을 파악해야 합니다.

이러한 구분을 통해 팀은 경험을 변화시키는 속도에 투자할 수 있습니다. 또한 마케팅 부서에서 전체 캠페인이 "실시간"이어야 한다고 말하는 대신 문제를 더 잘 설명할 수 있는 방법을 제공합니다.

합의할 사항: 어떤 고객 이벤트가 시작점이 되는지, 업데이트된 데이터를 어디에서 사용할 수 있어야 하는지, 그리고 허용 가능한 지연 시간은 얼마인지.

5. 데이터가 사용될 때 책임은 누구에게 있을까요?

고객 데이터에 접근할 수 있게 되면 데이터의 의미, 허용된 사용 범위, 지속적인 소유권에 대한 의문이 생깁니다. 이러한 책임은 타겟 데이터가 데이터 플랫폼을 벗어난 후에도 계속 유지됩니다.

실제로 거버넌스는 데이터 품질, 소유권 및 적절한 사용도 다룹니다. 유용한 출발점은 각 결정에 대해 지정된 소스를 식별하는 것입니다. 고객 식별자를 설정하는 시스템은 채널 선호도를 기록하거나 매출을 계산하는 시스템과 다를 수 있습니다.

그런 다음 데이터를 대상 시스템까지 추적해 보세요. 내보낼 당시에는 대상이었던 타겟이라도 나중에 전송하기 전에 업데이트된 제외(suppression) 처리가 필요할 수 있습니다. 저장된 복사본은 이를 생성한 캠페인보다 더 오래 유지될 수 있습니다. 팀은 변경 사항이 대상 시스템에 어떻게 도달하는지, 그리고 도달하지 않았을 때 누가 그 작업을 책임지는지 알아야 합니다.

Databricks CustomerLake(에이전틱 CDP)는 고객 데이터 플랫폼 기능을 Databricks 및 해당 거버넌스 기반에 기본적으로 통합합니다. 이 공유된 기반에서 작업함으로써 마케팅 팀과 데이터 팀은 신뢰할 수 있는 고객 컨텍스트를 공유할 수 있는 공간을 확보하게 됩니다. 

합의할 사항: 각 결정에 대한 신뢰할 수 있는 소스, 허용된 사용 범위, 대상 시스템에서의 업데이트 담당자.

실천 과제: 하나의 합의를 단일 캠페인을 넘어 유용하게 활용하기

Databricks를 기반으로 구축하는 팀의 다음 단계는 이러한 중요한 합의를 재사용 가능하게 만드는 것입니다. 팀은 비즈니스 정의를 Unity Catalog에 문서화한 다음, Genie에서의 분석, CustomerLake에서의 타겟 구축 또는 ML 모델 개발에서 검색하여 사용할 수 있도록 만들 수 있습니다. 새로운 캠페인을 진행할 때마다 마케팅과 데이터 엔지니어링 부서가 이미 합의하고 실행에 옮긴 정의를 기반으로 삼을 수 있습니다.

최근 캠페인에서 혼란을 야기했던 용어를 하나 선택해 보세요. 데이터 팀과 함께 한 명의 고객 사례를 살펴보며 문제를 해결한 다음, 다음번에 데이터를 사용하는 사람이 찾을 수 있는 곳에 그 결정을 기록해 두세요.

"고객"의 경우 레코드가 나타내는 의미와 그 뒤에 있는 식별자를 명명하는 것을 의미합니다. "최근 구매일"의 경우 어떤 거래를 포함할지 문서화하는 것을 의미합니다. "타겟 준비 완료"의 경우 출시 전에 무엇을 확인해야 하는지 합의하는 것을 의미합니다.

합의된 의미를 이를 구현하는 데이터 세트 또는 워크플로우에 연결하고, 변경 사항이 발생할 때 누가 관여해야 하는지 식별하세요. 문서화와 구현은 함께 발전해야 합니다.

이는 마케터가 자연어 도구와 AI 에이전트에게 고객 데이터 작업을 요청할 때 특히 유용합니다. "가장 가치 있는 이탈 고객 찾기"라는 요청은 가치, 비활성 상태, 신원, 권한에 대해 여전히 모호한 해석의 여지를 남겨둡니다. 명확한 지침이 없으면 AI는 스스로 결정을 내리게 되며, 매번 다른 결정을 내릴 것입니다. AI 도구에 명확한 비즈니스 정의와 컨텍스트를 제공하면 더 일관되고 우수한 결과를 얻을 수 있습니다.

다음 캠페인에 참여하는 사람이 원래 회의에 참석했던 사람들을 찾지 않고도 결정을 이해할 수 있는지 테스트해 보는 것이 좋습니다. 이해할 수 있다면 팀은 재사용 가능한 자산을 만든 것입니다.

이 시리즈에 대하여

마케터가 데이터 엔지니어링과 소통하도록 돕기는 MartechTherapy의 Matthew Niederberger와 협력하여 개발된 6부작 시리즈입니다. 이 문서에 포함된 24개의 정의는 Databricks의 후원을 받아 독립적으로 제작된 그의 가이드에서 발췌한 것입니다. 

다음 회의에 지참할 수 있는 인쇄용 참고 자료와 그의 관점을 확인하려면 Matthew의 원본 기사인 Same word, different meaning을 읽어보세요.

시리즈의 다음 편: 실행 가능한 데이터 요청서를 작성하는 방법.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)