ソリューションの評価とバグの発見においてマルコフ連鎖をどのように使用するか。 Pythonスクリプトを使用する場合

私たちにとって、トレーニング中に生徒に何が起こったのか、そしてそれらの出来事が結果にどのような影響を与えるのかを理解することが重要です。そのため、私たちはカスタマー ジャーニー マップ、つまり顧客体験のマップを作成します。 結局のところ、学習プロセスは継続的かつ統合的なものではなく、相互に関連した一連の出来事や生徒の行動であり、これらの行動は生徒によって大きく異なります。 これで彼はレッスンを完了しました。次に何をするでしょうか? 宿題になりますか？ モバイルアプリケーションも起動するのでしょうか？ 彼は進路を変更し、教師を変えるよう頼むでしょうか？ すぐに次のレッスンに行きますか？ それとも彼はただ失望して去ってしまうのでしょうか？ このマップを分析することで、コースを無事に完了するパターン、または逆に学生の「中退」につながるパターンを特定することは可能でしょうか?

通常、CJM の構築には、特殊で非常に高価なクローズド ソース ツールが使用されます。 しかし、私たちは最小限の労力で済むシンプルなもの、そしてできればオープンソースのものを考え出したいと考えていました。 そこで、マルコフ連鎖を使用するというアイデアが思いつき、私たちは成功しました。 私たちはマップを作成し、学生の行動に関するデータをグラフの形で解釈し、グローバルなビジネス問題に対する完全に非自明な答えを確認し、深く隠されたバグさえも発見しました。 私たちはこれらすべてをオープンソースの Python スクリプト ソリューションを使用して実行しました。 この記事では、これらの非常に明白ではない結果が得られた XNUMX つのケースについて説明し、スクリプトを全員と共有します。

したがって、マルコフ連鎖はイベント間の遷移の確率を示します。 以下は Wikipedia からの原始的な例です。

ここで、「E」と「A」はイベント、矢印はそれらの間の遷移 (イベントからイベントへの遷移を含む)、矢印の重みは遷移の確率 (「重み付き有向グラフ」) です。

何を使いましたか？

この回路は、生徒の活動ログを入力した標準的な Python 機能でトレーニングされました。 結果として得られる行列のグラフは、NetworkX ライブラリによって構築されました。

ログは次のようになります。

これは、学生 ID、イベントの名前、イベントが発生した時刻の XNUMX つの列からなるテーブルを含む CSV ファイルです。 これら XNUMX つのフィールドは、クライアントの動きを追跡し、マップを構築し、最終的にマルコフ連鎖を取得するには十分です。

ライブラリは、構築されたグラフを .dot または .gexf 形式で返します。 前者を視覚化するには、無料の Graphviz パッケージ (gvedit ツール) を使用できます。これも無料の .gexf および Gephi と連携しています。

次に、マルコフ連鎖の使用例を XNUMX つ挙げたいと思います。これにより、私たちの目標、教育プロセス、および Skyeng エコシステム自体を新たに見ることができました。 まあ、バグを修正してください。

最初のケース: モバイル アプリケーション

まず、最も人気のある製品である一般コースを通じて学生の歩みを調査しました。 その時、私は Skyeng の児童部門で働いていて、モバイル アプリケーションが児童視聴者にどの程度効果的に機能するかを確認したいと考えていました。

ログを取得してスクリプトで実行すると、次のような結果が得られました。

開始ノードは Start General で、一番下には XNUMX つの出力ノードがあります。学生は「眠りに落ちた」、コースを変更し、コースを終了しました。

• 眠りに落ちた、「眠りに落ちた」 - これは彼がもう授業を受けていないことを意味し、おそらく彼は落ち込んでしまいました。 私たちはこの状態を楽観的に「眠っている」と呼んでいます。 理論的には、彼にはまだ勉強を続ける機会がある。 私たちにとって最悪の結果です。
• 将軍を落とし、コースを変更しました - 将軍から他のものに切り替え、マルコフチェーンに迷いました。
• コースを終了しました、コースを終了しました - 理想的な状態、レッスンの 80% を完了しました (すべてのレッスンが必要なわけではありません)。

成功したクラス ノードに入るということは、教師と一緒にプラットフォームでレッスンを正常に完了することを意味します。 コースに沿った進捗状況と、「コースを完了した」という望ましい結果へのアプローチが記録されます。 私たちにとって、学生ができるだけ出席することが重要です。

モバイル アプリケーション (アプリ セッション ノード) についてより正確な定量的な結論を得るために、最終ノードごとに個別のチェーンを構築し、エッジの重みをペアごとに比較しました。

• アプリセッションからアプリセッションに戻ります。
• アプリセッションから成功したクラスまで。
• 成功したクラスからアプリセッションまで。

左側はコースを完了した学生、右側は「眠ってしまった」学生です。

これら XNUMX つのエッジは、生徒の成功とモバイル アプリの使用との関係を示しています。 私たちは、コースを完了した学生は、居眠りしていた学生よりもアプリケーションとの結びつきが強いだろうと予想していました。 しかし、実際にはまったく逆の結果が得られました。

• ユーザーのグループが異なれば、モバイル アプリケーションとの対話方法も異なるようにしました。
• 成功した学生は、モバイル アプリケーションをあまり集中的に使用しません。
• 居眠りをする生徒は、より積極的にモバイル アプリケーションを使用します。

これは、居眠りをした生徒がモバイル アプリケーションを使用する時間がますます長くなり、最終的には永久に使用し続けることを意味します。

最初は驚きましたが、よく考えてみると、これはごく自然な効果であることがわかりました。 一時期、モバイルアプリとYouTubeの文法講座という50つのツールを使って独学でフランス語を勉強していました。 最初は、時間を 50 対 100 の比率で分割していました。しかし、アプリケーションはより楽しく、ゲーミフィケーションがあり、すべてがシンプルで速く、明確ですが、講義ではそれを掘り下げて何かを書き留める必要があります, ノートに書いて練習します。 徐々にスマートフォンを使う時間が増え、その割合は XNUMX% に達しました。XNUMX 時間もスマートフォンを使用していると、仕事が完了したという誤った感覚が生まれ、そのせいで、スマートフォンを聴きに行く意欲がなくなりました。何でも。

しかし、どうしてこんなことがあり得るのでしょうか？ 結局のところ、私たちは特別にモバイルアプリケーションを作成しました。 エビングハウス曲線が組み込まれています、それをゲーム化し、人々がそこで時間を過ごせるように魅力的にしましたが、それは人々の気を散らすだけであることが判明しましたか？ 実際、その理由は、モバイル アプリケーション チームがそのタスクにうまく対処しすぎたため、その結果、モバイル アプリケーションがクールで自己完結した製品になり、私たちのエコシステムから外れ始めたためです。

調査の結果、主要な学習コースの邪魔にならないように、モバイル アプリケーションを何らかの方法で変更する必要があることが明らかになりました。 そして子供も大人も。 この作業は現在進行中です。

XNUMX 番目のケース: オンボーディングのバグ

オンボーディングは、新しい学生を登録する際のオプションの追加手順であり、将来の潜在的な技術的問題を排除します。 基本的なシナリオは、ある人がランディング ページに登録し、個人アカウントにアクセスし、連絡を受けて入門レッスンを受けることを前提としています。 同時に、導入レッスンでは技術的な問題の大部分が発生していることにも気付きました。ブラウザのバージョンが間違っている、マイクや音声が機能しない、教師がすぐに解決策を提案できないなど、これらすべてが特に難しいのです。子どもたちに。 したがって、私たちはあなたの個人アカウントで追加のアプリケーションを開発しました。このアプリケーションでは、ブラウザ、カメラ、マイクをチェックし、入門レッスン中に保護者が近くにいるかどうかを確認するという XNUMX つの簡単なステップを完了できます (結局、保護者が料金を支払うのです)。彼らの子供の教育）。

これらのいくつかのオンボーディング ページには、次のようなファネルが表示されていました。

1: XNUMX つのわずかに異なる (クライアントに応じた) ログインおよびパスワード入力フォームを持つ開始ブロック。
2: 追加のオンボーディング手順に同意するチェックボックス。
2.1-2.3: 親の存在、Chrome のバージョン、およびサウンドを確認します。
3: 最終ブロック。

それは非常に自然に見えます。最初の XNUMX つのステップで、ほとんどの訪問者は、何か記入したり確認したりする必要があることに気づき、立ち去りますが、時間がありません。 クライアントが第 XNUMX ステップに到達した場合、ほぼ確実に最終ステップに到達します。 ファネル上の何かを疑う理由は XNUMX つもありません。

それにもかかわらず、私たちは古典的な XNUMX 次元ファネルではなく、マルコフ連鎖を使用してオンボーディングを分析することにしました。 もう少しイベントを有効にしてスクリプトを実行すると、次の結果が得られました。

この混乱の中で、明確に理解できることは XNUMX つだけです。それは、何かが間違っていたということです。 オンボーディング プロセスは直線的であり、これは設計に固有のものであり、そのようなつながりの網が存在すべきではありません。 そしてここでは、ユーザーがステップ間を移動していることがすぐにわかりますが、ステップ間ではまったく遷移があってはならないのです。

この奇妙な状況には XNUMX つの理由が考えられます。

• 浅瀬がログデータベースに忍び込みました。
• 製品自体、つまりオンボーディングに間違いがあります。

最初の理由はおそらく真実ですが、テストには非常に労力がかかり、ログを修正しても UX の改善には役立ちません。 しかし、XNUMX 番目のものが存在する場合は、早急に何かを行う必要があります。 そこで、ノードを調べて、存在しないはずのエッジを特定し、その発生の理由を探しました。 一部のユーザーは行き詰まって円を描いたり、他のユーザーは途中から最初の段階で落ちたり、原則として最初の XNUMX つのステップから抜け出すことができなかったりすることがわかりました。 私たちはデータを QA に転送しました - そして、はい、オンボーディングに十分なバグがあることが判明しました。これは副産物であり、ちょっとした問題であり、十分に深くテストされていませんでした。 何も問題が起こるとは予想していませんでした。 レコーディングプロセス全体が変わりました。

この話は、QA 分野におけるマルコフ連鎖の予想外の応用を示しました。

あなたも試してみてください！

私のものを投稿しました マルコフ連鎖をトレーニングするための Python スクリプト パブリックドメインです - 健康のために使用してください。 GitHub のドキュメント。ここで質問できます。すべてに答えるように努めます。

さて、役立つリンク: NetworkX ライブラリ, Graphviz ビジュアライザー。 そしてここ ハブレに関する記事があります マルコフ連鎖について。 記事内のグラフは以下を使用して作成されています。 ゲフィ.

出所： habr.com