個性化服務是什麼？

下面例舉幾個典型的電商網站的個性化服務案例：

• 對於瀏覽過新品推薦的客戶，電商網站主動為此類客戶推薦一款新上市的商品
• 對於單筆訂單總金額達到1000，並且該訂單中包含化妝品的客戶，此使用者將被升級為金牌客戶，後續電商網站定期為金牌客戶推薦買一送一優惠促銷
• 對於完成註冊的新客戶，電商網站將推送優惠卷為新客戶
• 對於五月份生日的客戶，電商網站主動為客戶送出生日祝福廣告

根據這些典型的個性化服務案例，我們可以看出個性化服務是依據客戶屬性、行為等特徵，來識別目標客戶，進而向客戶提供、推薦相關的個性化資訊、服務，以滿足客戶的需求。從整體上說，個性化服務打破了傳統的被動服務模式，能夠充分利用客戶自身的資源，主動開展以滿足客戶個性化需求為目的的全方位服務。

實現個性化服務的步驟：

通過個性化服務案例，我們歸納出電商網站進行個性化服務實施所需要具備的兩個基本的步驟：

1. 識別目標客戶
2. 提供個性化服務

一個完整的服務場景是通過兩個串聯的步驟有序完成，首先電商網站動態的
收集客戶屬性、行為等特徵，將具有相同屬性或者特徵行為的客戶進行整理、分類、歸納到特定的目標客戶群，最終電商網站主動向目標客戶群提供個性化的服務。

那麼，基於Hybris電商平臺構建的電商網站，如何一步一步的提供個性化服務呢？近期，我們利用Hybris多個服務模組特點，成功的將個性化服務引入到某大型電商網站，並取得了很好的效果。下面，我們將為讀者分享這個實踐過程。

基於Hybris的個性化服務體系架構

對Hybris有使用經驗的讀者可能都知道Hybris提供個性化模組。但這個個性化模組是基於我們前面提到的第一步的結果來提供個性化服務。例如，當客戶A登入到系統中，而客戶A 已經被歸為化裝品產品系列的金牌客戶，個性化模組依據這個分類，按照事先定義好的金牌客戶的促銷手段去展示一個買一送一的商品。

那麼如何做到第一步，如何把客戶歸類就成為這個解決方案中很重要的一環。很自然想到的就是通過線下的方式，例如執行一個週期性的Job去掃描資料，來進行資料分析，提取客戶特徵，進而進行客戶的分類。這種依賴於整體資料掃描的辦法會有很大的計算量並且實時性比較差。我們希望在客戶購買了某個商品之後，購買額達到一定程度就立即將其歸為某一個特殊的客戶群並在客戶此次瀏覽網站的時候就會看到相應的內容。那麼，如何做到高效和實時呢？這就是我們要介紹的解決方案中的另一個關鍵模組 — 規則引擎模組。

在Hybris中，規則引擎模組主要是用於促銷的業務，所解決的問題是為讓電商網站中的所有客戶平等的獲得享受促銷的權利。換而言之，這是一種廣泛性的促銷應用。那麼，如何提供個性化的促銷服務呢？這就是我們在專案實踐中一個創造性的應用，即把規則引擎用於個性化的服務。

下面我們先從體系架構上把規則引擎模組和個性化服務模組如何整合在一起進行闡述，接下來會針對這兩個模組逐一細化具體使用的要點。

架構設計中考慮的問題

1. 模組之間整合

一個完整的個性化服務場景是通過兩個基本步驟有序串聯完成。因此，規則引擎與個性化模組需要有效的整合在一起，最終為電商網站提供一整套全方位的業務服務。為此，我們在架構體系中引入另外一個自定義模組，通過這個自定義模組有效的將規則引擎與個性化模組整合在一起，減少整合過程中出現業務，程式碼相互浸入的問題，保持模組的功能單一性原則。

2. 模組定製化

在選擇規則引擎模組後，我們丟擲了一種假設，是否需要定製化規則引擎模組？由於Hybris自身的實現機制，當前的規則引擎是服務於促銷的，也就是說規則引擎是通過Promotion Source Rule來驅動執行的。但是我們面對的業務是收集客戶的屬性與行為，顯而易見，業務的不同讓繼續使用Promotion Source Rule變得不合理。因此，建立新的Segment Source Rule不僅能夠滿足當前的業務需求，而且能夠與Promotion Source Rule進行隔離，避免交叉影響。

3. 可測性分析

能否快速進行功能性測試，以及程式碼單元測試是架構設計中需要考慮的一個問題。通過測試能夠衡量出模組之間是否存在著深度依賴，而導致區域性無法測試的問題。針對於當前的架構，規則引擎與個性化模組處於高聚合，低耦合模式，兩者能夠獨立執行，滿足功能可測性要求。

4. 資料儲存

通過自定義模組解決資料儲存問題，這部分資料在服務於不同的功能模組同時，又進行中心化儲存，便於資料維護工作。

5. 維護性與擴充套件性

規則引擎與個性化模組提供了友好的維護介面，業務人員可以通過後臺系統全方位的進行資料、功能的維護。與此同時，模組內部擴充套件性很高，易於新增新功能或修改現有功能。

體系架構

“UserToSegment”模組就是我們前面提到的自定義模組，“UserToSegment”模組不但能夠銜接兩個模組之間的功能性整合，同時也反應出資料層面上的整合。

個性化模組是通過不同資料模型間的關聯聯絡進行支撐，與資料整合相關的模型如下：

• Segment反映有共同偏好，喜好的客戶群
• UserToSegment 物件用於記錄User與Segment的關聯關係

通過資料模型，我們可以發現，個性化服務最終落實在客戶群(Segment)上，客戶群與客戶的對映關係被儲存在UserToSegment表中，而規則引擎所反映出的分配結果通過“UserToSegment”模組將兩者進行關聯，即建立或者修改一條客戶與客戶群關係的記錄。可見，規則引擎為個性化模組提供了必要的基礎資料準備。因此，無論是從功能角度，還是從資料角度，“UserToSegment”模組都是完成兩個模組整合的最佳切入點，同時這是一種是非侵入式的整合，意味著規則引擎與個性化模組仍然可以獨立執行。

到此，我們展現並闡述了個性化服務體系架構，以及明確了規則引擎與個性化模組在體系中各自功能職責，那麼這兩個模組應該如何具體利用呢？下面，將為讀者一一闡述。

基於Hybris規則引擎收集客戶屬性與行為，構建客戶群

收集客戶屬性、行為等特徵是開展個性化服務的依據，體現購物過程中的方方面面，具有動態性特點。通過屬性，行為可以衍生出複雜的業務條件用於構建客戶群，那麼，如何利用規則引擎呢？

首先，將收集客戶特徵行為所涉及的現實業務條件對映到規則引擎，通過規則引擎的規則條件進行描述。其次，將客戶整理，歸納到目標客戶群抽象為規則引擎的業務決策。

最終，通過不同的規則條件來驅動目標客戶的分類。

業務規則對映

1. 規則條件

基於客戶屬性，購物行為，產生不同的規則條件。比如：

• 客戶屬性（包括但不限於）
  生日，年齡，註冊時間、來源、狀態，常用支付方式。
• 購物行為（包括但不限於）
  購物車商品總數、是否包含特殊商品，訂單日期、數量、金額，下訂單頻率，瀏覽商品分類，訪問特殊頁面。

技術實現：Condition defines

2. 業務決策

當命中規則條件後，將客戶歸類到目標客戶群是期望的業務決策。

技術實現：Action define

利用Hybris 個性化模組提供個性化服務

Hybris個性化模組應用在CMS元件以及促銷上，並服務於目標客戶群。因此，將實際的個性化表現行為抽象為不同的CMS元件，或者促銷是利用個性化模組的基礎準備，最終藉助自動觸發機制向目標客戶群提供個性化服務。具體實現步驟如下：

1. 根據個性化表現行為抽象出CMS元件、促銷

• “新商品推薦“元件 – 該元件可以繫結任意一種商品，提供商品描述以及加入購物車功能
• “買一送一”個性化優惠促銷

2. 對映CMS元件、促銷等資源到個性化模組，用於配置管理

• CMS 元件- 技術實現：

• 促銷 - 技術實現：對於個性化促銷，只需要將一個普通的促銷標記為：“personalizatied”即可

到此，我們分別闡述瞭如何利用規則引擎與個性化模組來處理不同的業務需求。但是伴隨著研發週期的推進，新的個性化需求紛紛而至，那麼我們將如何應對這些新的挑戰呢？

業務延伸，伴隨而來的挑戰

在滿足個性化服務基本的需求後，隨著業務的延伸，勢必伴隨著新的挑戰。那麼，如何在當前的體系架構下來解決新的需求呢？下面，將通過若干例子來為讀者介紹。

1. 挑戰一：個性化的促銷提醒服務

藉助個性化模組，電商網站能夠針對目標客戶群釋出優惠促銷，那麼帶來的問題是：當釋出新優惠促銷或者更新已有的促銷規則後，如何快速地通知到客戶群裡的客戶呢？

解決方案：落實到促銷級別上。當促銷釋出後，通過擴充套件規則編譯監聽器的 ”afterComplie”方法能夠靈活的整合任何第三方系統（比如：郵件系統），向客戶群推送實時的訊息通知。

技術實現：Listener define

2. 挑戰二：個性化服務的動態失效機制

隨著業務的延伸，個性化服務需要提供服務的動態實效機制，當超過失效時間後，系統將自動收回該客戶的個性化服務。

解決方案：落實到個性化模組，通過擴充套件Segment模型，動態的為每個客戶計算失效時間，一但超過失效時間，系統將自動把客戶從客戶群中移除，從而達到服務失效的效果。

技術實現：在Segment模型建立“持續時間”屬性（單位：天）。失效邏輯：系統時間與客戶分配時間的天數差 大於 持續時間，則服務失效。

3. 挑戰三：個性化的促銷活動週期

相同的促銷，每一個客戶允許使用的時間是不同的。比如：客戶A在2月1日-3月15日內使用；客戶B在4月5日-5月12日內使用；那麼如何動態分配活動週期為每個客戶呢？

解決方案：利用Segment模型“持續時間”屬性（單位：天）來動態計算促銷活動週期。

技術實現：開始時間：客戶分配時間；結束時間：通過持續時間和客戶分配時間，推算出結束時間；

4. 挑戰四：離線分析與推薦

通過離線分析客戶最近數次購買記錄，將客戶分配到目標客戶群。在客戶下一次登陸電商網站的時候，就給出個性化的展示。

帶來的思考

本文基於Hybris電商平臺對個性化服務的實踐進行闡述，著重點在於如何利用Hybris電商平臺自身模組進行服務開發。但是，我們同樣能夠通過其他渠道來實現更加廣泛的個性化服務。比如，基於谷歌分析來採集客戶的購物行為。建立標籤庫，並結合個性化的推薦演算法使內容標籤化，使用者標籤化，最終通過這些標籤為客戶提供個性化資訊。豐富的個性化推薦演算法（比如：基於內容的推薦演算法，基於關聯規則的推薦演算法，協同過濾）以及大資料分析，AI的應用都能夠為個性化服務的實施提供強大的基礎保障。

結束語

隨著電商的不斷髮展，個性化服務顯得越來越重要，它能夠將網站的瀏覽者轉變為購物者，提高電商網站的的銷售能力，以及客戶的忠誠度。因此，個性化服務已成為推動電商發展的加速器。

作者簡介：楊智，現就職於奧博傑天軟體有限公司，擔任多個電子商務專案的解決方案架構師。曾擔任未來國際軟體股份有限公司多個專案的技術負責人，負責政府網站以及政務平臺設計，研發。參與國家林業局多個系統整合專案。關注電子商務應用，微服務架構以及DevOps。