WiDS Taipei 2020 | 當客服比你更懂你：用資料科學優化客戶體驗 — 陳冠穎 Amber

講者介紹 — 陳冠穎（Amber Chen）
📍現任國泰金控數位數據暨科技發展中心（數數發中心）資料科學實驗室的資料科學分析師，參與大數據信評、客戶進線預測、國泰優惠社群網絡分析等多個國泰內部專案。擅長運用 Spark 與 Neo4j 等技術進行資料前處理、圖學運算與特徵工程，對於資料科學與資料工程的領域充滿熱忱。
📍講者簡介影片：https://www.facebook.com/watch/?v=203259057659630

在金融業、銀行服務業中，每天都會遇到客戶因為不熟悉銀行業務的專業詞彙，而造成名詞誤用、或是很難描述清楚自己的問題，讓銀行客服很想大聲說一句：「你怎麼連話都說不清楚！」然而從客戶的角度來看，金融產品、信用卡類型何其多，通常都是在充滿困惑與挫折的情況下才會撥打客服電話，希望客服人員能更讀懂自己的心。

為了解決客戶與客服的溝通問題，第一步是先去了解「客服樣貌」並進行分析，包含：

1. 什麼人會打客服電話：客戶進線特徵尋找、年齡分佈、教育程度
2. 客戶進線時段分析：每個小時進線客戶樣貌
3. 客戶再次來電分析：客戶首次來電 vs 再次來電

為了要能夠回答這些問題，我們有一整個完整的資料科學專案、產品、系統迭代流程，整個迴圈與迭代的歷程如下，今天會用「客服進線問題預測」的案例來與大家分享這個流程的執行實務。

▍步驟一：定義問題

在客戶進線時，客服可以看到一個「客戶視圖」的介面，包含客戶基本資料（年紀、性別）、持有哪些金融商品、過去跟國泰有哪些互動行為，來了解客戶基本屬性，捕捉客戶歷程行為。

而我們希望這個介面上也可以有「預測問題」的版位，顯示系統預測三項這個進線客戶可能會提及的主題。畢竟客戶連話都說不清楚，我們希望可以協助客服更快掌握客戶現階段面臨到的問題，這樣客服人員就能在第一時間查找資料、回覆給客戶。

如何預測客戶進線的問題？

第一個直覺的做法是去觀察客戶在進線前所做的行為。每個客戶在進線前，都會有一筆跟國泰相關的接觸事件，中間歷時長短從一天到幾十天內都有可能。

舉例來說，客戶詢問客服有關消費明細的問題，他在進線前的最後一個事件可能是跟我們信用卡授權的通路有接觸，進線與最終事件發生的時間在一天之內。

接下來我們可以從自身經驗出發，設身處地設想當自己是客戶（使用者）時，整個客戶歷程會是什麼樣子。客戶不會無緣無故進線，一定是前面的客戶歷程中遭遇到困難，才會造成客戶想要打電話尋求客服幫助！

這時候就可以將前面的問題定義得更清楚：根據客戶進線前的行為，預測其可能的進線問題。

▍步驟二：數據整理 → 轉換數據

問題：根據客戶進線前的行為，預測其可能的進線問題。

國泰金控提供了非常多的服務，有很多子公司、很多通路，例如人壽、銀行、證券、產險，光是銀行前端接觸點也有好幾種，例如櫃檯、ATM等等，因此為了要能夠好好的說明客戶歷程並記錄資料，我們需要一個統一的規格，來描述每個使用者、在每個產品接觸的管道、所發生的每個行為。

這個統一規格包含了人、事（動作）、時、地（通路）、物（產品）以及其他屬性。

透過這個方式，我們可以整理出一個「客戶歷程資料庫」，亦即哪個用戶在什麼時間什麼通路用什麼產品做了什麼事情。上述這些都是已知且可以整理出來的，所以我們個慣用手法就是用這些資料來建立歷程彙總性變數。

除此之外，我們還希望可以結合客戶的序列行為。下圖為某一個客戶的歷程資料，我們會看時間的先後順序，從最早的事件看到最近期的事件，並把每個事件定義成 unique ID（Word 1 → Word n），希望以自然語言（NLP）的方式，解讀客戶的序列行為。

在 NLP 中，通常最小的分析顆粒度是 word，在閱讀英文時可以很簡單的用「空白格」去斷字；然而在分析客戶的行為序列時，要如何定義 word 的概念呢？

我們首先訪談了業務單位，了解他們的痛點、在意的資訊，接著做統計、歸納跟分析。

舉例來說，我們拿一個月國泰授權行為的資料，全行 460 萬個信用卡戶共有兩億多筆原始資料，從這麼大量的資料中很難看到共通性。

這時候我們想做的是類似文字探勘（text mining）中的字根還原， 類似將 ing、ed、s 結尾的字做字根還原，套用到信用卡行為的場域中，我們想要找出共通性。

消費者實際消費多少錢的數字本身並不重要，重要的是是正數還是負數（收款、匯款）、奇特的一元消費還是大金額、台幣還是非台幣（而不需要仔細區分每種幣別）、是不是在台灣商家做消費…等等分類與資料清整。

透過字根還原的概念來進行行為顆粒度的調整，將兩億筆原始資料，轉化為兩萬筆的行為種類，方便我們比對出人跟人之間的的共通性。

▍步驟三：數據實驗 → 訓練模型

有了序列行為特徵、彙總性變數特徵以及 NLP 模型後，那資料集呢？

我們可以先把問題定義為 Multi-Class Classification 的分類預測問題，從實務上會遇到的情境來作為發想的切入點。

國泰常見的業務場景包含一次性的行銷活動的名單預測、月執行預測（如興趣資料、信用風險等級），實作方式是例行性的進行每日、每月的排程（cron jobs）。

回到主問題，我們想要知道的到底是…

• 預測客戶的進線問題？
• 預測客戶某時間下的進線問題？

如果我們想深入了解的是「預測客戶某時間下的進線問題」，那意思是…

• 預測客戶 這個月的進線問題？
• 預測客戶 今天的進線問題？
• 預測客戶 當下的進線問題？

構建訓練資料集、預測資料集前，需要先思考上線後的預測頻率。可以從以下幾個方向來思考：

【方法一】將 2019 年 12 月客戶的進線問題當作 label、這些客戶在 2019 年 11 月的行為當作特徵變數（Feature）。

【方法二】如果覺得上述一個月的資料太狹隘，我們若認為每個月的進線問題會不太一樣，則可以取六個月的資料，將這些客戶這六個月的進線問題當作 label、其前一個月的行為當作特徵變數。

【方法三】再更進階一點，我們想要更細的顆粒度，因此不再用「客戶」作為 label，而是以近半年的「進線通話」作為 label、以進線這個月/上個月的資料作為特徵變數的來源。

舉例來說，我們以 2019/07/15 為例，每分每秒都會有人進線，我們希望拿到他進線的時、分、秒作為 label，並取這個時、分、秒以前的所有行為當作他的特徵，希望創造出來的 label 跟 feature 是完全沒有時間延遲性的。

我們想要知道的是，客戶在進線前到底做了什麼行為，導致他想要尋求客服支援。

▍步驟四：部署上線 → 監控與優化

將上述的預測模型上線後，客服人員就可以在後台介面的客戶視圖上看到我們預測的問題了。然而上線後，我們發現在使用這個後台系統的團隊成員們還是遇到了很多痛點。

客服人員的痛點：

• 客戶的行為事件沒有即時被更新
• 客戶同一天反覆進線，但當天後台預測的問題卻每次都一樣
• 這些預測問題的排序，是否是按照重要性與預測準確度排序

開發維運人員的痛點：

• 日平均進線量約 2 萬通、每天針對全行約 460 萬信用卡戶做預測（因為只能做到每日批次預測）
• 運算耗時，資源吃緊（有些客戶沒進線，我們卻還要花資源在他身上）

分析人員的痛點：

• 如同前面提到，在分析月、日、當下的選項中，我們當然是想要預測「當下」的進線問題，但很可惜用一般的排程工作（cron jobs）辦不到！

因為以上痛點，我們想要持續優化進線問題專案，希望透過串流處理搭配即時預測來分析資料，而不是每月、每日預測。

過去習慣拿批次資料，現在希望可以拿到即時資料；過去習慣用批次預測，現在希望可以即時預測的框架，希望將模型與預測的服務變成類似 API 的形式，針對每一筆的進線通話進行預測，透過改變根本架構來優化客戶與客服的體驗。

現行架構（優化前）

當客戶還沒進線時，灰底的部分都已經預先準備好了，批次預測程序會讀取模型資料，存取資料倉儲中之前有 latency 的資料，預測全部 460 萬個用戶今天分別最有可能問的三個問題後，再存到資料庫裡面。

當客戶進線後，客服人員可以看到後台的客戶視圖，前端才會去撈資料庫中的資料，呈現這個客戶今天最有可能問的三個問題。

因為這個預測是以「日」為單位，因此就算這個客戶今天進線了十次、客戶的支援有所進展、或遇到新的問題，客服人員看到的三個問題都還是相同的內容，因為都是去撈同一個資料庫。

概念性驗證（優化後）

上述批次資料搭配批次日預測並沒有辦法完全解決客服人員的痛點，因此我們想要將整個架構與流程優化為串流事件搭配即時預測的處理。

下方灰色的部分的三個黑色箭頭是不斷在發生的，客戶發生的新事件與狀態都會不斷的被蒐集、處理與儲存，而我們背後有一個 Model API。

與原先概念不同的是，當客戶進線、客服打開後台，這時候才去觸發背後的 Model API 開始工作，在進線當下才開始預測，因此就可以去撈他最近幾十筆的行為去預測，而不受限於天數的框架，且當客戶掛電話後，這個行為也會被記錄下來。

模型服務化（Model Serving）

在做類似於上述案例即時預測的模型服務化時，因為是個資料工程的大改變，需要考慮以下幾點：

1. 可服務化的模型格式
2. Model API
3. Model Server 容器化
4. 模型更版的彈性

資料工程結構的改變

這整個優化過程中，並沒有改變演算法與超參數，而是整個資料工程結構的改變，實現串流資料處理與儲存的完整架構，以模型服務化實現即時預測。而這個改變在單日命中的電話人數、單日命中的客戶人數、前三個問題的排序能力（MAP@1）上都有顯著的提升，這三個方面的成長率均超過 10%。

▍用資料科學優化客戶體驗

我們的中心思想是用資料科學的方法來優化客戶體驗、提升營運績效，上述的案例只是一小部分，而且要透過持續的迭代與優化才能達成。

機器學習是資料科學的核心之一，但是很小一小塊，外圍還有很多很重要的技術與基礎設施，例如資料蒐集、特徵抽取與整理、模型如何在 production 執行的架構等等，因此我們不能只在意 ML code 這個中心點，如果遺漏了某一塊，可能就會在不知不覺中留下技術債。

資料分析與資料工程不是非黑即白，而是一個光譜，包含學術研究、商業洞察、模型應用、資料 ETL、基礎工程，選定一個方向之後，可以慢慢探索自己喜歡與擅長的部分。希望大家都能在這之中找到自己適合前進的方向！

[數數發人才招募中] #跨界金融業最快捷徑
你是大數據、資料科學高手，有一身好本領卻苦無發揮舞台？你是職場新鮮人或想要轉戰金融業，想到重重關卡就頭皮發麻？有滿腹 good idea，公司卻沒有資源可以支援？
只要你是大數據、資料科學專才，對金融科技充滿熱情、想與技藝高超的團隊一起工作，立即報名就有機會參加 #國泰金控數數發數據菁英招募會，4/18(六)將進行初選線上面試、當日獲知是否進入決選名單，加入國泰數數發，就趁現在！
趕快來看職缺介紹跟同仁現身說法：https://lihi1.cc/Svc9c
#國泰金控 #數數發 #DDT #新人類徵才

想更深入了解 WiDS Taipei Conference 2020 的活動內容嗎？歡迎到此連結索取當天活動的 12 份完整簡報檔！

更多 WiDS Taipei 2020 精彩演說紀錄，回索引文：

WiDS Taipei 2020 資料科學 x 行銷科技應用研討會- 官方筆記手 12 篇筆記精華彙總！