現代 Salesforce 整合必須支援比簡單的資料交換更多。他們預期能夠提供即時客戶體驗、協調多個系統的動作,並在企業規模上可靠運作,同時符合嚴格的安全性和合規性需求。因此,選擇正確的整合方法是重要的結構決策,而非實作詳細資料。 請考量常見的企業案例。客戶在行動應用程式中完成購買,以觸發個人化優惠的即時資格檢查。同時,必須在 ERP 系統中記錄交易資料、在 Salesforce 中更新客戶屬性,以及將分析串流至資料湖—而不會導致延遲、資料重複或合規性風險。此類案例現在在現代 Salesforce 環境中很典型,Salesforce 很少獨立運作,且必須與更廣泛的應用程式與資料平台生態系統順暢整合。 此指南是為了協助結構設計師和開發人員以清晰且自信的方式設計這些整合。它不專注於點對點實作,而是呈現一組已驗證的整合模式,以處理循環的企業案例,例如流程協調流程、資料同步化和即時資料存取。每個模式都會強調架構意圖、權衡和執行模式,讓小組能夠做出明智的設計決策,以擴展和持續。 在此文件中,您會發現:

• 代表流程、資料和虛擬存取情況之間常見企業「階層類型」的整合模式
• 模式選取架構,可協助根據整合意圖和執行時間點找出正確的方法
• 關於可擴充性、彈性、管治和安全性考量事項的實際指引
• 從實際世界 Salesforce 與 Data 360 實作中所取得的最佳作法 此文件的目標是提供整合的共用結構語言,協助小組設計平衡效能、彈性和 Trust 的解決方案,同時與企業資料和管治策略保持一致。

此文件適用於需要將企業中其他應用程式的資料與 Salesforce Data 360 (先前稱為 Data Cloud) 整合的設計師和結構設計師。此內容是 Salesforce 結構設計師和合作夥伴成功實作的精密精簡。 若要熟悉可用於大規模採用 Data 360 的整合功能和選項,請參閱下方的「模式摘要」和「模式選取指南」一節。結構設計師和開發人員在將資料互動專案納入 Data 360 的設計和實作階段期間,應考量這些模式詳細資料和最佳作法。 若正確實作,這些模式可讓您盡快進入生產環境,並擁有最穩定、可調整且無維護的應用程式集。Salesforce 自己的諮詢結構設計師會在結構審查期間使用這些模式作為參考點,並主動維護和改善模式。 與所有模式一樣,此內容涵蓋大部分的整合案例,但並非全部。例如,Salesforce 允許使用者介面 (UI) 整合,但此類整合超出此文件的範圍。

每個整合模式皆遵循一致的結構。這可讓每個模式提供的一致資訊,並且更容易比較模式。

• 名稱:此模式識別碼也表示模式中包含的整合類型。
• **內容:**模式處理的整體整合情況。「內容」提供使用者嘗試達成之目標的相關資訊,以及應用程式支援需求的行為。
• **問題:**以問題表示,這是模式設計要解決的案例。請閱讀此區段以瞭解模式是否適合您的整合案例。
• **力:**使所述情況難以解決的限制與狀況。
• **解決方案:**解決整合案例的建議方法。
• **草稿:**UML 順序圖表,顯示解決方案如何處理案例。
• **結果:**說明如何將解決方案套用至整合案例的詳細資料,以及其如何解決與該案例相關聯的障礙。此區段也包含因套用模式而可能發生的新挑戰。
• **側列:**與模式相關的其他區段,其中包含重要的技術問題、模式變化、模式特定的疑慮等。
• **範例:**描述如何在 Salesforce 實際案例中使用設計模式的實際世界案例。範例說明整合目標,以及如何實作模式以達成這些目標。

使用此表格作為此文件中所包含整合模式的目錄。

此文件中的整合模式分為三個種類:資料、程序和視覺整合。

Data 360 中的資料整合模式可解決跨系統的資料移動和同步化,以確保 Data 360 與外部平台都保留一致、及時且值得信賴的資訊。這些模式通常會處理大規模、大量的資料流程,並依賴強制執行結構描述一致性、歷程追蹤和掌握規則的受管理管道。

• 「批次接收模式」代表企業資料上線的基礎層。從雲端儲存體服務 (例如 AWS S3、Azure Blob 或 Google Cloud Storage) 採取大量資料,可將大型歷程記錄資料集定期載入至 Data 360 以進行身分解析、區隔和分析。同樣地,從 Salesforce Clouds (例如 Sales、Service 或 Marketing Cloud) 大量採取會使用原生連接器和資料串流,將 CRM 資料帶入統一的資料層,確保參與系統之間的調和和和連續性。
• 「**串流和即時取用模式」**可藉由快速事件資料來加強此功能。透過「取用 API」以事件為導向的方式,讓外部系統能夠將客戶活動持續串流至 Data 360。即時的 Web 和行動行動行動行動行動式的行動式行動式行動式行動式的行動式行動式動作,可直接從數位接觸點中捕獲點閱串流和互動資料,以促進立即個人化。透過串流 API 進行近乎即時的 CRM 同步化,可確保客戶屬性和同意更新可在整個系統之間快速反映。來自如 Amazon Kinesis 或 Confluent MSK 等傳訊平台的事件串流,支援連續的高輸送量管道,讓 Data 360 與企業事件結構保持一致。
• 統一多組織資料平台與 Data Cloud One 進一步範例化資料整合,提供一個合併的環境,以在共同的管治和語意層下統一來自多個 Salesforce 組織和外部來源的資料。這可讓組織達成企業範圍資料一致性、共用資料模型和可調整分析。
• 在啟用階段中,批次啟用模式遵循相同的資料整合原則。在 Data 360 中精密設計的區段會在排程的工作中匯出至下游行銷和廣告平台 (例如 Marketing Cloud、Meta Ads 或 Google Ads),在其中觸發行銷活動執行。同樣地,資料集可以匯出至雲端儲存目標,以支援外部分析和資料科學銷售管道。在所有這些使用個案中,Data 360 會作為同步化與精密設計的客戶資料事實來源。

Data 360 中的流程整合模式涉及在近乎即時的情況下,觸發或協調跨系統的業務流程。這些模式可讓 Data 360 主動參與企業工作流程,以啟用內容相關回應和動態資料啟用。

• 隨選 API 型啟用可啟用即時參與情況。透過 Connect API,自訂應用程式可以直接從 Data 360 查詢或啟用客戶設定檔,以作為作業流程的一部分,例如工作人員主控台在客戶互動期間提取統一設定檔洞察。「**透過 Data Graph API 完成客戶設定檔檢索」**支援依賴對客戶完整實體圖表的 API 驅動存取權的複合應用程式和微型服務,以允許沒有預先階段區段的動態體驗。
• 「**即時資料動作」**透過啟用立即回應性,進一步推動此整合方法。當偵測到客戶訊號時 (例如購買、表單提交或值值事件),Data 360 可以觸發動作,例如更新 CRM 記錄、叫用外部 Webhook 或啟動個人化優惠工作流程。這些模式實現了真正的流程協調流程,將即時客戶智慧與自動化作業執行橋接。

Data 360 中的虛擬整合模式可讓您即時存取外部或聯邦資料來源,而無須實際複製或複製資料。這些對於在查詢時需要受管理且最新的資訊,同時將資料移動降到最低的企業而言至關重要。

• 輸入零複製資料聯合 (External Platforms-to-Data 360) 允許外部系統 (例如資料倉庫或資料湖) 透過受管理的安全連線 (例如 Snowflake 安全資料共用) 與 Data 360 共用資料集。這可確保 Data 360 可以虛擬地存取和操作外部資料,進而保持最新狀態並消除不必要的複製。
• 輸出零複製資料共用 (Data 360 至外部平台) 可讓 Data 360 透過安全的資料聯合和即時查詢機制,將精密設計的資料集公開供外部使用,例如 AI 建模、業務情報或進階分析。 為您的系統選擇最佳的整合策略並非不簡單。有許多要考慮的層面以及可以使用的工具,有些工具比其他工具更適合某些工作。每個模式都會處理特定重要區域,包括每個系統的功能、資料量、失敗處理和交易性。

選取整合模式時,請先回答整合整體設計和行為的兩個基本問題。 您要整合什麼?—程序、資料或虛擬存取權 此維度定義整合的主要目的。

• 流程整合著重於協調業務工作流程和跨系統協調動作。
• 資料整合專注於在系統之間同步化、增強或移入資料。
• 虛擬整合專注於即時存取外部資料,而無須在 Salesforce 或 Data 360 中複製或保留。 瞭解此意圖有助於決定系統之間所需的協調流程、資料移動和配對層級。
• 如何執行? — 同步或非同步方法定義整合的執行模式。
• 同步整合是即時和封鎖的,來電者預期立即回應,通常用於使用者驅動或驗證案例。
• 非同步整合為非封鎖與分離,專為處理規模、長時間執行流程、重試和大量資料而設計。 這些兩個維度 (整合意圖和執行時間) 共同提供清晰且一致的架構,可供選取正確的整合模式,同時平衡使用者體驗、可擴充性和作業彈性。 **備註:**整合可能需要外部中介或整合解決方案 (例如,Enterprise Service Bus),端視適用於整合案例的層面而定。

此表格列出模式及其關鍵層面,以協助您在從 Salesforce 整合至其他系統時判斷最適合您需求的模式

此表格列出模式及其關鍵層面,以協助您在從其他系統整合至 Salesforce 時,決定最符合您需求的模式。

此表格列出與 middleware 相關的一些重要詞彙,以及與這些模式相關的其定義。

Salesforce Data 360 資料生命週期中的第一個且最關鍵的步驟,即是資料取用。這是來自多個外部系統 (CRM、ERP、網頁、行動或第三方 API) 的原始資訊進入平台並成為統一客戶檢視的一部分的方式。 正確的採取模式取決於業務需求:

• 資料量—一次移動的資料量
• 延遲—資料的最新程度
• 來源系統功能—系統如何連線和傳送資料 Data 360 支援多種取用模式以滿足這些需求:大量載入的批次、近乎即時更新的串流、以事件為基礎的交易立即性,以及零複製取用,可立即存取外部資料而無須實際移動。 這些模式共同確保每個客戶訊號 (無論是購買事件、點閱記錄或忠誠度更新) 都會有效率、安全且在正確的時間範圍內流入 Data 360,以支援信任的分析和 AI 驅動的體驗。

大規模資料上線在 Data 360 中的支柱,是批次採取模式。其針對大量處理資料的情境 (通常是排程或定期處理) 而非持續處理資料的情況進行最佳化。 這些模式最適用於:

• 以現有企業記錄初始化平台的歷程記錄資料載入
• 定期與記錄系統 (例如 ERP、資料倉庫或專屬資料庫) 進行同步化
• 使用不需要即時新鮮度,但需要一致性、完整性和可稽核性的個案 針對管理結構化或半結構化資料的 TB 時,可預測的效能與作業簡易性,這使其成為信任的選擇。 Data 360 提供一組現成生產的廣泛可用**連接器,這些連接器**原生支援批次入院。這些連接器可簡化整合設定、減少自訂 ETL 開發,並確保每次匯入的資料品質與安全性。下表會醒目提示用於企業規模批次取用最常見的連接器。

Context

此模式針對企業案例設計,其中涉及從集中化資料湖或排程檔案中移除大量結構化資料 (例如 CSV 或 Parquet 檔案) 和非結構化資產。資料來源通常包括雲端儲存平台,例如 Amazon S3、Google Cloud Storage (GCS) 和 Microsoft Azure Blob Storage,其中檔案會定期作為上游資料銷售管道或批次匯出的一部分傳送。

問題

組織如何根據可預測的循環排程,建立可靠、安全且高輸出流程,將大量的檔案式資料集從其主要的雲端儲存平台提取至 Data 360,而不犧牲管治、擴展性或效能?

力量

將大量以檔案為基礎的資料集中至 Data 360 並非簡單的資料傳輸演練,而是由規模、管治和平台限制所塑造的結構挑戰。

**資料量與規模:**已針對可靠性和管治最佳化 Data 360 取用連接器,而非任何大量輸送量。例如,Amazon S3 連接器支援最多 1 千萬列或每個物件 50 GB,取決於先到達的限制。針對具有歷程記錄資料集的企業,此邊界會成為重要的設計限制。單一檔案、提取和排班方法快速無法運作,需要智慧資料分割、切分和協調策略才能達到規模,而無須達到連接器限制。

**結構描述定義與維護:**Data 360 需要針對每個採取管道具備明確的結構描述定義,以確保語意與結構完整性。在 S3 取用的情況下,csv 檔案必須定義欄標題和單一代表資料列。此檔案會作為來源系統 (即雲端儲存空間) 和 Data 360 之間的標準契約。欄位名稱、資料類型或編碼中的任何不對齊方式都可能導致移入失敗或無訊息資料損毀。在版本控制中維護此結構描述檔案,並透過 CI/CD 或資料管理工作流程強制驗證,會成為生產環境的最佳作法。

**嚴格命名慣例:**Data 360 會強制執行 嚴格的物件和欄位命名規則,以維持中繼資料圖表的一致性。

• 物件名稱必須以字母開頭,且只能包含字母、數字或底線。
• 欄位名稱必須遵循相同的模式。 違反這些慣例的檔案 (例如,包含空格、特殊字元或不支援符號的欄位) 會在取用期間無法驗證結構描述。企業必須實作食用前資料衛生程序,以清除和正規化傳入的檔案結構。

**驗證和安全性狀態:**每個外部儲存空間的連線都必須符合企業級安全性和合規性標準。

• 驗證通常會透過 AWS 存取金鑰/機密金鑰或聯邦身分提供者 (IdP) 驗證來處理。
• IAM 角色必須以範圍來強制執行最低權限,僅允許對指定儲存路徑的讀取存取權。
• 為了安全存取,輸出 IP 位址必須直接新增至來源系統的允許清單。 這些分層控制項可確保每個檔案傳輸都會在零 Trust 可稽核的範圍內運作,以平衡企業合規性與大規模摘要所需的彈性。

解決方案

此表格包含此整合問題的解決方案。

草稿

此圖表說明將資料從雲端儲存空間匯入至 Data 360 的步驟順序

在此情況下:

• 管理員透過 Data 360 設定介面設定雲端儲存空間的連線 (指定驗證、分類詳細資料、IAM 角色和白名單)。
• 「Data Cloud 設定」介面會使用 Cloud Storage Platform 進行驗證,驗證認證和存取權。
• 管理員會在 Data 360 中建立資料串流,將資料串流連結至 Cloud Storage 中的物件/資料夾,並定義取用排程。
• 在排程觸發時,資料串流會從雲端儲存平台要求來源檔案 (例如 CSV、Parquet)。
• Cloud Storage Platform 會傳送檔案,包括必要的有效 schema_sample.csv 以及其他符合命名慣例的資料檔案。
• 「資料串流」會將檔案傳輸至 Data 360 內的內部暫存環境。
• Data 360 Pipeline 處理檔案:使用 schema_sample.csv 中的結構描述定義「驗證結構、欄位名稱」,並在超過取所值 (100 百萬列/每個檔案 50 GB) 時分配載入。如果偵測到大型檔案,則會在外部執行預先處理的分割步驟 (通知管理員以進行下一次執行)。
• 記錄會從暫存匯入至資料湖物件 (DLO)。
• 如果需要且資料已分割,請使用批次資料轉換中的 append 節點來結合多個 DLO。
• Data 360 會記錄成功/失敗、更新監視狀態,並表示資料已準備好進行對應、調和和統一。

結果

此模式的應用程式可將結構化或非結構化檔案從企業雲端儲存平台安全、排程及大規模提取至 Data 360。此流程是自動化、可調整且彈性的,可將原始資料傳送至資料湖物件 (DLO),作為調和和對應至 Customer 360 資料模型的基礎。

吸收機制

取用機制取決於在 Data 360 中定義的連接器和排程策略。

錯誤處理與復原

錯誤處理和復原對於確保高流量摘要作業的可靠性而言至關重要。

• **錯誤偵測:**每個「資料串流」執行都會記錄「Data 360 監視」中的採取錯誤 (例如結構描述不相符、檔案損毀或命名違規)。管理員可以檢閱並重新處理失敗的批次。
• 復原機制 360 會維護檢查指標,以確保失敗的批次不會損毀先前的摘要。您可以在修正來源問題 (例如格式錯誤的 CSV) 之後設定重試。
• 結構描述驗證.csv 檔案會定義資料類型與結構。任何變更都會觸發驗證,以避免在執行之間漂移無訊息的結構描述。

潛在設計考量事項

依設計而言,會無法移入;重新處理相同的檔案不會導致記錄重複。 重要策略包括:

• **檔案指紋:**Data 360 會計算核取總和,以識別並略過先前處理的檔案。
• **交易提取:**資料會暫存並僅在成功處理所有記錄時認可至 DLO。
• **附加與取代:**視業務邏輯而定,串流可附加至或完全取代目標 DLO;如此可確保決定性成果並避免部分資料重疊。

安全性考量事項

從驗證到加密和存取控制,安全性在整個採取管道中是整體的。

• **驗證與授權:**連接器使用 Salesforce 的「安全整合架構」,利用已命名認證和外部認證進行驗證,而不公開密碼。
• **加密:**資料會在傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密。
• **網路控制:**來源儲存系統 (例如 S3 分類) 必須將 Data 360 IP 列入允許清單。
• **合規對齊方式:**與客戶管理金鑰 (CMK) 配對時,支援企業資料保護架構,例如 GDPR、HIPAA 和 FFIEC 指導方針。
• **稽核性:**系統會針對可追溯性與合規性報告,來記錄每個採取工作和認證存取權。

側列

及時性

時間取決於取用排程和資料量。

• 大型企業資料集 (超過 100 萬列) 可能需要分割以進行並列接收。
• 依檔案大小和轉換複雜度而定,通常會有從 分鐘到數小時的延遲。
• 針對近乎即時的採取,Data 360 串流或以 API 為基礎的連接器可以補充檔案型模型。

資料量

• 最適合大量定期批次採取。
• 透過 S3 連接器處理的每個物件最多支援 1 千萬列或每個檔案 50 GB。
• 針對 petabyte 級系統,請使用資料分割和多串流協調流程。

端點功能與標準支援

端點的功能與標準支援取決於您選擇的解決方案。

州/省管理

系統會透過「資料串流」及其上次成功執行時間戳記來追蹤狀態。

• Data 360 會自動維護同步化狀態和偏移,以確保僅在後續執行時處理新的或修改的檔案。
• 與外部 ETL 工具整合時,建議使用唯一的檔案識別碼 (例如 UUID 或時間戳記),以避免重複。

複雜整合案例

在進階企業結構中,此模式可以與:

• 中介 ETL 銷售管道 (例如 Informatica、MuleSoft): 可協調對 Data 360 轉移前的預先處理、驗證和檔案分割。
• AI/ML 工作流程: 處理的 DLO 資料可透過 DMO 發佈至模型化訓練環境,或透過 Data 360 啟用目標發佈至 RAG 索引。
• 交易系統: 協調的 DMO 可以透過「資料動作」或「平台事件」在 Salesforce CRM 或外部系統中觸發下游更新。

範例

全球金融機構將客戶和交易資料儲存在 AWS S3 資料湖中,其中會依區域 (例如美國、歐盟和亞太地區) 每晚產生分割的 Parquet 檔案。資料結構小組會在 Data 360 中設定多個「資料串流」,每個都連線至區域資料夾,並使用共用的 schema_sample.csv,以確保所有分割的標題和資料類型一致。每晚的採取排程會自動將資料載入至 DLO,之後「批次資料轉換」會將所有區域分割附加至統一的 Customer_Transactions_DLO。此協調資料集接著會對應至 Customer 360 資料模型,以啟用後續分析和 AI 啟用。此方法可從現有資料湖中提供自動且可靠的採取、強制執行與企業 IT 原則一致的強式驗證和加密,並提供可調整的模組式基礎,以支援未來擴展和結構描述演進。

Context

Data 360 的主要且重要使用個案是整合 Salesforce 生態系統中的客戶資料。此模式涵蓋從核心 Salesforce 平台 (Sales Cloud 和 Service Cloud (統一稱為 Salesforce CRM) 和 Marketing Cloud Engagement) 原生收集資料。來源包含標準和自訂 CRM 物件 (例如帳戶、連絡人、個案、機會) 和 Marketing Cloud Engagement 資料延伸模組,這些擴充模組會保留參與事件、電子郵件傳送和追蹤資料。

問題

組織如何有效且可靠地將標準和自訂 CRM 物件和 Marketing Cloud Engagement 資料延伸模組提取至 Data 360,以便將資料用於建立統一的客戶設定檔 (身分解析、Customer 360),同時維持效能、管治和最少的來源系統中斷?

力量

原生連接器可簡化工作,但必須管理數個作業和結構力:

• **全方位來源權限:**專屬連線使用者 (整合帳戶) 必須擁有適當的物件和欄位級讀取權限。無法指派必要權限集 (例如,預先建置的 Data 360 連接器權限集) 是一個常見的原因。
• **資料重新整理模式與成本:**連接器支援完整和 delta/增量重新整理模式。完整重新整理對效能和點數而言較為重要;delta 解壓縮會減少負載,但取決於來源系統中可靠的變更追蹤。
• **自訂結構描述與欄位對應:**CRM 例項通常包含自訂物件/欄位。需要精確的結構描述對應和自訂欄位 (名稱、類型) 處理,以避免對應錯誤或語意漂移。
• 入門資料搭售方案與自訂對應:「入門資料搭售方案」可透過預先選取一般物件/欄位來加速上線,但大量自訂的組織需要自訂串流定義。
• **輸出與 API 限制:**來源組織 API 限制和 Marketing Cloud 解壓縮率會限制您可排程重新整理的積極性。
• **資料衛生與命名慣例:**來源欄位名稱、空值行為和資料類型必須先正規化,才能避免發生下游對應問題。
• **安全性和最低權限:**連接器依賴安全驗證,且必須遵循最低權限的 IAM 模式、稽核性與網路控制。

解決方案

此表格包含此整合問題的解決方案。

草稿

此圖表說明將資料從雲端儲存空間匯入至 Data 360 的步驟順序

在此情況下:

• 管理員會佈建整合使用者,並在來源組織中指派連接器權限集。
• 管理員會在 Data 360 設定中設定連接器 (透過 OAuth/連線應用程式連線至 Salesforce CRM 和 Marketing Cloud)。
• **管理員建立「資料串流」,**選取物件和「資料延伸模組」,選擇完整或差異重新整理,並設定排程。
• 排程執行時,Data 360 會向來源要求結構描述和差異權杖。
• 來源系統會傳回記錄 (delta 或完整裝載)。Marketing Cloud 可能會傳送提取;CRM 可能會傳回 JSON/Query 結果。
• Data 360 會在其內部安全暫存區域中暫存檔案,並根據對應的結構描述進行驗證。
• 若驗證失敗,會記錄錯誤、警示管理員,並停止認可。如果驗證成功,Data 360 會以原子方式將記錄認可至目標 DLO。
• 監視與稽核記錄會以歷程、執行持續時間、列數和認證用量更新。若觸發的值或錯誤,則發出給管理員的警示。

結果

核心客戶關係與行銷參與資料會作為「資料湖物件」(DLO) 來加以輸入至 Data 360。這會產生:

• 包含設定檔、個案、機會和電子郵件/參與度量的 統一資料集。
• 身分解析與建立「統一個人設定檔」的基礎 。
• 下游調和、增強、AI 建模和啟用,同時保留管治與稽核能力的營運整備。

吸收機制

取用機制取決於在 Data 360 中定義的連接器和排程策略。

錯誤處理與復原

錯誤處理和復原對於確保高流量摘要作業的可靠性而言至關重要。

• **每次執行記錄:**每個「資料串流」執行都會提供成功/失敗詳細資料與列層級錯誤。
• **重試與檢查:**修正來源或結構描述問題後,可以重試失敗的執行;Data 360 使用暫存和原子認可語意。
• **警示:**設定結構描述漂移、重複失敗或差異序列間隙的警示。

潛在設計考量事項

依設計而言,會無法再多取所取—重新處理同一個項目不會導致記錄重複。 重要策略包括:

• **變更偵測:**差異解壓縮依賴來源系統變更指標 (LastModifiedDate / 系統變更資料擷取)。確認來源提供可靠的時間戳記/標記。
• **復原:**使用唯一的業務金鑰 (例如,Contact.ExternalId) 來復原或更新插入至 DLO。
• **交易認可:**記錄會暫存並僅在批次處理成功完成時認可。

安全性考量事項

從驗證到加密和存取控制,安全性在整個採取管道中是整體的。

• **驗證與授權:**連接器使用 Salesforce 的「安全整合架構」,利用已命名認證和外部認證進行驗證,而不公開密碼。
• **加密:**資料會在傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密。
• **網路控制:**來源儲存系統 (例如 S3 分類) 必須將 Data 360 IP 列入允許清單。
• **合規對齊方式:**與客戶管理金鑰 (CMK) 配對時,支援企業資料保護架構,例如 GDPR、HIPAA 和 FFIEC 指導方針。
• **稽核性:**系統會針對可追溯性與合規性報告,記錄每個採取工作和認證存取權

側列

及時性

時間取決於取用排程和資料量。

• 理想步調取決於業務需求—每小時為近乎即時的行銷觸發,每晚為大型協調。
• Delta 模式會降低負載和成本;完整重新整理較為繁重,並用於初始載入或主要結構描述變更。

資料量

• CRM 連接器針對交易和中量資料集 (數百萬筆記錄) 進行最佳化。
• 針對極大的歷程記錄量,請考慮階段式 ETL 以分割和載入階段。

端點功能與標準支援

端點的功能與標準支援取決於您選擇的解決方案。

州/省管理

• 連接器狀態:「資料串流」會維護上次成功同步化的時間戳記和差異位移。
• **主要關鍵策略:**偏好一致的公司識別碼 (外部識別碼),以決定下游協調和更新插入。

複雜整合案例

在進階企業結構中,此模式可以與:

• **混合式拓型:**使用串流 (平台事件) 結合 CRM 快取以取得近乎即時的更新。
• **中介協調流程:**當需要複雜協調流程、增強或轉換預先取用時,請使用 MuleSoft 或 ETL 工具。
• **啟用回饋意見迴圈:**協調的 DMO 可以透過「資料動作」或平台 API 觸發來源系統的下游更新 (請謹慎使用 SoD 控制項)。

範例

多國零售商將「帳戶」、「連絡人」、「個案」、「機會」和 Marketing Cloud 參與度量合併至 Data 360,以建立統一的客戶檢視。「入門資料搭售方案」會初始化核心「銷售」與「服務」物件,而小組會使用自訂欄位 (例如 Loyalty_Membershipc 和 Customer_Tierc) 來擴充模型,以獲取忠誠度內容。「CRM 資料串流」會在 delta 模式下每小時執行一次,而 Marketing Cloud Engagement 會使用參與事件的 delta 解壓每天同步化。這些資料集透過 DLO 和身分解析進行處理,進而產生統一的客戶設定檔,該設定檔結合了 CRM 和參與訊號,以強化個人化和下游 AI 模型。

這些模式是針對毫秒十分重要的情況所建立—當客戶互動、交易或訊號必須觸發立即洞察或動作時。其可超越傳統排程的批次取用,以啟用以事件為導向的資料流程,其中會在產生資訊時處理資訊。 在 Salesforce Data 360 生態系統中,「即時」不是單一模式,而是延遲模型的連續。一端是近乎即時的同步化,其中記錄系統 (例如 CRM 或 ERP) 的更新會在秒或分鐘內反映在 Data 360 中。另一端是即時事件捕捉,其中用戶端行為訊號 (例如點擊、購買或行動互動) 會以毫秒為單位,以取用和啟用。 對於結構設計師,區別不僅僅是語意。其定義銷售管道的設計方式、API 的叫用方式,以及下游決策的方式。選取正確的模式,無論是近乎即時的同步化或事件串流取用,都可確保系統符合業務的營運延遲目標,同時維持資料完整性、可擴充性和管治。

Context

此模式可讓任何外部系統 (例如自訂應用程式、物聯網 (IoT) 平台、銷售點 (POS) 系統或第三方服務) 以程式設計的方式,在離散事件發生時,近乎即時地將事件資料推送至 Data 360。

問題

開發人員如何以低延遲的方式,從外部應用程式將單筆記錄或非同步小批次的事件可靠地傳送至 Data 360,讓資料可供快速處理、區隔和啟用?

力量

此模式提供較低的延遲和更好的開發人員控制,但導入了數個技術限制和作業相依性:

• **開發人員相依性:**需要開發人員努力來實作已驗證的 REST API 用戶端和錯誤/重試邏輯—這不是點選連結。
• 嚴格的撰寫結構描述:「取用 API」會強制執行結構描述撰寫。必須定義精確的結構描述並上載至連接器組態;所有裝載都必須完全符合或遭到拒絕。
• **雙互動模式:**相同的連接器支援串流 (JSON),以進行低延遲、逐筆記錄更新,以及大量 (CSV),以進行較大的定期同步化—結構設計師必須為每個使用個案選擇。
• **驗證與安全性:**通話必須使用 OAuth 2.0 透過 Salesforce 連線的應用程式進行驗證 (例如,伺服器對伺服器的 JWT 承載者流程)。權杖管理、輪替和最低權限範圍是必要的。
• **營運可視性:**開發人員和平台小組必須實作回應代碼、重試、無效字母及結構描述漂移警示的監視。
• **即時圖表需求:**針對即時啟用 (即時區隔、即時 DMO 對應),目標「資料模型物件」(DMO) 必須是即時資料圖形的一部分;否則事件會周遊略低延遲的銷售管道。

解決方案

此表格包含此整合問題的解決方案。

草稿

此圖說明如何將資料從「取用 API」匯入至 Data 360 的步驟順序

在此情況下:

• 外部系統從「驗證伺服器」要求透過 OAuth/JWT 進行驗證。
• Auth Server 會將存取權杖傳回至外部系統。
• 外部系統會透過授權與 JSON 裝載,將資料取用 POST 要求傳送至 Data 360 取用 API。
• 透過「暫存驗證」模組驗證要求結構描述和驗證。
• 結構描述/驗證失敗時:
• 傳回至外部系統的錯誤。
• 針對監視與警示記錄的拒絕。
• 成功驗證時:
• 暫存並認可至資料湖物件 (DLO) 的記錄。
• 已成功記錄進行監視。
• 若已啟用,則會將資料移入至觸發下游工作流程的即時資料圖表 (DMO)。
• 否則,會透過標準批次或較高延遲管道處理資料。
• 通訊 API 確認外部系統的成功。
• 監視元件會警示管理員無效字母、拒絕率或延遲問題。

結果

外部事件資料會以較低的延遲將其採取至 Data 360 DLO。當目標 DMO 是即時圖表的一部分時,資料可用於立即區隔、工作人員工作流程、AI 模型和作業啟用。這可讓業務快速回應來自任何已連線系統的事件。

吸收機制

取用機制取決於在 Data 360 中定義的連接器和排程策略。

錯誤處理與復原

• **立即 (同步) 錯誤:**結構描述/驗證錯誤的 4xx 回應 — 用戶端必須修正裝載或權杖並重試。
• **暫存 (非同步) 失敗:**5xx 回應 — 具有指數反轉與動靜的用戶端重試。
• **無效信函 (DLQ):**持續失敗會進入 DLQ 以手動檢查和重新執行。
• **監視:**追蹤結構描述拒絕率、驗證失敗、延遲百分位數和 DLQ 待處理。通話的警示。

潛在設計考量事項

• **Idempotency 索引鍵:**每個事件應包含唯一的識別碼金鑰/訊息識別碼。
• **更新插入策略:**使用業務金鑰 (ExternalId) 可避免重複回覆。
• **停用視窗:**結構設計師應定義用於識別效能追蹤的取消重複視窗和保留。

安全性考量事項

從驗證到加密和存取控制,安全性在整個採取管道中是整體的。

• **驗證:**建議用於伺服器對伺服器的 OAuth 2.0 (JWT 承載者)。將範圍限制為僅取用。
• **加密:**TLS 1.2+ 用於傳輸;Data 360 會在靜態中強制執行加密。
• **最低權限:**連線的應用程式認證擁有最少權限;輪替機密和儀器存取記錄。
• **薪水管理:**在事件中繼資料中包含同意/耗用標記;在取用後立即套用 ABAC/CEDAR 原則。
• **IP 控制項 / 私人連線:**如有需要,請透過允許清單限制存取,或將「私人連線」用於私人網路。

側列

及時性

時間取決於取用排程和資料量。串流 JSON 會根據處理和圖形組態產生子秒到第二個延遲。大量 CSV 為分鐘到小時。根據業務 SLA 選擇。

資料量

個別事件大小應小 (< 幾 KB)。針對高輸送量產生者,請考慮在呼叫 API 之前在產生者處批次或使用串流緩衝時間 (Kafka/Kinesis)。

州/省管理

• **結構描述版本化:**在事件中繼資料中維護結構描述版本,並在更新 OAS 契約時使用連接器版本化。
• **連接器位移:**Data 360 會處理認可語意;產生者應追蹤識別碼鍵和最後一個成功的序列,以確保安全的重新執行。

複雜整合案例

在進階企業結構中,此模式可以與:

• **邊緣驗證層:**使用中介軟體將異質的產生者格式翻譯為必要的 OAS 契約、執行比率限制和預先增強。
• **混合結構:**針對事件與「連接器」來進行大量協調,來結合取用 API。
• **工作人員啟用:**對應至即時 DMO 的事件可以觸發 Agentforce 工作流程和 Einstein 模型以進行自動化決策。

範例

零售鏈將銷售點 (POS) 購買事件串流至 Data 360 inReal-Time,以促進立即的客戶參與。每個商店都會執行輕量型伺服器元件,該元件會收集交易、以位置和裝置中繼資料增強交易,並使用 JWT Bearer OAuth 與 IDempotency 金鑰安全地張貼 JSON 事件,以避免重複。管理員透過上載適用於 銷售點的 OAS 結構描述,並設定「接收 API」連接器來定義事件結構。傳入的事件會在 pos_sale DLO 中採取、對應至 銷售 DMO,並新增至即時圖表。因此,系統會立即偵測高價值的購買,在 Agentforce 中觸發 VIP 工作流程並更新客戶區段以驅動即時個人化。

Context

此模式可讓您在 trueReal-Time 中從網站和行動應用程式,從大量細微的使用者互動資料 (例如頁面檢視、按鈕點擊次數、產品印象和影片播放) 來捕捉。這是提供即時個人化的基礎,其中每個數位互動都可以動態地影響使用者體驗並驅動參與。

問題

企業如何從數位內容 (每分鐘可跨越數百萬個使用者互動) 捕捉和處理行為事件的連續串流,並使資料立即可在 Data 360 中使用,以強化即時區隔、個人化和啟用?

力量

此使用個案會引入數個設計挑戰,這些挑戰需要針對目的所建置且低延遲的採取結構:

• **極端輸送量:**高流量網站或行動應用程式每分鐘會發出數百萬個事件。接收層必須水平調整,才能處理此量,而不會發生事件損失或反壓,以確保在高峰負載下保持一致的延遲。
• **用戶端儀器:**不同於伺服器驅動的整合,此模式取決於用戶端 SDK。必須在每個頁面中內嵌 JavaScript 指標 (Salesforce Interactions SDK),或整合至行動應用程式的原生 SDK。這需要強大的用戶端部署、版本化和事件結構描述管理。
• **低延遲事件處理:**使用者動作 (例如「加至手推車」或「影片播放」) 必須在秒內到達 Data 360,以啟用即時啟用和內容相關回應 (例如目標化優惠、個人化建議)。
• **資料調和與身分解析:**收到的事件通常包含匿名識別碼 (Cookie、裝置識別碼、工作階段權杖)。若要強化 Customer 360 使用個案,必須透過 Data 360 的身分解析將這些個案對應至已知設定檔,並與 Customer 360 資料模型協調。

解決方案

建議的方法是使用 Salesforce Marketing Cloud 個人化連接器—專為高輸送量行為摘要而設計的原生完整受管理串流管道。

草稿

此圖說明將資料從 Mobile 和 Web 管道的步驟順序至 Data 360

在此情況下:

• 在 Web 或行動管道中部署 SDK (使用者-互動捕捉)。
• 使用租戶識別碼、環境和同意控制來設定 SDK。
• 將捕取的 JSON 事件 (中繼資料 + 屬性) 串流至 Marketing Cloud 串流端點。
• 在「Data 360 設定」中,建立並設定租戶的「個人化連接器」。
• 在 Data 360 內將 DLO → DMO 對應至 DLO。
• 在即時圖表中啟用 DMO,以立即啟用。
• 監視延遲、結構描述合規性、同意標記、輸出、錯誤率。
• 部署至生產環境並持續監視。

結果

從數位管道流入 Data 360 的行為事件連續低延遲串流。在秒數內,每個使用者動作都可用於即時區隔、預測建模或觸發個人化,以實現真正適應的客戶體驗。

吸收機制

取用機制取決於在 Data 360 中定義的連接器和排程策略。

錯誤處理與復原

• **分層錯誤容忍:**實作多階驗證和重試機制 — 用戶端 SDK 會處理暫時失敗,並以指數反向方式處理,當然,取用層級會使用可持久持續排列和可重新執行的管道來防止資料遺失。
• **結構描述與資料管理:**持續執行事件的版本與驗證結構描述;無效或進化事件會路由至「結構描述拒絕」或「無效信頭」以安全地分級與重新執行。
• **Idempotency 與 deduplication:**使用穩定事件識別碼和更新插入語意,以保證即使在重試或重試期間,仍能完全處理一次。
• **監視與復原自動化:**持續監視輸送量、延遲和錯誤率會觸發自動復原工作流程,以確保低延遲、可靠的傳送,以及一致的即時個人化結果。

潛在設計考量事項

• 每個事件都必須帶有唯一的識別碼或訊息識別碼,以便在下游中刪除重複的提交。
• 在適當的情況下使用業務金鑰 (例如 sessionID + eventTimestamp + userID) 來識別重複項目。
• 定義忽略或篩選重複事件的復原期間 (例如 24 小時)。
• 在適當的情況下使用更新插入策略 (例如,更新計數器或標記,而非插入重複項目)。

安全性考量事項

從驗證到加密和存取控制,安全性在整個採取管道中是整體的。

• **傳輸加密:**所有 SDK → 串流服務連線的 TLS 1.2+。
• Data 360 和行銷串流中的靜態資料加密。
• SDK 遵循 使用者同意標記 (GDPR/CCPA),並在拒絕同意時抑制追蹤。
• SDK 流量驗證: 確保只有已批准的租戶/用戶端可以串流事件。
• **中繼資料:**每個事件都必須包含來源識別碼、時間戳記、結構描述版本、工作階段識別碼、無效金鑰。
• **最低權限存取權:**SDK 端點與連接器僅限於事件取用範圍;定期輪替認證。
• **資料分類:**在事件裝載中註解 PII,並在取用後立即強制執行原則

側列

及時性

• 時間取決於一般使用者活動和事件串流組態。
• 經由 Salesforce Interactions SDK 收取並透過 Marketing Cloud 個人化串流傳送的事件通常達到子秒到 ~2 秒的延遲,然後才可在 Data 360 即時圖表中使用。
• 這可在啟用中的使用者工作階段內啟用近乎立即的區隔、個人化和啟用。

資料量

個別行為事件 (例如按一下、檢視、新增至手推車) 為輕量型,通常為每個裝載 1–5 KB。 針對大規模數位內容,每分鐘預期會發生數千到數百萬個事件。 若要確保輸出量與彈性:

• 針對高流量頁面使用 SDK 的內建批次與重試機制。
• 將突發處理卸載至 Marketing Cloud 串流緩衝層。
• 使用連接器度量顯示面板監視採取輸出和錯誤比率。

州/省管理

每個事件都包含狀態和版本控制的中繼資料:

• **結構描述版本化:**在每個事件中內嵌結構描述版本;更新結構描述時版本化個人化連接器。
• **重複執行處理:**由於暫時網路問題而失敗的事件會由 SDK 以指數反向的方式自動重試。
• **Idempotency 金鑰:**唯一識別碼 (sessionId + eventType + 時間戳記) 可確保重新執行的事件不會在 Data 360 中建立重複項目。
• **位移管理:**Data 360 會追蹤成功的認可,任何未處理的事件都會由連接器重新計算,直到成功取用為止。

複雜整合案例

此模式可順暢整合至進階企業結構:

• **邊緣增強層:**在事件到達 Marketing Cloud 之前,新增中繼軟體 (例如反向 Proxy 或無伺服器函數) 以插入其他內容,例如地理位置、裝置類型或行銷活動中繼資料。
• **混合式 (串流 + 批次):**將 Marketing Cloud 連接器用於即時串流,並將其與批次 ETL 工作 (例如訂單資料) 結合,以進行下游協調。
• **工作人員啟用:**對應至即時 DMO 的事件可以觸發 Einstein 個人化、Agentforce 工作流程或 AI 驅動的決策,以適應目前的數位體驗。
• **多租戶管理:**使用同意標記和認知租戶的中繼資料,以在多品牌或多區域環境中強制執行隱私權與合規。

範例

全球電子商務公司在購物者主動瀏覽 React 型單一頁面應用程式 www.retailx.com 時,向購物者提供個人化的產品建議和動態內容。使用用戶端的 Salesforce Interactions SDK,網站會即時捕捉頁面檢視、產品點擊、手推車動作和視訊互動。這些事件會透過「Marketing Cloud 個人化」事件串流和「個人化」連接器流入 Data 360 DLO,並在其中模型化為 DMO 並納入即時圖表。此結構可讓行為訊號立即用於區隔、Einstein 驅動的個人化和 Agentforce 啟用,以啟用回應式的工作階段客戶體驗

Context

針對許多業務關鍵流程,保持 Data 360 與核心 CRM 系統中最新更新的完全一致是必要的。客戶服務、銷售和行銷小組依賴最新的資訊來驅動決策、觸發旅程和啟用自動化。此模式提供一個機制,可將對關鍵 Salesforce CRM 物件 (例如連絡人、帳戶和個案) 的變更同步至 Data 360 的最短延遲,而不會造成頻繁批次輪詢的效率低下或延遲。

問題

Data 360 如何與關鍵 Salesforce CRM 物件保持近乎完全同步的狀態,確保下游分析、區隔和 AI 驅動的啟用一律在最新的可用資料上作業?

力量

此模式介紹了數個技術限制與結構考量事項:

• **事件驅動的結構:**同步必須為反應性,其由 CRM 來源組織中的變更事件所驅動,而非定期批次工作。
• **選擇性物件支援:**並非所有 Salesforce 標準與自訂物件皆支援即時串流。結構設計師在設計期間必須參照支援的物件清單,以避免發生間隙。
• **存取權與權限:**啟用串流需要將「啟用 CRM 串流的權限」系統權限指派給來源組織中的整合使用者。
• **資料新鮮度與處理成本:**雖然近乎即時同步化可改善回應能力,但過多的事件輸送量可能需要水平調整規模和強大的錯誤復原機制。
• **安全性與 Trust 層整合:**所有事件資料都必須符合 Salesforce 的 Trust 和 Security 架構—傳輸中加密、針對結構描述合規性進行驗證,並在組織的 Trust 界限內處理。

解決方案

建議方法是使用已啟用串流的 Salesforce CRM 連接器 (變更 資料擷取。為支援的 CRM 物件 (例如,連絡人) 建立資料串流時,管理員可以切換「啟用串流」選項。Salesforce 的 Change 資料擷取 (CDC) 平台會在每次在來源 CRM 組織中建立、更新、刪除或取消刪除記錄時,立即發佈 ChangeEvent 訊息。 Data 360 CRM 連接器會訂閱這些 CDC 事件,並將對應的變更近乎即時地套用至 Data 360 內的對應資料湖物件 (DLO)。這可確保 CRM 和 Data 360 之間的連續同步化,但需要最少的手動介入。

草稿

此圖說明在近乎即時的情況下,將 CRM 中的資料從 CRM 移至 Data 360 的步驟順序

在此情況下:

• 變更會在 Salesforce CRM 中發生 (建立/更新/刪除/取消刪除)。
• CDC 會將 ChangeEvent 發佈至內部 Salesforce Event Bus。
• Data 360 CRM 連接器會使用永久的重新執行游標來訂閱 Event Bus。
• 系統會針對結構描述、權限和資料完整性驗證事件裝載。
• Data 360 會將驗證的事件寫入對應的 資料湖物件 (DLO)。
• 若已啟用,則對應的「資料模型物件」(DMO) 會以近乎即時的方式更新,進而加強區隔和啟用。

結果

Data 360 會維持關鍵 CRM 資料的連續同步化鏡像。 這可啟用:

• 即時觸發 (例如建立「個案」時啟動 Journey)。
• 最新的區段 (例如,在帳戶狀態變更時將客戶移至「金級」區段)。
• 根據即時 CRM 內容更精確的分析和個人化。

吸收機制

系統會原生透過已啟用「變更資料擷取」(CDC) 的 Salesforce CRM 連接器來管理此模式的採取機制。Data 360 會作為 CDC 事件串流的訂閱者,確保來源 CRM 組織與 Data 360 之間的可靠低延遲同步化。

錯誤處理與復原

• **自動錯誤復原:**CRM 連接器會使用指數反向來自動重試暫時網路或平台錯誤,並將持續失敗路由至「無效字元排隊」(DLQ) 以供重新執行。
• **結構描述與驗證彈性:**結構描述不相符的項目會在「結構描述拒絕排隊」中進行隔離以供管理員檢閱,而驗證或權限錯誤會透過 Data 360 Monitoring 觸發受控制的重試和警示。
• **保證事件持續性:**持久的 ReplayID 可確保連接器停機期間不會遺失事件;錯過的事件會透過重新執行視窗或批次重新同步工作重新水化。
• **資料完整性和訂單:**內建的 idempotency (RecordID + SequenceNumber) 可防止重複,而 ChangeEventHeader.sequenceNumber 可保留每個 CRM 記錄的正確事件順序。

潛在設計考量事項

• **事件唯一性:**每個 CDC 事件都帶有 ReplayID 和 ChangeEventHeader.entityName 以進行決定性重複。
• **更新插入策略:**根據記錄識別碼實作 UPSERT 邏輯,以確保重複的事件不會建立重複項目。
• **重複執行處理:**使用連接器的重新執行游標,以在暫時失敗時從上次認可的位移繼續。
• 結構描述演進 會在事件中繼資料中維護結構描述版本,並在 CRM 結構描述變更時更新 DLO 對應。

安全性考量事項

從驗證到加密和存取控制,安全性在整個採取管道中是整體的。

• **加密和 Trust :**所有事件都使用 TLS 1.2+ 傳輸,並在 Data 360 中靜態加密儲存。
• **存取控制:**只有具備適當整合權限的已驗證連接器可以訂閱 CDC 管道。
• **結構描述驗證:**每個事件裝載都會根據 DLO 結構描述進行驗證,然後才會接收。
• **同意傳播:**同意與資料分類中繼資料會在每個事件後續流動,以保留隱私權與合規性 (GDPR、CCPA)。
• **作業管理:**系統會透過 Data 360 Trust 圖層記錄、稽核事件,並監視重新執行、結構描述拒絕和輸出異常。

側列

及時性

• CDC 事件會以近乎即時的方式處理,通常是在 CRM 中變更的秒內處理。
• 延遲會根據事件量和連接器輸送量而有所不同,但 Data 360 保證支援物件的子分鐘可用性。

資料量

• 每個事件裝載均為輕量型 (~1–5 KB)。
• 針對如「個案」或「連絡人」等高變速物件,請確保輸出限制符合 Salesforce CDC 事件配置。

州/省管理

每個事件都包含狀態和版本控制的中繼資料:

• **重複執行識別碼:**用於序列事件復原。
• **結構描述版本化:**維護版本中繼資料以管理契約變更。
• **Idempotency 金鑰:**在重試之間取消重複的回覆。
• **位移認可:**Data 360 會在每個成功的事件批次之後保留認可狀態。

複雜整合案例

此模式可順暢整合至進階企業結構:

• **混合式 (串流 + 批次):**使用 CDC 進行 delta 更新,並大量工作進行完整重新整理。
• **跨組織串流:**多個來源組織可以透過 DMO 對應統一串流至相同的 Data 360 租戶。
• **工作人員啟用:**即時物件更新會觸發 Einstein 或 Agentforce 自動化。
• **事件路由:**中間軟體 (例如 MuleSoft 或事件轉送) 可以增強或路由 CDC 訊息,然後再進行取用。

範例

全球銀行想要確保 Salesforce Sales Cloud 中的客戶資料變更會立即反映在 Data 360 中。當在 Sales Cloud 中更新連絡人的地址時,「變更 資料擷取」機制會發佈 ContactChangeEvent。Data 360 CRM 連接器會取用此事件、將更新套用至 Customer DLO,並自動更新所有相關聯的 Customer 360 設定檔。這會觸發 Einstein Next Best Action 驗證新地址—在原始 CRM 變更後的秒內完成回饋意見迴圈。

Context

現代數位企業依賴如 Amazon Kinesis 資料串流和 Amazon MSK (適用於 Apache Kafka 的受管理串流) 等即時事件串流平台,以便從散佈式應用程式、IoT 裝置和交易系統中捕捉連續的資料流。Data 360 可透過原生第一方連接器從這些平台直接採取,因此不需要自訂 ETL 或以中介軟體為基礎的解決方案。此模式是針對高輸送量、低延遲資料取用、提供近乎即時洞察、個人化和 AI 驅動的啟用所設計。

問題

企業如何安全且高效地將 Data 360 連線至 AWS Kinesis 或 AWS MSK Kafka 主題,以持續提取結構化事件和設定檔資料,確保結構描述合規性、可擴展性和管治?

力量

此模式介紹多個結構與作業考量事項:

• **原生連接器可用性:**Salesforce 提供適用於 Amazon Kinesis 和 Amazon MSK 的廣泛可用原生連接器。這些連接器提供第一方支援,並消除自訂 API 型管道的需求。
• **驗證與安全性:**每個連接器都需要 AWS 層級驗證。
• 針對 Kinesis,這會使用 AWS 存取金鑰和密碼金鑰,由 IAM 原則管理。
• 針對 MSK,您可以透過存取金鑰/密碼或 OpenID Connect (OIDC) 來設定驗證。
• **結構描述定義:**Data 360 需要結構描述才能解譯串流裝載。 針對 Kinesis,會在連線設定期間上載結構描述檔案,以定義事件結構和欄位對應。
• 組態來源:
• Kinesis 連接器訂閱特定的「Kinesis 串流」名稱。
• MSK 連接器訂閱 MSK 叢集內的「Kafka 主題」。
• **網路存取權:**針對安全的環境,可使用 PrivateLink 或 VPC 路由來設定連接器,以確保沒有任何資料周遊公用網際網路。
• **作業管理:**在 Data 360 Trust 層內監視串流輸送量、結構描述驗證和驗證事件,以確保合規性和可追蹤性。

解決方案

解決方案利用 Data 360 內的 原生 Amazon Kinesis 或 Amazon MSK 連接器。

草稿

此圖說明在近乎即時的情況下,將「事件」平台 (例如 Kafka 和 Kinesis) 的資料從「資料 360」納入「資料 360」的步驟順序

在此情況下:

• 應用程式或裝置會將事件發佈至 Kinesis 串流或 MSK 主題。
• Data 360 連接器會使用 AWS 認證或 OIDC 權杖進行驗證。
• 連接器會持續輪詢或訂閱串流。
• 事件會暫存、驗證結構描述與原則,然後認可至「資料湖物件」(DLO)。
• 若已對應,「資料模型物件」(DMO) 會近乎即時更新以供啟用。
• 「監視層」會追蹤度量、結構描述拒絕和延遲。

結果

將結構化資料直接從 AWS Kinesis 或 MSK 連續、低延遲地提取至 Data 360。資料可立即用於:

• 身分解析
• 即時區段
• Einstein AI 啟用
• Agentforce 驅動的觸發 去除批次 ETL 的相依性,啟用與企業事件驅動設計一致的串流型結構。

吸收機制

錯誤處理與復原

• **自動重試:**連接器會以指數反向的方式重試暫時網路或平台錯誤。
• **結構描述拒絕:**無效的裝載會路由至結構描述拒絕排列,以供管理員檢閱。
• **DLQ 重新執行:**持續失敗會在無效文字信號中來進行重新處理。
• **Idempotency Control:**事件索引鍵或序號可確保還原重複項目並順序地取用。
• **監視整合:**所有失敗、重試和輸送量度量都會顯示在 Data 360 Monitoring 顯示面板中。

潛在設計考量事項

• **事件唯一性和追蹤:**系統會將決定性唯一索引鍵指派給每個事件 (例如,PartitionKey + SequenceNumber for Kinesis,或 Topic + Partition + Offset for MSK),以確保精確取用一次性。
• **連接器檢查點數:**Data 360 連接器會保留最後處理的偏移或序號,以在失敗或重新啟動後安全恢復。
• **復原與 UPSERT 邏輯:**在 DLO 認可期間,系統會偵測及略過重複事件;有效記錄會使用唯一索引鍵來更新插入以維護一致性。
• **重複執行與復原控制:**失敗或延遲的事件會透過「無效字母」與「重新執行排列」從儲存的偏移重新執行,以確保可靠的復原而不會重複。

安全性考量事項

從驗證到加密和存取控制,安全性在整個採取管道中是整體的。

• **驗證:**使用 AWS IAM 原則或 OIDC 保護認證交換。
• 加密:Data 360 內傳輸中 (TLS 1.2+) 和 靜態 (AES-256) 加密的資料。
• **存取控制:**強制執行最低權限角色;範圍為特定串流/主題的連結。
• **管治:**套用至每個記錄的歷程和分類中繼資料,以確保完整的可追溯性。
• **網路安全性:**或者,使用 AWS PrivateLink 在 私人子網路中部署。

側列

及時性

• **近乎即時處理:**CDC 和串流連接器會在來源變更的秒內處理事件,通常可確保子分鐘資料是最新的。
• **決定性延遲:**端對端延遲取決於來源輸送量、事件批次和網路條件,但 Data 360 保證支援物件的可預測 SLA 驅動延遲。
• **彈性調整:**其會在高事件量下自動調整其規模,即使在資料高峰期間仍可保持準時性。
• **營運可視性:**監視顯示面板會顯示事件延遲、認可時間戳記和重新執行狀態,以確保延遲和疑難排解。

資料量

• **輕量型裝載:**個別 CDC 或串流事件精簡 (1–5 KB 標準大小),針對高頻率更新最佳化。
• **高變化物件:**針對波動式實體 (例如「個案」、「連絡人」、「訂單」),結構設計師必須確保 CDC 配置和事件輸送量符合預期的更新率。
• **平行串流:**Data 360 支援跨大型物件量或跨多個來源組織的水平調整多串流。
• **反壓處理:**內建的節流機制可在負載下維持吸收穩定性,而不會捨棄事件。

州/省管理

每個事件都包含狀態和版本控制的中繼資料:

• **重新執行與位移追蹤:**每個事件都帶有「重新執行識別碼」和序列中繼資料,可啟用排序遞送和檢查點式復原。
• **結構描述版本化:**事件標題內的版本標記可確保在來源結構描述演進時與舊版相容的處理。
• **Idempotency 金鑰:**每個事件都包含唯一的交易或認可金鑰,可讓 Data 360 安全地去除重複重複和重試。
• **Atomic Commit:**只有在下游認可 DLO 成功時,便會將偏移標記為完成,以確保一致性。

複雜整合案例

此模式可順暢整合至進階企業結構:

• **混合吸收:**將增量差異的 CDC 與大量資料串流結合在一起,以進行完整的重新整理,同時維持新鮮性和完整性。
• **跨組織串流:**多個 CRM 或 ERP 組織可以發佈至相同的 Data 360 租戶,並透過 DMO 對應和本文對齊方式統一。
• **事件增強:**中間軟體 (例如 MuleSoft、Event Relay) 可以在串流資料到達 Data 360 之前增強、篩選或路由串流資料。
• **AI 與工作人員啟用:**即時更新會在發起事件的秒數內觸發下游自動化,例如 Einstein 預估或 Agentforce 回應。

範例

一家全球零售企業使用 AWS Kinesis 來串流銷售點和 Web 互動資料。Data 360 的 Kinesis 連接器會透過 IAM 認證進行驗證,並持續將事件提取到「交易 DLO」中。每個記錄都會經過結構描述驗證、以中繼資料豐富,並立即傳播至「客戶 DMO」。在幾秒內,Einstein AI 模型會更新客戶區段,而 Agentforce 會觸發即時 Next-Best-Offers 建議,以達成完全以事件為導向的個人化迴圈。

「零複製」不只是整合方法,而是企業資料移動方式 (亦即不移動) 的基礎變更。傳統上,資料整合需要透過 ETL 管道複製大量記錄、建立冗餘的資料存放區、同步延遲和管治挑戰。零複製會消除所有項目。 在此模型中,Data 360 會直接連線至外部資料平台,例如 Snowflake 和 Databricks,安全地讀取並啟用資料,而無須移動或複製資料。結果是企業資料湖庫與 Salesforce 生態系統之間的流暢橋接,提供即時存取、降低營運負擔,並強化資料管理。

輸入零複製功能可讓 Data 360 查詢和協調儲存在 Snowflake 或 Databricks 中的來源外部資料,例如客戶設定檔、交易或產品資料。Data 360 會建立安全且具有中繼資料認知的連線,以利用外部倉庫中現有的結構描述定義和安全性原則,而不必取用檔案。

• **直接聯邦:**Data 360 會透過安全且最佳化的查詢讀取資料,而無須複製。
• **統一管理:**資料會保留在來源系統的安全性、存取控制及合規性架構之下。
• **營運效率:**消除 ETL 額外負擔和儲存重複,減少成本和複雜性。
• **即時整備:**啟用隨選調和—當 Snowflake 中的資料更新時,即可立即在 Data 360 中啟用。

Context

現代資料驅動的企業在雲端規模資料湖目錄平台 (例如 Snowflake 和 Databricks) 內管理客戶、交易和遠端測試資料的 petabyte。這些環境可作為分析、AI 和合規性的單一事實來源。 Data 360 導入 Zero CopyData Federation,允許 Data 360 直接查詢和使用外部資料集,而無須複製、轉換或儲存冗餘資料。__ 此模式可讓組織將 Customer 360 架構擴充至現有的資料倉庫或湖家基礎結構,以實現即時統一和啟用,並透過零重複、零延遲和零對管治進行妥協。

問題

企業如何利用已在 Snowflake、Databricks 或如 Apache Iceberg 等開放湖格式中精密設計的豐富資料集,以進行區隔、身分解析和在 Data 360 中啟用,而不需要 ETL 銷售管道或實體資料移動的成本、延遲和管治負擔?

力量

此模式導入多個結構、安全性和效能考量事項:

網路與安全性

• Data 360 必須建立與外部倉庫或湖舍的安全私人連線。
• 通常使用 Salesforce Private Connect 或 PrivateLink/VPC 對等設定,以確保流量永不離開客戶控制的網路。
• 外部系統必須將 Data 360 IP 列入允許清單,並強制執行 TLS 1.2+ 加密。

驗證與存取控制

• 支援金鑰組驗證、OAuth 2.0 或以身分提供者 (IdP) 為基礎的 Trust 委派 (Data 360 作為信任用戶端)
• 外部系統中以角色為基礎的存取控制 (RBAC) 會強制執行查詢的最低權限存取權。

效能與計算相依性

• 查詢聯合會將 SQL 執行推送至 Snowflake 或 Databricks,利用其運算叢集。
• 具有外部查詢負載的效能與成本級數—區隔延遲與成本與外部運算組態相關聯。

不斷發展的標準:檔案聯合

• 新一代模型檔案聯合利用如 Apache Iceberg 或 Delta Lake 等開放式表格格式,讓 Data 360 能夠直接從物件儲存空間 (例如 Amazon S3、Azure ADLS、Google Cloud Storage) 讀取資料。
• 透過略過來源計算層,檔案聯合可大幅減少易讀的分析工作負載延遲和成本,同時維持結構描述完整性。

管治與合規

• 資料永遠不會離開來源平台—規範、加密和保留原則仍會在原始位置強制執行。
• 所有中繼資料、歷程和同意屬性均會移入 Data 360 的 Trust 圖層,以確保端對端可追蹤性。

解決方案

建議方法是在 Data 360 內針對 Snowflake、Databricks 或檔案聯合使用原生 Zero Copy 連接器。

草稿

下圖說明如何在 Data 360 中設定零複製連線並建立外部 DLO。

在此情況下:

• 管理員會在 Data 360 設定 (Snowflake、Databricks 或檔案聯合) 中設定「零複製」連線。
• 已建立安全驗證和網路路由 (私人連線/OAuth/金鑰配對)。
• 管理員建立「資料串流」,選取外部來源—瀏覽即時資料庫、結構描述和表格。
• Data 360 會建立外部 DLO (資料湖物件),即參照即時表或 Iceberg 檔案的中繼資料指標,而不是複製資料。
• 外部 DLO 會對應至 Customer 360 實體 (例如客戶、交易、產品)。
• Data 360 會在區隔、啟用或洞察計算期間查詢來源。
• 所有存取、查詢歷程和中繼資料都會在 Data 360 Trust 層內進行稽核。

結果

• 外部資料會保留在 Snowflake、Databricks 或 S3 中—無 ETL、無重複,無額外儲存空間。
• Data 360 可取得企業規模資料的即時讀取存取權,以用於身分解析、已計算洞察和啟用。
• 組織可在其現有的管治、加密與合規架構下維持完整控制權。
• 此模式會啟用真正的「零複製」結構,結合本機存取的效能與聯合儲存空間的管理。

通話機制

呼叫機制取決於用來實作此模式的解決方案。

錯誤處理與復原

• **自動重試與查詢待處理項目:**暫時連線或查詢逾時會使用指數反斜方式自動重試。
• **結構描述不相符的隔離:**來源結構描述中的變更 (例如,新資料欄) 會記錄到「結構描述拒絕排隊」中;管理員可以重新對應或重新整理結構描述中繼資料。
• **驗證失敗:**如果認證到期,Data 360 會使用儲存的重新整理權杖或金鑰輪換原則重試連線。
• **計算可用性偵測:**如果 Snowflake 或 Databricks 叢集已暫停,則 Data 360 會在計算恢復時暫停聯合工作和重試。
• **監視整合:**Data 360 Monitoring 顯示面板中顯示的所有連線健康、查詢延遲和歷程中繼資料。

潛在設計考量事項

• **查詢決定性:**聯合查詢會使用一致的快照語意,以確保區隔或啟用期間可穩定且可重複的讀數。
• **外部 DLO 版本化:**每個聯合查詢都包含用於歷程追蹤的結構描述和時間戳記中繼資料。
• **無位移存取權:**由於「零複本」為唯讀,因此不依賴事件位移—透過外部系統的 ACID 保固 (Snowflake/Delta Lake) 強制執行一致性。
• **結構描述漂移管理:**在 Data 360 中維護版本化結構描述對應;重新整理來源進化上的外部 DLO 中繼資料。

安全性考量事項

安全性在整個聯合模型中是不可或缺的,因此可確保不會影響 Trust 或合規性。

• **加密:**所有資料交換都使用 TLS 1.2+;外部倉庫使用 AES-256 靜態加密。
• **存取控制:**透過具有唯讀權限的最低權限角色存取外部表格。
• **網路隔離:**私人 Connect 或 VPC 路線可防止任何公用端點的曝光。
• **受管理資料流程:**屬性、同意和分類中繼資料會流入 Data 360 Trust 圖層以強制執行原則。
• **稽核性:**系統會記錄每個聯合查詢和結構描述存取事件,以便追蹤合規性 (GDPR、CCPA、HIPAA)。

側列

及時性

• 查詢會針對外部倉庫或儲存空間即時執行,以確保即時可看見最新的資料狀態。
• 區隔或啟用執行會反映 Snowflake、Databricks 或 S3 支援的 Iceberg 表格中最新的變更。
• 查詢延遲取決於來源系統的效能層級,通常為每個查詢的秒數到秒數。
• 適用於需要「最新且未複製」資料存取權的分析和 AI 工作量。

資料量

• 支援原生儲存在 Snowflake 或 Databricks 中的 petabyte 級資料集,而無須複製。
• Data 360 只會提取結果,而非原始資料集,以將網路和運算成本降到最低。
• 檔案聯合透過分割與資料欄推送功能表來最佳化大型分析掃描。
• 透過倉庫計算容量和 Data 360 的聯合查詢協調流程層,以線性方式調整規模。

州/省管理

• 外部 DLO 會保留在 Data 360 中的連線、結構描述和版本中繼資料。
• 系統會透過中繼資料重新整理週期自動管理結構描述進化。
• 查詢歷程包含時間戳記、使用者身分和執行度量以確保可追溯性。
• 系統不會維護任何狀態取用或位移—一致性繼承自外部來源的 ACID 保固。

複雜整合案例

• **混合模式:**將「零複製」(適用於即時聯邦) 與取用 (適用於歷程記錄資料集) 結合。
• **跨倉庫存取權:**Data 360 可從一個組織內的多個 Snowflake 或 Databricks 租戶聯合。
• **AI/BI 互通性:**外部系統 (例如 SageMaker、Tableau、Power BI) 可以透過反向零複製來查詢 Data 360 的增強型設定檔。
• **檔案聯合副檔名:**採用開放湖格式 (Iceberg/Delta) 的企業可以在一個聯合模型下統一結構化與非結構化資料。

範例

全球金融企業將所有交易和互動資料儲存在 Snowflake 中,同時在 Data 360 中維護客戶屬性和行銷事件。使用「零複製資料聯合」,Data 360 會透過私人連線安全地與 Snowflake 連線。當區隔工作執行時,例如「過去 30 天內支出 $10,000 的客戶,Data 360 會將查詢向下推送至 Snowflake,並且在 Journey Builder 中即時啟用這些設定檔。不需要複製或 ETL。此範例使用整個企業資料生態系統統一的即時聯合情報。

輸出零複本會反向地延伸相同的原則。如 Snowflake 等外部系統無法從 Data 360 匯出或複製資料集,而是可以直接查詢 Data 360,將其視為豐富客戶智慧的聯合來源。

• **反向聯邦:**外部分析或 AI 平台可以存取 Data 360 的統一設定檔資料,而無須將其解壓縮。
• **來源的資料啟用:**無論是 AI 建模、報告或客戶個人化,業務小組都可以利用已存在資料所在位置的洞察。
• **免延遲的互通性:**沒有批次匯出或同步化工作;洞察會在平台之間立即流動。
• **一致的語意:**由於兩個系統皆共用相同的本體與結構描述對應,因此會在整個生態系統中保留內容與意義。 Zero copy 會將 Data 360 的角色從 資料存放庫重新定義為語意啟用層級。它可讓組織在受管理且高效能的倉庫中確實保留資料,同時在 Salesforce Trust 界限內釋放其完整價值。 此模式與現代資料網格和 AI 原生結構保持一致:資料會保持去中心化,但智慧會統一。結構設計師現在可以建立更快速、更精簡且更符合的啟用管道,無須複製。

Context

現代企業日益在多平台資料生態系統中運作,其中 Salesforce Data 360 可支援統一的客戶設定檔和啟用,而如 Snowflake 或 Databricks 等企業資料倉庫可作為資料科學、機器學習和 BI 工作負載的分析支柱。 Salesforce Data 360 的「零複製輸出共用」功能可順暢地橋接這些環境,允許直接在 Snowflake 或 Databricks 中管理、安全且即時地存取協調的 Data 360 資料,無須複製或 ETL。 這可讓分析師和資料科學家在支援行銷、銷售和服務啟用的相同即時、信任資料上進行查詢、視覺化和建模。

問題

企業如何安全且有效地將 Data 360 的統一客戶設定檔和計算度量 (例如「終身價值」、「流失風險」) 公開給外部分析系統,而無須複製資料、破壞管治或透過傳統反向 ETL 管道導入延遲?

力量

此模式介紹多個結構、管治和營運考量事項:

• **管理安全性:**Data 360 資料的存取權必須受控制、精確且可稽核。「零複製」共用使用明確的物件級存取權,確保僅已批准的「資料模型物件」(DMO) 和「已計算洞察物件」(CIO) 可供指定消費者使用。
• **明確物件選取:**管理員透過「資料共用」精密設計可共用資料,明確選取要公開的物件。這可維持監管並將風險曝光降到最低。
• **雙邊組態:**Data 360 與外部倉庫都需要設定。Data 360 定義「資料共用目標」(Snowflake/Databricks),而接收系統必須接受並例項化共用。
• **查詢聯合模型:**一旦接受後,外部平台便會透過聯合檢視即時查詢、管理 Data 360 資料,進而去除解壓縮工作或手動重新整理週期。
• **開放標準演進:**如檔案聯合等新增方法利用開放式表格格式 (例如 Apache Iceberg) 來在儲存層啟用唯讀存取權,進而改善跨多雲端結構的擴充性、效能和互通性。

解決方案

此解決方案利用 Salesforce Data 360 的原生「零複製共用」搭配如 Snowflake 或 Databricks 等資料平台。

草稿

下圖說明從 Salesforce Data 360 至外部 Data Platform 的呼叫。

在此情況下:

• Data 360 管理員定義「資料共用」,包括「統一客戶」和「已計算洞察」物件。
• 使用安全認證和管治原則註冊「資料共用目標」(Snowflake 或 Databricks 帳戶)。
• Data 360 會發佈共用;Snowflake/Databricks 管理員會接受該共用。
• 共用的資料會在倉庫內顯示為安全且唯讀的表格。
• 分析師、BI 工具或 ML 管道會查詢即時且統一的客戶資料,而無須複製或同步化。
• 所有存取權都會在 Data 360 Trust 層與倉庫管理記錄中進行稽核。

結果

• 外部倉庫可取得已協調 Data 360 資料的即時可查詢存取權。
• 去除反向 ETL 銷售管道,減少營運負擔和延遲。
• 直接在統一資料上啟用 AI/ML 訓練、預測建模和進階 BI。
• 維持零重複、強大的管治,以及安全的依設計存取控制。
• 完成雙向「零複製」迴圈,其中輸入聯合與輸出共用在單一管治模式下同時存在。

通話機制

呼叫機制取決於用來實作此模式的解決方案。

錯誤處理與復原

• **連線重試:**Data 360 與倉庫之間暫時連線或驗證失敗的自動重試。
• **共用驗證:**無效或未經授權的共用組態會在「管理員檢閱排隊」中進行隔離。
• **同步化健康狀態監視:**Data 360 會透過「監視」顯示面板呈現即時共用狀態、查詢延遲和存取記錄。
• **存取撤銷:**管理員可以立即撤銷共用,並停用兩端的存取權,而不需要殘差資料複本。
• **受管理稽核追蹤:**系統會記錄所有組態和存取權變更以進行合規性驗證。

潛在設計考量事項

• **一致共用識別:**每個「資料共用」與「資料共用目標」配對都有唯一識別碼,可確保精確的監管與存取追溯性。
• **固定的檢視:**共用資料物件為唯讀;消費者無法變更狀態,以確保決定性結果與合規性。
• **原子共用生命週期:**共用發佈、撤銷和更新是原子作業,完全完成或回復。
• **重複執行一致性:**Data 360 資料重新整理時,倉庫端查詢一律傳回最新的一致快照,以免過時讀取。

安全性考量事項

安全性可固定零複製共用的每個層面:

• 驗證:使用 OAuth 2.0、私人金鑰交換或身分聯合 (OIDC) 建立的共同 Trust。
• 加密:在傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密的資料。
• 存取控制:物件級權限會強制執行最低權限存取權;由 Data 360 Trust 層管理。
• 網路安全性:資料交換會透過私人網路連結 (例如 Salesforce Private Connect 或 Secure Data Exchange API) 進行。
• 管治中繼資料:每個共用的物件都帶有歷程、分類和同意屬性,以確保完整的可追溯性與法規合規性。

側列

及時性

• **即時可用性:**共用的資料會反映 Data 360 的最新狀態,而不會發生複製延遲。
• **查詢重新整理:**DMO 或 CIO 中的變更會立即移入共用的倉庫檢視。
• **效能彈性:**查詢推送功能表會動態調整至倉庫計算資源。
• **監視:**即時顯示面板會顯示共用延遲和查詢效能度量,以確保作業。

資料量

• **可調整共用:**根據分析需求,支援細微物件層級或完整網域資料共用。
• **最佳化查詢效能:**Snowflake/Databricks 會智慧地快取共用資料,以將延遲降到最低。
• **儲存效率:**零重複會減少冗餘的儲存成本。
• **檔案聯合選項:**針對 petabyte 級資料集,直接 Iceberg 式共用會略過計算並加速存取。

州/省管理

• **結構描述演進:**版本控制的結構描述會在 Data 360 模型演進時確保相容性。
• **存取狀態追蹤:**針對生命週期管理,在 Data 360 中維護的啟用/停用共用狀態。
• **中繼資料同步化:**共用物件定義的更新會自動反映在下游倉庫目錄中。
• **不變狀態保固:**倉庫檢視一律代表 Data 360 資料的一致時間點狀態。

複雜整合案例

• **混合模式:**將「零複製」(適用於即時聯邦) 與取用 (適用於歷程記錄資料集) 結合。
• **跨倉庫存取權:**Data 360 可從一個組織內的多個 Snowflake 或 Databricks 租戶聯合。
• **AI/BI 互通性:**外部系統 (例如 SageMaker、Tableau、Power BI) 可以透過反向零複製來查詢 Data 360 的增強型設定檔。
• **檔案聯合副檔名:**採用開放湖格式 (Iceberg/Delta) 的企業可以在一個聯合模型下統一結構化與非結構化資料。

範例

跨雲端分析可讓組織將受管理的 Salesforce Data 360 資料與如 Snowflake 和 Databricks 等平台中的原生資料集結合在一起,以提供完整的全方位分析檢視。透過多租戶存取權,不同的業務單位可以透過個別共用安全地取用精密設計和保單控制的資料配量,而無須重複資料。然後,資料科學家可以透過直接在 Snowflake ML 或 Databricks MLflow 環境中的統一客戶設定檔上訓練模型,來執行聯合 AI 和機器學習。在整個流程中,內建的歷程、管治和稽核功能可確保所有資料存取和使用都保持符合企業原則和法規需求,例如 GDPR 和 HIPAA。

Data Cloud One 可讓具有多個 Salesforce 組織的組織 (例如因為業務單位、區域、產品線或收購) 共用單一的集中 Data 360 例項。此組織會作為「首頁組織」,而其他組織 (稱為「同伴組織」) 可以存取統一資料並對其採取行動,只需花費最少的精力、無須自訂程式碼及完整的管治控制。

Context

企業經常執行多個 Salesforce 組織 (例如,一個用於銷售、一個用於服務、一個用於行銷或不同的區域)。每個組織都可以擁有自己的資料、組態和流程。在 Data Cloud One 之前,每個組織都需要自己的 Data 360 設定或複雜的自訂程式碼,才能跨組織共用資料。Data Cloud One 允許使用 Data 360 和多個透過低程式碼組態和中繼資料共用連線的「同伴」組織來簡化此操作。

問題

企業如何在所有 Salesforce 組織之間 (以便銷售、行銷、服務等皆使用相同的基本資料) 啟用一致使用統一 Customer 360 資料 (由主要組織的 Data 360 採取、協調和管理),同時避免工作重複、自訂編碼、每個組織的個別 Data 360 例項以及管治缺口?

力量

此模式導入多個結構、安全性和效能考量事項:

• 多組織複雜性:每個業務單位的組織可能有不同的資料、自訂物件、安全性與流程,因此不易維持一致的統一檢視。
• 重複與成本:每個組織執行個別的 Data 360 例項表示額外的設定、額外的監管、額外的授權,以及資料孤立的風險。
• 管治與資料共用控制:您需要決定每個伴隨組織可以看見並採取行動的資料—您無法簡單地共用「所有內容」,而不需要管理風險。
• 設定速度:行銷、銷售或服務小組無法等待數週的自訂程式碼,讓跨組織資料可供使用—他們需要點按組態解決方案。
• 資料落地、區域考量事項:如果首頁與伴隨組織位於不同的區域,則可能會有關資料儲存位置或資料共用方式的法律或法規限制。

解決方案

下表包含此整合問題的各種解決方案。

草稿

下圖說明此模式中的事件順序,其中 Salesforce 是資料主要資料。

在此情況下:

• 首頁管理員:建立「資料空間」並定義「資料共用」(選取 DMO/CIO、區段)。
• 首頁管理員:為伴侶組織建立「資料共用目標」,並設定 Trust (OAuth 用戶端、允許的組織識別碼)。
• 首頁管理員:將「資料共用」發佈至目標;附加 ABAC 原則 (CEDAR) 和加密/金鑰控制項 (如有需要,CMK)。
• 伴侶組織管理員:接收邀請、驗證身分對應,並接受共用。
• 伴侶組織 Cloud One Bridge 會佈建 Data Cloud One 使用者,並套用「權限集與資料空間」可視性。
• 伴隨組織應用程式 (流程 / Einstein / Apex):查詢資料圖表或呼叫 Data Cloud One API 以讀取共用的 DMO 或區段。
• 啟用:伴侶組織會觸發啟用,或透過資料動作寫回 (若允許)。

結果

• 所有已連線組織中客戶資料 (Customer 360) 的 單一事實來源—沒有冗餘的 Data 360 例項。
• 更快的評估時間,伴隨組織只需要幾分鐘,才能存取統一資料和 Data 360 技術的功能,而不需要數週的自訂編碼。
• **受控制的資料共用。**只會共用授權的資料空間,以保留安全性和管治,同時啟用業務靈活性。
• 業務功能 (銷售、服務、行銷) 會在相同的統一資料基礎上運作,在整個企業中啟用一致的度量、啟用和洞察。

通話機制

呼叫機制取決於用來實作此模式的解決方案。

錯誤處理與復原

• **跨組織同步彈性:**Data Cloud One 會使用暫時網路或平台錯誤的指數反向回應,在「首頁」與「伴隨組織」之間自動重試失敗的同步化工作。
• **部分批次隔離:**失敗的記錄批次會在「首頁組織」內的「重試到來」中進行隔離,直到協調成功為止,以避免資料分歧。
• **結構描述拒絕管理:**結構描述或對應不相符的項目會路由至「結構描述拒絕排隊」以供管理員檢閱和更正。
• **重複執行與恢復持續性:**每個同步化工作都會維護偏移檢查點,因此複製可以從上次成功認可繼續,而不會重複。
• **整合監視:**所有失敗、重試和復原度量都會在 Trust 圖層監視顯示面板中進行儲存,以取得可視性和 SLA 保證。

潛在設計考量事項

• **決定性識別碼能力索引鍵:**每個同步化事件都會帶有唯一的金鑰 (組織識別碼 + 記錄識別碼 + 版本號碼),以保證完全可處理一次。
• **重複執行安全性:**重複或重新執行的事件會在認可時間篩選,以確保一致的下游 DMO 和 CIO 更新。
• 原子認可語意:「伴侶組織」只會在成功下游撰寫後將資料標記為已認可,以保留跨組織交易完整性。
• **衝突解決:**多來源更新會遵循上次寫成交或原則驅動的合併邏輯,維持歷程和一致性。
• **檢查點持續性:**同步化工作會保留在「Trust 層」內的上次處理偏移和狀態,以安全地復原和重新執行。

安全性考量事項

• 強式驗證:「首頁」與「伴隨組織」之間的連線會使用共同 OAuth 2.0 與透過「連線的應用程式」管理的自動旋轉權杖。
• 細微授權:「伴侶組織」只能存取透過受管理的「資料共用原則」明確共用的特定「資料空間」、「DMO」或 CIO。
• **隨處加密:**資料會在「首頁」與「伴侶組織」之間傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密。
• **最低權限原則:**整合使用者的範圍僅限於必要物件;不會移入管理或系統層級權限。
• **稽核與合規性可視性:**所有同步化事件、結構描述變更、認證更新和存取授與都會記錄在 Data 360 Trust 層中,以確保完整的可追蹤性。
• **私人網路隔離:**選擇性 Salesforce 私人連線或私人連結可確保資料複寫僅透過安全內部管道進行。

側列

及時性

• 「首頁」與「伴侶組織」之間的同步化會近乎即時進行,通常是在來源組織中資料變更的秒數內。
• 「零複製」結構可確保所有參與組織都能立即查詢共用資料,而不會發生複製或批次延遲。
• 啟用和區隔工作會自動反映來自任何已連線組織的最新更新,維持營運最新狀態。
• 端對端延遲是決定性的,並由 Data Cloud One 的協調流程管道管理,以確保即使在載入的情況下仍可保持一致的跨組織時間。

資料量

• 針對跨區域和業務單位的多租戶超規模資料同步化所設計,可在每個組織中管理數十億筆記錄。
• 資料會參照,而非重複,進而減少儲存空間足跡,同時維持全域可查詢性。
• 串流差異與中繼資料壓縮可最佳化頻寬,並為高變速物件 (例如「連絡人」、「訂單」) 認可負擔。
• 透過透過 Trust 層級的自適應負載平衡和協調流程,水平調整多個「伴隨組織」。

州/省管理

• 每個同步化的資料集都會維護中繼資料歷程、版本和組織擁有權內容,以確保端對端可追蹤性。
• 檢查點持續性會針對組織之間的上次同步偏移,允許復原而不會重複。
• 結構描述版本化和跨組織的語意對齊方式由 Trust 圖層自動管理。
• 不需要手動狀態重設,系統會透過 Data Cloud One 協調流程服務來維護同步化狀態。

複雜整合案例

• **跨組織聯合:**在統一管理模型下,在多個 Data 360 租戶或區域之間啟用流暢的查詢和啟用。
• **混合同步化:**將近乎即時的交易更新複寫與大量或歸檔資料的已排程同步化結合。
• **多區域管理:**支援地理散佈的資料共用,同時遵守落地、同意和合規性邊界。
• **AI 與自動化啟用:**同步化資料可立即為組織之間的 Einstein AI、Agentforce 或自訂 ML 模型提供動力,以啟用即時的跨組織情報。

範例

一個全球零售組織有三個 Salesforce 組織:一個用於消費者零售、一個用於高級品牌,另一個用於國際市場。他們在 Consumer Retail 組織中佈建 Data 360 (使其成為主要組織)。透過 Data Cloud One,他們可以設定與 Premium Brands 和 International Markets 組織的伴侶連線。他們只會與每個伴侶組織共用適當的資料空間 (例如「Customer 360 – Retail Profiles」和「Customer 360 – Premium Profiles」)。在 Premium Brands 組織中,行銷小組可以檢視統一的客戶設定檔、根據已計算的洞察 (例如,頂級客戶終身價值) 建立區段,並觸發行銷自動化—所有這些都由主組織的 Data 360 例項提供技術支援,無須自訂編碼或資料重複。

資料啟用是 Salesforce Data 360 的真正價值開始生效的地方。這是取得平台內統一、豐富和受管理資料的流程,並使其在整個業務中運作。在實際上,這意味著安全地將 Data 360 的精密設計區段、已計算洞察和內容屬性傳遞至與客戶互動的系統,無論是行銷自動化、服務主控台、銷售啟用、分析或 AI 模型。 從技術角度來看,啟用模式會定義此資料的移動方式:觸發哪些管道、發生哪些轉換或對應,以及如何在過程中強制執行原則。這些模式並非僅用於匯出資料,而是用於協調即時的原則認知資料流程,以推動可測量的業務成果。每個啟用路線都會將 Customer 360 轉為即時的作業資產,為每個接觸點提供個人化、預測決策和持續學習。

批次啟用仍是從 Data 360 匯出資料的最常用且經營證明方法。其會以排程的步調運作—定期將預先定義的受眾區段或屬性集發佈至下游平台。此模式非常適用於依賴一致且大量受眾傳送而非立即更新的行銷和參與工作流程。 一般使用個案包括增強電子郵件旅程、直接郵件行銷活動,或受眾上載至數位廣告網路。每個啟用執行都會從 Data 360 的統一設定檔圖表中提取合格區段、套用監管與同意原則,並安全地將輸出傳輸至目標系統。 在結構上,批次啟用為資料散佈提供可預測、可稽核且具成本效益的方法,以平衡營運簡易度與企業級可靠性。這是大規模行銷活動執行的支柱,其中正確的資料會即時提供並控制,進而推動可測量的業務影響。

Context

現代行銷人員跨多個參與管道 (電子郵件、廣告、行動和 Web) 作業,每個管道都需要精確、及時且個人化的客戶受眾。Data 360 可作為這些受眾的統一基礎,將每個系統的客戶資料結合到豐富且可運作的區段中。 批次啟用是用來將這些區段從 Data 360 匯出至下游行銷或廣告平台的最常見啟用模式。一般目的地包括 Marketing Cloud Engagement、Google Ads、Meta 自訂受眾或 LinkedIn Ads,您可在其中直接針對這些精密設計的受眾執行行銷活動。

問題

行銷小組如何取得使用 Data 360 中統一且豐富資料建立的精確定義受眾,並使其可在外部行銷或廣告系統中供啟用? 例如,請思考區段:「過去 90 天內未購買,但最近在網站上參與的高價值客戶。」 行銷人員需要確保此受眾正確轉移、使用相關屬性 (例如,忠誠度等級、區域或預測的 CLV) 增強,並定期重新整理,以維持行銷活動的相關性和成效。

力量

多個技術與作業因素構成「批次啟用」模式:

• **身分對應:**精確的受眾傳送需要將 Data 360 的「統一個人識別碼」對應至目的地系統中的對應識別碼,例如 Marketing Cloud 中的「訂閱者金鑰」或數位廣告平台的雜湊電子郵件。這可確保精確比對並免除目標錯誤。
• **屬性選取與增強:**行銷人員必須超出識別碼,並包含其他設定檔資料 (例如名字、忠誠度狀態、CLV 或其他個人化屬性),才能啟用下游個人化和分析。
• **目標平台組態:**每個目的地必須在 Data 360 中註冊為「啟用目標」,包括連線詳細資料、驗證和資料欄位對應。此一次性設定會定義安全連線,並管理哪些系統可以接收已啟用的資料。
• **管治與合規:**資料啟用必須遵循同意中繼資料、隱私權原則 (例如 GDPR 或 CCPA),以及儲存在統一設定檔中的行銷權限。認可啟用可確保資料僅用於授權用途。
• **排程和效能:**啟用通常會每日或每小時排程,以讓下游受眾保持最新狀態。系統必須有效處理大量和增量重新整理,而不會重複或遺失資料。

解決方案

Data 360 中的 批次啟用流程遵循引導式工作流程,可將行銷人員的技術摩擦降到最低,同時保留管治與延展性:

草稿

以下是步驟的摘要:

• **建立區段:**行銷人員或分析師使用視覺區隔工具建立區段,結合任何統一資料物件的篩選條件。
• **建立啟用:**他們選取區段作為來源,並選擇預先設定的目的地 (例如 Marketing Cloud 或 Google Ads)。
• **定義裝載:**連絡人識別碼和其他設定檔屬性會選擇用於受眾匯出與報告。
• **排程遞送:**啟用排程為執行一次或循環執行,讓受眾在目的地處於最新狀態。
• **執行:**在觸發時,Data 360 會查詢區段、建立裝載、套用篩選條件以取得同意,並將結果推送至目的地系統。

結果

• Data 360 的目標性、豐富的受眾區段可直接在下游行銷和廣告平台中使用。
• 受眾會自動重新整理並使用最新的統一客戶資料進行同步化,以維持即時行銷活動的相關性。
• 行銷人員可以使用這些已啟用的受眾作為 Marketing Cloud 旅程、電子郵件行銷活動或數位廣告平台 (例如 Google Ads、Meta 或 LinkedIn Ads) 中的自訂受眾的輸入來源。
• 每個啟用執行都會維持端對端歷程,確保 Data 360 與外部系統之間的合規性、可追蹤性和一致性。
• 業務使用者可以透過完整且信任的 Customer 360 檢視提供高度個人化的資料驅動體驗。

通話機制

呼叫機制取決於目的地平台和啟用目標組態。

錯誤處理與復原

• **工作層級錯誤隔離:**每個啟用執行都會在 Data 360 協調流程層中作為個別且可追蹤的工作執行。失敗的執行會自動隔離,而不會影響其他啟用或區段定義。
• **部分批次復原:**如果某些記錄無法匯出 (例如,由於識別碼不相符或 API 速率限制),則系統會使用增量差異排入和並行復原的差異排列來重試這些記錄。
• **結構描述驗證錯誤:**當輸出裝載屬性不再符合目標結構描述 (例如,已刪除的屬性或重新命名的欄位) 時,工作會將受影響的記錄路由至「結構描述拒絕排隊」以供管理員檢閱。
• **重新執行與恢復支援:**每個啟用工作都會維護檢查點權杖,以便捕捉最後一個成功批次。復原後,處理會從檢查點恢復,以確保不會重複或遺失資料。
• **全方位監視:**所有啟用事件、重試和傳送度量都會記錄在 Trust 層監視中,啟用 SLA 追蹤、根本原因分析,以及透過 Event Monitoring API 自動化警示。

潛在設計考量事項

• **決定性啟用金鑰:**每個啟用執行都會使用複合使用者效能金鑰 (其結合「區段識別碼」、「啟用識別碼」和「目標系統識別碼」),以保證完成一次傳送。
• **重複執行偵測:**Data 360 啟用服務會根據先前的工作雜湊來檢查傳入的裝載,以偵測並抑制回覆。
• **原子匯出認可:**僅在成功寫入確認後,才會將裝載認可至目標系統,以防止部分更新或重複計數。
• **一致的身分解析:**由於啟用取決於統一識別碼 (例如「統一個人」),因此重試或重試一律會鎖定相同的金級記錄,以維持語意一致性。
• **啟用狀態持續性:**協調流程層會保留啟用狀態中繼資料 (時間戳記、狀態代碼和序列權杖),以便視需要進行決定性重新處理。

安全性考量事項

• **強式驗證:**每個啟用目標 (例如 Marketing Cloud、廣告或 CRM) 都會使用 OAuth 2.0 搭配權杖輪換和租戶特定範圍,以防止未經授權的資料匯出。
• **屬性層級管理:**只有「統一設定檔」中的已批准屬性符合啟用資格,由「資料共用原則」與「啟用範本」強制執行。
• **傳輸和靜態加密:**所有裝載都會在傳輸期間使用 TLS 1.2+ 加密,而 AES-256 會在 Data 360 和目標平台中靜態加密。
• **同意與保單強制執行:**啟用工作會遵循儲存在 Data 360 的 Trust 圖層中的「同意物件」和「資料原則」。沒有有效同意中繼資料的記錄會自動從匯出中排除。
• **稽核與合規性記錄:**每個啟用執行都會捕捉起始者、傳送的資料以及目的地—在 Trust 層顯示面板內啟用完整的監管稽核追蹤 (GDPR、CCPA)。
• **最低權限存取權:**每個目標的整合使用者僅限於啟用特定範圍—沒有管理權限或不相關系統的寫入存取權。

側列

及時性

• 針對排程或近乎即時的批次匯出 (分鐘到小時延遲) 所設計。
• 支援與行銷活動行事曆一致的時間範圍重新整理。
• 可使用資料整備標記來排序啟用工作,以確保資料是最新的。
• 最適合非互動式啟用案例,其中資料準確性高於立即性。

資料量

• 處理大規模資料集 (每次執行數百萬筆記錄)。
• 透過區段分割和並列匯出管道水平調整規模。
• 使用以區塊為基礎的批次來避免逾時並最佳化輸送量。
• 適用於資料完整性十分重要的企業級資料銷售管道。

州/省管理

• 維護記錄工作識別碼、時間戳記和序列權杖的啟用狀態物件。
• 使用檢查指標進行重新啟動和錯誤復原。
• 版本化區段定義可確保啟用週期之間的可複製性。
• 啟用來源區段、DMO 屬性和目標裝載之間的歷程追蹤性。

複雜整合案例

• 透過預先建置的連接器,與 Salesforce CRM、Marketing Cloud 和外部系統順暢整合。
• 支援多目標啟用,同時將資料散佈至不同的目的地 (例如 CRM + Ads)。
• 可以觸發複合工作流程,例如批次匯出,後面接著是下游 API 呼叫或 AI 評分。
• 透過「資料模型管理層」妥善處理結構描述進化。

範例

一個全球零售品牌想要重新吸引過去 90 天內未啟用的客戶。資料結構設計師會使用 Data 360 定義「孤立購物者」區段,其中包含購買歷程記錄、忠誠度等級和同意中繼資料。「批次啟用工作」會每晚執行,將此區段推送至 Marketing Cloud Engagement 以觸發個人化「我們遺漏您」電子郵件行銷活動,並推送至 Ad Studio 以重新定位。此工作運用臨時傳送功能,確保不會重複重複重試,且所有事件都會記錄在 Trust 層中進行稽核合規性。

Context

企業通常需要受管理機制,才能將 Salesforce Data 360 的統一或區隔資料匯出至標準檔案格式 (例如 CSV 或 Parquet),以供歸檔、合規或後續整合。此模式可啟用 Data 360 至雲端儲存空間匯出—允許信任的客戶資料安全地流入 Amazon S3、Azure Blob 或 Google Cloud Storage (GCS) 上主控的企業資料湖或分析管道。 一般使用個案包括:

• 定期歸檔同意的客戶資料集以供監管保留。
• 匯出非 Salesforce 分析工作量 (例如 Tableau、Databricks 或 Power BI) 的精密設計區段。
• 啟用需要結構化 CSV 或 Parquet 檔案作為輸入的外部機器學習模型。

問題

組織如何以受管理、安全和自動的方式,從 Data 360 將精密設計的區段或資料集匯出至雲端儲存分類 (例如 Amazon S3),同時維護結構描述完整性和合規性控制?例如,規範小組可能需要:「在取得有效同意的情況下,從歐盟地區的所有已啟用客戶中提取資料,並每週將資料匯出至 S3 位置以進行外部稽核和報告。」這需要可重複且注意原則的匯出管道,以確保正確的檔案格式、存取權限和傳送排程,而無須手動介入或未受管理的資料移動。

力量

多個營運與結構因素管理此匯出模式:

• 驗證與授權:匯出必須遵循雲端提供者的 IAM 模型 (例如,AWS IAM 角色或 Azure 服務主體),以確保只有授權的系統可以寫入至目標分類。
• 結構描述對齊:輸出結構描述必須符合目標系統預期的結構與格式 (CSV、Parquet 或 JSON)。
• 資料隱私與同意:匯出的資料集必須篩選出任何缺少有效同意中繼資料的記錄。
• 排程與新鮮度:許多匯出都是定期 (每日、每週或每月) 且必須符合企業資料重新整理週期。
• 管治與監視:每個匯出都必須可以完整的歷程可視性進行稽核,以確保符合資料保留和法規要求 (例如 GDPR、CCPA)。

解決方案

「檔案匯出啟用」模式會重複使用與用於取用但針對資料匯出設定的相同安全雲端儲存連接器。管理員會先將雲端儲存平台 (例如 Amazon S3、Azure Blob Storage 或 GCS) 註冊為 Data 360 中的「啟用目標」。接著,使用者可設定並執行「啟用工作流程」,將所需區段匯出至指定的檔案儲存路徑。

草稿

以下是步驟的摘要。

• **選取「區段:**分析師或資料管理員選擇要匯出的統一區段。
• **建立啟用:**他們會建立新的「啟用」工作,並選取註冊的「Cloud Storage」目標。
• **定義裝載:**指定匯出結構描述、屬性清單和檔案格式 (例如 CSV)。
• **排程匯出:**選擇一次性或循環排程。
• **執行工作:**Data 360 會產生檔案並安全地將其傳送至指定的分類路徑。
• **監視與確認:**系統會在「Trust 層」中檢閱結果和記錄以瞭解驗證與合規性。

結果

• Data 360 的目標性、豐富的受眾區段可直接在下游行銷和廣告平台中使用。
• 受眾會自動重新整理並使用最新的統一客戶資料進行同步化,以維持即時行銷活動的相關性。
• 行銷人員可以使用這些已啟用的受眾作為 Marketing Cloud 旅程、電子郵件行銷活動或數位廣告平台 (例如 Google Ads、Meta 或 LinkedIn Ads) 中的自訂受眾的輸入來源。
• 每個啟用執行都會維持端對端歷程,確保 Data 360 與外部系統之間的合規性、可追蹤性和一致性。
• 業務使用者可以透過完整且信任的 Customer 360 檢視提供高度個人化的資料驅動體驗。

通話機制

呼叫機制取決於目標雲端儲存平台和啟用組態。

錯誤處理與復原

• **工作層級隔離:**每個匯出都會以離散工作執行。失敗的工作會獨立隔離並重試。
• **部分檔案重試:**如果某些批次無法上載 (例如由於網路中斷),則系統會使用指數反向方式重試這些區塊。
• **結構描述不相符處理:**任何結構描述漂移或欄位不相符都會將記錄路由至「結構描述拒絕排隊」以供檢閱。
• **檢查點與恢復:**匯出工作會維護檢查點中繼資料,從上次成功的寫入啟用恢復,而不會重複。
• **整合監視:**失敗和重試會記錄在 Trust 圖層顯示面板中,以取得可視性和 SLA 合規性。

潛在設計考量事項

• **決定性匯出索引鍵:**每個匯出工作都包含由「區段識別碼 + 目標識別碼 + 時間戳記」所組成的唯一識別碼。
• **重複執行安全性:**系統會使用工作雜湊偵測重複的工作執行,並略過以防止冗餘匯出。
• **原子寫入保證:**Data 360 只會在完整完成和核取總和驗證後,將檔案認可至目標分類。
• **一致的結構描述版本化:**匯出定義是版本控制,以確保執行之間的結構描述一致。
• **檢查點持續性:**匯出工作保持狀態,可視需要進行決定性復原和重新處理

安全性考量事項

• **強式驗證:**雲端連接器會針對已驗證的寫入使用 OAuth 2.0、IAM 角色或服務主體。
• **隨處加密:**資料會在傳輸 (TLS 1.2+) 和靜態 (AES-256) 中加密。
• **同意感匯出:**僅會匯出具有有效同意的記錄,由 Trust 層原則強制執行。
• **最低權限原則:**匯出使用者和服務帳戶僅限於其指定的儲存路徑。
• **全方位稽核記錄:**每個匯出都會記錄中繼資料,包括起始者、結構描述、目的地和合規性報告的時間戳記。

側列

及時性

• 針對具有子秒延遲的立即事件驅動啟用所設計。
• 適用於需要立即個人化、建議或決策的情境。
• 在串流模式中作業—只要在 Data 360 中發生合格資料變更,便會觸發。
• 確保持續回應,而無須等待批次排程或區段重新計算。

資料量

• 處理大規模資料集 (每次執行數百萬筆記錄)。
• 透過區段分割和並列匯出管道水平調整規模。
• 使用以區塊為基礎的批次來避免逾時並最佳化輸送量。
• 適用於資料完整性十分重要的企業級資料銷售管道。

州/省管理

• 每個事件動作都會維護自己的事件權杖和重新執行識別碼,以進行識別處理。
• 支援在暫時失敗時,從上次認可的事件恢復檢查點持續性。
• 包含內建的復原邏輯和重新執行視窗,以確保完全符合啟用一次的語意。
• 動作結果 (成功/失敗) 會即時記錄,並透過 Trust 圖層可觀察性顯示面板呈現。

複雜整合案例

• 直接與 Salesforce 流程、Einstein 1 平台事件或立即回應鏈的外部 Webhooks 整合。
• 可以觸發下游自動化,例如立即 CRM 記錄更新、AI 評分或 Marketing Cloud 訊息傳送。
• 支援可編譯協調流程:事件觸發可以呼叫 Data 360 動作、Apex 叫用或外部 API。
• 針對具有即時感知內容回應的代理和自適應企業模式所設計。

範例

全球零售企業需要每週匯出其「已啟用忠誠度成員」區段,以在 Databricks 中進行分析。Data 360 管理員會將 Amazon S3 設定為啟用目標,並排程每週的 CSV 匯出至 s3://enterprise-analytics/loyalty/weekly_exports/ 路徑。匯出工作會每週日執行,產生具有 2 百萬筆以上記錄的同意篩選檔案。 所有事件、結構描述定義和歷程記錄在 Trust 圖層顯示面板中,以確保透明度、可稽核性和合規性。

隨選 API 型啟用是一種即時、以事件為導向的方法,可讓 Data 360 洞察在需要時運作,而不必等待批次工作或排程匯出。此模式可讓外部系統、Salesforce 應用程式或 AI 工作人員直接呼叫 Data 360 API,以依需求提取或啟用特定受眾配量、客戶屬性或洞察,而不是以固定步調發佈預先建立的區段。 此模式是針對互動式、以觸發為基礎的體驗所設計,例如當使用者登入入口網頁、工作人員開啟客戶記錄,或 AI Copilot 起始 Next-best-action 查詢。系統不會依賴預先計算的匯出,而是動態地從 Data 360 inReal-Time 查詢或啟用最新的受管理資料。 主要優點為立即性和精確度:

• 每個 API 呼叫都會在 Data 360 的統一同意設定檔圖表中存取最新的客戶智慧。
• 啟用功能適用且可稽核,符合企業 Trust 與合規性需求。
• 可透過 Einstein 1 平台 API、Connect API 或啟用 API,直接從 Salesforce 流程、Apex 或外部系統觸發整合。 此方法支援最重要的延遲和個人化使用個案,例如:
• 在服務通話期間觸發個人化產品供應項目。
• 根據即時行為事件產生動態行銷活動受眾。
• 將即時決策提供給參與時作業的 AI 或 ML 模型。

Context

企業通常需要在自訂建立的應用程式 (例如內部網頁入口網頁、行動應用程式或合作夥伴面向的 Web 體驗) 內呈現協調的即時 Data 360 洞察。此模式可讓開發人員建立以 UI 為中心的安全解決方案,這些解決方案會與 Salesforce CRM 和其他內容相關系統一起取用並顯示統一的客戶資料,全都透過受管理和以 API 為基礎的存取。 一般使用個案包括:

• 將 Data 360 洞察內嵌至內部員工顯示面板或行動應用程式。
• 使用客戶和交易可視性建立合作夥伴或經銷商入口網頁。
• 將 Data 360 資料整合至第三方 Web 應用程式或體驗層。
• 顯示 Data 360 和 Einstein 1 提供的即時個人化建議。

問題

開發人員如何建立以 UI 為中心的自訂應用程式,以安全地存取並顯示協調的 Data 360 資料,通常與其他 Salesforce 資料來源一起,而不重複或匯出敏感資訊? 例如,企業可能需要建立客戶入口網頁,以從 Data 360 顯示統一的客戶設定檔、互動和已計算洞察。 這需要單一、安全且效能高的 API 圖層,以支援前端體驗、處理驗證,並確保監管,同時移除 Data 360 內部資料模型的複雜性。

力量

多個結構與作業考量事項會影響此模式:

• **以使用者為中心的存取權:**主要目標是在自訂前端體驗 (Web 或行動) 內呈現資料,而不是執行批次解壓或後端同步。
• **Secure Gateway:**所選的 API 必須作為已驗證應用程式和使用者的安全且可調整的進入點,強制執行企業級存取控制。
• **統一資料內容:**應用程式應能順暢地將 Data 360 資料 (例如統一設定檔、已計算洞察) 與 CRM、ERP 或自訂物件資料結合在一起。
• **開發人員簡單性:**API 應傳回簡報就緒的裝載,以將用戶端層中的後端處理或結構描述對應最小化。
• **管治與可觀察性:**所有存取權都應透過可信任且可稽核的管道來流動,並具有明確的歷程、驗證和強制執行原則。

解決方案

解決方案是使用 Salesforce Connect REST API 作為在 Data 360 上建立自訂資料驅動應用程式的主要整合門戶。 Connect API 提供對 Salesforce 資料 (包括 Data 360 的協調設定檔、區段和已計算洞察) 的 RESTful 存取權,其回應格式針對 UI 耗用最佳化 (JSON 型、輕量型和行動使用)。 開發人員透過連線的應用程式進行驗證、取得 OAuth 2.0 權杖,並呼叫 Connect API 資源,例如 /query、/Chatter 或 /data,以直接在其應用程式介面中呈現統一資料。 Connect API 可在背景作為其他 API (例如查詢 API、Data Graph API 和 Einstein 1 Platform API) 的傳輸基礎,讓開發人員能夠在單一統一存取模式下結合多個資料來源。

草稿

以下是步驟的摘要。

• 註冊連線的應用程式 — 定義外部應用程式驗證的 OAuth 範圍和 API 權限。
• 取得存取權杖 — 外部應用程式執行 OAuth 2.0 驗證以接收 Data 360 存取權杖。
• Invoke Connect API — 應用程式會執行 REST API 呼叫,以提取統一設定檔、區段或洞察資料。
• 在 UI 中呈現資料—會剖析回應,並在品牌入口網頁或行動介面中向使用者顯示。
• 處理錯誤與重新整理權杖 — 應用程式會實作重試邏輯和自動權杖重新整理,以保持工作階段持續性。
• 監視與稽核存取權 — 所有 API 呼叫都會記錄在 Trust 圖層中,以瞭解可視性和合規性。

結果

開發人員可以建立與 Data 360 密切整合的安全自訂品牌應用程式。這些應用程式可以:

• 以即時方式呈現已協調的客戶設定檔和洞察。
• 透過統一 API 與 CRM 或自訂物件一起顯示 Data 360 資料。
• 透過 Trust 層運用一致的驗證、授權和稽核控制。
• 為業務使用者或合作夥伴提供流暢且受管理的跨體驗信任客戶智慧存取權。

通話機制

呼叫機制取決於目標雲端儲存平台和啟用組態。

錯誤處理與復原

• **要求節流:**自動在比率限制下備份和重試 API 呼叫。
• 結構描述漂移保護:使用 GraphQL 結構描述版本化或 REST 中繼資料探索以適應結構描述變更。
• 權杖到期管理 – 應用程式會自動重新整理 OAuth 權杖,以避免工作階段中斷。
• API 錯誤區隔 – 系統會記錄失敗的 API 呼叫並重試,而不會影響同時工作階段。
• 信任層觀察性 – API 成功/失敗率和存取記錄會顯示在「信任層」顯示面板中。

潛在設計考量事項

• 決定性要求識別碼:每個 API 要求都包含重複執行安全處理的關聯性識別碼。
• **快取驗證標題:**ETag 和「上次修改」標題會防止冗餘的資料提取。
• **原子讀取作業:**Connect API 可確保每個回應皆反映統一資料的一致快照。
• 重複執行保護 – 使用要求簽章和時間戳記篩選重複的 API 呼叫。

安全性考量事項

• **OAuth 2.0 驗證:**所有 API 呼叫都會透過「連線的應用程式」使用安全且短暫的 OAuth 存取權杖。
• **最低權限存取權:**API 範圍僅限於必要物件和欄位。
• **隨處加密:**傳輸中的 TLS 1.2+;快取或儲存回應的靜態 AES-256 加密。
• 同意資料存取權 360 可確保所有已提取的記錄皆遵循同意與管治原則。
• **全方位稽核記錄:**系統會在 Trust 圖層中記錄使用者、應用程式和時間戳記中繼資料的每個 API 互動。

側列

及時性

• 針對低延遲、即時 API 存取所設計。
• 適用於需要立即資料呈現的互動式應用程式。
• 透過快取與索引的 Data 360 來源支援近乎立即的查詢回應時間。
• 不需依賴批次排程或非同步啟用週期。

資料量

• 針對互動式使用個案 (例如設定檔、洞察或最近交易) 所最佳化。
• 透過游標式分頁順暢地處理分頁結果。
• 不適用於大量大量匯出—針對大型資料集使用「批次」或「檔案匯出」模式。

州/省管理

• 應用程式會使用 OAuth 權杖和本機快取來維持輕量型工作階段狀態。
• Connect API 支援條件式要求和部分重新整理以提升效率。
• API 回應包含版本標記,用於跨版本的結構描述一致性。

複雜整合案例

• 將 Connect API 與 Data Graph API 結合,以跨多個網域進行語意查詢。
• 與 Einstein 1 Copilot 或 AI API 整合,以獲得預測式對話式體驗。
• 搭配 Experience Cloud 或 Lightning Web 元件使用,以進行混合式 UI 開發。
• 透過 MuleSoft 擴充,以即時協調資料增強或外部系統對應。

範例

跨國保險公司建立客戶自助式服務入口網頁,讓保單持有人能夠檢視其統一設定檔、最近索賠和個人化優惠。前端以 eact 為基礎的應用程式會透過 OAuth 2.0 進行驗證,並使用 Connect REST API 和 Data Graph API 提取資料。所有資料都會即時顯示、感知同意,並透過 Data 360 Trust 層級進行管理。開發人員可直接在 Salesforce 內監視 API 呼叫並稽核追蹤,以確保完全合規性和可觀察性。

Context

企業對即時決策系統 (例如服務主控台、建議引擎或個人化平台) 所需的完整客戶設定檔即時存取權越來越多。此模式可讓應用程式使用 Data 360 的 Data Graph API,以近乎即時的方式,以預先計算且統一檢視客戶資料,為互動體驗提供子秒回應時間。 一般使用個案包括:

• 在「客戶服務」或 Sales Console 內顯示全方位的客戶檢視。
• 為 AI 型「Next Best Action」或「Next Best Offer」建議提供動力。
• 在頁面載入時提供超個人化的 Web 或行動體驗。
• 在工作人員或自助式服務環境中支援工作階段內決策。

問題

應用程式如何能立即提取完整、預先計算且統一的客戶檢視,而不是在執行階段執行慢速的多物件查詢?例如,網頁個人化引擎必須在毫秒內載入完整的客戶內容 (人口統計、偏好、交易和已計算洞察),才能選取個人化優惠。傳統關聯式查詢可能需要多個聯結,並導致無法接受的延遲。這需要 API,提供反正規化且可供使用的設定檔資料,且可透過單一金鑰對應 (結合速度、完整性和管治性) 來進行搜尋。

力量

多個營運和效能因素會影響此模式:

• **速度:**回應時間必須接近即時。API 必須在毫秒內傳回完整設定檔,才能支援同步互動。
• **完整性:**回應必須包含所有相關屬性、關係和已計算洞察,理想情況下是在單一裝載中。
• **對應效率:**設定檔應可透過識別碼 (例如 customerId、contactKey 或電子郵件),以免發生多步驟查詢。
• **資料新鮮度與延遲:**某些使用個案偏好預先計算 (快取) 的資料速度;而其他則需要即時資料,接受較高的延遲。
• **管治與安全:**存取權必須保持由 Salesforce Trust 圖層原則管理,以確保符合資料可視性和同意規則。

解決方案

解決方案是使用 Salesforce 資料圖表 API 來檢取儲存為「資料圖表」記錄的預先計算反正規化客戶檢視。「資料圖形」是一種具體化的語意檢視,將多個「資料模型物件」(DMO) (例如「個人」、「交易」和「ProductInterest」) 結合成單一唯讀記錄,通常以 JSON blob 表示。 開發人員可以使用 REST 端點,例如: GET /api/v1/dataGraph/{dataGraphEntityName}/{id} 以透過其唯一識別碼,來取回完整記錄。針對動態情況,API 支援 live=true 參數,可略過已具體化的快取,在 Data 360 中執行即時查詢,並針對最新的資料交易最短延遲。 這可讓開發人員根據業務需求,在立即 (快取) 和最新 (即時) 設定檔中選取。

草稿

以下是實作流程的摘要:

• 定義資料圖表 — 資料結構設計師建立「資料圖表」,在多個 DMO 之間建模統一的客戶檢視。
• 註冊連線的應用程式 — 開發人員可設定 OAuth 認證以安全地存取 API。
• 叫用資料圖表 API — 應用程式會發出具有「資料圖表」名稱和記錄識別碼的 GET 要求。
• 流程回應 — API 會傳回客戶設定檔的完整 JSON 表示。
• 呈現或動作—取用應用程式 (UI 或引擎) 會使用統一資料進行個人化、建議或服務動作。
• 監視和調整 — 透過 Trust 層觀察性主控台檢閱效能度量和存取記錄。

結果

應用程式現在可以立即提取完整且預先加入的客戶設定檔,以支援即時互動,例如個人化、服務和決策自動化。 此模式可確保:

• 目前決策的子秒回應時間。
• 與 Data 360 語意模型相符的一致且受管理的資料提取。
• 簡化應用程式邏輯—無聯結,無結構描述協調。
• 可透過 Trust 層進行追蹤且符合的存取,以進行稽核和可觀察。

通話機制

呼叫機制取決於目標雲端儲存平台和啟用組態。

錯誤處理與復原

• 優良回復 – 如果即時查詢失敗或超過逾時值,則會自動回復為快取的「資料圖形」,
• 逾時管理 – 針對載入高的 API 呼叫實作重試與斷線邏輯。
• 識別碼處理無效 – 傳回標準 404 找不到不存在設定檔金鑰的回應;請謹慎處理 UI。
• 結構描述版本驗證 – 驗證「資料圖表」版本中繼資料,以避免結構描述演進時發生不相符項目。
• 可觀察性整合 – 記錄 SLA 監視的「信任層」顯示面板內所有錯誤、重試和延遲。

潛在設計考量事項

• 決定性索引鍵 – 每個設定檔會使用穩定識別碼 (例如,IndividualId),以確保可預測且安全地執行查詢。
• 快取一致性 – 使用 ETag 或「上次修改」標題以進行條件式提取和快取驗證。
• Atomic Retrieval – 每個 API 回應皆代表已具體化「資料圖形」記錄的一致快照。
• 重複執行保護 – 確保用戶端應用程式透過關聯性識別碼和時間戳記偵測重複的提取。

安全性考量事項

• 強大驗證 – OAuth 2.0 透過連線的應用程式強制執行以權杖為基礎的安全存取。
• 同意感取 – 只會傳回同意的屬性;同意篩選會由 Trust 層自動套用。
• 欄位級管理 – 透過 Data 360 的中繼資料和原則定義控制屬性的存取權。
• 在傳輸和靜態加密 – 所有回應都使用 TLS 1.2+ 和 AES-256 加密。
• 稽核與可追溯性 – 系統會使用識別碼、時間戳記和原則內容來記錄每個設定檔提取事件。

側列

及時性

• 適用於即時取用。
• 支援以略有較高的延遲 (子秒) 即時查詢最新的資料。
• 針對同步決策和互動式應用程式最佳化。
• 無須進行批次前啟用或區段重新計算。

資料量

• 對於每個要求的 單筆記錄對應或小組 (十到數百個) 而言非常適合。
• 並非針對大規模的大規模大量取用最佳化;針對大量讀取使用批次或查詢 API。
• 使用水平調整快取和預先具體化的速度。

州/省管理

• 維護輕量型且無狀態的存取權;每個要求皆獨立。
• 支援快取標題以確保重新執行安全性。
• 應用程式可以維護本機快取或短時間工作階段儲存空間,以減少重複對應。

複雜整合案例

• 與 Einstein 1、Connect API 和 MuleSoft 順暢整合,以獲得複合資料體驗。
• 可以支援需要立即上下文感知的原始系統 (例如 Copilot 或 AI 推理引擎)。
• 與「資料動作」結合,以便在取用或狀態變更時即時觸發。
• 實現大規模的個人化,而不會影響績效或管治。

範例

全域電子商務平台使用 Data 360 的 Data Graph API 即時針對其建議引擎來提取統一的客戶設定檔。當使用者登入時,應用程式會叫用 Data Graph 端點來為該客戶提取 UnifiedCustomerProfile,以單一 JSON 裝載傳回人口統計屬性、行為訊號和已計算洞察。個人化引擎會在啟用的工作階段期間,在毫秒內耗用此回應,以決定並顯示「Next Best Offer」。所有要求都會透過 Trust Layer 進行管理和記錄,以確保整個互動的完整可視性、強制執行原則和合規性。

即時資料動作可在 Data 360 中隨即啟用客戶資料。這些動作不會等待排程的批次匯出,而是會以毫秒的方式將更新、洞察或觸發直接推送至 Salesforce 或外部系統。在 Data 360 中更新客戶的狀態、同意或參與度量時,該訊號會立即強化個人化優惠、觸發 Service Cloud 自動化或更新忠誠度層級,以確保每個客戶體驗皆反映最新的統一事實。 此模式適用於高影響、敏感於延遲的使用個案,例如個人化 Web 體驗、詐騙偵測警示、Next-best-action 建議或即時 CRM 更新。其可減少資料洞察與業務動作之間的間隙,將統一資料轉為即時情報。

Context

現代數位體驗和作業工作流程在事件發生時需要立即的內容相關動作,例如在 Checkout 期間更新客戶記錄、掃描退貨時調整庫存,或在使用者離開手推車時提供個人化促銷。**即時資料動作**可讓系統透過子秒到秒延遲,叫用、增強統一 Data 360 設定檔和已計算洞察,並對其採取動作,以實現互動式個人化、作業自動化和即時決策。

問題

應用程式、UI 互動流程或中介軟體如何在執行階段呼叫 Data 360 以讀取、計算或更新單一統一設定檔,或以低延遲、強大一致性和管治控制來觸發動作 (例如傳送優惠、更新 CRM、啟動工作流程),而無須等待排程的批次工作或繁重的管道?

力量

多個技術、營運和管治部門構成此模式:

• **低延遲需求:**通話必須在下秒到幾秒的範圍內完成,才能保留良好的 UX 或符合作業 SLA。
• **決定性身分解析:**要求必須可靠且快速地解析至正確的「統一個人」設定檔 (金級記錄)。
• **微調授權:**即時呼叫必須在要求時間強制執行屬性層級原則和同意檢查。
• **支付量最小化:**即時裝載應小型且聚焦 (單一設定檔或小型屬性集),以減少延遲和成本。
• **開發人員體驗:**API 必須為開發人員易用 (REST/gRPC/GraphQL),具有明確的結構描述和穩定的契約,才能供生產使用。
• **稽核與可追溯性:**每個即時動作都必須以歷程記錄、使用者身分和原則決策來進行合規。

解決方案

建議的解決方案是使用 Data 360 的即時資料動作介面 (API + SDK),並在必要時結合邊緣快取和最少的運算轉換。整合會叫用資料動作端點來讀取或寫入設定檔屬性、計算洞察或起始協調流程。在退回任何裝載或執行動作之前,系統會在「保單強制執行點」上套用即時原則檢查 (CEDAR) 和動態遮蔽。

草稿

以下是步驟的摘要。

• Client (UI/ middleware/POS) 會傳送具有識別碼和動作類型的已驗證「資料動作」要求。
• API Gateway 會驗證權杖、比率限制,並轉送至 Data 360 Action Service。
• 動作服務會解析識別碼 → 統一個人識別碼 (快速路徑快取;回復至圖表對應)。
• 「保單強制執行」(PDP) 會使用 PIP 與要求內容中的屬性評估 CEDAR 原則。
• 若允許,則「動作服務」會讀取任何必要的設定檔屬性/洞察,並執行輕量轉換。
• 「動作服務」會同步傳回回應 (例如提供權杖、更新的屬性),或排入非同步協調流程,並傳回確認。
• 所有事件、決策和裝載都會記錄到 Trust 圖層,並選擇性轉送至 SIEM。

結果

• 應用程式會收到透過子秒到第二次延遲的統一設定檔讀/寫和動作觸發的原則管理即時存取權。
• 即時個人化、決策和作業工作流程 (例如,優惠、工作人員協助、庫存更新) 會啟用,而不會發生批次延遲。
• 所有動作皆可稽核、感知同意,並強制執行屬性層級遮蔽,以維護隱私權與合規性。

通話機制

呼叫機制取決於目的地平台和啟用目標組態。

錯誤處理與復原

• **同步錯誤:**使用人類可讀的訊息和識別權杖傳回結構化錯誤代碼。
• **暫時重試:**客戶應針對 429/5xx 回應重試具有指數反向的潛在要求。
• **原則拒絕處理:**拒絕會傳回明確原因代碼;原則失敗時,不會傳回敏感資料。
• **非同步協調流程失敗:**協調流程工作會移至 DLQ 並可重新執行;工作狀態 API 允許客戶輪詢或接收回呼。
• **回復策略:**如果身分解析失敗,則傳回決定性錯誤,並選擇性傳回建議的補救措施 (例如,需要 externalId)。

潛在設計考量事項

• **Idempotency 索引鍵:**用戶端提供識別碼金鑰 (UUID + 用戶端命名空間) 以用於變更動作。
• **決定性索引鍵:**使用複合索引鍵 (UnifiedIndividualId + ActionType + TimestampWindow) 來偵測重複項目。
• **安全重試:**設計動作以容忍副作用,或執行更新插入而非隱藏插入。
• **重複執行保護:**保留已處理的 idempotency 金鑰,並在業務期間後進行 TTL,以避免重複執行。
• **無國籍:**盡可能將同步動作保持為無狀態;保留非同步工作流程的最低狀態。

安全性考量事項

• **驗證:**OAuth 2.0 (JWT 承載者或 mTLS 用於服務帳戶);短期權杖和重新整理輪替。
• 授權:「原則決策點」會針對每個要求強制執行「以屬性為基礎的存取控制」(CEDAR) 和同意檢查。
• **傳輸與儲存加密:**傳輸中的 TLS 1.2+;任何快取片段或稽核記錄的靜態 AES-256。
• **最低權限:**範圍為最小權限的 API 用戶端;讀取與寫入與協調的角色分開。
• **資料最小化:**僅傳回要求與同意的屬性;對 PII/PHI 套用動態遮蔽。
• **網路控制:**您可以選擇性地從私人網路 (Private Connect、IP 允許清單) 呼叫,以進行高風險動作。
• **稽核與監視:**將要求中繼資料、原則決策、要求者身分和回應雜湊記錄至 Trust Layer 和 SIEM。

側列

及時性

• 針對同步動作的子秒到低單秒範圍中平均延遲所設計。
• 邊緣快取 (短 TTL) 和預先計算洞察會減少來回行程。
• 非同步路徑針對繁重工作提供近乎即時的確認與背景處理。

資料量

• 針對單一記錄或小批次互動 (1–100 筆記錄) 最佳化。
• 不適用於大量匯出—針對大量使用使用批次啟用。
• 高輸送量會使用集區/連線重複使用和並列協調流程。

州/省管理

• 同步通話的無州要求模型;贈款/交易的最低動作狀態仍存在。
• 由變更事件驅動的快取無效—確保 TTL 和無效訊號讓快取保持最新狀態。
• 協調流程工作會維持儲存在 Trust 圖層中的永久狀態 (jobId、status、retries)。

複雜整合案例

• **工作人員助理:**工作人員的即時設定檔對應 + 以子秒傳回至 Service Console 的已計算傾向。
• **POS/邊緣裝置:**本機 SDK + 偶發資料動作,用於驗證促銷或忠誠度狀態。
• **混合式流程:**針對決策 + 非同步協調流程同步化資料動作,以更新下游系統並觸發行銷活動。
• **第三方中繼軟體:**MuleSoft 或 API Gateways 可以媒介驗證、增強內容,並強制執行額外的原則檢查。

範例

零售行動應用程式會決定購物者點選「 結帳 」時是否要顯示個人化的立即優惠券,方法是透過使用購物者的電子郵件和手推車內容叫用優惠 資格 資料動作。要求會由 API Gateway 驗證,並轉送至「資料動作服務」,此服務會使用快取快取來解析電子郵件至統一個人識別碼、透過 PDP 驗證行銷同意,並根據客戶的終身價值和最近購買的時間評估資格。如果購物者符合資格,則服務會傳回簽署的優惠券權杖並記錄決策。當優惠券核發需要庫存預留時,會觸發非同步協調流程來預留庫存並通知 CRM 系統。應用程式會立即顯示優惠券,而後續更新會在背景中完成,而「Trust 層級」會針對管治與合規性的完整稽核追蹤。

• 連接器與整合
• Web 與 Mobile SDK
• 次要即時的吸收
• 自帶湖 (零複製查詢)
• 自帶湖 (零複製檔案)
• 資料圖
• 啟用 參與
• 啟用 個人化
• 啟用 Commerce
• 資料共用 (零複製)
• 啟用:檔案儲存空間
• 資料動作
• 即時次要資料動作
• 外部啟用平台