對我們來說，了解學生在培訓期間發生的情況以及這些事件如何影響結果非常重要，因此我們建立了客戶旅程地圖 - 客戶體驗地圖。 畢竟，學習過程不是連續的、完整的，而是學生的一系列相互關聯的事件和行動，這些行動在不同的學生之間可能有很大差異。 現在他已經完成了課程：下一步他要做什麼？ 它會去做作業嗎？ 它將推出行動應用程式嗎？ 他會改變路線，要求更換老師嗎？ 你會直接進入下一課嗎？ 還是他會失望地離開？ 透過分析這張地圖，是否有可能識別導致學生成功完成課程或相反導致學生「輟學」的模式？
通常，使用專門的、非常昂貴的閉源工具來建造 CJM。 但我們想提出一些簡單的東西，需要最少的努力，如果可能的話，開源。 因此，我們提出了使用馬可夫鏈的想法 - 我們成功了。 我們建立了一張地圖，以圖表的形式解釋了學生行為的數據，看到了全球商業問題完全不明顯的答案，甚至發現了隱藏得很深的錯誤。 我們使用開源 Python 腳本解決方案完成了這一切。 在這篇文章中我將討論兩個結果非常不明顯的案例，並將腳本分享給大家。
因此，馬可夫鏈顯示了事件之間轉換的機率。 這是維基百科的一個原始範例：
這裡「E」和「A」是事件，箭頭是它們之間的轉換（包括從事件到相同事件的轉換），箭頭的權重是轉換的機率（「加權有向圖」）。
你用了什麼？
此電路使用標準 Python 功能進行訓練，並提供學生活動日誌。 所得矩陣上的圖形由 NetworkX 函式庫建構。
日誌如下圖所示：
這是一個 csv 文件，包含一個三個清單：學生 ID、事件名稱、事件發生時間。 這三個欄位足以追蹤客戶的移動、建立地圖並最終獲得馬可夫鏈。
此函式庫以 .dot 或 .gexf 格式傳回建構的圖形。 為了視覺化前者，您可以使用免費的 Graphviz 套件（gvedit 工具），我們使用 .gexf 和 Gephi，也是免費的。
接下來我想舉兩個使用馬可夫鏈的例子，這讓我們能夠重新檢視我們的目標、教育過程和 Skyeng 生態系統本身。 嗯，修復 bug。
第一個案例：行動應用
首先，我們透過最受歡迎的產品——普通課程探索了學生的旅程。 當時，我在 Skyeng 的兒童部門工作，我們想看看行動應用程式如何有效地與我們的兒童受眾合作。
獲取日誌並通過腳本運行它們，我得到以下結果：
起始節點是“開始常規”，底部有三個輸出節點：學生“睡著了”、改變課程、完成課程。
- 睡著了，「睡著了」——這意味著他不再上課了，很可能他摔倒了。 我們樂觀地稱這種狀態為“睡眠”，因為… 理論上，他還有繼續學業的機會。 對我們來說最糟糕的結果。
- 放棄了將軍，改變了路線——從將軍轉向了其他東西，並迷失了我們的馬可夫鏈。
- 完成課程，完成課程 - 理想狀態，該人已完成 80% 的課程（並非所有課程都是必需的）。
進入成功上課節點，意味著與老師一起順利完成我們平台上的課程。 它記錄了課程的進度以及達到預期結果的方法——「完成課程」。 對我們來說，讓學生盡可能多地參加很重要。
為了獲得行動應用程式（應用程式會話節點）更準確的定量結論，我們為每個最終節點建立了單獨的鏈，然後逐對比較邊權重：
- 從應用程式會話返回它；
- 從應用程式會話到成功的課程；
- 從成功的課程到應用程式會話。
左邊是完成課程的學生，右邊是「睡著了」的學生
這三個邊緣顯示了學生的成功與他們對行動應用程式的使用之間的關係。 我們希望看到完成課程的學生比睡著的學生與應用程式有更強的聯繫。 然而，實際上我們得到了完全相反的結果：
- 我們確保不同的用戶群體與行動應用程式的互動方式不同；
- 成功的學生較少使用行動應用程式；
- 入睡的學生更積極地使用行動應用程式。
這意味著睡著的學生開始在行動應用程式中花費越來越多的時間，並最終永遠留在其中。
起初我們很驚訝，但仔細想想，我們意識到這是一個完全自然的效果。 曾經，我使用兩種工具自學法語：行動應用程式和 YouTube 上的語法講座。 一開始我是按照50比50的比例來劃分時間的。但是應用比較好玩，有遊戲化，一切都很簡單，快速，清晰，但是在講課中你必須深入研究，寫一些東西，在筆記本上練習。 漸漸地，我開始花更多的時間在智慧型手機上，直到它的份額增長到100%：如果你在上面花費三個小時，你就會產生一種完成工作的錯覺，因此你不想去聽任何東西。
但這怎麼可能呢？ 畢竟我們專門創建了一個行動應用程序， ，將其遊戲化，使其具有吸引力，以便人們願意花時間在其中，但事實證明這只會分散他們的注意力？ 事實上，原因是行動應用程式團隊處理得太好了，結果它變成了一個很酷的、自給自足的產品，並開始脫離我們的生態系統。
研究結果表明，行動應用程式需要以某種方式進行更改，以減少對主要學習課程的干擾。 而且無論是兒童還是成人。 這項工作目前正在進行中。
第二種情況：引導錯誤
入職培訓是註冊新生時的一個可選附加程序，可消除未來潛在的技術問題。 基本場景假設一個人已經在登陸頁面上註冊，獲得了對其個人帳戶的訪問權限，被聯繫並接受了介紹性課程。 同時，我們在入門課程中註意到很大一部分技術困難：瀏覽器版本錯誤、麥克風或聲音不起作用、老師無法立即提出解決方案，而這一切在真正發生時尤其困難給孩子們。 因此，我們在您的個人帳戶中開發了一個額外的應用程序，您可以在其中完成四個簡單的步驟：檢查您的瀏覽器、攝影機、麥克風並確認家長在入門課程期間會在附近（畢竟，他們是支付費用的人）孩子的教育）。
這幾個入門頁面顯示了這樣的漏斗：
1：起始區塊有三個略有不同（取決於客戶端）的登入和密碼輸入表單。
2：同意附加入職程序的複選框。
2.1-2.3：檢查家長是否存在、Chrome 版本和聲音。
3：最後一塊。
看起來很自然：在前兩步中，大多數訪客離開，意識到有一些東西需要填寫、檢查，但沒有時間。 如果客戶已經到達了第三步，那麼他幾乎肯定會到達最後一步。 沒有任何理由懷疑漏斗上的任何內容。
儘管如此，我們決定不使用經典的一維漏斗來分析我們的入職，而是使用馬可夫鏈。 我們打開了更多事件，運行腳本並獲得：
在這片混亂中，只有一件事可以清楚地明白：出了問題。 入職過程是線性的，這是設計中固有的，其中不應該有這樣的連接網絡。 在這裡，很明顯地用戶被拋出到步驟之間，而這些步驟之間根本不應該有任何轉換。
出現這個奇怪的畫面可能有兩個原因：
- 淺灘潛入日誌資料庫；
- 產品本身就存在錯誤－入職。
第一個原因很可能是正確的，但測試它是相當耗費人力的，更正日誌無助於改善使用者體驗。 但對於第二個，如果存在的話，就必須緊急採取行動。 因此，我們去查看節點，找出不應該存在的邊，尋找它們出現的原因。 我們看到有的用戶被卡住了，繞圈子走，有的用戶從中間掉到了開頭，還有的用戶原則上走不出前兩步。 我們將數據傳輸給品質檢查 - 是的，事實證明，入職過程中存在足夠多的錯誤：這是一個副產品，有點拐杖，它沒有經過足夠深入的測試，因為... 我們沒想到會出現任何問題。 現在整個錄音過程已經改變了。
這個故事向我們展示了馬可夫鏈在 QA 領域的一個意想不到的應用。
自己嘗試一下吧！
我發布了我的 在公共領域 - 為了您的健康而使用它。 文件在GitHub上，有問題可以在這裡提問，我會盡力回答一切。
嗯，有用的連結： , 。 和這裡 關於馬可夫鏈。 文章中的圖表是使用 .
來源： www.habr.com