CVポイントでのアクションを分析する機構を自前で作って学んだこと
この記事は NAVITIME JAPAN Advent Calendar 2020 の 最終日の記事です。
こんにちは、ちょくにゃんです。
ナビタイムジャパンで法人向け店舗データ管理・店舗検索サイト構築SaaSの開発・運用を担当しています。
今回は、店舗検索サイト内のコンバージョン（CV）ポイントでのユーザーのアクションを分析するための機構を、自前で開発した話です。普段の業務で分析を専門にしているわけではなく、特に集計回りで初めて学んだことが多かったためご紹介します。リアルタイムに蓄積されていくデータの集計をする際の参考になれば幸いです。
法人向け店舗データ管理パッケージについて
ナビタイムジャパンでは、多店舗展開している事業者向けに「NAVITIME Location Cloud」という店舗データ管理パッケージを提供しています。店舗データを一括で管理しさまざまなメディアに自動連携することで、一般のユーザーの目に触れる店舗情報が、常に最新で正確なものになるように支援するサービスです。
その中で、店舗データを登録するだけでオウンドメディアとして店舗検索サイトを簡単に構築する機能があり、飲食チェーンや銀行などさまざまな企業にご利用いただいています。
店舗検索サイトは、それぞれのお客様のブランドイメージやご要望に合わせて色味やレイアウトのカスタマイズができるようになっています。その他、キャンペーンの訴求バナーや、飲食店であればデリバリーや注文予約のリンクなどを設置することが可能です。
リンクでのユーザーアクションの傾向を知りたい
このようなリンクは、店舗検索サイトの目的であるお客様の店舗・サービスへの送客に繋がるポイントになるため、コンバージョン（CV）ポイントと呼んでいます。例えば、ECサイトの購入ボタンやアプリの会員登録ボタンなどもCVポイントです。
CVポイントはなるべく効果の高くなるように設置する、つまり多くのユーザーの目に留まり多くクリックしてもらうリンクにすることが重要になってきます。弊社が提供する店舗検索サイトでも、一部のCVポイントのクリックを記録して設置効果を分析できるようにしていましたが、毎回複雑なクエリを書く必要があるなど営業メンバーやお客様が簡単に分析をすることはできていませんでした。
CVポイントでのユーザーアクションを分析することは、CVポイント設置機能を提供する弊社にとっても、それを利用してプロモーションを行うお客様にとっても重要です。
そこで今回、CVポイントでのアクションを計測・集計し、社内やお客様向けに可視化するための機構を開発しました。分析機能を一通り開発する中で特に集計部分で様々な学びがあったので、今回はそのあたりについて書きたいと思います。
なぜGoogle Analyticsは使わないのか？
Webサイトの分析といえば、Google Analyticsが定番だと思います。様々な目線からの分析をその場で期間や条件を切り替えながら素早く行うことができますが、今回の用途には向いておらず採用しませんでした。
Google Analyticsには、イベントトラッキングという機能があります。サイト内でのユーザーのアクション（ページ表示、クリック、スクロールなど）に対してJavaScriptを用いてイベントを送信することができ、カテゴリ、アクション、ラベルの3段階で分類できます。
弊社が提供する店舗検索サイトもGoogle Analyticsを利用していますが、ユーザーのアクションを分類するには、どのお客様のサイトか、どの店舗のページか、どのCVポイントか、インプレッションなのかクリックなのか、といったことを分類する必要があり、カテゴリ、アクション、ラベルという3段階の枠での分類が適しませんでした。
そこで、より店舗検索サイトの実運用に合った方法でユーザーアクションの計測・集計ができる仕組みを新たに構築することにしました。
作るものの要件
今回分析機構を作成するにあたっての要件は次のようなものでした。
・店舗検索サイト内の任意の箇所に設置したCVポイントのユーザーアクション（インプレッション、クリック）を記録する
・CVポイントそれぞれについて、日ごと、店舗ごとのインプレッション数、クリック数を集計する
・集計した値を社内やお客様向けに表やグラフとして可視化し、CVポイントの設置効果を分析できるようにする
例えば、上の画像のようにCVポイントとして来店予約ボタンを設置したサイトで、次のようにユーザーのアクションがあったとします。
このとき、次のように集計しツール上で素早く可視化できるようにすることが今回の目標です（実際にはどのサイトか、どのページかなどの情報もありもう少し複雑です）。
CVポイントを増やせば増やすほどインプレッションやクリックのログは増えていくため、集計した値をいかに素早く分析ツール上で取り出すことができるかが今回の機構のポイントになりました。
全体の構成
今回構築した機構の全体像は下の図の通りです。
ナビタイムジャパンのサービスでは、アクセスログ等の集計用途でTreasure Dataというデータプラットフォームサービスを使用しています。通常、生のアクセスログはデータレイクとしてS3に保存し、Treasure Dataは分析用途でデータウェアハウスとして利用していますが、今回はユーザーアクションを記録する限定的な用途のため、サイト上から直接イベントを飛ばす形でTreasure Dataをデータレイクとして利用しています。
今回の構成で鍵になるのが、Treasure Data内の生ログを定期的に一次集計するバッチ処理と、一次集計した結果を分析ツール側の要求に合わせて整形して返却するAPIです。
APIから直接Treasure Dataに集計クエリを送信する方法では、その集計に関係ないデータも含まれる中から集計するため負荷が大きいこと、Treasure Dataのクエリ同時実行数に制限があり頻繁には行えないこと、外部サービスであるTreasure Dataとの通信に時間がかかることなど、今回の限られた用途の集計を頻繁に行いたいという要件には適さないデメリットがあります。
そのため、APIリクエストのたびにTreasure Dataにアクセスしなくていいように、一次集計した中間テーブルを用意しそこを参照するようにしています。
学んだ大事なこと
この分析機構作成のために集計バッチ処理やAPIを開発する中で学んだことを紹介します。
1. 集計結果の意味は軸と指標で決まる
何かのデータを集計する際には、集計軸（dimension）、集計指標（metrics）、集計条件（filter）が決まっている必要があります。ここを何にするかで、集計された結果の意味を変えることができます。
例えば、各店舗の詳細ページにある来店予約ボタンが1日にどれくらいクリックされているかを知りたいときは、日付が集計軸に、クリック数が指標になります。まずデータを日付でグルーピングし、クリック数を合計することでそれぞれの日のクリック数が分かります。
同じ来店予約ボタンについて、店舗ごとのクリック数が知りたい場合は店舗が集計軸に変わります。さらに、日付ごとに店舗ごとのクリック数が知りたいとなれば、集計軸は日付×店舗になります。
そして、どのサイトを集計するのか、何日から何日まで集計するのかなどを決めるのが、集計条件になります。この軸・指標・条件の3つの組み合わせで、集計結果の意味を変えることができます。
2. 中間テーブルを作成し、生ログと集計APIは切り離す
ユーザーアクションのログは日に日に溜まっていきます。APIがリクエストされた際、このような膨大な生ログを対象に毎回集計していては時間がかかります。分析ツールは簡単に集計期間や集計軸を切り替えられながら数値を追えるようになっている必要があるため、ツールの操作に対するAPIのレスポンスが遅いことは致命的です。
この問題を解決するためには、生ログを一次集計した中間テーブルを作成しておくことが効果的です。APIリクエストとは非同期のタイミングで定期的に一次集計処理を実行しておくことで、APIは必要な情報に絞られたデータを用いて求められた結果を素早く返却することができます。
またこの方法を取ることで、時間がかかる生ログの集計を利用者の少ない時間帯にまとめて行うことができるようになり、クエリの同時実行数の制限などを回避することができます。
この方法でのデメリットは、集計結果のリアルタイム性が無くなるということです。ユーザーアクションが記録されてからそのデータが中間テーブルに集計されるまで時間差があるため、集計バッチ処理を日次で行っている場合は当日のアクションは翌日までAPIで取得することはできなくなります。
3. 中間テーブルは想定される軸ごとに作っておく
ある集計軸で一度集計してしまうと、その結果を使って別の軸で集計し直すことはできません。そのため、集計軸として想定されるものについてはあらかじめ対応する中間テーブルと集計処理を用意しておく必要があります。
例えば、日付を軸としてクリック数を集計したい場合、日付を主キーとする中間テーブルと、そこにデータを入れる集計処理が必要になります。そしてもし後から店舗ごとの集計もしたくなった場合でも、この集計済みのテーブルから集計し直すことはできないということです。店舗ごとに集計したいのであれば、店舗を主キーとした中間テーブルと対応する集計処理があらかじめ必要になります。当然、日付ごとに店舗ごとのクリック数が見たければ、日付と店舗を主キーとした中間テーブルと対応する集計処理が必要になります。
このように、想定する軸が集計の最小単位となるため、API、つまり分析ツールが指定しうる軸についてあらかじめ一次集計することになります。例えば日付ごとではなく時間ごと、分ごとなどより細かい単位で集計する場合それだけデータ量が増えていくことになるため、パフォーマンスや使いやすさとデータ量とのバランスになります。
4. ログは最初から集めて保存しておく
ユーザーのアクションによって溜まっていくログデータは、過去にさかのぼって集めることはできません。そのため、どう集計するかはっきりとは決まっていない状態であっても、必要になりそうなデータは早めに記録・計測しておくことが大切です。
また、生ログが保存されていれば再集計は後からいつでもできます。データ量との兼ね合いにはなりますが、後から集計軸が増える可能性があるのであればなるべく生ログを残しておくべきです。
5. API利用者にデータ構造を意識させない
利用者から見た集計APIは、軸・単位・絞り込み条件を決めれば結果が得られるというインターフェースになっているべきであり、利用者に元データの構造を意識させないようにすることが大切です。
また、裏側でどのような集計が行われていても、そこから得られるデータは利用者から見れば集計結果という1つのリソースです。そのため、APIは1つのエンドポイントに対して軸・単位・条件をパラメータで指定する形になっていると利用しやすくなります。
今回の例で言えば、日付を軸として集計したテーブル、店舗を軸として集計したテーブルなど複数の中間テーブルがありますが、1つのエンドポイントに対して、集計軸は日付、指標はクリック数、絞り込み条件として先週1週間分、というような形でリクエストできるため、利用者はデータベース側の構造を意識せずにデータを要求することができます。
まとめ
今回は、日々集まる膨大なデータを分析するための機構を作って学んだことをご紹介しました。
・集計結果の意味は軸と指標で決まる
・中間テーブルを作成し、生ログと集計APIは切り離す
・中間テーブルは想定される軸ごとに作っておく
・ログは最初から集めて保存しておく
・API利用者にデータ構造を意識させない
主に集計に関する内容となりましたが、どなたかの参考になれば幸いです。