CDP 連接器神話

在我參加的最近一次 CDP 演示中，一位緊張的客戶詢問供應商他們是否有連接到 Salesforce Sales Cloud 的連接器。 供應商肯定地回答，客戶鬆了一口氣。 但事實是——大多數客戶數據平台 (CDP) 供應商的封裝連接器令人失望。 繼續閱讀以了解為什麼會這樣以及您可以做些什麼。

一段歷史：企業“portlets”競賽

這次邂逅讓我想起了“企業門戶”時代。 當我回顧 2000 年代末和 2010 年代初時，請放縱我——大多數客戶和供應商都願意忘記這段時間，但今天仍然有教訓。

企業門戶應該為潛在廣泛的企業應用程序提供一個單一、方便的界面，在儀表板主題的屏幕上顯示為單獨的塊。 支撐這些單獨塊的技術有很多名稱，但現在，讓我們稱它們為“portlet”。

很快就很清楚，門戶程序從根本上講是高度複雜的集成項目，因此企業自然會尋求利用預製連接器代碼。 供應商以 portlet 目錄作為回應，軍備競賽隨之而來。 “我們有 250 個 portlet，”供應商會吹噓道。

這些 portlet 在出處、支持、可用性、性能、安全性和（至關重要的）技術基礎方面會有很大差異。 “portlet”通常是某人為單個客戶端實現編寫的某些 Java 或 C# 代碼的參考實例。 通常情況下，代碼需要徹底修改，有時是從頭開始。

供應商反駁 - 並非不公平 - 問題通常源於遠程系統的配置方式，而不是門戶平臺本身。 也許是這樣，但企業最終厭倦了 portlet。 在數字世界的其他技術和業務變革中，門戶平台技術逐漸過時。

新的 CDP 連接器競賽

快進到今天，世界開始將 CDP 理解為集成環境（以及其他）。 我們合作的每個 CDP 選擇團隊都在努力尋找具有預構建連接器的供應商，以與其現有平台相匹配。 然而，幾乎每個 CDP 實施都發現昂貴的開發人員大量修改或重寫這些連接器。

CDP 供應商似乎屈服於他們的門戶網站兄弟所承受的壓力。 如果客戶重視多樣化的連接器目錄，那麼作為 CDP 供應商，您必須展示其中的許多連接器，無論是否準備就緒。 在 CDP 演示中，連接器在屏幕上顯示為整齊的塊（連接平台徽標突出顯示），您可以四處拖動 — 幾乎像 portlet！

好吧，沒那麼快。 與 portlet 一樣，CDP 供應商連接器可能僅來自單個實現的輸出。 更重要的是，在某些情況下，單個連接器不可能解決另一端 Martech 平台的複雜性。

考慮上面提到的 Salesforce Sales Cloud。 該平台存在一個有問題的對像模型，大多數被許可人扭曲或大量擴展該模型。 這就像連接到一隻非常憤怒的章魚。 Salesforce 在這方面絕非孤軍奮戰。 在這種情況下，CDP 供應商的連接器只能提供基本的腳手架，其餘的留給開發人員。

敵人是我們嗎？

門戶網站因另一個原因而消失。 如果說眼睛是心靈之窗，那麼門戶就是企業腸胃之窗。 門戶僅與底層應用程序一樣有用。 通常，這些應用程序雜亂無章，缺乏通用的內容和元數據模型，採用不同的訪問控制機制，展示不同的用戶體驗模型，有時還會暴露低質量的數據。

在我的公司，我們在 CDP 上看到了類似的現象。 根據您如何確定 CDP 工作的範圍（以及這裡出現的不同模式），CDP 可能會暴露您更廣泛的客戶數據管理制度的不成熟——更有理由將任何預期的 CDP 與您更廣泛的數據架構相匹配。

深入挖掘：如何使用新的 CDP 識別和組織數據

提防聲稱擁有多種連接器目錄的 CDP 供應商

一如既往，預先警告是預先準備好的。 首先，重新考慮超重聲稱擁有與您的堆棧匹配的連接器目錄的供應商。 除了其他原因，簡單地移動 CSV 文件可以解決許多（非實時）用例。 當您需要封裝的連接器時，特定的集成經驗會變得有用，但並不會固有地對沖您未來的實質性發展。 關鍵是看多少 發展。

希望您正在遵循一個敏捷的 CDP 選擇過程，該過程以競爭激烈的烘烤和與一兩個決賽入圍者的更具技術性的概念驗證 (PoC) 結束。 PoC 是測試一些基本連接器的絕佳環境。 然後，您將了解在必要時進行大修的努力程度——而且可能經常如此。

與他們的門戶供應商前輩一樣，CDP 供應商將承諾“快速啟動”包以加速初始實施。 別相信。 再一次，一些延遲可能源於您需要整理自己的數據室的時間，而且，我可以向您保證，有人將進行連接器開發，並且這項工作以季度而不是月為單位進行衡量。 相應地預算您的資源。

獲取營銷技術！ 日常的。 自由的。 在您的收件箱中。

企業電子郵件地址

訂閱 加工...

見條款。