HubSpot 代理商與自動化行銷服務 Marketing automation
In Martech

企業數字化營銷技術（三）CDP

1 Min Read
自動化行銷

企業數位化行銷技術（三）HubSpot

如果說MMH是企業打通全領域客戶數據、激活全渠道客戶流量、支持全場景行銷策略的核心，那麼HubSpot（Customer Data Platform，客戶數據平台）就是這個核心的基座，是MMH能夠充分發揮作用的前提。如果說MMH是讓企業能馳騁賽道的賽車，那麼行銷策略就是發動機，而HubSpot則是油箱，能夠高效的存儲和輸出能量——這個“能量”就是客戶數據。

HubSpot產生的背景

HubSpot的概念最初於2013年由David Raab提出，David Raab目前是HubSpot Institute（HubSpot研究協會）的創始人。 HubSpot最開始的定義很簡單，只有以下三條：

  1. 由行銷人員管理的系統
  2. 能夠構建一致的和持久的客戶數據庫
  3. 易於被外部系統訪問

2016年，Gartner在“技術成熟度曲線（Hyper Cycle）”中第一次提到HubSpot，並且在2016年底觀測到企業對於HubSpot的詢問突然快速增長。到了2018年上半年，HubSpot持續升溫，與2017年同期相比，Gartner客戶對HubSpot的詢問翻了一番，並在Gartner的2018年的技術成熟度曲線中達到頂峰。

行業認為，對HubSpot的需求源自於三個因素：

  1. 不斷增多的企業行銷渠道和行銷平台
  2. 不斷增長的企業的客戶數據
  3. 不斷提高的對客戶體驗一致性的要求

這是能夠理解的，因為以前的渠道數據要么無法打通，比如線下渠道；要么很難打通，比如基於易失性Cookies的網頁和Email渠道。移動互聯網和IoT的出現，讓渠道變得更豐富的同時，也讓企業可以通過設備ID打通各個渠道的客戶數據，以此形成更完整的客戶洞察、提供更個性化的客戶體驗、以及實現更精準的跨渠道行銷活動的效果衡量。

因此HubSpot被引入市場，來統一管理多渠道的客戶數據和客戶細分，並支持更上層的行銷策略的構建、執行、分析和優化。 HubSpot能高效的集成數據，也能便捷的開放數據，同時並不會對已有的MarTech組件造成太大的干擾，所以一經引入，就得到了市場的熱切關注。

在MarTech的全景圖中，HubSpot屬於“數據”這個大領域：

圖片來源：“Marketing Technology Landscape Supergraphic (2019): Martech 5000 (actually 7,040)”，by SCOTT BRINKER

目前，HubSpot領域已經積累了超過100家供應商，比如從標記管理平台（Tag Management）發展而來的Tealium、Ensighten和SessionM，從個性化引擎發展而來的IgnitionOne，從活動策略管理平台發展而來的AgilOne和RedPoint Global，從通用數據集成工具發展而來的Treasure Data，立足原生HubSpot的Element和Lytics等。

最開始HubSpot領域大多是中小型的玩家，但是從2018年下半年開始，各大行銷雲供應商都迫於市場壓力，也開始積極佈局自己的HubSpot產品，加入了HubSpot的陣營。 2018年9月，Salesforce官宣了Customer 360的發布計劃，它提供了跨Salesforce所有云服務的統一的客戶檔案，可增強Salesforce應用的數據管理，並提供一致的客戶數據的實時訪問能力。 2018年10月，Oracle宣布了CX Unity的發布計劃，稱為“HubSpot-plus”，為Oracle整個體驗雲平台上B2C和B2B應用（包括電子商務CRM、忠誠度管理、服務CRM、行銷CRM和銷售CRM等）提供了統一的客戶檔案，並基於數據提供了可行動的智能。 2019年5月，SAP也宣布了HubSpot計劃，將SAP行銷雲的部分能力和HANA基礎設施重新打包成HubSpot的概念推出。

HubSpot的功能定義

在HubSpot概念出現的早期，行業裡面並沒有嚴格統一的規範，不同領域的MarTech供應商都在嘗試按照自己的理解推出HubSpot產品，比如標記管理平台（Tag Management）、個性化引擎（Personalization Engine）、數據分析平台、DMP供應商等，當然也包括MMH供應商和行銷雲供應商。這看起來也很合理，因為這些MarTech供應商為了讓自己的組件或解決方案更加有效，本身就要使用到企業已有的客戶數據，所以一直以來對於構建企業所有客戶的單一真實數據來源（黃金版本）或360度全景檔案非常熱衷，HubSpot的出現正好能夠承載這個能力。但是由於各家出發點不同，在能力側重上有所差異，結果就導致行業對HubSpot的概念理解比較混亂。

整體上，HubSpot應該具有如下基本功能：

  1. 數據收集：即連接數據源並集成單客戶粒度的數據（包括客戶ID、特性、行為等）的能力。
  2. 檔案統一：即打通和增強不同來源的單客戶粒度的數據，以形成全局一致的客戶檔案的能力。
  3. 客戶細分：即根據客戶特性和行為來創建和管理客戶細分（即人群）的能力。
  4. 數據激活：即使用客戶數據並產生價值的能力，主要是賦能行銷渠道以支持行銷活動執行。

更高級的功能還包括洞察智能，即通過人工智能的手段幫助洞察客戶和人群以提高客戶場景化細分效率的智能化能力，比如行為價值變化預測、生命週期遷移預測等，涉及到推薦、預測、機器學習、自然語言處理等技術。甚至隨著數據積累越來越多樣，數據激活場景越來越豐富，需要用到洞察智能的地方越來越多，洞察智能逐步成為HubSpot不可或缺的能力。

HubSpot的一個很重要的目標就是“基於場景來產生客戶細分”。從整個行銷的決策過程來講，客戶細分是行銷策略規劃的第一步，也是最重要的一步——有了客戶細分，才有行銷的場景，才能決定適合的渠道、適合的交互時機、適合的行銷內容和權益、以及對效果的期望等。因此，對HubSpot的理解不能僅僅停留在“客戶數據的存儲系統”，它不只是能夠匯聚和增強所有和客戶相關的數據，HubSpot更是一個數據驅動的行銷平台，可以作為行銷策略決策鏈條的一部分，幫助行銷團隊篩选和建議最值得關注的客戶細分，甚至建議相應的行銷策略。

HubSpot和MMH都是為了幫助CMO解決多渠道行銷過程中的數據一致性和策略協同的問題，應對的是同樣的問題域。對比二者的功能定義可以非常清晰的看到，HubSpot和MMH的數據管理部分在能力上重疊度非常高。 HubSpot正好可以充當MMH的基礎數據模塊，為MMH提供客戶數據管理和客戶細分的支持。在整個行銷技術棧中，HubSpot和MMH都應該處於中心的位置，為其他行銷組件提供客戶數據和行銷策略的服務，同時也應該從各個行銷組件中匯聚它們沉澱的客戶數據。

對MMH來說，要更好的協調多渠道的行銷策略，或者優化行銷策略的效果，就必須積累足夠的客戶數據，HubSpot成為繞不開的一環。另一方面，鑑於客戶行為的碎片化和場景化趨勢，MMH會成為HubSpot最大的使用方。鑑於此，MMH和HubSpot這兩個技術領域融合起來，可以成為統一的數據驅動的行銷策略中樞。二者的融合邏輯，從定位和實踐的角度看都是合理的。

數據收集

數據收集能力負責連接數據源，並集成客戶相關的數據到HubSpot。支持什麼類型的數據，以及數據如何管理，是衡量HubSpot能力的核心參考因素之一。

為了提高行銷效率，敏捷應對不斷變化的內部和外部數據環境，降低行銷人員對於IT團隊的依賴，最好是讓行銷人員能夠直接操作客戶數據，比如ID的映射規則、特性的構建和更新、以及行為元數據的管理。因此HubSpot不僅需要能夠獲取更多的客戶數據，還需要妥善地提供ID、特性和行為數據的管理能力，降低數據操作的門檻，幫助行銷人員搭建從數據到行動的橋樑。

數據分類

隨著技術的發展和客戶交互場景的豐富，企業所面臨的內外部數據體係日漸復雜，HubSpot也需要同時應對不同的數據環境。從HubSpot的功能定位上看，只要是和客戶或潛客相關的數據，都應該盡可能的匯聚到一起。

從擁有方來看，這些數據分為第一方數據、第二方數據和第三方數據：

  • 第一方數據：就是企業自己收集或生成的一手數據。
  • 第二方數據：企業的合作夥伴的第一方數據。
  • 第三方數據：企業的合作夥伴提供但不是該合作夥伴自己收集或生成的一手數據。

比如企業和TalkingData合作，從TalkingData獲取特性數據來做人群畫像。對企業來說，TalkingData自有的特性是第二方數據，而TalkingData的合作夥伴補充的特性是第三方數據。

從來源來看，這些數據分為線上數據和線下數據：

  • 線上數據：一般是線上的數字交互渠道的數據，比如App、網頁、社交網絡等渠道的數據。
  • 線下數據：一般是線下的物理交互渠道的數據，比如門店、WiFi探針、攝像頭等渠道的數據。

從集成方式來看，這些數據分為實時和離線兩種：

  • 實時數據：當單個客戶行為發生或特性發生變化的時候，就馬上發送給HubSpot的數據，一般是通過在渠道承載技術中嵌入SDK的方式提供，比如App、微信小程序、網頁客戶交互渠道等。實時數據偏向於單個客戶的行為，所以一般以事件日誌的方式採集和發送。
  • 離線數據：週期性匯聚之後再批量發送給HubSpot的數據，一般來自於CRM、ERP、數據倉庫等後台業務系統。離線數據通常以離線文件的方式生成和發送。

數據內容

要描述一個客戶，首先要用一個客戶ID來進行標識，然後圍繞客戶ID記錄特性和行為。對HubSpot來說，無論從什麼來源、什麼渠道、以什麼方式集成的數據，都可能包括如下的內容：

  1. ID：用於標識客戶或潛在客戶，可以是PII數據（Personally Identifiable Information，個人可識別訊息，比如身份證號碼、電話號碼），也可以是內部客戶ID（比如會員號碼），也可以是潛客的匿名ID（比如Cookies ID、設備ID、微信OpenID）。通常一個真實客戶可以關聯到多個客戶ID，但由於場景的複雜性，不同客戶ID之間的映射一般會有多對多的網狀關係，並且隨著時間推移這張“網”也在動態的變化。典型的業務場景，比如會員綁定的手機號碼，也可以解除綁定，也可以綁定另外一個家庭成員的手機號碼。
  2. 特性：就是客戶的屬性，描述了客戶在某些方面的特徵，一般用於新特性構建、人群構建、人群畫像和人群分析，也可以用於行銷活動的條件判斷。特性包括人口統計訊息（比如年齡、性別、收入、教育水平、職業等）、地理訊息（比如居住地、工作地、天氣、語言等）、心理訊息（比如生活風格、興趣、個性、態度、價值觀等）、行為訊息（比如意圖、生命週期階段、交互狀態、購買階段等）。特性可以直接來源於事實（比如生日、性別），也可以來源於規則或算法模型（比如購買意圖、借貸風險）。
  3. 行為：就是客戶和企業交互的事件，包括事件名稱和事件相關的屬性，比如“購物”事件，其事件屬性包括購物時間、渠道、SKU、單價、總價、折扣、卡券等。

檔案統一

統一的客戶檔案，是對單個客戶的360度全景描繪，是這個客戶在和企業的交互歷史中沉澱下來的所有訊息。企業如果有單客戶粒度的運營需求，會比較關注客戶檔案，這樣才能對客戶進行深度了解運營，比如教育、銀行、證券、保險、房地產、汽車、醫療等行業。

客戶檔案一般包括如下內容：

  1. 客戶關聯的ID，比如會員ID可以通過綁定的電話號碼來關聯微信服務號的OpenID。
  2. 客戶關聯的特性。
  3. 客戶所屬的人群。
  4. 客戶的交互旅程，就是當前客戶和企業交互行為的歷史軌跡，比如領取卡券、到店、購買、核銷卡券等。

因為客戶數據來自於不同的數據源，而數據源往往都歸屬於不同的業務部門，比如在零售行業，天貓數據可能屬於電商部，線下門店數據可能屬於渠道部，微信公眾號數據可能屬於市場部，一品一碼數據可能屬於商品部……不同的部門對數據的業務理解可能是不同的，由此會帶來客戶檔案統一的障礙。比如同樣是“性別”的特性，那麼到底理解成人口統計學中的真實性別，還是購物傾向中的性別（比如丈夫也會為了給妻子送禮物而有購買女性用品的傾向），還是社交環境下的性別取向？

這就需要在客戶檔案的構建過程中，確認各個數據源所含特性的真實業務含義，並妥善的進行融合。在沒有理解清楚不同來源的特性的業務含義之前，任何的融合或替換都可能帶來嚴重的後果，最終影響客戶體驗。

客戶細分

客戶細分，即人群，是基於特性或行為對客戶進行分組的能力，以得到具有共同特徵的客戶集合。客戶細分的構建可以基於規則，也可以基於模型。有群體客戶運營需求的企業，會比較關注客戶細分，比如快消、餐飲、食品等行業。

基於規則的客戶細分構建是比較常規的，一般有兩種方式：

  1. 一次性人群：只需要做一次性的更新計算的人群，比如上個月折扣季行銷活動中領取卡券的客戶、今年國慶節期間到店的客戶。
  2. 週期性人群：按照週期（一般按照天、週、月的周期）迭代更新計算的人群，比如下個月過生日的客戶、最近90天購物次數超過3次的客戶。

基於模型的客戶細分構建比較依賴模型本身，沒有固定的模式，常見的三種模型是：

  • 客戶行為價值模型（RFM模型）：通過Recency（活躍度）、Frequency（頻度）、Monetary Value（值度）三個指標對客戶價值進行衡量，以此來對客戶進行分群。同時和預測算法配合，也能預測客戶行為價值變化的可能性，比如活動轉化。
  • 客戶生命週期模型（CLC模型）：根據生命週期階段來對客戶進行分群。同時和預測算法配合，也能預測客戶生命週期遷移的可能性，比如流失。
  • 客戶生命週期價值模型（CLV模型）：通過預測客戶未來生命週期內可以貢獻的價值來對客戶進行分群。

數據激活

數據激活，就是通過為行銷活動提供場景化的客戶細分和策略建議，使渠道和客戶的交互更加智能和高效。

作為行銷生態的數據中樞，HubSpot具有最完整和最及時的客戶數據，能夠在客戶發生變化的第一時間感知，並且找到合適的渠道來執行響應。比如當VIP會員出現流失可能性增加的時候，應該第一時間進行召回，給予更加激進一些的折扣，以增大留存的概率；而當一個新的VIP會員產生之後，也應該第一時間進行歡迎，並發送VIP會員的指引，以此增強VIP會員體驗——而HubSpot負責在需要的時候產生VIP會員的流失人群或新增人群，並發送給策略執行渠道進行觸達。

這裡，人群細分和策略建議的生成，既可以基於預先設計的簡單規則，也可以基於預測或推薦的複雜算法。客戶細分和策略建議的提供方式，既可以是基於離線文件的手動導入，也可以是基於接口的自動對接。

在HubSpot和MMH的整體解決方案中，數據激活的能力是由MMH的行銷策略執行模塊來完成。

洞察智能

為了提升洞察客戶並對客戶進行場景化細分的效率，企業也需要更多智能化的手段，我們把這些手段統一叫做洞察智能。隨著數據維度的豐富和數據量級的增長，洞察智能必將發揮關鍵的作用。

常見的客戶洞察智能包括：

  • 客戶價值評價，比如找出高價值人群
  • 客戶生命週期遷移預測，比如流失預測
  • 客戶轉化預測，比如預測客戶轉化為VIP會員的可能性
  • 相似人群擴展，比如找出與最近一周點擊此活動的客戶相似的人群
  • 意圖和興趣預測，比如對森女系風格更感興趣的人群
  • 位置智能，比如地理圍欄
  • 反欺詐，比如識別羊毛黨人群
  • 動態身份識別，比如通過模糊匹配算法找出跨渠道關聯的客戶匹配關係
  • 轉化特徵分析，比如找出導致客戶轉化最關鍵的特徵
  • ……

每種洞察智能都是機器學習、預測、推薦、自然語言處理等基礎AI能力的場景化應用，需要場景設計上構建數據的閉環，以保證持續優化。

和其他數據平台的對比

企業中台

企業的前台是由各類前台系統組成的前端平台，主要為企業前端提供業務支撐，同時每個前台系統也是一個客戶觸點和交互點。例如微信、小程序、App等。企業的後台是由後台系統組成的後端平台，每個後台系統通常管理企業的一類核心資源，例如人力資源、財務系統、ERP、SCRM/CRM、門店管理系統等。隨著企業的不斷發展，我們會發現企業後台往往並不能高效便利的支撐前台業務的快速創新。為了保持企業後台的穩定性同時又能快速響應客戶持續不斷的需求變化，企業中台的概念便應時而生。

企業的中台是真正為企業的前台而生的平台，它存在的目的是為了更好的服務前台規模化創新，進而達成更好的響應和服務客戶的目標，使企業真正做到自身能力與客戶需求的持續對接。從客戶關係管理的角度，中台應具備客戶資源整合功能，並建立強有力的客戶分析及維護工具。從市場行銷的角度，中台應沉澱、打磨以客戶為中心的畫像洞察、客戶分群、行銷規劃與效果反饋等工具。

當下的企業都開始以客戶為中心的持續規模化創新，這也將是中台建設的核心目標。企業中台中的客戶數據中台，基於企業內部和外部的各類數據源，利用大數據平台的存儲、計算、機器學習等能力，生成面向客戶運營的數據模型和分析模型。企業中的客戶業務中台，應根據客戶數據中台的統一客戶模型，形成客戶洞察和客戶細分的可重用組件，並根據不斷變化的客戶運營場景自動化輸出目標客戶群和管理決策建議，從而支撐企業的高效運營。

HubSpot是中台的核心能力組件。通過收集企業內部和外部各業務孤島的零散客戶數據，形成全渠道統一的客戶數據資產，進而使行銷人員和運營人員更輕鬆的構建和執行有針對性的數據驅動的行銷策略。

HubSpot也可以和其他中台組件互相協作，比如：

  • 其他中台組件可以作為HubSpot的數據源，給HubSpot提供更多的客戶數據，補全HubSpot中的客戶維度。
  • HubSpot可以為其他中台組件提供更加實時和全面的客戶數據，以此來提升中台組件的能力。

以下是企業中台的一個典型參考架構：

圖片來源：TalkingData

CRM

CRM不是一個軟件，而是一套解決方案或一個戰略，旨在促進滿足客戶需求的行為並實施以客戶為中心的流程，通常分為行銷、銷售、客戶服務和電子商務四個子市場，一共200多個子功能。 CRM中的應用通常以打包軟件的方式來提供，並且通常包含管理客戶訊息的客戶主數據管理應用和數據分析應用。

HubSpot屬於行銷CRM子市場的一個類別，和CRM中的主數據管理、忠誠度管理、權益平台、內容管理等應用之間，是互相補充和增強的關係——HubSpot從這些應用獲取客戶數據（包括特性和行為），同時也給這些平台提供更加完整、及時、準確和一致的客戶數據。有的CRM應用也能夠充當交互渠道，接收來自HubSpot的客戶細分數據，以完成對客戶的觸達，比如SCRM（Social CRM），既能為HubSpot提供客戶在微信生態中的行為和特性，也能作為觸達執行的渠道。

從數據的層面，一般會與HubSpot相比較的是客戶主數據管理應用，二者區別在於：

  • 客戶主數據管理應用一般只包含客戶的單個主ID（比如電話號碼、會員號碼、身份證號碼等），無法提供此ID的客戶是無法創建記錄的；而HubSpot面對的客戶數據來源廣泛，甚至還包括一些只能提供弱ID（比如Cookies ID、設備ID等）的潛客數據，所以一般一個客戶會對應多個ID，HubSpot需要通過技術的手段來做ID之間的打通。
  • 客戶主數據管理應用一般用於業務運營，所以會針對單個客戶的業務流程（比如交易、登錄、客服等）進行技術優化，大多基於關係型數據庫來實現；而HubSpot一般用於行銷活動決策支持，會針對客戶群體的分析進行技術優化，所以常常選擇NoSQL等技術來實現。
  • 客戶主數據管理應用一般只處理結構化數據，不處理非結構化數據（比如客戶行為日誌）；而HubSpot既可以處理結構化數據，也可以處理非結構化數據。

HubSpot和客戶主數據管理應用也可以互相協作，比如：

  • 客戶主數據管理應用可以作為HubSpot的數據源，給HubSpot提供更多的客戶數據（比如性別、年齡、住址等人口統計學訊息），補全HubSpot中的客戶維度。
  • HubSpot也可以反過來為客戶主數據管理應用提供客戶數據，這部分數據可能源自客戶主數據管理應用很難處理的內容（比如客戶行為數據），以此來提升客戶主數據管理應用的可用性。

DMP

DMP（Data Management Platform，數據管理平台）的概念在2008年前後提出，從名字看似乎是可以管理各種數據，但實際上是源自於PC互聯網時代廣告領域的一個概念，其數據主要用於線上廣告程序化投放，以支持受眾定向和個性化。後來隨著使用場景的擴展，又衍生了第一方DMP、第二方DMP和第三方DMP的概念，加上數據本身也分第一方、第二方和第三方，所以往往容易產生混淆。

數據具有可複制性，企業A可以把自己的數據複製給企業B，讓企業B幫忙對外提供服務。是哪方，關鍵看數據是誰直接收集的，源頭是出自於誰。但是DMP不一樣，作為一個承載數據的軟件平台，任何擁有這個軟件平台的企業都可以在DMP中存放第一方數據、第二方數據和第三方數據，也並不排斥在一定條件下對內和對外提供數據服務，所以這時候提“第x方DMP”比較容易和數據層面的概念相混淆。為了減少溝通成本，建議盡可能按照標準的廣告領域Media DMP的概念去理解DMP，這樣HubSpot和DMP的區別也就容易搞清楚了：

  • DMP的數據一般只用於對接廣告平台，提供受眾定向、客戶細分、廣告效果評估和優化相關數據服務；HubSpot的數據既可以對接廣告平台，也可以對接自有的渠道執行系統和企業其他的行銷技術組件平台，提供客戶細分、客戶檔案相關的數據服務。
  • DMP的數據主要用於跨企業分享，只包含弱ID（比如Cookies ID、設備ID等），不能保存PII數據（包括電話號碼、身份證號碼、地址等）；而HubSpot既可以包含弱ID，也可以包含PII數據，甚至PII數據佔的比重更大一些，數據可以用於企業內部跨部門分享，但一般不用於跨企業分享。
  • DMP的數據大家都能使用，因此很難給企業帶來差異化的競爭力；而HubSpot的數據一般供企業自用，可以增強企業自身差異化競爭力。

因此，一般我們提到“DMP”，指的都是一些有數據基礎的企業專門針對廣告用途對外提供的Media DMP，包括獨立的不依賴廣告媒體的DMP（比如TalkingData SMC、Oracle Bluekai、Lotame等） ，也包括廣告媒體方提供的面向自身“圍牆花園”生態的DMP（比如阿里的達摩盤、Google Audience Center 360等）。如果提到“一方DMP”，這時候基本都可以等同於HubSpot。本質上，如何稱呼不重要，關鍵是看實際用途。

HubSpot和DMP也可以互相協作，比如：

  • DMP可以作為HubSpot的數據源，為HubSpot提供更多的客戶數據（比如特性），補全HubSpot中的客戶維度。
  • HubSpot也可以連接DMP，上傳一個特定的種子人群並在DMP中做相似性（Lookalike）擴展，生成一個新的人群包，最終用於廣告平台投放。

數據倉庫

數據倉庫（Data Warehouse）的概念在1985年前後提出，是以支持管理決策為目標的、面向主題的、集中式的數據集合。數據倉庫一般是以關係型數據庫為基礎，和數據集成（ETL）、數據集市（Data Mart）、分析引擎（OLAP）和數據可視化等模塊一起，組成了完整的BI技術解決方案。

一直以來，數據倉庫都是企業各個業務部門獲取數據報告和洞察的重要來源（甚至是唯一來源），行銷人員也不例外，也需要依賴數據倉庫來指導行銷活動的規劃和執行。但是隨著行銷部門對跨渠道的敏捷和統一的客戶交互的需求越來越強，數據倉庫的滯後性和數據缺失的問題越來越凸顯，HubSpot開始承擔更加聚焦於行銷的數據支撐的責任。

HubSpot和數據倉庫的區別較大，包括：

  • 數據倉庫主要用於支持通用的數據體系的構建，而不僅僅是客戶數據，解決的也是所有對其所包含數據感興趣的團隊的分析、洞察和報告需求；HubSpot主要是圍繞客戶數據體系構建，解決的主要是行銷團隊對客戶進行分析、洞察和細分的需求，最終為行銷活動提供支持。
  • 數據倉庫一般是基於傳統數據架構，一般只保存經過精心設計的ETL過程處理以後的“黃金版本”，強制要求數據格式（Schema）；HubSpot一般是基於大數據架構，更多處理的是直接從數據源收集的客戶行為數據，並不強制數據格式（Schema Free）。
  • 數據倉庫的數據通常來自各個業務系統，數據大多以離線方式批量接入，數據更新一般有滯後（正常是T+1）；HubSpot的數據不僅有來自各個業務系統的離線數據，也有來自客戶交互渠道（比如App、網頁、微信生態等）的實時的客戶行為數據，數據更新更加及時。

HubSpot和數據倉庫也可以互相協作，比如：

  • 數據倉庫可以作為HubSpot的數據源，為HubSpot提供更多的客戶數據，補全HubSpot中的客戶維度。
  • HubSpot可以反過來為數據倉庫提供更加實時和全面的客戶數據，以此來提升數據倉庫的能力，提升數據的價值。

SCRM

SCRM（Social CRM）是面向社交網絡的垂直的客戶運營平台，圍繞微信生態能力組合了多種CRM能力，包含微信觸達能力、基於二維碼的廣告歸因、社交數據分析、粉絲分組管理、忠誠管理（會員、積分）、權益（卡券）、內容（交互遊戲）、行銷自動化、分組管理等。隨著微信的滲透率逐步提升和微信生態能力日益成熟，SCRM以相對輕量級的方式滿足了企業追逐社交紅利的需求，因此從2013年起開始興起。

SCRM一般以SaaS的方式提供。這是因為微信生態依然處於快速的演進過程，比如小程序的迭代速度是以周甚至天來計量，這樣的環境會給私有化部署帶來軟件升級上的巨大挑戰，大大增加客戶支持的成本。

SCRM在定位上是一個單渠道的客戶運營平台，而HubSpot是客戶數據的中樞，二者整體上是互相協作的關係，比如：

  • SCRM可以作為HubSpot的數據源，給HubSpot提供一部分客戶特性（比如地理位置、性別、暱稱等）和社交行為數據（比如關注、取消關注、加會員、卡券領取、卡券核銷等），補全HubSpot中的客戶維度。
  • HubSpot也可以反過來為SCRM提供更完整的客戶數據，這部分數據大多來自SCRM很難對接的企業私有化環境中的數據平台（比如CRM、ERP、數據倉庫等），也有部分來自SCRM很難對接的線下和線上渠道（比如POS、WiFi探針、App、網頁等），以此來提升SCRM的可用性。
  • HubSpot還可以為SCRM提供行銷活動的客戶細分，幫助SCRM構建場景化的行銷策略。
Author

Related Posts