初めまして。いつも拝読させていただいています。
限られた条件の中で、何を計測するか、また何は削ぎ落とせるかを整然と整理されているので読んでいて大変納得感がありました。
物理的に、「全部はムリ」という状況でも「えーできないの?」という反応を示されることが多いので、説得法や指針の打ち出し方のポイントも是非伺いたいです。
今後も楽しみにしています。
Yahoo!トップページにSiteCatalystを入れるとしたら
SiteCatalyst経験者の中途採用募集で一時Twitterを賑わしたYahoo! JAPAN。もし元楽天の解析リーダーがYahoo!のトップページにSiteCatalystを導入するなら、と妄想しながら実装してみました。現役時代には書けなかったエントリーです。
勝手に想像した要件
- Yahoo!のトップページはデスティネーションではなくスタートページなので、流入ではなく離脱を分析することで、送客のコントロール精度を高めたいハズ。
- 全ページビューを計測するのはサーバー負荷やコストの面で非現実的。用途を絞り込むことで、計測コール数を最低限に抑えたい。
- 全部のサイトにSiteCatalystを導入するのは社内調整や実装に時間がかかり過ぎる。実装の負荷をどこまで抑えられるか?
と、勝手に想像しました。
要件定義では、知りたいことを明確にするだけでなく、各種の制約も明確にし、さらに解析の費用対効果についてもメドをつけたいところです。
これらの要件を満たすため、自分なら以下のように設計・実装します。
図:計測のモデル:
Topのページビューを計測しない
SiteCatalystはコール数(≒PV)に応じて費用が増える従量課金制なので、膨大なトラフィックが集中するYahoo!トップページで単なる閲覧をカウントするのはお金の無駄。そもそもページビュー数や訪問回数、ユニークビジター数のような単純な合算のためにSiteCatalystを使うのはオーバースペックなので、既に導入されているであろう社内ツールに任せます。
正確には、s_code.jsをロードしてJS関数を実行しますが、条件を満たさない場合はs.t()関数を実行しないようにすることで計測のコールを発生させません。コールが飛ばなければ課金も増えません。
グループ内へのリンクのクリックのみを計測する
ページ閲覧時にコールを飛ばさない代わりに、グループ内サービスへのリンクをクリックした時にコールを飛ばすようにします。linkHandlerというプラグインを使うと、ページ内の全リンクを探査してルールに合致するURLのみクリックを計測することができます。各リンクにonClick属性を個別設定することなく自動計測できるので、確実な運用が可能です。
この方法だとブラウザの挙動の違いや、クリックとロード、リクエスト送信のタイミングによってはコールが飛ばなず計測されないことがありますが、目安として相対的な推移と複数の指標の間の相関関係を調べるだけなので、深く追求しないことにします。
流入チャネルを分類してCookieに格納する
ページの閲覧時にしか取得できないリファラ系のデータは、閲覧時にデータを送信する代わりにCookieに入れておき、次にコールを飛ばす時に一緒に送信すればok。
流入元の分析は、今回想定した要件には含まれていませんが、この実装ならコストが増えないので、念のため実装・取得しておきます。集客のための効果測定だけでなく、送客効果を高めるための流入元ベースのコンテンツターゲティングの可能性を模索するためにデータが使えそうです。
リンク先のグループ内サイトでは、主要コンバージョンのみをピンポイントで計測する
リンクのクリック回数を合算するだけなら、bit.lyや自作プログラムで十分です。SiteCatalystを使うからには、コンバージョンを計測して、いろいろな時間軸や粒度でクロス集計やアトリビューション分析したいところです。
そこで、サイト内のページ間遷移をスパッと切り捨てて、Yahoo!トップを経由してどのサービスでコンバージョンしたのかを、点と点でピンポイント計測し、クロス集計することにします。
期間によって計測のon/offを切り替えられるようにする
月末や年末に、コール数の消費状況を見ながら計測を一時的に停止できると便利です。
という方針に基づき、実際に動作するs_code.jsを作ってみました。
SiteCatalystの実装方法
- TOPページの閲覧時にs.t()を実行しないで、各種の値をCookieにスタックしておく
- ChannelManagerで判別した流入元チャネル
- スクロール量(Y座標の最大値)
- 訪問回数(セッション開始時にインクリメント)
- linkHandlerでグループへのリンクのクリックを自動検出&計測する
- Cookieに保存しておいた上記の値(eVarへ)
- 時間+曜日(UUを知るためpropにも入れる)
- OS・デバイス名(Win, Mac, Android, iPhone, iPadなど制作時の分類で)
- リンクの画面エリアID、リンク先URL、リンク先ドメイン(UUを知るためpropにも入れる)
- 主要サービスの完了ページのみ、コンバージョン用のカスタムevent変数やproduct変数をセットする
- カスタムevent変数(新規とリピートで変数の番号を分ける)
- サービス名(UUを知るためpropにも入れる)
- コンバージョン名(UUを知るためpropにも入れる)
TOP用のs_code.jsプラグイン部分の例
s.usePlugins=true function s_doPlugins(s){ var url=s.linkHandler("/r/|/f/|/t/|/z/"); if(url){ s.linkTrackVars="prop1,events"; s.linkTrackEvents="event1"; if(url.match(/\/[rftz]\/(.+)$/)){ s.prop7=RegExp.$1; s.eVar7="D=c7"; s.events=s.apl(s.events,"event1"); } } } s.doPlugins=s_doPlugins;
導入するプラグイン
- linkHandler
- ChannelManager
- getPercentPageViewed
- getVisitNum
- ユーティリティ系(apl, p_gh, Cookie Combine Utility)
今回は高トラフィックなページなので、軽くするために少なめにしました。実際はデフォルト構成からさらにチューニングが必要ですね。
さて、これらを計測するとどのようなレポートが得られて、どんな改善が可能になるのでしょうか?
次回に続きます(ニーズありますか?コメントどうぞ)