Wrikeの分析を超える分析

スパークでタスクを待っている日付エンジニア。

Wrikeの開発の長年にわたって、ユーザーの行動に関する多くの散在する情報を蓄積してきました。 この情報は複数のデータベース、ログ、外部サービスに分散しているため、アナリストはこのデータを収集し、それらのパターンを見つけて、 SaaSの永遠の質問に対する答えを見つける必要があります。

• 顧客が離れる理由
• どのユーザーが私たちにお金をもたらしますか？
• 製品をさらに開発する方法は？

SQLを使用して解決するタスクのほとんどは、SQLを介したログへのクエリが面倒で遅くなります。 これらは自動化または詳細な分析に使用できますが、何かをすばやく確認する必要がある場合は、分析よりもデータの準備に時間がかかります。

頻繁に見なければならない場合、それは痛みを引き起こします。この記事では、それを克服する方法とデータを最大限に活用する方法を説明します。

私たちの決定

ログには、ユーザーが実行したアクションとこのアクションの特性に関する情報が保存されます。 ユーザーがサブスクリプションを選択すると、ログに次のイベントが記録されます。

• ユーザーAがページにアクセスし、ビジネスサブスクリプションを提供しました。
• ユーザーAはマーケターのサブスクリプションを選択しましたが、これは私たちが提供したサブスクリプションではありません。

これをSQLに便利にするには、これらのログのメトリックを考え出し、これらのメトリックをグループ化するディメンションを見つける必要があります。

測定値として、 時間とユーザーIDを選択しました。

時間-メトリックの値の変化を追跡するため。
ユーザーID-ほとんどすべてのログにあり、その情報は簡単に集約できるため。 アカウント内のすべてのユーザーのメトリックを要約すると、アカウントのアクティビティが取得されます。

メトリックは、ログから情報を抽出するために私たちが尋ねる質問です。 それらを決定することはより困難です。 興味のある内容に応じて、これらの質問は変わります。

• 各サブスクリプションを購入したユーザーの数を見積もる場合、「ビジネスサブスクリプションを購入したユーザーの数」、「マーケティング担当者のためにサブスクリプションを購入したユーザーの数」を尋ねます。
• コンバージョンを評価する場合は、「このフォームを見た人は何人ですか？」、「このフォームで計画を選んだ人は何人ですか？」

アプリケーションの構造を詳細に調査し、すべての重要な質問をし、ログでそれらの回答を抽出すると、次の構造が得られます。

user_id|date|   ?|     ?|... 

しかし、すべての質問をすぐに推測することは不可能であり、新しい指標を追加して古い指標を再集計する可能性を維持することが重要です。

すべてのメトリックを組み合わせて、ユーザーIDごとにグループ化し、測定値（国、ユーザーロケール、アカウントにいる人の数、このアカウントが私たちにお金を払っているかどうか）で充実させます。 そして、これをPostgreSQLのorcテーブルにロードします。

このテーブルの構造は次のようになります。

 user_id|date|metric1|metric2|metric3|metricN|dimension1|dimension2|dimensionN 

この表の背後にあるのは、アナリストが日常業務を取り除き、製品をよりよく理解するのに役立つインフラストラクチャです。 この内部製品を「カスタムデータストアフロント」と呼びます。

これはアナリストにどのように役立ちますか？

バックエンドからログとテーブルを処理するためのスクリプトをまとめました。 以前は、アナリストは自分自身を保存し、スクリプトを手動で共有し、毎回新しい方法でコピーして修正しました。

店頭を作ったとき、私たちはそれが拡張可能で、アナリストにとってシンプルで、思いやりのある名前付けができるようにしたかったのです。 作成したすべてのメトリックが、アナリスト（会議中）とスコアボードを介して自分でデータを分析したい人の両方にアクセスできるようにしたかったのです。 そして何よりも、製品をよりインテリジェントにするために十分なデータを収集したかったのです。

ショーケース拡張可能

データウェアハウスを拡張可能にするために、モジュールのシステムを作成しました。
モジュールは、入力から次の構造を取得する方法を示すPythonコードです。

 (user_id, {metric_1_key: metric_1_value, metric_2_key: metric_2_value}) 

このスクリプトに加えて、モジュールで依存関係を宣言し、集計の前後にメトリックのデフォルト値と説明を記述します。

モジュールは互いに独立して考慮され、一部のモジュールでエラーが発生した場合、このモジュールにデフォルト値を入力し、特別にトレーニングされたテーブルにこのモジュールが正しく計算されなかったことを書き込みます。 別のモジュールでエラーが発生しても、システム全体には影響しません。

私たちは、 単一責任の原則に従ってモジュールを組み立てようとします。1つの理由で変化するコードのみが同じモジュールにあるべきです。 この場合、モジュールは異なるログとデータベースで動作できます。 不安定なデータ構造はモジュールの入力に到着し、データを破壊することはできません。また、パフォーマンスに大きな影響を与えない限り、何でも作成できます。

これらのモジュールをどの程度正確に開発し、どのような困難に遭遇したかについては、次の記事で説明します。

ショーケース-アナリストにとってシンプル

店頭の助けを借りて、PythonまたはSQLのスキルを知っている人なら、たとえアナリストでなくても、ログ仕様を実装する開発者または製品をよりよく理解したいテスターであっても、いくつかの新しいメトリックを追加できるようにしたかったのです。

この観点から、Pythonは理想的なソリューションのように見えました。データフレームとPandasSQLを備えた簡単なプログラミング言語とPandaがあります。 すべてのアナリストがpythonを知っていて愛しているわけではありませんが、誰もがSQLまたはデータフレームを操作する方法を知っているため、このソリューションは理想的なように見えました。

確かに、パンダは大量のデータに対して非常にゆっくりと動作し、モジュールの数が増加するにつれて、実行速度は指数関数的に増加しました。 ここで、SparkデータフレームとSpark SQLに切り替えて、不要なデータの逆シリアル化を取り除きました。新しいモジュールはストアフロントをそれほど遅くせず、それらをさらに最適化する方法を知っています。

ウィンドウでは、思慮深い命名

多数のメトリックがある場合でも、メトリックの名前は同様のメトリックに固有のものにする必要がありました。 現在、750のメトリックがあり、毎月50の新しいメトリックを追加しています。 そして今のところ、彼らは名前の交差点に遭遇したことはありません。

メトリックの名前は、7つの部分で構成されています。

1. エンティティ -このメトリックが参照するエンティティ：
   act （アクティビティ）、 search （検索）、 i （統合）。
2. イベント -どうしたの？
   btn_clckd （ボタンをクリックした）、 dashb_open （ダッシュボードを開いた）
3. ソース -どのアプリケーションで？
   ws （ワークスペース、私たちのWebアプリケーション）、 andr （アンドロイド）、 ios （と言っても）、 x （どれでも）。
4. パス -アプリケーションのどの部分でアクションが発生しましたか？
   たとえば、タスクの編集は、検索検索の後、またはdbord ダッシュボードで行うことができます。
5. 測定 -集計にどのアクションを使用しますか？
   sum、flg、str（文字列連結）、json（jsonでイベントを記述）。
6. 単位 -測定単位
   イベントの数ev、タスクの数tまたはユーザーusrsを要約できます
7. 詳細 -他に何か？
   同一のイベントを別々にカウントしたり、異なるログから読み取ったりできる場合は、ここでこれを示す価値があります。

実際、メトリックの名前は次のようになります。

entity__event__source__path__measure__unit__details説明の一部がXを置くメトリックに適用できない場合、コンポーネントパーツ（ティッカー）を2つのアンダースコアと、単語を1つで分離します。

view__reports_open__ws__x__cnt__ev__xビューがWebアプリケーションから開かれたときのイベントの数（最後から読み取る方が良い）。

act__assignment__x__user__flg__fct__non_self_assignmentはファクトメトリックです。ユーザーが別のユーザーを持っている場合は1、それ以外の場合は0を書き込みます。これらのメトリックはアカウントまたは名前ごとに完全に集約されます。

略語を恐れないでください、それらを解読する特別な辞書があり、人々は人間の名前で働きます。

すぐにこの命名には至りませんでした。 最初は、ティッカーの少ないショーケースを作成しようとしましたが、ミスを犯し、膨大な数のメトリックの名前を手で変更する必要がありました。 これらの変更はほとんどのアナリストに影響を与え、多くの時間が無駄になり、その後、結果を長期間にわたってかき集めました。

調子はどう？

現在、7人が作成した22のモジュールがあります（これは、このショーケースをサポートするチームの2倍です）。

このストアフロントにモジュールを追加することなく大きな機能の単一の問題が完成することはなく、このデータから益々多くの利益を得ています。

これは同僚にどのように役立ちますか？

1か所で多くの有用なデータを収集し、アナリストを迂回して関心のある人々にアクセスできるようにしたいと考えました。 これを行うために、Tableau Onlineで自動的に更新されるダッシュボードを作成しました。 その中で、プログラミングに不慣れな人々は、メトリックを集計し、測定値でそれらをカットし、製品の使用に関する質問に答えることができます。例えば：

「Androidに登録されている有料ユーザーは何人ですか？」-Androidの登録数を確認し、無料のユーザーをフィルタリングできます。

「IEのバグを見つけました。何人のユーザーがそれに遭遇する可能性がありますか？」-IEの各バージョンを使用している人の数を別のダッシュボードで確認できます。

「このボタンをクリックした回数」-このボタンを閉じて、このイベントをウィンドウに追加するように依頼できます。

これらのダッシュボードを実装するために、 Tableauを選択しました。 分析のダッシュボードに積極的に使用し、Tableauもこのタスクに適していると判断しました。 その中に、カスタムストアフロントからのメトリックの一部が自動的に分類されるダッシュボードを作成しました。

このダッシュボードについて同僚と話し続け、分析が簡単であることを理解するのを助けます。 誰かが製品の仮説を持っている場合、このダッシュボードで定量的にテストできます。

スコアボードをどのように使用しますか？

次の理由により、スコアボード上の元の形式でデータベースの図を使用できませんでした。

• グラフの列の名前を自動的に変更することはできません。
• 列名の構成部分を使用してメトリックをフィルタリングすることはできません。
• Measure ValuesおよびMeasure Keysオブジェクトの機能は制限されており、新しいメトリックを自動的に追加することはできていません。

EAVを使用してこれらの問題を解決しました。つまり、テーブルをビューに変えました。

• 日 ;
• ユーザーID
• メトリックの名前。
• 63文字を超えるメトリックの完全名（postgresの制限）。
• メトリック値。
  グラフを作成します
• メトリック情報。
  メトリックを見つけるには
• ユーザーと彼のアカウントに関する情報。
  グラフをカットします

スコアボードがグラフをフィルタリングして構築できるように、ユーザー情報の値のすべての組み合わせについて集約されたメトリックを計算しました。 国（ロシアまたは米国）とアカウントタイプ（有料または無料）の2つのディメンションがある場合、これらの値のすべての組み合わせのメトリックを集計し、各メトリックについて4行を取得します。

• ロシアから無料で。
• ロシアからの支払いの場合。
• 米国から無料で。
• アメリカから支払われます。

これらの交点にゼロがあったとしても、この組み合わせを見逃すことはありません。そうでなければ、チャートを構築することができなくなるか、省略されます。

ただし、3次元以上をフィルター処理する必要があります。 このため、スコアボードテーブルは巨大であり、スコアボードのダッシュボードの動作は非常に遅くなります。

さらに、Tableau Onlineにデータを転送するには、古いドキュメントを含むライブラリを使用してSpark DataframeをTableau Data Extractに変換する必要があり、Windowsのみを使用してTableau Onlineサーバーにデータを送信できますが、これらは人生でささいなことであるため、一度決定し忘れました。

これは会社に何をもたらしましたか？

このデータストレージ形式の最も優れた点は、自動的に分析できることです。

これらのメトリックの異常を探しています。 これにより、アナリストや製品マネージャーにとって面白くなく、長期間更新されていない場合でも、すべての機能の使用を毎日監視する機会が与えられます。

最新の調査では、すべての利点を追跡できます。
このデータでのユーザーの流出を予測する場合、どの要因がそれに影響するかを理解できます。
どの要因が影響するかを理解すれば、製品のメリットを十分に活用できず、サポートが必要なアカウントをより優先順位付けできます。
モデルがそのようなアカウントを正確に識別することを理解すれば、サポートを安価または無料にすることもできます。つまり、製品の価値を高め、同僚を日常業務から救うことができます。
高価なものを安くし続けるなら、それ自体がクライアントのタスクに適応するインテリジェントな製品を作ります。

このデータの使用方法については、多くの計画があります。

• リードの優先順位付けの改善。
• マーケティングとオンボーディングを最適化する際に、ユーザーのアクティビティを考慮します。
• ユーザーの流出をよりよく理解する。
• 製品の使用シナリオをよりよく理解する。
• ユーザーを引き付けるものをよりよく理解する。
• ユーザーおよびメンバーへの推奨事項のパーソナライズ。

次の記事では、すべてがどのように機能するかを説明し、同様のシステムを開発する際のさらなる妥協点に飛び込み、進行中のレーキと成功したソリューションについて説明します。

冒頭の写真は、スパイクジョーンズの映画「彼女」のフレームです。