HI, 你好！我是來自19DPG 數字營銷學院的孫櫟。本文是旨在幫助買家評估客戶數據平台（Customer Data Platform）系統的系列文章之二。它提供了CDP系統的揹景，CDP系統的一般功能描述，並對買家準備選擇採用CDP系統所進行評估時所涉及到數據攝入問題列示了檢核清單。
客戶數據平臺的揹景及功能描述
請參考 CDP非技術問題評估
數據攝入問題的檢核列表
數據加載
這些問題涉及將多方源數據加載至CDP系統相關方面。
內部系統。公司自己的系統是CDP的基礎，因為它提供了有關與客戶和潛在客戶交互的直接信息。 典型的源系統包括公司網站，電子商務，移動應用程序，零售POS，銷售自動化，客戶支持，訂單處理，計費和客戶忠誠計劃。 您的業務可能還有其他類型，如銀行存款賬戶或航空公司票務。 來自公司係統的數據通常被稱為“第一方”數據。 關鍵問題包括CDP是否可以整合貴公司源系統提供的數據類型; 貴公司現有系統是否有現有連接器; 是否有公共應用程序接口（API）來構建新的連接器; 以及構建這種連接器所需的努力。
跟踪標籤。一些CDP通過網站標籤和相關技術直接收集數據。 具有此功能的大多數供應商最初都是使用Javascript標籤開始的，該標籤將關於網站訪問者的信息發回中央服務器，這些服務後來演變成為“標籤管理系統”，包括更多其他標籤，減少了頁面加載時間，簡化了多個標籤的維護，並賦予所有者更多的控制從他們的網站流出的數據。 供應商還擴大了他們的範圍，以從其他來源（如移動應用程序）捕獲數據，這需要與原始Javascript標籤不同的技術（請參閱下一部分）。 由於標籤管理本身仍然是一個重要功能，因此要問的關鍵問題包括CDP用戶如何添加，配置和刪除其他標籤; 對頁面加載時間的影響; 以及他們如何控制通過何種標籤所獲取的哪些數據可以被共享。 更一般的問題涉及系統可以捕獲的數據類型以及如何存儲和訪問。
軟件開發工具包（SDK）。一些CDP提供可嵌入移動應用程序或類似系統（交互式電視系統，健身設備，智能家居設備，其他物聯網產品）的SDK。 SDK收集有關用戶和應用程序行為的數據。 許多SDK超越行爲數據的收集，可以在應用程序內傳遞消息和採取其他動作。 像標籤管理系統一樣，來自CDP的SDK可能會控制從應用程序到其他系統的數據流，從而使應用程序開發人員不必將多個SDK嵌入到其產品中。 要問的問題包括：部署和管理SDK需要哪些技術或技能; SDK可以捕獲什麼樣的數據; 將數據提供給其他應用程序（替換這些應用程序的SDK）以及數據庫或報告系統等其他來源的預構建連接器; 什麼功能可用來創建自定義連接器; 以及該系統具有傳遞消息並採取其他應用程序內動作的能力。
網絡爬蟲。一些CDP供應商從外部網站收集數據，包括公共社交媒體活動。 這通常用於開發企業營銷的公司資料。 由此產生的數據被用來增強客戶和潛在客戶資料，以及公司無法通過自己的系統收集的信息。 這種處理需要先進的技術來解釋非結構化的來源數據，如網站內容和自然語言評論。 關鍵問題包括：可以包含哪些數據源; 如何選擇這些來源; 如何處理源數據以提取信息; 數據分配給哪些類別; 用戶是否可以創建自定義類別; 並可進行怎樣的檢查以確保准確性。 再次，還有其他更一般的問題，如信息如何與正確的公司或個人相關聯。
外部數據。CDP可以合併來自其他所有者的數據。這些數據所有者通常是收購和銷售數據的公司，例如大型個人或商業數據庫的編譯者或將網絡行為信息與匿名cookie相關聯的廣告網絡。這種信息被稱為第三方數據。有時，這些信息可能來自另一家有興趣與其他公司共享有關其客戶或潛在客戶信息的公司，這樣做的原因大多是為了共同推廣。這被稱為第二方數據。對於第二方數據的處理可以由可信代理處理，使得兩個公司都不需要與另一個共享其整個客戶數據。與外部數據有關的問題包括：是否與特定的商業來源存在既有整合;涉及建立新連接的努力;數據源更新和數據加載的頻率;是否可以在不導入數據的情況下實時訪問數據源;以及如何管理任何使用限制。第二方數據還經常帶有必須在CDP中管理的特定使用限制。
加載方法。數據可以通過多種方式加載到CDP中。首選技術通常是一個API連接，一旦建立，幾乎不需要付出任何努力。有關API連接的問題包括API是否已發布和文檔化;有什麼功能可用（除了加載數據，你還可以做一些事情，如定義新的數據類型或關係）;是否可以一次加載多個記錄;有什麼樣的安全措施？ CDP是否可以從另一個系統的API請求數據;以及API調用的數據量或頻率是否有限制。當源系統不支持API連接時，可能會使用批處理文件進行加載。第一個問題是批量加載是否被支持;其他問題包括哪些文件格式被接受（CSV，XML，數據庫表等），加載是否可以自動執行以及如何工作;在加載過程中的錯誤處理;與大小或頻率相關的任何限制。第三個加載選項是CDP主動查詢外部系統。問題將包括支持的查詢類型;連接如何配置;自動化調度;錯誤處理;數據量或頻率限制。
外部訪問。一些CDP可以訪問存儲在公司內部系統或外部系統中的數據。 這種方法有時被稱為“聯合訪問”。 它避免了加載大量的細節，比如Web日誌，或者僅在某些情況下相關的數據，例如購買行爲發生時的天氣或位置。 與外部訪問相關的問題包括可用的連接類型; 具體來源有哪些可用連接器？ 檢索數據並使其可用（對於實時交互非常重要）所需的時間; 系統如何找到特定個人的數據（例如，是否需要客戶ID？），CDP如何指定返回哪些數據元素; 以及如果沒有找到請求的數據，系統如何響應。
數據結構
這些問題涉及數據如何被存儲在CDP系統相關方面。
數據類型。一般來說，您的CDP需要存儲源系統發送的任何類型數據。這至少包括標準的結構化要素，如客戶名稱和交易日期。這些很容易適合傳統的數據結構，每個項目都被仔細地定義和存儲在自己的位置。但是今天的大多數客戶數據還包括較少結構化的信息，例如Web日誌和消息文本。這類數據的情況可能各不相同，包含不同的元素集合，具體取決於正在報告的內容。有時這些元素在提供時被標記，例如在包含兩個元素的“鍵:值 對”中：指定數據類型的鍵和指示實際數據的值。這樣的一對可能是“名字:大衛”。如示例所示，通常需要額外的上下文來指示鍵值對的所有者 – 在這種情況下，它可能與顯示客戶ID或帳號的另一鍵值對關聯。這些鍵值對在“NoSQL”數據庫中很常見。他們可以很容易地添加新的數據元素（即密鑰），而無需事先對其進行正式定義。當然，密鑰必須一致地命名以使數據可用。
其他數據類型的結構化程度更小，例如必須使用高級語言處理技術解析的文本塊，這些技術可以提取特定元素，例如在新聞稿中標識公司名稱或在客戶投訴電子郵件中標識產品名稱。 更高級的處理可以超越尋找實體名稱，以理解實體之間的關係（例如，一篇新聞文章說，公司A收購了公司B，另一篇文章說公司C正在起訴公司D）或理解情緒（例如， 顧客對一個產品不滿意）。 通常，這種處理用於將非結構化數據轉換為結構化元素，然後可以使用標準技術處理結構化元素。
CDP也可以存儲非文本數據，如圖像，視頻或音頻。 這些信息通常伴隨著結構化的數據，如名稱，主題和日期，用於訪問和分析數據。 諸如圖像識別之類的高級技術也可用於將結構化數據附加到這些輸入的數據之上。
與數據類型相關的問題包括系統可以採集什麼類型的數據; 從非結構化或半結構化輸入中提取信息的能力怎樣; 以及如何訪問存儲的數據和描述性屬性。
模式。傳統的關係數據庫（如Oracle或SQL Server）將數據存儲在具有已定義數據元素（列）的確定數據庫表中，並在表之間定義關係（通過諸如Customer ID之類的公共元素關聯）。 這組定義提供了一個固定的模式，可以很容易地理解什麼數據存儲在哪裡。 這樣的結構在很多情況下可以非常有效地處理，並且幾乎總是存在於CDP中的某個地方，只是因為外部系統需要它們來訪問存儲在CDP中的數據。 但是這樣的模式本質上是僵化的，這意味著任何變化，例如添加一個新元素或表格，都必須事先定義。 可以攝取半結構化數據的CDP也能以半結構化的方式存儲該類數據，例如前面提到的“半結構化的”鍵:值對。 這使得CDP可以容納新的數據元素，而無需預先計劃，使其顯得更加靈活。
為了使數據可訪問，CDP必須跟踪哪些元素已經被加載，並且必須經常將這些元素轉換為定義的數據結構，以便它們可以被映射和索引以供外部工具使用。與CDP模式相關的問題包括：如何定義數據元素;添加新元素的過程;如何通知用戶和其他系統有哪些元素可用;以及元素之間的關係是否有任何限制。關係問題是重要的，因為CDP越來越期望在社交網絡中存儲諸如連接之類的關係，然後讓用戶查詢他們 – 例如找到“朋友的朋友”或“朋友擁有的產品”。對於傳統的關係數據庫來說，這些可能是困難的。同時，無模式系統在捕獲關係數據庫模式中精確指定的關係時可能會遇到問題。所以營銷人員需要考慮各種情況，並具體探討CDP如何處理每一種情況。
標準對象。根據定義，CDP數據是圍繞客戶組織的。一些CDP將所有輸入視為客戶的屬性。這使加載數據變得簡單，但可能會限制在項目之間存儲關係的能力，例如將產品鏈接到活動。其他CDP為數據結構提供了諸如產品，渠道，營銷活動和消息等標準對象。標準對象讓CDP包含使用這些對象的預建功能，例如活動報告和下一個產品購買的預測模型。標準對像還可以簡化外部數據到CDP的映射，並通過外部系統訪問CDP數據。與標準對象相關的問題包括：CDP中內置了哪些標準對象;對像是如何相互關聯的？添加一個對象的必要條件;新對象與標準對象相關聯是否有限制？如果不使用標準對象，會發生什麼情況;而且，是否有依賴於標準對象的特定功能？
輸入映射。雖然有些技術允許攝取數據而不將其分配給預定義的數據元素，但是這些數據最終必須被分類以備使用。 這意味著用戶必須指定一組標準元素，例如姓名或電子郵件地址，然後定義來自每個來源的哪些信息將被分配給這些元素。 這個映射過程對於結合來自不同來源的信息和進行多種分析和處理是必不可少的。 與映射過程相關的問題包括：如何定義標準元素; 來自源系統的輸入如何分配給標準元素; 如何處理丟失的元素（特別是關鍵元素，如客戶標識符）; 如何處理新的或未映射的元素; 以及在將輸入放入標準元素之前，系統如何轉換或標準化。
訪問限制。允許在CDP中使用某些數據可能受到政府法規，公司政策或與供應商達成的協議的限制。 CDP需要能夠執行這些限制，或者至少需要獲取數據才能使執行成為可能。 與訪問限制有關的問題包括：是否有定義對指定數據元素的訪問權限的標準方法; 可以限制時間（如合同到期日期）; 系統是否可以要求指定的憑證來訪問指定的元素（例如特殊的密碼）; 系統是否可以限制訪問其他指定的系統; 系統是否可以保存指定元素的訪問日誌; 系統能否提醒管理者未經授權的訪問嘗試; 系統可以將屬性添加到描述允許使用的數據元素中; 並且，系統可以通過在提取之前移除指定的標識符來匿名化數據。
性能
這些問題涉及CDP系統的性能相關方面。
延遲。這是指在CDP內獲得新數據需要多少時間。其中一個因素是從源系統獲取數據的速度有多快，從即時（只要進入源系統）到週期性（加載所有新數據的頻次，從最後一次加載以來每天，每週甚至更長周期） 。另一個因素是提供新數據所需的時間：系統可能需要從非結構化數據源提取結構化數據，將數據轉換為標準格式，檢查數據的準確性或完整性，創建聚合或索引，或者加載數據轉化為針對外部訪問優化的專用數據庫。與延遲有關的問題包括：接受實時輸入的能力;批量輸入頻率的任何限制;準備數據所需的過程，以及這些過程的時間;有時間將數據加載到任何二級結構中;以及在數據更新過程發生時可訪問的內容。如果更新過程冗長，那麼最後一個問題是重要的：如果沒有做出適當的規定，系統可能完全不可用，運行緩慢或返回不一致的信息。請記住，輸入頻率通常由源系統決定，因此某些延遲可能超出了CDP系統的控制範圍。
響應時間。這是指系統在請求時可以多快返回數據。如果CDP支持實時交互，如網站個性化，展示廣告出價或電子商務產品推薦，則響應時間最為緊迫。這樣的交互可以有非常嚴格的響應要求，對於某些應用程序，低至30毫秒。響應時間對於非實時進程也很重要，比如用戶指定的記錄段計數需要多長時間，或者需要提取記錄段中的數據時長。分配給CDP的計算資源通常可以調整以滿足指定的性能要求，或者可以引入諸如索引的其他特徵。用戶需要提前知道他們需要的響應時間。與響應時間相關的問題包括：返回實時請求的時間;可以在實時請求期間完成的活動（例如計算預測模型評分）;對實時返回的數據量或類型的任何限制;需要預先確定哪些元素是實時可用的;哪些需要時間進行分析計算，哪些因素會影響時間;使用不同的方法（API，查詢，批處理文件）提取數據所需花費的時長;以及必要時可用來縮短響應時間的選項。
可擴展性。這是指CDP可以處理的數據量。 它有很多維度，包括源系統的數量，客戶的數量，每個客戶的數據元素的數量，數據模型的複雜性以及所存儲的數據的總量。 延遲和響應時間通常受數據量的影響，使其成為可擴展性等式的一部分。 對於實時應用程序，可伸縮性還包括在滿足所需響應時間的同時系統可以維護的同時連接（對於Web會話，呼叫中心代理，移動應用程序等）的數量。 與可伸縮性相關的問題包括：對各個維度（源系統，客戶，數據元素，數據模型，總量，連接等）的限制; 配置選項來克服可伸縮性限制; 以及現有供應商配置的規模。
功能
這些問題涉及支持數據攝取所需的特定功能。
部署工作。這是指部署系統所需的員工時間和技能。 營銷人員需要特別關注的是技術和非技術兩方面。 需要花費太多精力的CDP根本不會被部署。 與部署工作相關的問題包括：營銷人員的工作任務，包括工作時間，技能和所需的具體業務知識; 由供應商或其他外部人員執行的任務; 企業IT人員執行的任務; 需要的培訓; 初始部署的範圍; 項目時間表; 建立在時間軸上的假設; 和項目管理過程。
維護工作。這是指部署後維護系統所需的員工時間和技能。 它既包括日常運作系統的工作，也包括增加新數據，調整數據準備流程，發布新輸出，連接新系統以使用CDP等方面的改變。 儘管這些信息不能準確地提前得知，但營銷人員需要對CDP需要的資源進行現實的估算。 與維護有關的問題包括：維護系統所需的任務; 工作時間，日曆時間，技能和特定任務所需的培訓，如添加新的數據源; 可用於幫助完成這些任務的工具; 以及為這些任務使用供應商或外部資源的選項。
檢查輸入。這是指對輸入數據進行基本檢查，例如是否包含預期的數據結構，元素和值。在加載時發現錯誤的輸入是非常重要的，因為一小部分壞數據一旦被合併到整個CDP的更大的數據池中，就很容易被忽略。輸入檢查對於高度結構化的數據是最重要的，因為系統可能無法處理例外格式的記錄。但是即使是可以接受非結構化輸入的系統也可能需要標記新的元素或標籤，以便用戶可以決定如何對它們進行分類。有些系統還可以檢查特定字段中數據值的分佈是否合理：例如，將所有客戶生日設置為同一天或所有交易金額設置為零的數據饋送將是高度可疑的。與輸入檢查有關的問題包括：什麼樣的檢查是可能的;提供什麼報告;系統如何識別可疑的輸入;而且，系統如何提醒用戶潛在的問題。
回滾不良輸入。這是指在數據已經被輸入系統後刪除不良數據的能力。 它要求將數據標記為其原始來源，並且系統要么物理刪除不良信息，要么將其標記為忽略。 覆蓋現有數據而不是附加新記錄的系統可能難以糾正，因為之前的值可能會丟失。 刪除不良數據還可能需要重新計算派生數據，如聚合，提取和索引。 涉及到大量數據時，這可能非常耗時。 有關回滾的問題包括：是否存在回滾功能; 哪些類型的數據可以回滾; 配置選擇需要使回滾成為可能; 執行回滾所需的步驟和技術技能; 執行回滾所需的時間; 以及在回滾期間的系統可用性。
發現和探索。這是指讓用戶在添加到系統之前探索新數據的功能。 （加載後的數據探索包含在不同的清單中。）它超越了對輸入質量的自動化輸入檢查，讓用戶找到新的數據元素，值和關係。核心功能包括查看輸入記錄的樣本;數據元素標籤和值的頻率分析;標籤和值之間的相關性報告;並將新投輸入與以前輸入進行比較。具體目標是幫助用戶確定是否以及如何使用新的數據源。要問的問題包括：有哪些工具可用於檢查輸入數據;什麼樣的標準報告是可用的;在可以探索數據之前，必須完成多少加載流程;使用這些工具需要什麼技能;可以在將數據與主數據存儲合併之前將數據加載到暫存區域中;什麼樣的數據存儲用於暫存區域;可以使用哪些第三方工具來檢查暫存區中的數據;並且可以將分段區域中的數據與已經加載到主數據存儲中的數據進行比較。
网友评论