hsano.jp

Note from daily life.

なぜ、OSSなアナリティクスツールプロジェクトをやっているのか?

Posted at — Aug 5, 2019

2つのOSSアナリティクスツール

2019年4月に、PolytrekとIngestlyという2つのプロジェクトを立ち上げました。

2月まで在席していた会社でフルスクラッチで構築したリアルタイムなアナリティクスツールは、モダンな計測SDKとストリームデータ処理やマイクロバッチを組み合わせ、 膨大なレコード数を捌きながらリアルタイムなデータ拡張を行い、いくつかのデータベースを組み合わせることでデータ量と処理速度をアプリケーション全体としてバランスしました。 このツールによって、分析に使えるデータの量と質を劇的に向上し、データの用途を広げ、意思決定を早め、柔軟で自由なデータ利活用を実現したと自負しています。 プロジェクトの後半ではオープンソース化に取り組んだものの、コードレビューが進まず部分的な公開のまま時間が経ってしまいました。

公開すると宣言したのに公開できていないというもどかしさ、リアルタイムデータを活かしたマーケティングを大衆化したいという思い、世の中のアナリティクスツールが微妙にCXを侵害している事実…

様々な思いがあって、最初のリアルタイムアナリティクスツールを作ったメンバーで、プロジェクトをリブートしようという話になりました。

Polytrekは、まさにプロジェクトのリブート版として、モダンなAPIを活用したり計測する指標やイベントを標準化していくという基本コンセプトに加え、 互換性を持ちつつ累積的な改良を反映する、という狙いがあります。 特にnavigationが切り替わるタイミングでのデータ送信や、クリック計測のブロッキングの抑制、PWAにおけるオフライン計測を視野に入れ、現代のウェブサイトやアプリにおいて測るべき事象を改めて網羅しようとしています。

一方のIngestlyでは、「自社でアナリティクスを保有する」ことで、「ファーストパーティのツール」「技術を内に持つ」を誰もが実践するために、最短で展開でき、なおかつ超低コストであることを目指したものです。 データ構造は似せているので、分析ノウハウは転用できるようにしています。こちらはあくまで簡易版なので、データ拡張やアプリ計測は視野に入っていません。

マーケティングのリアルタイム化

人間の脳が事象を認知して、動作にフィードバックするまでにかかる時間は200ミリ秒という説があります。 もしデータが200ミリ秒未満で入手でき、行動予測をしたり、施策を繰り出すまでの一連の処理まで含め200ミリ秒で完結できたとしたら、人の思考を先回りした施策が打てるのではないか?

2016年にアナリティクスツールの内製に取り組んだとき、当初はLatency(イベントが発生してからアナリストのクエリーにデータが反映されるまでの時差)の目標はもっと長いものでしたが、 開発が終わり、実際に運用してみると、データの流れが思いのほか速く、200ミリ秒が現実的な世界になってしまったのです。

そして様々なマーケティングツールを統合し、リアルタイムなマーケティング、そして更にその先、「確実に先回りするマーケティング」の可能性に気付いたのでした。

予測に基づくマーケティングは古くからありますが、元となるデータの鮮度がどうか、直近のイベントが反映できるか、によって、予測の精度は変わります。 真のリアルタイム化によって、現在進行中のコミュニケーションを最適化できる、そう思います。

アナリティクスの内製の壁

アナリティクスツールを内製している組織はいくつかありますが、社内のメインストリームとして複数部署で単一のツールを使っているケースは希です。 開発者がサイトの健全性を把握するために作ったとしても、マーケティングチームは別のツールを使っていたりしますし、内製ツールはサブで、あくまでGAがメイン、ということもあります。

アナリティクスツールを内製して運用する最大の課題は、エンドポイントの堅牢性と、SDKの機能、そして何より社内文化にどう浸透させるか、かなと思います。 まずエンドポイントについては、クラウドネイティブな設計をしていけば解決できるかもしれませんが、完全マネージドで手放しで運用できるのがベストです。 そういう意味でIngestlyはメンテナンス工数がゼロです。Polytrekもk8sやEBでスケーリングできるようにし、ある程度は自動で耐久性を確保できるでしょう。

SDKは、モダンなAPIを活用したプロジェクトがまだ少なく、PWAやAMPのような新しいウェブの形に対応できるツールは希です。アプリの計測はずいぶんと発展しましたが、ウェブはどうやら取り残されています。 ここを解決するために、ウェブで計測すべきイベントを簡単な設定で網羅でき、なおかつ計測処理がユーザー体験に影響しないようなSDKを用意することにしました。

そして文化。同じツールを使う人が増えたり、ツールは違えど同じデータ構造を扱う人口が増えることでノウハウがシェアでき、困ったことがあってもググったりコミュニティ内で相談できれば、利用する上での不安は減ります。 ツールそのものがどんなに人気があっても、実装が各社各サイト異なると知識や経験をシェアできないので、実装の「標準化」によってシェア可能にし、細かな差異にとらわれずに一つの文化を作っていきたいと思います。

comments powered by Disqus