Twitch 客戶體驗監控升級：QoUX 之旅

作者介紹：我是 Chirag Sachdeva，我從航太工程師轉職為 Twitch 的會員團隊的軟體工程師。過去四年來，我有幸加入 Twitch 的大家庭，並參與了訂閱、贈禮、turbo 和創建者徽章等多項計畫。對我來說，客戶體驗一直是我最在乎的事情，也是我在 Twitch 工作的動力之一。

Live 實況的步調很快，使用者體驗品質直接影響觀眾續留和滿意度。我很高興能和大家分享 Twitch 如何透過使用者體驗品質 (QoUX) 改善監控能力。這項計畫讓我們能夠瞭解使用者行為，更快速、更輕鬆找出影響使用者的問題並迅速因應。

挑戰

儘管我們有強大的後台監控，但是我們仍然面臨一項嚴重的盲點：我們無法即時瞭解使用者在我們平台上的體驗。讓我用一個具體的例子來帶您瞭解這個問題。

假設您是 Twitch 觀眾，想要贈送多月份的 Twitch 訂閱給您最喜愛的實況主。您按下贈禮按鈕並選擇收禮對象，但在您選擇 3 個月的訂閱選項時，按鈕卻根本沒有反應。從您的角度來看，這個功能故障了；但從我們後台的角度來看，一切看起來都很正常。

我們之前進行贈禮測試的時候，當中確實就有少數使用者不小心停用了多月份選擇按鈕。我們的後台系統沒有顯示錯誤，因為從技術上來說，請求並沒有失敗：按鈕根本沒有發送請求。使用者裝置 (用戶端) 上的代碼讓互動根本無法傳到我們的伺服器。

傳統的伺服器端指標雖然很有價值，但無法告訴我們訂閱者是否在完成購買時遇到困難，或是特定地區的贈禮流程是否失敗。在使用 QoUX 之前，我們的監控和警報系統主要集中於後台服務和基礎設施，導致無法偵測這類用戶端故障。

您可能會想：為什麼我們一開始不就進行用戶端監控呢？因為這麼做的代價十分龐大：

1. **資料量。**用戶端監控產生的資料遠比後台監控多。由於有數百萬名使用者，每個人都進行數十次互動，遙測資料量很快就會變得難以負荷。
2. **隱私權考量。**為了尊重使用者隱私權並遵守法規，用戶端監控必須謹慎實施。
3. **可信度受挑戰。**後台系統在受控環境中運作，而用戶端監控必須存取無數可能干擾追蹤的裝置類型、瀏覽器、網路狀況和擴充功能。
4. **開發複雜性。**每項功能都需要額外程式碼，才能增加開發時間並降低錯誤風險，展現穩定的用戶端監控。
5. 監控複雜性：將原始事件轉化為可執行的分析並非易事。過程需要仔細彙整和轉換，避免誤判為正確或錯誤。

QoUX 的誕生，是為了在更貼近使用者與軟體互動的地方 (也就是用戶端) 進行監控並解決這些挑戰。這項計畫已成為 Twitch 營運能力的核心，讓我們能夠更深入瞭解使用者的行為，同時更容易發現影響到使用者的問題並縮短應變時間。

什麼是 QoUX？

使用者體驗品質 (QoUX) 是一個可配置的框架，旨在監控和分析用戶端的體驗。它建立在三個核心原則之上：

1. **用戶端優先。**監控使用者實際與 Twitch 互動的地方
2. **即時可見性。**即時分析使用者體驗
3. **可操作的指標。**資料能直接指導產品決策

用戶端事件如何運作

QoUX 的核心是用戶端事件，也就是直接從使用者裝置發出的專門遙測訊號。這些活動是：

• **由用戶端應用程式發出。**無論是 Twitch 網頁行動 App、行動 App，還是主機行動 App，用戶端代碼本身就會產生這些事件。
• **在重要的使用者互動期間觸發。**使用者執行特定操作 (例如點擊按鈕、嘗試購買或在頁面之間瀏覽) 時，事件就會被觸發。
• **豐富的情境資料。**每個事件都包含使用者的裝置、地區，以及使用特定元件或功能的詳細資訊。
• **專為降低效能影響而設計。**事件經過批次處理和壓縮，避免影響使用者體驗。

讓我帶您看一個實際的例子，說明實際的運作方式：

1. 來自用戶端的原始事件：使用者點擊多月份訂閱按鈕時，會觸發包含以下內容的事件：
   • 按鈕類型：「multi_month_selection」
   • Funnel ID：「gift_subscription_flow」
   • 事件類型：「click」
   • 用戶端資訊：瀏覽器/行動 App 版本、裝置類型
   • 地區：使用者的地理位置
   • 時間戳記：互動發生的時間
2. 轉換 + 彙整後：這些原始事件：
   • 已將資料串流至 Kinesis
   • 由 Lambda 函數處理，會篩選、轉換並加以彙整
   • 以 5 分鐘為間隔進行分組 (間隔根據該事件類型的正常數量而定)
   • 加上來自我們系統的額外情境
3. 最後顯示的內容：處理後的資料：
   • 發送到 CloudWatch 儀表板並設定警報
   • 針對這個特定的多月按鈕活動，如果有 5 個資料點低於閾值，或在過去 25 分鐘內沒有收到任何資料 (表示該按鈕沒有被點擊)，我們的待命工程師會接到通知

QoUX 背後的技術

QoUX 的監控功能核心是一個促進事件指標轉換、彙整和資料串流的框架。為什麼要建立自訂框架，而不只是將原始事件傳送給團隊？

QoUX 框架的優勢：

• **資料量管理。**原始用戶端活動累積的資料會使團隊不堪負荷。QoUX 能夠智慧彙整和篩選，提供有意義的訊號。
• 標準化。確保 Twitch 所有功能的活動結構和處理流程一致。
• **營運效率。**團隊不需要建立自己的處理管道或監控系統。
• **重視隱私權。**在框架層級適當處理 PII 和敏感資料。

事件會被發佈到 Kinesis Stream，然後由 Lambda 函數進行轉換、建模、篩選和聚合，最後作為自訂指標發佈到 CloudWatch。這個架構能結合活動資料，並依照團隊定義的方式製作成分鐘分佈圖，直接或透過嵌入式指標格式 (ENF) 壓縮資料並將資料寫入 CloudWatch 指標中，以獲取高基數紀錄。貢獻者分析。

即時監控和警報

CloudWatch 警報不僅僅是設置靜態閾值，而是透過以下方式接受訓練：

• 正常使用模式的歷史分析
• 考慮一天中的時間和一週中每天變化的自適應閾值
• 能偵測超出簡單閾值的異常情況的機器學習模型
• 進行相關分析減少誤報

這些指標包含：

• **元件供應狀況。**按地區劃分的元件層級可用性和延遲指標。
• **使用者操作。**來自使用者操作的資料，例如按鈕點擊、試圖結帳和贈禮活動。
• **失敗。**這些流程失敗所觸發的通知，包含具體的失敗原因。

實際影響

回到我們的多月份贈禮範例：我們在贈禮實驗中不小心停用部分使用者多月份選擇按鈕時，QoUX 在啟用後 25 分鐘內偵測到這個問題。在使用 QoUX 之前，我們只能在客戶回報後才發現這個問題，這可能需要數小時甚至數天，尤其是對於只有少數觀眾使用的功能。

自訂的 CloudWatch 警報監控錯誤率高峰、關鍵操作失敗和延遲問題，確保我們能比以往更快偵測到用戶端中斷或效能下降。

QoUX 使用案例

即時監控客戶體驗

QoUX 與 CloudWatch 的整合允許您即時監控訂閱、贈送訂閱和結帳等關鍵功能。透過追蹤這些元件的各區域可用性、延遲和故障事件，我們可以快速識別直接影響客戶體驗和收益的中斷和故障。這種方法導致我們偵測到多起因缺乏用戶端監控而未被注意的重大故障。

功能發布監控

QoUX 的一大亮點功能是能在功能推出時即時監控使用者互動。舉例來說，在最近一次修改關鍵使用者介面元素的功能推出期間，我們觀察到長期使用者的訂閱取消率出現意料之外的激增。多虧了 QoUX 的監控功能，我們在啟用後 10 分鐘內就發現了問題。我們修改了有問題的使用者介面元件的顯示狀況，快速調整使用者體驗，大幅降低對使用者續留的負面影響。這種快速分析和反應能力充分展現了 QoUX 系統的強大能力，即便是在主要功能推出期間，也能維持正面的使用者體驗。

透過 CloudWatch 異常偵測進行進階異常偵測

我們的異常偵測利用 CloudWatch Anomaly Detection，透過機器學習為使用者互動模式建立動態基準。以下是我們的實施方式：

• **建立基準。**我們設定要 CloudWatch 分析每個指標 2-4 週歷史資料，建立正常模式
• **調整閾值。**除了靜態閾值，我們使用 CloudWatch 的異常偵測範圍，自動根據一天中的時間和一週中的日期模式進行調整
• **情境式警示。**系統只要偵測到異常狀況，通知就會附上特定情境，像是發生錯誤的原因、受影響的區域及元件詳情

這種方法已被證明對於具有週期性模式或漸進趨勢的指標特別有效，因為傳統的靜態閾值會觸發誤報。

統一跨團隊監控和警報

QoUX 打破了傳統的孤立狀態，實現跨團隊的即時可見性，徹底改變了我們的組織監控能力。透過 CloudWatch 跨帳號觀察，我們打造的生態系統讓團隊可以獨立存取、分析共享指標，並設定通知，同時保持清楚的所有權界限。

舉例來說，訂閱流程中出現用戶端問題時，訂閱團隊和結帳團隊能立即取得相同的真相來源。團隊共享資訊，能加快協調速度，更有效因應事件，讓團隊能看到受到影響的元件並共同找出解決方案，不用再費力調整不同的監控系統。

統一的方法已讓我們的平均偵測時間減少約 40%，並改善事件期間的跨團隊合作，因為每個人都能取得相同的即時資料。

教訓和未來展望

透過 QoUX 實施用戶端監控，已經顯示出即時掌握使用者體驗的強大能力。透過監控使用者實際與您的應用程式互動的位置，您能立即獲得傳統後台監控可能完全遺漏的問題分析。

重點摘要

1. **從小規模做起，持續擴張。**先從最重要的使用者流程開始偵測，包含與收益或核心功能直接相關的使用者流程。在我們的情況下，訂閱和結帳流程是最適合的起點。
2. **選擇正確的指標。**重點放在能直接反映使用者成功或失敗的指標上，而不僅僅是技術表現。按鈕點擊、完成率和錯誤頻率通常比伺服器回應時間更能完整描述情況。
3. **有效利用 AWS 服務。**CloudWatch 異常偵測為動態通知提供了強大的基礎，不需要複雜的機器學習專業知識。資料串流用的 Kinsis、處理用的 LAY 和監控用的 CloudWatch 聯手出擊，打造靈活且可擴展的架構。
4. **在資料量與可操作性之間取得平衡。**用戶端監控產生的資料比伺服器端監控的資料多得多。策略性收集和彙整資料，以免讓您的系統和團隊不堪負荷。

開始執行您自己的 QoUX

1. **審核您目前的監控。**找出您現有監控策略中的不足之處，特別是在使用者介面和互動方面。
2. **監控關鍵使用者的旅程。**在您執行的關鍵路徑中新增用戶端事件發送，並將焦點放在：
   • 轉換漏斗
   • 驗證流程
   • 付款處理程序
   • 核心功能互動
3. **建立您的處理管道。**使用 Kinesis、Lambda 和 CloudWatch 等 AWS 服務來收集、處理和可視化您的用戶端事件。
4. **建立基準並設定通知。**收集 2-4 週的資料建立正常模式，然後再設定異常偵測通知。
5. **建立跨團隊可視性。**確保所有利害關係人都能存取相同的監控資料，以便在事件發生時改善合作。

透過執行您自己的 QoUX，您可以改變對使用者體驗的理解和因應方式，預先發現問題，避免影響您的事業，並為您的使用者創造一個更可靠的平台。