Twitchでのカスタマーエクスペリエンスモニタリングの向上：QoUXの旅

執筆者について: Twitchのメンバーシップチームでソフトウェアエンジニアを担当しているCherag Sachdvaです。以前は航空宇宙学の技術者をしていました。この4年間、Twitchファミリーの一員として、サブスクやギフト、Turbo、ファウンダーバッジなどの取り組みを担当してきました。私にとって、顧客体験は常に最優先事項であり、Twitchでの仕事の原動力の一つです。

ハイペースなライブ配信の世界では、ユーザー体験の質が視聴者の維持や満足度に直接影響を与えます。Twitchがユーザー体験の質(QoUX)という取り組みを通じて監視機能をどのような変更を行ったかを共有させていただきます。この取り組みにより、ユーザーの行動を理解し、ユーザーに影響を与える問題をより迅速かつ少ない労力で発見し、迅速に対応することが可能になりました。

チャレンジ

バックエンドのモニタリングは充実していますが、ユーザーが私たちのプラットフォームをリアルタイムでどのように体験しているかを正確に理解しにくいという重要な盲点がありました。この問題を説明するための具体的な例を挙げさせていただきます。

あなたがTwitchの視聴者で、お気に入りのストリーマーに複数月分のサブスクを贈りたい場合を想像してください。ギフトボタンをクリックし、受取人を選択しますが、3か月のサブスクオプションを選択しようとすると、ボタンが反応しません。皆さんから見ると、この機能は機能が足りないと感じるかもしれませんが、私たちのバックエンド側から見ると、すべて正常に見えています。

まったく同じ状況が、ギフトのテスト開始時に、一部のユーザーが複数月の選択ボタンを誤って無効化したときに発生していました。バックエンドシステムにはエラー表示は行われていません。技術的にはリクエストが失敗していなかったためです。単にボタンがリクエストを送信していなかったのです。ユーザーのデバイス(クライアント)のコードが原因となって、インタラクションがサーバーに到達することを妨げていました。

従来のサーバーサイドのメトリクスは、価値がある一方で、サブスクライバーが購入を完了するのに苦労しているかどうかや、特定の地域でギフトのフローが失敗しているかどうかを教えてくれませんでした。QoUX以前は、Twitchの監視およびアラートシステムは、主にバックエンドのサービスやインフラストラクチャに焦点を当てており、こうしたクライアントサイドの障害を検出するにはギャップがありました。

「なぜ最初からクライアント側の監視を行わなかったのでしょうか？」と疑問に思われるかもしれません。トレードオフが大きいためです。

**データ量。**クライアント側の監視はバックエンドの監視よりもはるかに多くのデータが生成されます。数百万人のユーザーがそれぞれ数十回のインタラクションを行うと、テレメトリの量がすぐに圧倒的になる可能性があります。
**プライバシーの懸念。**クライアント側の監視を行うには、ユーザーのプライバシーを尊重し、規制を遵守するために慎重に実装する必要があります。
**信頼性の課題。**バックエンドシステムは管理された環境で動作しますが、クライアントの監視は無数のデバイスの種類、ブラウザ、ネットワーク状況、トラッキングを妨げる可能性のある拡張機能にわたって機能する必要があります。
**開発の複雑さ。**クライアント側で強力な監視を実装するには、各機能に追加のコードが必要となり、開発時間が増加し、バグの可能性も高まります。
監視の複雑さ : 生のイベントを実行可能に移せるインサイトに変換するのは簡単なことではありません。誤検知と見逃しの両方を避けるために、慎重に集計および変換する必要があります。

QoUXは、これらの課題に対処しながら、ユーザーがソフトウェアを操作する場所に近い状況、つまりクライアントサイドでソフトウェアを監視する必要性から生まれました。この取り組みはTwitchの運営機能の核となる部分となっており、ユーザーの行動をよりよく理解できるようになった一方で、ユーザーに影響を与える問題をより簡単に特定できるようになり、対応時間の短縮につながりました。

QoUXとは

ユーザー体験の質 (QoUX) は、クライアント側の体験を監視および分析するために設計された設定可能なフレームワークです。以下の3つの基本原則に基づいています。

**クライアントサイド第一。**ユーザーが実際にTwitchとどのようにインタラクトするかを監視します。
**リアルタイムでの可視性。**ユーザー体験に関する即時のインサイト
**実行可能なメトリクス。**製品の意思決定に直接情報を提供するデータ

クライアントサイドイベントの動作

QoUXの中心にあるのはクライアント側のイベントで、ユーザーのデバイスから直接発信される特殊なテレメトリ信号です。イベントの詳細は次のとおりです。

**クライアントアプリケーションによって発行。**Twitchウェブアプリ、モバイルアプリ、コンソールモバイルアプリのいずれでも、クライアントコード自体がこれらのイベントを生成します。
**主要なユーザーインタラクション時にトリガー。**ユーザーがボタンをクリックしたり、購入を試みたり、ページを移動するなどの特定のアクションを行うと、イベントが発生します。
**コンテキストデータによる強化。**各イベントには、ユーザーのデバイス、地域、および使用されている特定のコンポーネントや機能に関する詳細が含まれています。
**パフォーマンスへの影響を最小限に抑えるように設計。**ユーザー体験への影響を避けるために、イベントはバッチ処理および圧縮されます。

実際の例を見てみましょう。

クライアントからの生イベント: ユーザーが複数月分のサブスクボタンをクリックすると、以下を含むイベントが発生します。
- Button type: “multi_month_selection”
- Funnel ID: “gift_subscription_flow”
- Event type: “click”
- Client information: ブラウザ/アプリのバージョン、デバイスの種類
- Region: ユーザーの地域
- Timestamp: インタラクションの発生日時
変換＋集計後：生イベントは次のように処理されます。
- Kinesisに配信されます
- フィルタリング、変換、集計を行うLambda関数によって処理されます
- 5分ごとにグループ化(間隔は、そのイベントの通常の音量に応じて異なります)
- システムから追加コンテキストが提供されます
最後に表示される内容: 処理されたデータ:
- アラーム設定がされた状態でCloudWatchダッシュボードに送信されます
- この特定の複数月にわたるボタンイベントでは、5つのデータポイントがしきい値を下回るか、過去25分間にデータポイントが受信されない（つまり、そのボタンがクリックされない）場合、オンコールのエンジニアに通知が送信されます。

QoUXを支える技術

QoUXの監視機能の中心にあるのは、イベントメトリクスの変換、集計、ストリーミングを容易にするフレームワークです。しかし、なぜチームに生のイベントを送信するのではなく、カスタムフレームワークを構築するのでしょうか？

QoUXフレームワークの利点:

**データ量の管理。**生のクライアントイベントは、ペタバイト単位のデータでチームを圧倒することになります。QoUXはインテリジェントに集計およびフィルタリングを行い、意味のあるシグナルを提供します。
標準化。Twitchのすべての機能において、イベントの構造と処理を一貫して行うことを保証します。
**運用効率。**チームは独自の処理パイプラインや監視システムを構築する必要はありません。
**プライバシーを想定したデザイン。**PIIや機密データをフレームワークレベルで適切に取り扱います。

イベントはKinesis Streamに投稿され、Lambda関数によって変換、モデル化、フィルタリング、集計されてから、CloudWatchにカスタムメトリクスとして公開されます。このフレームワークは、イベントデータをチームが定義したディメンションで分単位の分布に組み合わせ、圧縮してCloudWatchメトリクスに直接書き込んだり、高カーディナリティログ用の埋め込みメトリクスフォーマット（EMF）を使用して書き込んだりすることで、Log Insightsによる追加分析とContributor InsightsによるトップNのサマリーが可能になります。

リアルタイム監視とアラート

CloudWatchのアラームは、単に静的なしきい値で設定されているわけではありません。以下のようにトレーニングされています:

通常使用パターンの履歴分析
時間帯や曜日の変動を考慮した適応型しきい値
単純なしきい値の違反を超えて異常を検出する機械学習モデル
誤検出を減らすための相関分析

これらのメトリクスには以下が含まれます：

**コンポーネントの可用性。**コンポーネントレベルの利用可能時間と遅延のメトリクス。地域ごとにセグメント化されます。
**ユーザーアクション。**ボタンのクリック、チェックアウトの試行、ギフトなどのユーザーアクションからのデータ。
**失敗。**これらのフローの失敗によってトリガーされるアラート、特定の失敗理由を含みます。

実際の影響

複数月分のギフトの例に戻りましょう。ギフトの実験を開始した際に、一部のユーザーで複数月選択ボタンが誤って無効化されましたが、QoUXは導入後25分以内にその問題を検出しました。QoUX以前は、顧客から報告を受けて初めてこの問題を発見することができました。特に、視聴者の中でもごく一部でしか使用されない機能に関しては、発見までに数時間、場合によっては数日かかることもありました。

カスタムCloudWatchアラームは、エラー率の急増、重要なアクションの失敗、遅延の問題を監視し、クライアント側の障害やパフォーマンスの低下をこれまで以上に迅速に検出できるようにします。

QoUXのユースケース

カスタマーエクスペリエンスのリアルタイムモニタリング

QoUXのCloudWatchとの統合により、サブスクリプション、サブスクギフト、チェックアウトなどの重要な機能をリアルタイムで監視することができます。これらのコンポーネントの地域別の可用性、遅延、障害イベントを追跡することで、顧客体験や収益に直接影響を与える障害や停止を迅速に特定することができます。このアプローチにより、クライアント側の監視がなかったために以前は見逃されていた重大な障害が検出されるようになりました。

機能のローンチを監視

QoUXの際立った機能の一つに、機能のリリース時にユーザーとのインタラクションをリアルタイムで監視する能力があります。たとえば、最近の機能のリリースで主要なユーザーインターフェース要素が変更された際に、長期利用者の間で予期しないサブスクのキャンセルが急増したことが確認できました。QoUXの監視機能のおかげで、この問題は発生から10分以内に特定されました。問題となっていたUI要素の可視性を変更することで、ユーザー体験を迅速に調整し、ユーザー維持への悪影響を大幅に軽減することができました。この迅速なインサイトと対応能力は、大規模な機能の展開中であっても、ポジティブなユーザー体験を維持する当社のQoUXシステムの力を示しています。

CloudWatch異常検知を用いた高度な異常検出

Twitchの異常検出は、機械学習を使用してユーザーのインタラクションパターンの動的ベースラインを確立する、CloudWatch異常検知を使用しています。以下のように実装を行っています:

**ベースラインを作成。**各メトリクスの2～4週間の履歴データを分析し、正常なパターンを確立するようにCloudWatchを設定します
**適応型しきい値。**静的なしきい値に加えて、CloudWatchの異常検出バンドを使用し、時間帯や曜日のパターンに自動的に調整します。
**状況に応じたアラート。**異常が検出された場合、アラートには障害の理由、影響を受ける地域、コンポーネントの詳細などの具体的な状況が含まれます。

このアプローチは、従来の静的なしきい値では誤警報を引き起こす可能性がある、周期的なパターンや徐々に変化する傾向を持つメトリクスに対して特に効果的です。

統合されたチーム間のモニタリングとアラート

QoUXは従来の縦割り構造を打破し、チーム間のシームレスな可視性を可能にすることで、組織の監視能力を変革しました。CloudWatchはアカウント間で監視を行うことで、明確な所有権の境界を維持しながら、共有メトリクスに対してチームが個別にアクセス、分析、アラートを設定できるエコシステムを作り出しました。

たとえば、サブスクのフローで顧客向けの問題が発生した場合、サブスクチームとチェックアウトチームの両方が同じ情報源に即座にアクセスできます。この可視性の共有により、各チームはどのコンポーネントが影響を受けているかを正確に把握し、異なる監視システムを調整することなく、解決策を協力して考えることができるため、迅速な調整とより効果的なインシデント対応が可能になります。

この統合化されたアプローチによって、全員が同じリアルタイムデータに基づいて作業を行うため、検出までの平均時間が約40%短縮され、問題発生時のチーム間でのコラボレーションが改善しました。

教訓と次のステップ

QoUXを通じたクライアント側の監視の実装は、ユーザー体験のリアルタイムな可視性がいかに強力であるかを示しています。ユーザーが実際にアプリケーションを操作する場所を監視することにより、従来のバックエンド監視では完全に見逃される可能性のある問題について即座にインサイトを得ることができます。

主なポイント

**小さく始めて、徐々に拡大していく。**まずは、収益やコア機能に直接関連する最も重要なユーザーフローを計測することから始めます。私たちの場合、サブスクとチェックアウトのフローが自然な出発点でした。
**適切なメトリクスを選択する。**技術的なパフォーマンスだけでなく、ユーザーの成功や失敗を直接示すメトリクスに注目しましょう。ボタンのクリック数、完了率、エラー頻度は、多くの場合、サーバーの応答時間よりも包括的な情報を提供します。
**AWSサービスを効果的に活用してください。**CloudWatch異常検出は、複雑な機械学習の専門知識を必要とせずに、動的アラートを提供するための強力な基盤を提供します。ストリーミングにはKinesis、処理にはLambda、監視にはCloudWatchを組み合わせることで、柔軟でスケーラブルなアーキテクチャを実現します。
**データ量と実行可能性のバランスを取る。**クライアント側の監視には、サーバー側のモニタリングよりも大幅に多くのデータが生成されます。システムやチームに負担をかけないように、収集する内容とその集計方法について戦略的に考えてください。

独自のQoUX実装を始めるには

**現在の監視状況を調べる。**特にユーザー向けのコンポーネントやインタラクションに関して、既存の監視戦略のギャップを特定しましょう。
**主要なユーザージャーニーを計測する。**以下に焦点を当てて、クライアント側のイベント発行をアプリケーションの重要なパスに追加します。
- コンバージョンファネル
- 認証フロー
- 支払い処理
- 主な機能のインタラクション
処理パイプラインを構築するKinesisやLambda、CloudWatchなどのAWSサービスを使用して、クライアント側のイベントを収集、処理、視覚化します。
**ベースラインを確立し、Twitch上のアラートを設定します。**2～4週間データを集めて通常のパターンを確立してから、異常検出アラートを設定しましょう。
**チーム全体の可視性を維持する。**すべての関係者が問題発生時に連携を改善するために、同じ監視データにアクセスできるようにしてください。

独自のQoUXバージョンを実装することで、ユーザー体験の理解と対応を変革し、問題がビジネスに影響を与える前に特定し、ユーザーにとってより信頼性の高いプラットフォームを構築することができます。