網路上有數百篇關於分析客戶行為的好處的文章。 這通常涉及零售業。 從食品籃分析、ABC 和 XYZ 分析到保留行銷和個人優惠。 各種技術已經使用了幾十年，演算法已經被深思熟慮，程式碼已經編寫和調試——接受並使用它。 就我們而言，出現了一個根本問題——我們 ISPsystem 從事軟體開發，而不是零售。
我叫 Denis，目前負責 ISPsystem 的分析系統後端。 這是我和同事的故事 - 那些負責數據視覺化的人 - 試圖透過這些知識的棱鏡來看待我們的軟體產品。 像往常一樣，讓我們從歷史開始。
一開始有一個詞，這個詞是“我們要嘗試嗎？”
那時我在研發部門擔任開發人員。 這一切都始於丹尼爾讀到關於哈布雷的文章 — 用於分析應用程式中使用者轉換的工具。 我對在這裡使用它的想法有些懷疑。 作為範例，庫開發人員引用了對應用程式的分析，其中明確定義了目標操作 - 下訂單或如何向所有者公司付款的其他變更。 我們的產品是在現場供應的。 也就是說，用戶首先購買許可證，然後才開始他的應用程式之旅。 是的，我們有演示版本。 你可以嘗試那裡的產品，這樣你就不會陷入困境。
但我們的產品大部分都是針對託管市場的。 這些都是大客戶，業務開發部門就產品功能向他們提供建議。 它還表明，在購買時，我們的客戶已經知道我們的軟體將幫助他們解決哪些問題。 他們在應用程式中的路線必須與產品中嵌入的 CJM 一致，UX 解決方案將幫助他們保持在正軌上。 劇透：這並不總是發生。 圖書館的介紹被延後了……但時間不長。
隨著我們新創公司的發布，一切都改變了 - — 用於透過 Instagram 帳號建立線上商店的平台。 在此應用程式中，用戶有兩週的時間免費使用所有功能。 然後你必須決定是否訂閱。 這完全符合「路線-目標行動」的概念。 我們決定：我們來試試看吧！
第一個結果或從哪裡獲得想法
我和開發團隊在一天之內就將產品連接到了事件收集系統。 我馬上要說的是，ISPsystem 使用自己的系統來收集有關頁面訪問的事件，但沒有什麼可以阻止您使用 Yandex.Metrica 來實現相同的目的，它允許您免費下載原始資料。 研究了使用該庫的範例，經過一周的資料收集後，我們收到了一個轉換圖。
過渡圖。 基本功能，為了清晰起見刪除了其他轉換
結果就像例子中一樣：平面、清晰、美麗。 從這張圖中，我們能夠辨識出人們停留時間最長的最頻繁的路線和交叉口。 這讓我們明白了以下幾點：
- 大型 CJM 覆蓋了十幾個實體，而只有兩個實體被積極使用。 我們還需要使用使用者體驗解決方案將使用者引導到我們需要的地方。
- 有些頁面由使用者體驗設計師設計為端到端，最終導致人們在其上花費了不合理的時間。 您需要弄清楚特定頁面上的停止元素是什麼並進行調整。
- 經過 10 次轉換後，20% 的人開始感到疲倦並退出應用程式中的會話。 這考慮到我們的應用程式中有多達 5 個入門頁面！ 您需要識別使用者經常放棄會話的頁面並縮短到達這些頁面的路徑。 更好的是：識別任何常規路線並允許從來源頁面快速轉換到目標頁面。 您不認為這與 ABC 分析和廢棄購物車分析有一些共同點嗎？
在這裡，我們重新考慮了我們對該工具對於本地產品的適用性的態度。 決定分析一種活躍銷售和使用的產品 - 。 它要複雜得多，有更多數量級的實體。 我們興奮地等待著看看轉換圖會是什麼樣子。
關於失望和靈感
失望#1
27 月 XNUMX 日，是工作日的結束，也是月的結束，也是年的結束。 資料已積累，查詢已撰寫。 一切都處理完畢之前還剩幾秒鐘，我們可以查看我們的勞動結果，以找出下一個工作年度從哪裡開始。 研發部門、產品經理、使用者體驗設計師、團隊負責人、開發人員聚集在顯示器前，看看他們的產品中的使用者路徑是什麼樣的，但是...我們看到了這一點：
由 Retentioneering 庫建構的轉移圖
靈感#1
強連結、數十個實體、非顯而易見的場景。 很明顯，新的工作年不是從分析開始，而是從發明一種利用這種圖表簡化工作的方法開始。 但我無法擺脫這種感覺：一切都比看起來簡單得多。 經過十五分鐘研究 Retentioneering 原始碼後，我們能夠將建構的圖匯出為點格式。 這使得將圖表上傳到另一個工具 - Gephi 成為可能。 並且已經有分析圖表的範圍：佈局、過濾器、統計量——您所要做的就是在介面中配置必要的參數。 帶著這樣的想法，我們出發去參加新年週末。
失望#2
回到工作崗位後，發現大家都在休息的時候，我們的客戶卻在研究產品。 是的，太難了，以至於儲存中出現了以前不存在的事件。 這意味著需要更新查詢。
一些背景知識可以理解這個事實的悲傷。 我們傳輸我們標記的事件（例如，點擊某些按鈕）和使用者造訪的頁面的 URL。 就 Cartbee 而言，「一次操作 - 一頁」模式發揮了作用。 但對於 VMmanager，情況完全不同：可以在一頁上開啟多個模式視窗。 用戶可以在其中解決各種問題。 例如，網址：
/host/item/24/ip(modal:modal/host/item/ip/create)
表示使用者在「IP 位址」頁面新增了 IP 位址。 這裡同時出現兩個問題：
- URL 包含某種路徑參數 - 虛擬機器的 ID。 需要將其排除。
- URL 包含模式視窗 ID。 您需要以某種方式「解壓縮」此類 URL。
另一個問題是我們標記的事件都有參數。 例如，有五種不同的方式可以存取包含清單中虛擬機器資訊的頁面。 因此，發送了一個事件，但帶有一個指示用戶進行轉換的方法的參數。 這樣的事件很多，而且所有的參數都不同。 我們擁有 Clickhouse 的 SQL 方言中的所有資料檢索邏輯。 150-200 行的查詢開始變得司空見慣。 問題圍繞著我們。
靈感#2
一天清晨，丹尼爾悲傷地瀏覽了第二分鐘的請求，向我建議：“讓我們編寫數據處理管道嗎？” 我們思考了一下，決定如果我們要做的話，那就是 ETL 之類的東西。 這樣它就會立即過濾並從其他來源提取必要的數據。 這就是我們第一個具有成熟後端的分析服務的誕生。 它實現了資料處理的五個主要階段：
- 從原始資料儲存中卸載事件並準備進行處理。
- 澄清是對模態視窗的識別符、事件參數和其他澄清事件的細節的「解包」。
- 豐富（來自“致富”一詞）是指使用第三方來源的資料添加事件。 當時，這僅包括我們的計費系統BILLmanager。
- 過濾是過濾掉扭曲分析結果的事件（來自內部站、異常值等的事件）的過程。
- 將接收到的事件上傳到儲存中，我們稱之為乾淨資料。
現在可以透過新增處理事件甚至相似事件群組的規則來保持相關性。 例如，從那時起我們就再也沒有更新過URL解包。 儘管如此，在此期間添加了幾個新的 URL 變體。 它們遵守服務中已製定的規則並正確處理。
失望#3
一旦我們開始分析，我們就意識到為什麼圖表如此連貫。 事實上，幾乎每個 N 元語法都包含無法透過介面執行的轉換。
一項小型調查開始了。 我很困惑，一個實體內部不存在不可能的轉變。 這意味著這不是事件收集系統或我們的 ETL 服務中的錯誤。 有一種感覺，使用者同時在多個實體中工作，而無需從一個實體移動到另一個實體。 如何實現這項目標？ 在瀏覽器中使用不同的選項卡。
在分析 Cartbee 時，我們被它的特殊性所拯救。 該應用程式是在行動裝置上使用的，在行動裝置上使用多個選項卡非常不方便。 在這裡，我們有一個桌面，當在一個實體中執行任務時，希望花時間在另一個實體中設定或監視狀態是合理的。 為了不丟失進度，只需打開另一個選項卡即可。
靈感#3
前端開發的同事教了事件收集系統如何區分tab。 分析可以開始了。 我們開始了。 正如預期的那樣，CJM 與真實路徑不匹配：用戶在目錄頁面上花費了大量時間，在最意想不到的地方放棄了會話和選項卡。 透過轉換分析，我們能夠發現一些 Mozilla 建置中的問題。 其中，由於實作特性，導航元素消失或顯示半空頁面，這些頁面應該只有管理員才能存取。 頁面打開了，但後端沒有任何內容。 計算轉換使得評估實際使用了哪些功能成為可能。 這些鏈使得了解使用者如何收到這個或那個錯誤成為可能。 這些數據允許根據用戶行為進行測試。 這是成功的，這個想法沒有白費。
分析自動化
在其中一項結果示範中，我們展示如何使用 Gephi 進行圖形分析。 在此工具中，轉換資料可以顯示在表格中。 UX 部門負責人表示，一個非常重要的想法影響了公司整個行為分析方向的發展：“讓我們也這樣做，但是在 Tableau 中並帶有過濾器 - 會更方便。”
然後我想：為什麼不呢，Retentioneering 將所有資料儲存在 pandas.DataFrame 結構中。 總的來說，這是一張桌子。 這就是另一個服務的出現：Data Provider。 他不僅根據圖表製作了表格，還計算了該頁面及其相關功能的受歡迎程度、它如何影響用戶保留、用戶在該頁面上停留的時間以及用戶最常離開哪些頁面。 而且 Tableau 中視覺化的使用大大降低了研究圖形的成本，以至於產品中行為分析的迭代時間幾乎減半。
丹尼爾將討論如何使用這種視覺化以及它可以得出什麼結論。
給桌神多幾桌！
簡化後的任務是：在Tableau中顯示轉換圖，提供過濾功能，並盡可能清晰方便。
我其實不想在 Tableau 中繪製有向圖。 即使成功了，與 Gephi 相比，收益似乎並不明顯。 我們需要一些更簡單、更容易獲得的東西。 桌子！ 畢竟，圖形可以輕鬆地以表格行的形式表示，其中每一行都是「來源-目標」類型的邊緣。 此外，我們已經使用 Retentioneering 和 Data Provider 工具精心準備了這樣一個表格。 剩下要做的就是在 Tableau 中顯示表格並翻閱報表。
說到每個人都多麼喜歡桌子。
然而，這裡我們面臨另一個問題。 資料來源要做什麼？ 無法連接 pandas.DataFrame；Tableau 沒有這樣的連接器。 建立一個單獨的基礎來儲存圖表似乎是一個過於激進的解決方案，前景模糊。 由於需要持續的手動操作，本地卸載選項並不合適。 我們查看了可用連接器列表，然後我們的目光落在了該項目上 ，他絕望地蜷縮在最底層。
Tableau 擁有豐富的連接器選擇。 我們找到了一個可以解決我們問題的方法
什麼樣的動物？ 瀏覽器中開啟了一些新分頁 - 很明顯，該連接器允許您在存取 URL 時接收資料。 計算資料的後端本身已經準備就緒，剩下的就是與 WDC 成為朋友了。 Denis 花了幾天時間研究文件並與 Tableau 機制進行鬥爭，然後向我發送了一個鏈接，我將其貼到連接視窗中。
與我們的 WDC 的連接表。 丹尼斯挺身而出並注意安全
等待幾分鐘後（資料根據請求動態計算），表格出現：
這就是原始資料數組在 Tableau 介面中的樣子
如同所承諾的，這樣的表的每一行代表圖的一條邊，即使用者的定向轉移。 它還包含幾個附加特徵。 例如，唯一使用者數、轉換總數等。
可以按原樣在報告中顯示此表，慷慨地撒上過濾器並發送工具航行。 聽起來很合乎邏輯。 你能用桌子做什麼？ 但這不是我們的方式，因為我們製作的不僅僅是一張表格，而是一個分析和做出產品決策的工具。
通常，在分析數據時，人們希望獲得問題的答案。 偉大的。 讓我們從他們開始。
- 最頻繁的轉變是什麼？
- 他們從特定頁面去哪裡？
- 在離開之前，您平均在該頁面上花費多長時間？
- 您多久從 A 過渡到 B？
- 會話在哪些頁面結束？
每個報告或它們的組合應該允許用戶獨立地找到這些問題的答案。 這裡的關鍵策略是為您提供自己完成此操作的工具。 這對於減輕分析部門的負擔和減少決策時間都很有用 - 畢竟，您不再需要去 Youtrack 並為分析師創建任務，您只需打開報告即可。
我們得到了什麼？
人們最常在儀表板上的哪些地方產生分歧？
我們報告的片段。 在儀表板之後，每個人都會轉到虛擬機器列表或節點列表
讓我們使用一個包含轉換的通用表並按來源頁面進行過濾。 大多數情況下，它們會從儀表板轉到虛擬機器列表。 此外，規律性列表示這是一個重複動作。
它們從哪裡進入群集列表？
報告中的篩選器可以雙向工作：您可以找出您離開的位置或前往的位置
從範例中可以清楚地看出，即使存在兩個簡單的過濾器並按值對行進行排名也可以讓您快速獲取資訊。
讓我們問一些更困難的事情。
使用者最常在哪裡放棄會話？
VMmanager 使用者經常在單獨的選項卡中工作
為此，我們需要一份數據按推薦來源匯總的報告。 所謂的斷點被視為任務──充當轉換鏈末端的事件。
這裡要注意的是，這可以是會話結束，也可以是新分頁的開啟。 此範例表明，該鏈通常以包含虛擬機器清單的表結束。 在這種情況下，特徵行為是切換到另一個選項卡，這與預期模式一致。
當我們以類似的方式進行分析時，我們首先測試了這些報告對我們自己的有用性 ，我們的另一個產品。 隨著表格和濾鏡的出現，假設的測試速度更快，眼睛不再那麼疲勞。
在開發報告時，我們沒有忘記視覺設計。 當使用這種大小的桌子時，這是一個重要因素。 例如，我們使用了一系列平靜的顏色，易於感知 對於數字，線條的顏色會根據特徵的數值來突出顯示。 這些細節可以改善使用者體驗並增加該工具在公司內成功推廣的可能性。
該表相當龐大，但我們希望它仍然具有可讀性
值得一提的是我們內部客戶的培訓：產品專家和使用者體驗設計師。 專門為他們準備了包含分析範例和過濾器使用技巧的手冊。 我們將手冊連結直接插入到報告頁面中。
我們只是將手冊製作為 Google 文件中的簡報。 Tableau 工具可讓您直接在報表工作簿內顯示網頁。
而不是後面的
底線是什麼？ 我們能夠相對快速且便宜地獲得日常所需的工具。 是的，這絕對不能取代圖表本身、點擊熱圖或網路檢視器。 但此類報告極大地補充了列出的工具，並提供了深思熟慮以及新產品和介面假設。
這個故事只是 ISPsystem 分析開發的開始。 在過去的六個月裡，又出現了七項新服務，包括產品中用戶的數位肖像以及為相似定位創建資料庫的服務，但在接下來的幾集中將詳細介紹它們。
來源： www.habr.com