跳至主要內容

Twilio Segment 客戶數據平台:企業全面指南

本技術指南說明如何導入 Twilio Segment 客戶數據平台 (CDP) 以整合碎片化的數據源。它為 IT 和行銷團隊提供了可行的架構藍圖與部署策略,用以啟用第一方數據。

📖 5 分鐘閱讀📝 1,171 字數🔧 2 範例3 練習題📚 8 關鍵定義

收聽此指南

查看播客逐字稿
您是一位資深技術顧問,擁有沉穩且具權威感的英國口音,正在私人會議室中向客戶進行簡報。請以沉著自信、不疾不徐的節奏以及偶爾帶點冷幽默的方式交談。這不是在上課,而是同儕之間的簡報。請清晰地發言,並在各章節之間保持自然停頓: 歡迎參加這次關於 Twilio Segment 客戶數據平台(CDP)的簡報。我將帶您了解它是什麼、幕後的運作原理、如何部署,以及至關重要的是,像您這樣的企業如何從中獲得真正的價值。 [medium pause] 讓我們從背景開始說起。當今大多數企業都面臨著一個看似數據優勢,實則是數據難題的狀況。您的網站分析在一套工具中,CRM 記錄在另一套系統,POS 交易記錄在其他地方,而顧客 WiFi 登入數據又在另一個系統中。每個團隊對客戶都有自己的看法,而且彼此互不相符。這就是 Twilio Segment 旨在解決的問題。 Segment 是一個客戶數據平台 - 也就是 CDP。它的工作是從每個接觸點收集第一方數據,將其統一為單一客戶檔案,然後在您的下游工具中啟用該檔案。您可以將其視為客戶數據架構的中樞神經系統。 [medium pause] 現在,Twilio 在 2020 年以約 32 億美元收購了 Segment。這告訴了我們兩件事。第一,市場非常重視 CDP。第二,Segment 的數據基礎設施與 Twilio 的通訊平台相結合,創造了真正實用的功能 - 這套系統讓您可以收集數據、了解客戶,然後透過電子郵件、簡訊或推播通知與他們聯繫,而這一切都來自於一個相連的架構。 [medium pause] 讓我為您介紹其架構。Segment 有四個核心元件。 第一,Connections。這是數據管道層。您可以使用 Segment 的 Analytics.js 函式庫來配置您的網站,使用他們的 iOS 或 Android SDK 來配置您的行動應用程式,並使用其伺服器端函式庫之一來配置您的伺服器端系統。每一次使用者行為 - 網頁瀏覽、按鈕點擊、購買、WiFi 登入 - 都會向 Segment 發送一個事件。這些事件使用六種 API 呼叫類型進行標準化:Identify、Track、Page、Screen、Group 和 Alias。Identify 呼叫記錄使用者是誰。Track 呼叫記錄他們做了什麼。這種標準化非常重要,因為這意味著無論數據來自哪個來源,都會以一致的結構定義(schema)送達。 [medium pause] 第二,Protocols。這是 Segment 的數據治理層。您需要定義一個 Tracking Plan(追蹤計畫) - 這份文件指定了您想要擷取哪些事件、每個事件必須攜帶哪些屬性,以及適用哪些命名規範。Protocols 會根據該計畫驗證傳入的數據,並標記或阻擋不符合規範的事件。對於企業團隊來說,這就是乾淨的數據倉庫與混亂泥潭之間的差別。 [medium pause] 第三,Unify(統一)。這是進行身分識別解析的地方。當顧客連接到您的 WiFi 並使用電子郵件登入,隨後又從不同裝置造訪您的網站時,Segment 的 Identity Graph(身分識別圖譜)會將這兩個工作階段縫合為一個持續的設定檔。它是透過比對識別碼(使用者 ID、匿名 ID、電子郵件地址和自訂外部 ID)來實現此目的。其結果是產生一個反映跨每個管道之每次互動的單一客戶設定檔。對於餐旅業和零售業營運商而言,這特別有價值。一位入住您的飯店三次、點了兩次客房服務,並點擊了您入住後電子郵件的顧客,並不是三筆獨立的記錄。他們是一位具有明確行為模式的高價值客戶。 [medium pause] 第四,Engage(互動)。這是啟用層。一旦您擁有了統一的設定檔,您就可以建立受眾 - 在 Segment 的術語中稱為區段。您可能會將一個區段定義為:在過去 90 天內造訪超過兩次、至少開啟過封電子郵件,且在過去 30 天內沒有進行預訂的顧客。Segment 會即時評估該定義,並保持受眾成員身份的最新狀態。接著,您可以將該受眾同步到您的電子郵件平台、您的 CRM、您的廣告網路,或 Segment 目錄中 550 多個目的地中的任何一個。受眾會隨著客戶行為的變化而自動更新。 您是一位擁有沉穩、權威英國口音的資深技術顧問,正在繼續向客戶進行簡報。請以沉著的自信和沉穩的節奏發言。從上一節自然地繼續: 現在,讓我們來談談這對於場地營運商、零售商和餐旅品牌來說,有哪些有趣的地方。 在部署 CDP 的組織中,我最常看到的單一失敗模式是將其視為一項技術專案,而不是商業專案。工程團隊配置了來源,數據流入 Segment,然後... 什麼也沒發生。受眾就停留在那裡。沒有人去啟用他們。 原因幾乎總是相同的。在開始實施之前,沒有定義好商業應用場景。所以,這是我給每位客戶的原則:在撰寫任何一行追蹤程式碼之前,先定義好您的前三大應用場景。這些數據將推動什麼決策?它將助力什麼行銷活動?它將執行什麼排除機制? [medium pause] 讓我給您兩個具體的例子。 一個中型市場的酒店集團 - 擁有 40 家物業、大約 2,000 間客房 - 當時正在向其整個賓客資料庫發送電子郵件行銷活動。開信率大約在 12% 左右。他們部署了 Segment,連接了他們的物業管理系統作為來源,並建立了三個客群:過去 60 天內入住過的賓客、超過 12 個月未再入住的賓客,以及直接預訂與透過 OTA 預訂的賓客。他們在獲客行銷活動中排除了 OTA 賓客 - 因為沒有必要付費重新獲取已經認識您的客戶。他們向流失的客群發送了個人化的挽回郵件序列。在 90 天內,來自電子郵件的直接預訂收入增長了 34%。數據一直都在。Segment 只是讓它變得可以付諸行動。 [medium pause] 第二個例子。一家擁有 120 家門市的零售連鎖店正面臨傳統的難題:線上和門市的客戶數據存在於不同的系統中。一個在線上購買過三次的客戶,在走進門市時卻被當作新客戶對待。他們將其電子商務平台、會員應用程式以及門市 WiFi 登入數據連接為 Segment 中的來源。身分圖譜合併了這些設定檔。店員可以透過客戶關係維護應用程式看到,他們面前的客戶是一位從未在門市購買過的高價值線上購物者。這種情境改變了對話。在六個月內,參與門市的平均交易金額增長了 22%。 [medium pause] 現在,實施的陷阱。有四個是我經常看到的。 第一:追蹤計劃維護不善。團隊在未先就命名規範達成一致的情況下就部署了事件。結果就是「購買完成」、「訂單已確認」和「交易成功」都代表同一個意思。Protocols 可以防止這種情況,但前提是您必須從第一天就開始使用它。 第二:身分解析設定錯誤。如果您設定了過於寬鬆的合併規則,您就會開始合併本應保持獨立的設定檔 - 例如兩個人共用一台裝置。如果您設定的規則過於嚴格,您就會錯過真實的跨裝置縫合。Segment 的預設模型適用於大多數情況,但在上線前,請務必檢視合併保護設定。 第三:目的地超載。團隊在第一天就連接了他們能想到的所有目的地。一個目的地中的數據品質問題會產生連鎖反應。先從兩到三個目的地開始,驗證數據品質,然後再進行擴展。 第四:GDPR 與同意管理。Segment 的 Privacy Portal 讓您可以從一個地方管理整個技術棧中的數據刪除和排除請求。但您必須在來源層級正確設定同意類別。如果使用者選擇退出行銷,該偏好設定必須傳播到每個目的地。請在上線前設定好這一點,而不是在收到第一個主體存取請求之後。 [medium pause] 在合規性方面 - Segment 在 GDPR 規範下擔任資料處理者的角色。您則是資料控制者。Segment 為國際資料傳輸提供資料保護增補協議(DPA)與標準契約條款(SCC)。他們在 2018 年 5 月生效日期前就已符合 GDPR 規範。但合規是共同的責任。您的追蹤計劃、您的同意流程以及您的資料保存政策,都需要由您自行管理。 [medium pause] 現在,進入一個關於我常收到客戶提問的快速問答環節。 導入 Segment 需要多少時間?對於簡單的部署 - 一個網站來源、一個行動裝置來源、三個目的地 - 一個優秀的工程團隊大約需要四到六週的時間。而包含多個來源、Protocols 治理與 Unify 身分識別解析的完整企業級部署,通常需要三到四個月。 費用是多少?Segment 依每月追蹤用戶數(MTU)計費。免費方案涵蓋 1,000 個每月追蹤用戶。團隊方案起價約為每月 120 美元。企業方案價格為議價,並隨資料量擴充。如果您的團隊以前從未部署過 CDP,請編列專業服務預算。 它能與我現有的技術堆疊協同工作嗎?答案幾乎是肯定的。超過 550 個目的地目錄涵蓋了 Salesforce、HubSpot、Braze、Klaviyo、Google Analytics、BigQuery、Snowflake、Redshift 以及大多數主要的行銷與分析平台。如果您的工具不在目錄中,Segment 的 HTTP API 和 webhook 目的地也支援自訂整合。 [medium pause] 最後,讓我總結一下核心要點。 Twilio Segment 是一款成熟且文件齊全的 CDP,擁有龐大的整合目錄與強大的身分識別解析能力。其四層架構 - Connections、Protocols、Unify 以及 Engage - 涵蓋了從收集到啟用的完整資料生命週期。 商業價值來自於啟用,而非收集。在配置您的來源之前,請先定義好您的使用情境。 符合 GDPR 規範需要進行設定,而不僅僅是簽署 DPA。在正式上線之前,請先設定好同意類別與刪除工作流程。 對於場域營運商與餐飲旅宿品牌,投資報酬率最高的使用情境通常是:在獲客廣告活動中排除現有客戶、為流失的顧客個人化重塑回流序列,以及利用整合的客戶檔案來豐富場域內服務人員的工具。 最後 - 如果您正在收集顧客 WiFi 登入資料,那是擁有已驗證電子郵件和明確同意的第一方資料。這是您可以連接到 CDP 的最寶貴來源之一。不要讓它閒置在獨立的系統中。 [medium pause] 簡報到此結束。如果您想深入了解其中任何領域 - 導入架構、使用情境優先順序或廠商評估 - 我們都有提供完整的書面指南。感謝您的時間。

header_image.png

執行摘要

大多數企業 IT 團隊管理著零散的數據架構。網站分析數據存在於一個工具中,CRM 記錄存在於另一個工具中,POS 交易數據存在於第三個工具中,而 Guest WiFi 登入數據則存在於第四個工具中。每個團隊都只能看到客戶的部分視圖。Twilio Segment 客戶數據平台 (CDP) 透過從每個觸點收集第一方數據,將其統一為單一設定檔,並即時路由到下游工具,從而解決了這個問題。

對於場地營運商、零售商和餐旅品牌而言,部署 CDP 不僅僅是一項數據工程工作。這是一項商業要求。透過統一身份,您可以在獲客廣告活動中排除現有客戶、個性化挽回流失客戶的序列,並在廣告平台上啟用高價值受眾。本指南詳細介紹了 Twilio Segment 的技術架構、實施路徑以及確保投資報酬率且與廠商無關的最佳實踐。

技術深潛:Segment 架構

Twilio Segment 架構跨越四個不同的層級運作:Connections、Protocols、Unify 和 Engage。對於規劃企業部署的網路架構師和數據工程師而言,理解這種數據流至關重要。

cdp_architecture_diagram.png

1. Connections:數據管道

Connections 是攝取和路由層。您可以使用 Segment 的 SDK 和函式庫(網頁端使用 Analytics.js,行動端使用 iOS/Android SDK,後端系統使用伺服器端函式庫)來配置您的數據源。

每個用戶操作都會使用六個 API 呼叫的標準化架構向 Segment 發送事件:

  • Identify:記錄用戶的身分及其特徵。
  • Track:記錄用戶的操作(例如「已購買商品」)。
  • Page:記錄網頁瀏覽量。
  • Screen:記錄行動應用程式螢幕瀏覽量。
  • Group:將用戶與帳戶或組織關聯。
  • Alias:將匿名 ID 連結到已知用戶 ID。

這種標準化確保了無論數據是源自 Retail POS 系統還是飯店預訂引擎,都能以一致的格式送達。

2. Protocols:數據治理

Protocols 作為驗證層。在編寫任何程式碼之前,您會先定義一個 Tracking Plan - 一個嚴格的結構,指定了允許哪些事件、它們必須包含哪些屬性以及必要的資料類型。Protocols 會即時對照此計劃驗證傳入的資料,在不合規的事件污染您下游系統之前,予以封鎖或加上標記。

3. Unify:身分整合 (identity resolution)

Unify 是身分識別圖譜。當使用者連線到您的網路並進行驗證時,他們的裝置 MAC 位址、電子郵件和工作階段資料就會被擷取。如果該使用者稍後從不同的裝置造訪您的網站,Segment 會將這些互動合併為單一的持續性個人檔案。它透過跨管道確定性地配對識別碼來實現此目的。

例如, 如何透過您的顧客 WiFi 留下美好的第一印象 (並保持品牌一致性) 討論了 Captive Portal 的重要性。當與 Segment 整合時,該 Portal 就會成為主要的身分整合節點,將匿名的實體訪客連結到已知的數位個人檔案。

4. Engage:受眾啟用

Engage 是受眾建立與啟用層。一旦個人檔案完成統一,行銷團隊就可以定義動態客群 (例如:「90 天內未造訪的高價值顧客」)。Segment 會持續評估這些規則,並將產生的受眾同步到其支援的 550 多個目的地中的任何一個,例如 Google Ads、Salesforce 或電子郵件平台。

實作指南

部署 CDP 需要 IT 與行銷部門之間的緊密配合。請遵循此部署路徑,以避免收集了沒人使用的資料這類常見陷阱。

步驟 1:定義業務使用案例

在明確定義資料將推動哪些決策之前,請勿編寫追蹤程式碼。找出三個高影響力的使用案例。例如:

  1. 在付費媒體獲客活動中排除最近的購買者。
  2. 當流失的顧客登入店內 WiFi 時,觸發個人化的電子郵件序列。
  3. 將高終身價值顧客客群同步到 Meta,以進行類似受眾 (lookalike audience) 的產生。

步驟 2:建置 Tracking Plan

使用 Protocols 建立一個統一的 Tracking Plan。在整個企業中達成命名規範的共識。一致使用 snake_case 或 camelCase。定義推動這三個使用案例所需的最基本可行事件。不要追蹤每一個可能的按鈕點擊。

步驟 3:部署來源並驗證

從兩個主要來源開始:您的網站和您最可靠的離線資料來源,例如 Purple WiFi Analytics

purple_wifi_cdp_integration.png

實作 SDK 並使用 Segment 的除錯工具來驗證事件是否正確觸發並符合 Tracking Plan。

步驟 4:設定身分解析

檢閱 Unify 合併規則。Segment 預設的確定性比對效果良好,但您必須確保來源系統正確傳遞識別碼。對於共用裝置的環境,請確保在登出時觸發正確的 reset() 呼叫,以防止設定檔合併錯誤。

步驟 5:連接目的地並啟用

連接您的下游目的地。從一個分析目的地(例如 Google Analytics)和一個啟用目的地(例如電子郵件平台)開始。在 Engage 中建立您的目標受眾,並驗證同步率。

最佳實踐

  • 將訪客 WiFi 視為主要身分來源:訪客 WiFi 可在獲得明確同意的情況下,擷取已驗證的第一方數據(電子郵件、電話號碼)。它填補了匿名人流與已知數位設定檔之間的空白。確保您的網路架構支援此整合。如需設計考量,請參閱 三種 SSID 統治一切:訪客、Passpoint 與 IoT WiFi
  • 強制執行嚴格的資料類型:使用協定來強制執行資料類型(例如,確保營收始終以浮點數而非字串形式傳遞)。錯誤的資料類型會中斷下游整合。
  • 標準化硬體整合:將網路基礎設施整合為資料來源時,請使用支援的企業級硬體。Purple 與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 無縫整合。

疑難排解與風險緩釋

GDPR 與同意管理

您是資料控制者;Segment 是資料處理者。在 GDPR 規範下,您必須嚴格管理同意權。如果使用者在您的網站上拒絕行銷通訊,該偏好設定必須傳播到每個下游目的地。

使用 Segment 的隱私入口網站來管理資料刪除請求。然而,您必須在來源層級正確設定同意類別。在 WiFi 登入過程中擷取明確的同意,並將該同意狀態對應到使用者的 Segment 設定檔。

「目的地超載」失敗模式

常見的失敗模式是在第一天就連接 20 個目的地。這會將資料品質問題級聯到整個技術堆疊。請依序連接目的地。在新增下一個目的地之前,先在目的地工具中驗證資料流。

投資報酬率與商業影響

CDP 的投資報酬率主要透過三個維度來衡量:

  1. 廣告支出效率:透過使用統一的 CDP 目標受眾在開發客群活動中排除現有客戶,企業通常可以減少 10% 到 20% 的浪費廣告支出。
  2. 活動營收提升:由即時行為觸發因素驅動的個人化交叉銷售和贏回活動,其轉換率高於批次發送的群發電子郵件。
  3. 營運效率:自動化資料管道和目標受眾同步,消除了資料工程師和分析師先前執行的手動 CSV 匯出和資料比對工作。對於 旅宿餐飲交通運輸 領域的組織而言,實體客流量是主要的互動指標,透過 Segment 將實體數據與數位系統相連結,能立即帶來商業效益。

關鍵定義

識別解析 (Identity Resolution)

透過確定性或機率性比對不同數據點 (Cookie、裝置 ID、電子郵件) 來建立單一、統一的客戶個人檔案的過程。

當 IT 團隊需要在使用者通過驗證後,將匿名網站訪客與已知的 CRM 記錄進行合併時。

追蹤計劃 (Tracking Plan)

一個正式的結構綱要,定義了允許進入 CDP 的確切事件、屬性和數據類型。

由數據工程師用於管理數據品質,並防止未記錄的事件污染數據倉庫。

第一方數據 (First-Party Data)

公司在取得客戶明確同意的情況下,直接從客戶端收集的資訊,例如 CRM 記錄或 Guest WiFi 登入資訊。

隨著主要瀏覽器逐步淘汰第三方 Cookie,這對行銷策略至關重要。

Source

任何產生數據並將其發送到 Segment 管道的系統、應用程式或網站。

常見的來源包括 iOS 應用程式、Node.js 伺服器以及像 Purple WiFi 這樣的硬體整合。

Destination

任何接收來自 Segment 數據的下游工具或平台。

常見的目的地包括 Google Analytics、Salesforce CRM 和 Snowflake 數據倉庫。

Audience

由特定特徵或行為定義的動態使用者區隔,由 CDP 即時更新。

由行銷團隊用於觸發定向行銷活動或在廣告中排除特定使用者。

確定性比對 (Deterministic Matching)

根據唯一識別碼 (例如電子郵件地址或使用者 ID) 的精確比對來合併客戶個人檔案。

最精確的識別解析方法,首選用於合規性和定位精準度。

數據處理者 (Data Processor)

在 GDPR 規範下,代表數據控制者處理個人數據的實體。

Segment 充當數據處理者,這意味著場所營運商 (數據控制者) 仍負責取得使用者同意。

範例

一家擁有 200 間客房的飯店需要停止向已預訂住宿的顧客投放廣告預算,但其預訂引擎的數據與其 Google Ads 帳戶並未連通。

  1. 在 Segment 中將飯店預訂引擎連線為 Source。
  2. 觸發名為 Booking CompletedTrack 事件,其屬性包含 booking_valuecheck_in_date
  3. 在 Segment Engage 中,建立一個定義為「在過去 60 天內執行過 Booking Completed 的使用者」的 Audience。
  4. 將 Google Ads 連線為 Destination。
  5. 將 Audience 同步至 Google Ads,並將其套用為所有獲客行銷活動的排除排除名單 (排除客群)。
考官評語: 這是經典的受眾排除應用案例。它透過消除浪費的廣告支出立即帶來投資報酬率。另一種做法 - 手動從預訂引擎匯出 CSV 並上傳到 Google Ads - 速度慢、容易出錯,且違反數據安全最佳實踐。

一家零售連鎖店希望在高價值線上顧客首次登入店內 WiFi 時,觸發一封提供 10% 折扣的個人化電子郵件。

  1. 在 Segment 中將電子商務平台和 Purple Guest WiFi 連線為 Source。
  2. 電子商務平台傳遞 Identify 呼叫,其中包含顧客的電子郵件以及計算出的特徵值 Lifetime_Value > 500
  3. 當顧客登入店內 WiFi 時,Purple 會觸發具有相同電子郵件地址的 Identify 呼叫。
  4. Segment Unify 將線上個人檔案與實體造訪數據進行合併。
  5. 建立一個由 WiFi Login 事件觸發的 Engage Journey,並針對具有高價值特徵的使用者進行篩選。
  6. 該 Journey 向電子郵件平台發送 Webhook 以觸發折扣碼。
考官評語: 此方法彌合了線上到線下的差距。透過使用電子郵件地址作為確定性比對鍵,識別圖譜成功地將電子商務個人檔案與實體店面造訪進行即時串聯,從而實現立即啟用。

練習題

Q1. 您的行銷團隊希望追蹤新行動應用程式上的 150 種不同使用者互動,並將其發送到 Segment。您應該如何處理此實作?

提示:考量維護成本和資料用途。

查看標準答案

拒絕該請求。要求行銷團隊定義每個事件將推動的具體業務決策或行銷活動。將清單縮減至這些使用案例所需的最基本可行事件,並在 Tracking Plan 中記錄,且僅實作這些事件。在沒有使用案例的情況下追蹤資料會產生技術債。

Q2. 客戶要求根據 GDPR 刪除其所有個人資料。您如何在連線到 Segment 且擁有 15 個不同下游工具的架構中執行此操作?

提示:查看 Segment 的隱私功能,而非手動刪除。

查看標準答案

使用 Segment 的 Privacy Portal 發出刪除請求。Segment 將在自己的封存檔案中處理刪除,並自動將刪除請求轉發到所有支援的下游目的地,以確保整個架構的合規性,而無需在 15 個獨立工具中進行手動干預。

Q3. 您注意到單一使用者在 Segment 中有兩個獨立的設定檔:一個包含其網站瀏覽歷史記錄(匿名 ID),另一個包含其 WiFi 登入資料(電子郵件地址)。為什麼 Unify 沒有合併它們?

提示:身分圖譜(identity graph)如何將匿名流量連結到已知使用者?

查看標準答案

使用者尚未在網站上執行將匿名 Cookie 連結到其已知電子郵件地址的動作。要解決此問題,您需要在網站上進行驗證事件(例如登入或訂閱電子報),以觸發傳遞匿名 ID 和電子郵件地址的 Identify 呼叫。一旦發生這種情況,Segment 將把歷史瀏覽資料與 WiFi 設定檔合併。