Show Menu
主題×

決策服務概觀

Decisioning Service 提供在Adobe Experience Platform上執行的應用程式中建立個人化、最佳化和協調的體驗的功能。 使用 Decisioning Service時,您可從一組可用 選項中 ,決定最佳選項。 這些選項(也稱為替代選項)可以是選件、產品建議、網頁體驗的內容元件、對話指令碼和要採取的動作。 目前支援選件決策的使用案例和 網域 ,其中決策選項會以選件為特定模型,並支援未來的更多使用案例。
有了這 Decisioning Service項功能,客戶就可以重複使用商業邏輯,並跨通道和應用程式共用一系列選項。 現在,不論客戶的使用者在何時、以何種方式和何種管道與企業或組織互動,都可以在應用程式中深入運用決策選項和選擇策略,而不需在應用程式中管理決策選項。
決策策略可以考慮客戶在許多通道和應用程式上的許多互動。 例如,客服中心應用程式活動可能會在投訴後啟用或隱藏一段時間的行銷訊息,而該訊息本身可能是根據客戶所進行的購買和張貼的審核。
Decisioning Service 促進體驗個人化的發展。
體驗決策之前
體驗決策後
在單一通道或少量的體驗觸點中個人化並最佳化其使用者體驗。
體驗是跨互動協調的回應。
最佳化主要針對單一且通常較短的使用者歷程階段
決策依據的是整個互動歷史,從過去偵測到的行為到最新的情境。
選項以及在客戶體驗期間選擇要呈現的策略通常會在應用程式中深入編碼。
選擇最佳選項的策略是在通道特定應用程式之外定義,並可重複使用。
客戶體驗是根據簡單化的目標進行個人化和最佳化的,例如增加網頁上的成功結帳次數或接受與代表互動時所呈現的優惠。
客戶體驗會根據對客戶目前需求的整體瞭解而最佳化,並適應使用者擁有的所有體驗(無論好壞)。 例如,行銷促銷活動可能不適用於最近提出產品或服務投訴的客戶。
Decisioning Service 將您的體驗個人化功能從單一通道鎖定到決定客戶與品牌互動生命週期中獨立於通道的整體階段。 生命週期階段比區段會籍複雜得多,而且幾乎總是以複雜事件串流、商業規則和預測屬性為基礎。
產品和服務為提供類似使用案例而使用的其他條款:
  • 即時互動管理(RTIM)
  • 歷程管理
  • 全方位通道行銷和個人化
  • 即時決策

如何運 Decisioning Service 作?

當客戶透過傳入通道( Decisioning Service 例如您的網站或行動應用程式)與您的品牌互動時,可即時自訂體驗。 決策也可用來透過對外通道自訂訊息,例如電子郵件或推播通知。
決策可以用很多方式做出。 一種方法是先後排除選項,直到僅剩一個或選項已縮減,且剩餘部分或從約簡集中隨機挑選成功者為止。 根據計算公式選擇成功選項的這種方法的變體。 合格選項的排名是使用函式來完成。 對於選件決策,該函式可計算成本、選件給企業的價值,並使用預先確定的選件被使用者接受的可能性。 產生的分數可用來排序選件。
或者,或者另外,戰略可以基於先前與建議類似選項的類似客戶進行互動時收集到的結果。 在該策略中,學習計算優先順序值的函式。 最佳結果值與活動目標掛鈎,預測的績效指標是在提出備選方案後取得結果的頻率。

決策策略

決策策略是透過稱為活動的物 件來設定 。 每個決策策略實質上是以N個選項{o1,o2,...oN}為輸入的算法或函式,並產生選項的有序清單(o1,o2,...oK),其中根據優化准則將清單中的第一個選項視為最佳選項,然後將結果清單中的第二個選項視為第二最佳選項等。
在客戶歷程中的任何指定時間,都會根據最新的上下文變數、規則和限制來重新評估指定活動的最佳選項。 上下文變數包含儲存在中的記錄 Real Time Customer Profile。 中央記錄實體是客戶的個人檔案,但其他實體(例如營運業務資料)對活動也同樣適用。
產生top-K選項清單的演算法或函式會隨使用案例而異。 該演算法的內部元件對於不同的使用案例不同。 這些元件在設計時在儲存庫中定義,並「編譯」為用例特定決策策略的說明。

使用 Decisioning Service

與其 Decisioning Service他服務一 Platform 樣,該服務採用API優先理念。 這表示API是主要介面,所有函式(包括管理函式)皆可透過API使用。 這也表示其他服 Platform 務、Adobe解決方案和第三方整合都使用相同的API。
您可以在 Decisioning Service 簡單的HTTP REST API所協助的同步請求——回應互動模式中使用。 API呼叫會傳回單一描述檔目前最佳的選項。 「目前最佳選項」選擇會根據特定活動所考慮的所有選項所套用的規則和限制而改變。 REST API可讓您一次取得多個活動的下一個最佳選項。 這允許跨通道仲裁選項。 當同時取得多個活動的回應時,可套用其他規則。

與其他工作流程 Platform 整合

使用是 Decisioning Service 可選的,除了建立和管理實體所需的典型步驟外,只需要 Profile 幾個步驟。
為了充份運用, Real-time Customer Profile此軟體直 Decisioning Service 接與描述檔存放區整合。 API呼叫只需要指定指定描述檔的其中一個身分。
一般的步驟順序是從建立描述檔開始:
  • 驗證 Experience Platform。
  • 根據描述檔類別定義方案,並可選擇根據體驗事件類別定義方案。
  • 設定資料集,將記錄和時間系列資料上傳至 Customer Profile。
  • 透過在前一步驟中設定的資料集新增資料,或透過管道串流例項資料。
  • 將體驗事件串流至 Platform ,以豐富行為資料的個人檔案。
此外,若要使 Decisioning Service用,請執行下列步驟:
  • 使用儲存庫API定義決策元件。 這些是構成決策策略的商業邏輯實體。 決策元件將自動編譯為由使用的格式 Decision Service Runtime。 資料庫API在下圖的左側顯示。
  • 呼叫執行階段API,以取得前一步驟所定義之商業邏輯的最佳選項。 API Decision Service Runtime 在下圖的右側說明。
商業邏輯實體的啟動會自動且持續進行。 一旦將新選項保存在儲存庫中並標籤為「已批准」,它將成為要包含在一組可用選項中的候選選項。 一旦更新決策規則,規則集就會重新組合併準備執行時期執行。 在此自動啟動步驟中,將評估由商業邏輯定義且不依賴執行時期內容的任何限制。 此啟動步驟的結果會傳送至快取,供執行階段使 Decisioning Service 用。 這在下圖中說明。
在選項集、規則集和限制被啟用並推送至節點後, Decisioning Service 會使用簡單API來張貼決策請求。 API通常由傳送服務呼叫,接著會採取建議的選項(例如下一個最佳動作或下一個最佳選件)並組合體驗或執行動作。 如果提案是選件,則會查閱代表該選件的內容,並將其插入傳送給使用者的體驗中。 這在下圖中說明。
Delivery Service 為決策請求收集資料。 它會決定決定最佳選項之描述檔實體的ID。 它也會組合任何未儲存在但可能被決策邏 Customer Profile 輯使用的上下文資料。
決策邏輯由活動組織,每個活動都為應該為此活動考慮的選項子集指定一個篩選器,以及一個備用選項。
每個決策是先套用限制以減少選項數目,然後對剩餘選項進行排名。 雖然大部分邏輯是在內部評估的, Decisioning Service但是使用各種附屬服務來協助這兩個方面。 例如,封頂服務管理選項在任何決策中使用頻率的上界,而另一服務則可托管用於計算設定檔和選項分數的機器學習模型。
若要進一步瞭解使用Repository API,請參閱使用API管理 決策實體和規則的教學課程
若要進一步瞭解如何使用執 Decisioning Service 行階段,請參閱「使用API 使用決策服務執行階段」教學課程