製品の本当の顔を見て、生き残ってください。 いくつかの新しいサービスを作成する理由としてのユーザーの移行に関するデータ

インターネット上には、顧客の行動を分析する利点に関する記事が何百もあります。 ほとんどの場合、これは小売部門に関係します。 食品バスケット分析、ABC および XYZ 分析から、リテンション マーケティングや個人向けオファーまで。 何十年もの間、さまざまなテクニックが使用され、アルゴリズムが考え出され、コードが作成され、デバッグされてきました。それを取り入れて使用してください。 私たちの場合、XNUMX つの根本的な問題が発生しました。それは、私たち ISPsystem は小売ではなくソフトウェア開発に従事しているということです。
私の名前はデニスです。現在、ISPsystem で分析システムのバックエンドを担当しています。 これは私の同僚と私がどのように過ごしたかの物語です ダニル — データ視覚化の責任者 — は、この知識のプリズムを通して当社のソフトウェア製品を見ようとしました。 いつものように、歴史から始めましょう。

最初に言葉があって、その言葉が「やってみようか？」でした。

当時、私は研究開発部門で開発者として働いていました。 すべてはダニールがハブレについて読んだときに始まりました リテンションについて — アプリケーションにおけるユーザーの遷移を分析するツール。 私はそれをここで使用するという考えに少し懐疑的でした。 ライブラリ開発者らは例として、注文やオーナー企業への支払い方法のその他のバリエーションなど、対象となるアクションが明確に定義されているアプリケーションの分析を挙げた。 当社の製品はオンプレミスで供給されます。 つまり、ユーザーは最初にライセンスを購入し、その後初めてアプリケーションでの操作を開始します。 はい、デモ版があります。 豚を刺す必要がないように、そこで製品を試すことができます。

しかし、当社の製品のほとんどはホスティング市場を対象としています。 これらは大規模な顧客であり、ビジネス開発部門は製品の機能についてアドバイスを提供します。 また、お客様は購入時に、当社のソフトウェアがどのような問題の解決に役立つかをすでに知っていることになります。 アプリケーション内のルートは製品に組み込まれた CJM と一致する必要があり、UX ソリューションはそれらが順調に進むのに役立ちます。 ネタバレ: これは常に起こるわけではありません。 図書館への導入は延期されました...しかし長くは続きませんでした。

私たちのスタートアップのリリースですべてが変わりました - カートビー — Instagram アカウントからオンライン ストアを作成するためのプラットフォーム。 このアプリケーションでは、ユーザーはすべての機能を無料で使用できる XNUMX 週間の期間が与えられました。 次に、購読するかどうかを決定する必要がありました。 そして、これは「ルートターゲットアクション」の概念に完全に適合します。 「やってみよう！」ということになりました。

最初の結果またはアイデアの入手先

開発チームと私は文字通り XNUMX 日で製品をイベント収集システムに接続しました。 ISPsystem はページ訪問に関するイベントを収集するために独自のシステムを使用しているとすぐに言いますが、同じ目的で Yandex.Metrica を使用することを妨げるものはありません。これにより、生データを無料でアップロードできます。 ライブラリの利用例を検討し、XNUMX週間のデータ収集後に推移グラフを受け取りました。

遷移グラフ。 基本的な機能。わかりやすくするために他のトランジションは削除されています

例のように、平面的でクリアで美しいことがわかりました。 このグラフから、人々が最も長い時間を費やす最も頻繁なルートと交差点を特定することができました。 これにより、次のことが理解できました。

• XNUMX のエンティティをカバーする大規模な CJM の代わりに、アクティブに使用されるのは XNUMX つだけです。 さらに、UX ソリューションを使用してユーザーを必要な場所に誘導する必要があります。
• 一部のページは、UX デザイナーによってエンドツーエンドになるように設計されており、ユーザーがそのページに不当に長い時間を費やすことになります。 特定のページ上の停止要素が何であるかを把握し、調整する必要があります。
• 10 回の遷移の後、20% の人が疲れ始め、アプリケーションのセッションを終了しました。 これは、アプリケーションにオンボーディング ページが 5 つもあったという事実を考慮しています。 ユーザーが定期的にセッションを放棄し、そこへのパスを短縮するページを特定する必要があります。 さらに良いのは、通常のルートを特定し、ソース ページから目的のページに素早く遷移できるようにすることです。 ABC分析と放置カート分析には共通点があると思いませんか？

そしてここで、このツールのオンプレミス製品への適用可能性に対する当社の姿勢を再考しました。 活発に販売および使用されている製品を分析することにしました - VMマネージャー6。 それははるかに複雑で、桁違いに多くのエンティティが存在します。 私たちは、遷移グラフがどのようになるのかを楽しみに待っていました。

失望とインスピレーションについて

失望 #1

それは、営業日の終わり、月末、そして年末が同時に重なった27月XNUMX日でした。 データが蓄積され、クエリが書き込まれました。 すべての処理が完了し、作業の結果を見て次の営業年度がどこから始まるかを知るまで、あと数秒ありました。 研究開発部門、プロダクト マネージャー、UX デザイナー、チーム リーダー、開発者がモニターの前に集まり、製品内のユーザー パスがどのように見えるかを確認しましたが、次のことがわかりました。

Retentioneeringライブラリによって構築された遷移グラフ

インスピレーション #1

強力に接続され、数十のエンティティ、明確ではないシナリオ。 新しい営業年度が分析ではなく、そのようなグラフを使用して作業を簡素化する方法の発明から始まることは明らかでした。 しかし、すべては思ったよりもずっと単純だったという感覚を払拭することができませんでした。 そして、Retentioneering のソース コードを XNUMX 分間検討した後、構築されたグラフをドット形式にエクスポートすることができました。 これにより、グラフを別のツール Gephi にアップロードできるようになりました。 また、レイアウト、フィルター、統計など、グラフを分析するための範囲がすでに用意されています。インターフェースで必要なパラメーターを設定するだけです。 そんなことを思いながら、年末年始に出発しました。

失望 #2

仕事に戻った後、みんなが休んでいる間に、クライアントが製品の研究をしていることがわかりました。 はい、とても大変だったので、以前は存在しなかったイベントがストレージに現れました。 これは、クエリを更新する必要があることを意味しました。

この事実の悲しみを理解するための背景を少し説明します。 当社は、マークしたイベント (たとえば、いくつかのボタンのクリック) と、ユーザーが訪問したページの URL の両方を送信します。 Cartbee の場合、「XNUMX アクション XNUMX ページ」モデルが機能しました。 しかし、VMmanager では状況がまったく異なり、XNUMX つのページ上で複数のモーダル ウィンドウを開くことができました。 ユーザーはそれらの中でさまざまな問題を解決できます。 たとえば、URL:

/host/item/24/ip(modal:modal/host/item/ip/create)

「IP アドレス」ページでユーザーが IP アドレスを追加したことを意味します。 そして、ここでは XNUMX つの問題が同時に確認できます。

• URL には、ある種のパス パラメーター (仮想マシンの ID) が含まれています。 それを除外する必要があります。
• URL にはモーダル ウィンドウ ID が含まれます。 このような URL は何らかの方法で「解凍」する必要があります。
  もう 150 つの問題は、マークしたイベントそのものにパラメータがあることです。 たとえば、リストから仮想マシンに関する情報を含むページにアクセスするには、200 つの異なる方法がありました。 したがって、XNUMX つのイベントが送信されましたが、ユーザーがどのメソッドに遷移したかを示すパラメーターが含まれていました。 このようなイベントはたくさんあり、すべてのパラメーターが異なりました。 また、Clickhouse では、すべてのデータ取得ロジックが SQL 言語で提供されています。 XNUMX ～ XNUMX 行のクエリは、いくぶんありふれたもののように思え始めていました。 問題が私たちの周りにありました。

インスピレーション #2

ある早朝、ダニルは悲しそうにリクエストを XNUMX 分間スクロールしながら、「データ処理パイプラインを書いてみませんか?」と私に提案しました。 考えた結果、やるならETLのようなものにしようと決めました。 そのため、すぐにフィルタリングし、必要なデータを他のソースから取得します。 こうして、本格的なバックエンドを備えた最初の分析サービスが誕生しました。 データ処理の XNUMX つの主要な段階を実装します。

1. イベントを生データ ストレージからアンロードし、処理の準備をします。
2. 明確化とは、モーダル ウィンドウ、イベント パラメーター、およびイベントを明確にするその他の詳細の識別子そのものを「開梱」することです。
3. エンリッチメント (「金持ちになる」という言葉から) とは、サードパーティのソースからのデータを使用してイベントを追加することです。 当時、これには当社の請求システム BILLmanager のみが含まれていました。
4. フィルタリングは、分析結果を歪めるイベント (内部スタンドからのイベント、外れ値など) をフィルタリングして除外するプロセスです。
5. 受信したイベントをストレージにアップロードします。これをクリーン データと呼びます。
   イベントまたは同様のイベントのグループを処理するためのルールを追加することで、関連性を維持できるようになりました。 たとえば、それ以来、URL 解凍については更新していません。 ただし、この間にいくつかの新しい URL バリエーションが追加されました。 これらはサービス内ですでに規定されているルールに従っており、正しく処理されます。

失望 #3

分析を開始すると、グラフがなぜこれほど一貫性があるのか​​がわかりました。 実際、ほぼすべての N-gram には、インターフェイスを通じて実行できない遷移が含まれていました。

小規模な調査が始まりました。 XNUMX つのエンティティ内で不可能な遷移がないことに混乱しました。 これは、これがイベント収集システムまたは ETL サービスのバグではないことを意味します。 ユーザーは、あるエンティティから別のエンティティに移動することなく、複数のエンティティで同時に作業しているような感覚がありました。 これを達成するにはどうすればよいでしょうか? ブラウザーでさまざまなタブを使用する。

Cartbee を分析する際、私たちはその特異性によって救われました。 このアプリケーションはモバイル デバイスから使用されていましたが、複数のタブから作業するのは単純に不便でした。 ここにはデスクトップがあり、あるエンティティでタスクが実行されている間に、この時間を別のエンティティのセットアップやステータスの監視に費やしたいと考えるのは当然のことです。 進行状況を失わないように、別のタブを開いてください。

インスピレーション #3

フロントエンド開発の同僚は、イベント収集システムにタブを区別するよう教えました。 分析が始まる可能性があります。 そして、私たちは始めました。 予想通り、CJM は実際のパスと一致しませんでした。ユーザーはディレクトリ ページに多くの時間を費やし、最も予期しない場所でセッションやタブを放棄しました。 遷移分析を使用すると、一部の Mozilla ビルドで問題を見つけることができました。 これらでは、実装機能により、管理者のみがアクセスできるはずのナビゲーション要素が消えたり、半分空のページが表示されたりしていました。 ページは開きましたが、バックエンドからコンテンツが送信されませんでした。 遷移をカウントすることで、どの機能が実際に使用されたかを評価することが可能になりました。 チェーンにより、ユーザーが特定のエラーをどのように受け取ったかを理解することが可能になりました。 ユーザーの行動に基づいてテストできるデータ。 それは成功でした、そのアイデアは無駄ではありませんでした。

分析の自動化

結果のデモンストレーションの XNUMX つでは、Gephi がグラフ分析にどのように使用されるかを示しました。 このツールでは、換算データを表形式で表示することができます。 そして、UX 部門の責任者は、社内の行動分析の方向性全体の発展に影響を与えた非常に重要な考えの XNUMX つを言いました。「同じことをしましょう。ただし、Tableau とフィルターを使用すると、より便利になります。」

そこで私は、「なぜ、Retentioneering はすべてのデータを pandas.DataFrame 構造に保存しないのか」と考えました。 そして、これは概してテーブルです。 これが、別のサービスである Data Provider の登場です。 彼はグラフから表​​を作成しただけでなく、そのページとそのページに関連する機能の人気度、それがユーザー維持にどのように影響するか、ユーザーがそのページに滞在する時間、ユーザーが最も頻繁に離脱するページを計算しました。 また、Tableau での視覚化の使用により、グラフの調査コストが大幅に削減され、製品での動作分析の反復時間がほぼ半分になりました。

Danil は、この視覚化がどのように使用されるか、そしてそれによってどのような結論が導き出せるかについて話します。

テーブルの神様にもっとテーブルを！

簡素化された形式では、タスクは次のように定式化されました。Tableau で遷移グラフを表示し、フィルター機能を提供し、可能な限り明確で便利なものにすることです。

Tableau で有向グラフを描きたくなかったのです。 そしてたとえ成功したとしても、Gephi と比較してその利益は明白ではないようでした。 もっとシンプルでアクセスしやすいものが必要でした。 テーブル！ 結局のところ、グラフはテーブル行の形式で簡単に表現できます。各行は「ソース-宛先」タイプのエッジです。 さらに、私たちはリテンショニアリングツールとデータプロバイダーツールを使用して、そのようなテーブルをすでに注意深く準備しています。 あとは、Tableau でテーブルを表示し、レポートを精査するだけでした。

みんなテーブルが大好きな様子といえば。

しかし、ここで別の問題に直面します。 データソースをどうするか? pandas.DataFrame に接続できませんでした。Tableau にはそのようなコネクタがありません。 グラフを保存するための別のベースを構築することは、見通しが曖昧なあまりにも根本的な解決策であるように思えました。 また、継続的な手動操作が必要なため、ローカルでの荷降ろしオプションは適していませんでした。 私たちは利用可能なコネクタのリストを調べ、そのアイテムに視線を落としました。 ウェブデータコネクタ、最下層で寂しく身を寄せていた。

Tableau には豊富なコネクタが用意されています。 私たちの問題を解決するものを見つけました

何の動物ですか？ ブラウザーでいくつかの新しいタブが開き、このコネクタを使用すると、URL にアクセスするときにデータを受信できることが明らかになりました。 データを計算するためのバックエンド自体はほぼ準備ができており、あとはそれを WDC と友達にするだけでした。 Denis は数日間ドキュメントを研究し、Tableau のメカニズムと格闘し、私が接続ウィンドウに貼り付けたリンクを私に送ってきました。

当社の WDC への接続フォーム。 デニスは前に出て安全を確保した

数分間待機すると (データはリクエストに応じて動的に計算されます)、次の表が表示されます。

Tableau インターフェイスでの生データ配列は次のようになります。

約束どおり、このようなテーブルの各行はグラフのエッジ、つまりユーザーの有向遷移を表します。 また、いくつかの追加の特徴も含まれていました。 たとえば、一意のユーザーの数、遷移の合計数などです。

この表をそのままレポートに表示し、フィルターを惜しみなく散布してツールを航行させることも可能でしょう。 論理的に聞こえます。 テーブルを使って何ができるでしょうか？ しかし、これは私たちのやり方ではありません。なぜなら、私たちは単なるテーブルではなく、分析と製品決定を行うためのツールを作成しているからです。

通常、データを分析するとき、人は質問に対する答えを得たいと考えます。 素晴らしい。 まずはそれらから始めましょう。

• 最も頻繁に起こる移行は何ですか?
• 特定のページからどこに行くのでしょうか?
• 終了するまでに、このページに平均どのくらいの時間を費やしますか?
• A から B に移行する頻度はどれくらいですか?
• セッションはどのページで終了しますか?

各レポートまたはそれらの組み合わせにより、ユーザーはこれらの質問に対する答えを独自に見つけることができる必要があります。 ここでの重要な戦略は、それを自分で行うためのツールを提供することです。 これは、分析部門の負荷を軽減し、意思決定にかかる時間を短縮するのに役立ちます。結局のところ、Youtrack にアクセスして分析担当者のタスクを作成する必要はなくなり、レポートを開くだけで済みます。

何が得られたでしょうか？

ユーザーがダッシュボードから最も頻繁に分岐するのはどこですか?

私たちのレポートの一部。 ダッシュボードの後、全員が VM のリストまたはノードのリストに移動しました。

トランジションを含む一般的なテーブルを取得し、ソース ページごとにフィルターしてみましょう。 ほとんどの場合、ダッシュボードから仮想マシンのリストに移動します。 さらに、「規則性」列は、これが繰り返されるアクションであることを示唆しています。

それらはクラスターのリストのどこから来たのでしょうか?

レポートのフィルターは両方向に機能します。どこから出発したのか、どこへ行ったのかを知ることができます。

例から、XNUMX つの単純なフィルターの存在と値による行のランク付けでも、情報を迅速に取得できることが明らかです。

もっと難しいことを聞いてみましょう。

ユーザーがセッションを放棄することが最も多い場所はどこですか?

VMmanager ユーザーは多くの場合、別のタブで作業します。

これを行うには、参照元によってデータが集計されたレポートが必要です。 そして、いわゆるブレークポイントが割り当て、つまり一連の遷移の終わりとして機能するイベントとして扱われました。

ここで重要なのは、これはセッションの終了である場合もあれば、新しいタブが開く場合もあることです。 この例は、チェーンがほとんどの場合、仮想マシンのリストを含むテーブルで終了することを示しています。 この場合、特徴的な動作は別のタブに切り替わることであり、予想されるパターンと一致しています。

私たちはまず、同様の方法で分析を実行したときに、これらのレポートの有用性を自分自身でテストしました。 ヴェップ、当社の別の製品。 テーブルとフィルターの登場により、仮説の検証が迅速化され、目の疲れも軽減されました。

レポートを開発するとき、私たちはビジュアルデザインを忘れませんでした。 このサイズのテーブルを操作する場合、これは重要な要素です。 たとえば、認識しやすい落ち着いた色調を採用しました。 等幅フォント 数値の場合、特性の数値に応じて線を色で強調表示します。 このような詳細により、ユーザー エクスペリエンスが向上し、社内でツールがうまく普及する可能性が高まります。

表は非常にボリュームがあることが判明しましたが、読みにくくなっていないことを願っています

社内クライアントである製品スペシャリストやUXデザイナーのトレーニングについては、別途言及する価値があります。 分析例とフィルターを使用するためのヒントを記載したマニュアルが特別に用意されました。 マニュアルへのリンクをレポート ページに直接挿入しました。

マニュアルはGoogle Docsでのプレゼンテーションとして簡単に作成しました。 Tableau ツールを使用すると、レポート ワークブック内に Web ページを直接表示できます。

後の言葉の代わりに

肝心なことは何でしょうか？ 毎日使う道具を比較的早く、安価に手に入れることができました。 はい、これはグラフ自体、クリックのヒート マップ、または Web ビューアに代わるものではありません。 しかし、そのようなレポートはリストされたツールを大幅に補完し、思考の材料や新しい製品やインターフェイスの仮説を提供します。

この話は、ISPsystem における分析の開発の始まりにすぎませんでした。 過去 XNUMX か月間で、製品内のユーザーのデジタル ポートレートや、類似ターゲティング用のデータベースを作成するサービスなど、さらに XNUMX つの新しいサービスが登場しましたが、それらについては次のエピソードで説明します。

出所： habr.com