수익 어트리뷰션을 위한 단일 진실 공급원 구축하기

수익 조직에 있는 세 사람에게 지난 분기 몇 건의 거래가 성사되었는지 물어보면 아마 세 개의 숫자를 얻게 될 것입니다. 마케팅은 자동화 플랫폼에서, 영업은 CRM에서, 재무는 청구 시스템에서 가져오며, 각자 자신의 숫자를 20분 동안 방어할 수 있습니다. 저희는 그런 회의에 앉아본 적이 있습니다. 정확히 말하면 아무도 틀리지 않았습니다. 하지만 기본적인 집계 수치가 일단 어긋나면, 그 위에 구축된 모든 어트리뷰션 모델은 그 불일치를 물려받고, 아무리 정교한 모델링도 서로 충돌하는 사실에서 시작한 분석을 고치지 못합니다.

어트리뷰션을 위한 단일 진실 공급원은 나머지 모든 것을 믿을 수 있게 만드는 지루한 인프라입니다. 그것은 대시보드가 아니고, 매달 마지막 금요일에 누군가 손으로 맞춰보는 스프레드시트도 아닙니다. 그것은 아이덴티티, 이벤트, 수익이 매번 같은 방식으로 조인되는 거버넌스된 데이터 계층입니다. 다음은 실제로 이를 구축하는 데 필요한 것들입니다.

숫자가 서로 어긋나는 이유

파편화는 누군가 일을 못했다는 신호가 아닙니다. 이는 성장하는 모든 스택에 일어나는 일입니다. 여러분이 도입하는 각 도구는 그 자신의 식별자, 그 자신의 타임스탬프, 그리고 사물이 무엇인지에 대한 그 자신의 정의를 가진, 현실의 자기 조각에 대한 시스템 오브 레코드입니다.

• CRM은 계정과 기회를 알지만, 회사 레코드는 오래되었거나 중복되어 있습니다.
• 마케팅 플랫폼은 연락처와 참여도를 알지만, 종종 한 사람을 올바른 계정에 연결하지 못합니다.
• 제품 데이터베이스는 사용량을 알지만, 영업 측의 어떤 것에도 매핑되지 않는 내부 사용자 ID로 키가 지정되어 있습니다.
• 청구 시스템은 실제로 청구된 것을 알지만, CRM의 계정 계층 구조와 일치하지 않는 계정 계층 구조를 사용합니다.

이 각각은 내부적으로는 일관되지만 서로와는 호환되지 않습니다. 이는 왜 여러분의 수익 스택이 파편화되고 있는지의 배후에 있는 것과 동일한 조건입니다. 어트리뷰션은 그저 그 고통이 가장 시끄럽게 나타나는 지점일 뿐입니다. 어트리뷰션은 이 모든 것을 한 번에 가로질러 조인해야 하기 때문입니다.

세 개의 조인이 전체를 떠받친다

작동하는 SSOT는 세 가지 아이덴티티 문제를 해결하는 것으로 귀결됩니다. 이것들을 제대로 해내면 대부분의 하위 분석이 다루기 쉬워집니다. 잘못 해내면 모든 모델이 조용히 훼손되고, 보통 누군가 고위층에서 날카로운 질문을 던지기 전까지는 알아차리지 못합니다.

연락처 대 계정이 첫 번째입니다. 모든 사람은 이메일 도메인, 자회사, 그리고 어느 부사장이 웨비나에 가입할 때 사용한 개인 지메일 주소를 가로질러 올바른 회사로 해석되어야 합니다. 이것이 없으면 한 계정에서 여섯 명이 모두 여러분을 평가하고 있다는 것을 볼 수 없고, 이는 구매 위원회 분석이 아예 불가능하다는 뜻입니다.

계정 계층 구조가 두 번째입니다. 모회사, 자회사, 인수된 브랜드, 지역 부서. 이것들이 일관되게 롤업되지 않으면, 하나의 글로벌 계정이 아무도 서로 연결하지 않는 열두 개의 무관한 소규모 계정처럼 보이고 그 수익은 흩어집니다.

접점 대 수익이 세 번째입니다. 모든 마케팅 및 영업 상호작용은 그것이 관련된 기회에, 그리고 결국에는 청구된 수익에, 무엇이 기회로 간주되고 언제 시작되는지에 대한 하나의 정의를 사용해 조인되어야 합니다.

바로 여기에 실제 엔지니어링이 있습니다. 퍼지 매칭, 결정론적 키, 강화, 중복 제거. 이 모든 것은 하나의 목표, 즉 모든 시스템이 동의하는 모든 계정과 사람에 대한 안정적이고 표준화된 아이덴티티를 위해 존재합니다.

영리한 SQL보다 거버넌스가 더 중요하다

이를 기술 프로젝트로 취급하고 싶은 본능이 있습니다. 모든 것을 웨어하우스로 파이핑하고, 모델을 좀 작성하면 끝. 하지만 저희 경험상 배관은 좀처럼 실패하는 부분이 아닙니다. 정의가 실패합니다. 마케팅이 MQL을 한 방식으로 세고 영업이 자격을 갖춘 기회를 다른 방식으로 센다면, 저장소를 통합하는 것은 그저 논쟁을 다른 방으로 옮길 뿐입니다.

그래서 지속 가능한 SSOT는 엔지니어링과 함께 거버넌스가 필요합니다. 이는 계정, 기회, 단계, 수익에 대해 하나의 합의된 의미가 있어야 하고, 이것이 팀별이 아니라 누군가에 의해 공동으로 소유되어야 한다는 뜻입니다. 어떤 시스템이 어떤 사실에 대해 권위를 갖는지(수익에 대해서는 청구 시스템, 단계에 대해서는 CRM) 결정하고 더 이상 모든 시스템의 버전을 동등하게 유효한 것으로 취급하지 않는다는 뜻입니다. 사용자가 각 필드가 얼마나 최신인지, 어디서 왔는지 볼 수 있어야 한다는 뜻입니다. 지난주 스냅샷에 기반한 어트리뷰션은 오해를 불러일으키기 때문입니다. 그리고 통합된 계층에 대한 폭넓은 접근이 명확한 소유권과 짝을 이루어, 정의가 한 분기 안에 다시 갈라지지 않도록 해야 한다는 뜻입니다.

이는 또한 그 숫자들이 재무와의 접촉에서 살아남게 하는 규율이며, 이는 왜 여러분의 CFO가 어트리뷰션을 불신하는가 전체의 주제입니다. CFO는 더 예쁜 차트를 원하지 않습니다. 그 숫자가 총계정원장과 일치하는지 알고 싶어합니다.

충분한 아키텍처, 과하지 않게

시작하는 데 2년짜리 데이터 플랫폼 이니셔티브가 필요하지는 않지만, 올바른 형태는 필요합니다. 실용적인 버전은 계층화되어 있습니다. 모든 출처로부터의 원시 수집, 표준 키를 할당하는 아이덴티티 해석 단계, 이벤트가 거버넌스된 정의 하에 계정과 수익으로 조인되는 모델링된 계층, 그리고 리포팅과 활성화 모두에 정보를 제공하는 서빙 계층입니다. 더 완전한 청사진은 수익 플랫폼을 위한 참조 아키텍처에 있습니다.

두 가지가 이것이 부풀어 오르지 않게 막아줍니다.

리포팅뿐 아니라 활성화를 위해서도 모델링하십시오. 대시보드에만 정보를 제공하는 SSOT는 절반만 구축된 것입니다. 동일한 통합 계층이 담당자에게 실시간 신호와 다음 최선의 행동을 제공해야 하며, 이는 흩어진 데이터를 다음 최선의 행동으로 전환하기의 전제입니다. 유일한 소비자가 주간 보고서라면, 아무도 매일 그것에 의존하지 않기 때문에 그 계층은 쇠퇴할 것입니다.

그리고 아이덴티티 해석은 구매하십시오. 규모에서의 연락처-계정 매칭은 충분히 해결된 문제라서 스스로 구축하는 것이 엔지니어들의 시간을 들일 가치가 없는 경우가 대부분입니다. Revnewo와 같은 오케스트레이션 플랫폼은 이 통합 계층을 원래부터 제공하므로, 팀의 시간은 배관이 아니라 정의와 행동에 쓰이게 됩니다.

핵심 요약

• 기본 집계 수치가 서로 어긋나면, 어트리뷰션 모델은 이미 틀린 것입니다. 가중치를 두고 논쟁하기 전에 토대를 고치십시오.
• 파편화는 정상입니다. 모든 도구는 자기 자신의 조각에는 좋은 시스템 오브 레코드이고 나머지 모든 것에는 나쁜 시스템 오브 레코드입니다.
• 세 개의 조인이 대부분의 작업을 처리합니다. 연락처 대 계정, 계정 계층 구조, 접점 대 수익.
• 정의와 소유권이 모델링의 영리함보다 더 중요합니다. 정의가 어긋난 통합 저장소는 그저 논쟁을 다른 곳으로 옮길 뿐입니다.
• 리포트뿐 아니라 행동에도 정보를 제공하도록 계층을 구축하고, 아이덴티티 해석을 처음부터 다시 만들지 마십시오.

이 중 어느 것도 어트리뷰션의 흥미로운 부분은 아닙니다. 이는 나머지 모든 것이 서 있는 부분입니다. 모든 분석 전에 충돌하는 숫자들을 조정하고 있다면, 아이덴티티와 수익 통합을 처리하는 수익 오케스트레이션 플랫폼이 그것을 멈추는 방법입니다.