動態資料流設定使用案例

本頁涵蓋Dynamic Datastream Configurations的六個常見使用案例：依值區分事件、階層式資料保留策略、系統事件隱藏、機器人流量篩選、選擇性Experience Cloud解決方案路由，以及Analytics來源聯結器移轉。

每個使用案例都是獨立的。 僅實作套用至您實作的專案。

在設定規則之前，請完成先決條件和規劃檢查清單，並檢閱設定模式，為您的實作選擇正確的主要資料集策略。

使用案例1：將可作業與分析事件分開 uc1

目標：​僅將​ 可操作 ​事件路由至Real-Time Customer Profile，同時讓​ 分析 ​事件可用於Customer Journey Analytics，藉此最佳化設定檔存放區使用量並降低資料量總計。

使用時機：​您正在將Web SDK或行動SDK事件擷取到Adobe Experience Platform，並遇到設定檔超額、資料量總計超額或串流擷取護欄壓力，因為所有事件都著陸於啟用設定檔的資料集中。

資料集策略 uc1-dataset-strategy

以下兩個資料集結構會依事件設定檔值來分隔事件。

規則設定 uc1-rule-config

在設定規則之前，請先決定是否使用可操作first或分析性first資料集策略。 該選擇會決定您將哪個資料集設定為資料流上的主要資料集。

範例1：分析優先 — 可操作的事件規則

主要資料集： Web Events - Analytics （未啟用設定檔，預設遞補）
次要資料集： Web Events - Profile （已啟用設定檔）

撰寫一個規則，將​ 可操作 ​事件提升至啟用設定檔的資料集。 所有​ 分析 ​事件會自動進入主要資料集。

規則：可操作的事件

針對其他​ 可操作 ​事件型別（例如commerce.productListAdds或leadGeneration.formComplete），使用OR邏輯新增其他條件。

範例2：可操作的第一 — 分析事件規則

主要資料集： Web Events - Profile （已啟用設定檔，預設遞補）
次要資料集： Web Events - Analytics （未啟用設定檔）

撰寫一個規則，將​ 分析 ​事件路由到啟用設定檔的資料集之外。 所有​ 可操作 ​事件會自動進入主要資料集。

規則：分析事件

為其他​ 分析 ​事件型別新增其他條件。

使用案例2：階層式資料保留策略 uc2

目標：​根據資料集的長期商業價值，將事件路由至保留期間不同的資料集，以管理資料保留成本。

何時使用：​不同的事件型別需要不同的保留期間。 例如，Adobe Real-Time CDP中購買資料的保留時間較長，產品互動的保留時間較短。

如需資料集保留組態的詳細資訊，請參閱體驗事件資料集保留指南。

資料集策略 uc2-dataset-strategy

下列三層結構會根據事件值指派保留期間。

規則設定 uc2-rule-config

將資料流上的主要資料集設定為Browsing - General，讓不符的事件預設會登陸在非設定檔資料集中，而不是膨脹設定檔存放區。 您不需要一般瀏覽事件的規則，這些事件會自動進入主要資料集。

規則1：購買

規則2：產品互動

為commerce.productListAdds新增含OR的其他條件、含UTM引數的頁面檢視以及其他產品互動事件。

使用案例3：隱藏個人化系統事件 uc3

目標：​保留Customer Journey Analytics和Real-Time Customer Profile中的decisioning.propositionFetch和personalization.request個事件。 當Adobe Target或Adobe Journey Optimizer擷取個人化決定時，這些系統事件會在每次頁面載入時引發。 它們是沒有分析或設定檔值的​ 消耗性 ​事件。

何時使用：​您將Adobe Target或Adobe Journey Optimizer與Customer Journey Analytics或Adobe Real-Time CDP一起用於個人化，這些系統事件會誇大您的可記帳列數、消耗設定檔存放區容量，或消耗串流擷取輸送量。

規則設定 uc3-rule-config

將系統事件路由到專用的隔離資料集，而不是完全停用Adobe Experience Platform服務。 這會在您確認事件不含有任何值之前保留事件以進行偵錯。

規則：系統事件

為personalization.request以及您要隱藏的任何其他系統事件型別新增OR條件。

將這些事件路由到隔離資料集後，請確定已將它從您的Customer Journey Analytics連線中排除。

使用案例4：機器人流量篩選 uc4

目標：​停止機器人產生的事件進入Real-Time Customer Profile、膨脹Customer Journey Analytics量度，或耗用串流擷取輸送量。

使用時機：​您已在資料流上啟用機器人偵測，且想要對指派給事件的機器人分數採取行動。

先決條件 uc4-prerequisites

在設定此規則之前，請先完成先決條件和規劃檢查清單中所述的機器人偵測設定：

規則設定 uc4-rule-config

一律以隔離機器人事件以進行分析開始。 在您驗證機器人評分正確之後，您可以繼續隔離或選擇完全捨棄這些事件。

規則：機器人流量

選項A：隔離以進行分析（一開始建議使用）

確定此資料集已從您的Customer Journey Analytics連線中排除。

選項B：完全捨棄（在驗證選項A之後）

在驗證隔離資料集並確認機器人評分正確之後，請停用規則中的Adobe Experience Platform服務以停止這些事件完全到達Adobe Experience Platform。

您也可以在個別規則中停用機器人流量的其他服務：

規則順序 uc4-rule-ordering

將機器人篩選規則​放在規則清單的前，放在任何​ 可操作 ​或​ 分析 ​規則之前。 由於Edge Network會使用首次比對成功評估，因此先放置此規則可確保Edge Network在任何其他路由邏輯執行前擷取並捨棄機器人流量。 將機器人事件路由至啟用設定檔的資料集會消耗不必要的設定檔存放區容量。

使用案例5：選擇性Experience Cloud解決方案路由 uc5

目標：​控制哪些Experience Cloud解決方案(Adobe Analytics、Adobe Target、Adobe Audience Manager)會接收特定事件型別，並根據事件條件覆寫解決方案層級設定，例如報表套裝或屬性代號。

使用時機：​您要將多個資料串流合併為一個，不同的事件型別應該移至不同的Adobe Analytics報告套裝，或某些事件不應達到Adobe Target或Adobe Audience Manager。

範例A：依事件型別覆寫Analytics報表套裝 uc5-example-a

為多個網站區段提供服務的單一資料流，可報告至不同的報表套裝：

規則1：電子商務事件

規則2：內容事件

範例B：停用分析事件的目標 uc5-example-b

防止​ 分析 ​事件到達Adobe Target，以減少每秒的Target要求和不必要的處理：

規則：分析事件

範例C：合併多個資料串流 uc5-example-c

如果您目前為Adobe Analytics和Adobe Target、Event Forwarding、Adobe Journey Optimizer和Customer Journey Analytics維護個別的資料串流，您可以合併成單一資料串流：

這樣可以減少資料串流管理負荷，並消除使用者端邏輯在資料串流之間選取的需求。

如需規則表格與規則順序基本原理的完整合併範例，請參閱端對端範例。

使用案例6：從Analytics來源聯結器遷移 uc6

目標：​將Adobe Analytics來源聯結器取代為Web SDK資料集合，同時保留提供的來源聯結器資料列層級篩選條件。

使用時機：​您正從Adobe Analytics來源聯結器移轉至Web SDK資料彙集，移轉至Adobe Experience Platform，並依賴來源聯結器來篩選設定檔收到的事件。

移轉方法 uc6-migration

請依序按照下列步驟操作。 步驟1和2是規劃您在接觸資料流前完成的步驟。

步驟1：您的來源聯結器篩選器的詳細目錄

記錄來源聯結器目前從擷取中排除的事件：

步驟2：將來源聯結器篩選器對應至規則

步驟3：建立您的資料集策略

根據您的保留要求，遵循使用案例1或使用案例2。

步驟4：設定規則

實施步驟2中對應的規則。 決定於分析性優先或可操作的優先模式。 優先處理影響最大數量事件的規則，並將所有其他事件保留為預設遞補。

步驟5：執行平行內嵌

在移轉期間，針對驗證視窗同時執行來源聯結器和Web SDK擷取。 比較：

驗證結果後，解除授權來源聯結器。

後續步驟