Dropbox Paper

コンポーネント志向における分析システム設計

アプリケーション設計における開発/分析単位は

ページ単位であることがほとんどであった。

技術の発展や開発体制の変化に伴い分析のニーズが変化しつつある。

このようなニーズは集計済みの情報ではなく、生ログの需要を高めることとなる。

アドホックな分析やアプリケーション開発に対応可能なデータ基盤が必要となる。

一方で、実際の開発はOSSや業界の動きも激しいのが現状である。

ベースとなる考え方、パラダイムをおさえて技術選定に活かせると望ましい。

ページ指向アプリケーションの分析デザイン

Web初期からの分析単位ではURL単位での分析が主だった。

HTMLによるコンテンツ表示とハイパーリンクへのクリックによるページ遷移が

主だったサービス構成においてはURLごとのページビューやURLの遷移を確認するだけで十分であることが多い。

これらの

例えばGoogle Analyticsではサイト内に埋め込むリンクに対して ?utm_source=hoge といったようにGETリクエスト用パラメータを埋め込んだり、HTTP Referrerによるヘッダー情報の利用によりユーザチャネルの把握を行うことができた。

また広告配信システムに代表されるようなタグ埋め込みによるユーザ識別子のCookie埋め込みを活用することでクロスオリジンな分析を行うことができる。

URLのようなページ単位での分析を行うことが専らであった。

ここからGoogle Tag Manager(以降GTM)のような機能にある通り

デプロイレスなアドホックなイベントログの収集が可能になった。

ブログの記事の読了率といったインビューイベントなどより詳細なユーザ行動に着目した分析も行われるようになった。

このような時代のアプリケーションでは主に機能＝ページであったと言える。

分析設計もページ単位に合わせた設計がなさていたと言える。

ページ単位からより小さい機能単位へと関心が移っていく背景には

アプリケーションの高度化がある。

ネイティブアプリケーションにはじまったアプリケーションのモバイル化は

インタラクティブやレスポンシブな動作を実現可能にしました。

それに追従してWeb技術も大きく発展してきました。

WebのSPA(Single Page Application)のようなアプリケーション形態では

仮想DOMやService Worker、そのほかブラウザAPIの高機能化は

Webにおける開発パラダイムを大きく変え、サーバサイドで担っていたようなページ生成を

ブラウザ上で実現できるようになりました。

実際のサービスをもとに、ページあたりにどのようなコンポーネントが埋め込まれているかを確認してみましょう。

次の図はTwitterとNetflixのサービス画面について、コンポーネントごとに領域を明示化してみました。