GAのCookie活用でSiteCatalystをスマホ対応させる方法

2011年08月12日 01:09

1st-party Cookieの台頭

自サイトのドメインで発行されるCookieを1st-Party Cookie(ファーストパーティークッキー)、他のドメインで発行されるCookieを3rd-Party Cookie(サードパーティークッキー)と呼びます。最近はプライバシー重視のため、ドメインを超えてデータを保持できる3rd-Party Cookieへの風当たりが強くなってきました。既にSafariは、3rd-Party Cookieを拒否するのがデフォルト設定になっています(MacもiPhoneもiPadも)。 もしIEやFirefoxのようなメジャーなブラウザがバージョンアップでこの方針に追従したら、3rd-Party Cookieは事実上使えないものになります。3rd-Party Cookieへの依存を減らし、プライバシーを尊重できる仕組みを早く確立しておく必要があります。

Google AnalyticsとCookie

Google Analyticsは、1st-Party Cookieに各種データを格納します。ユニークビジターを特定するためのビジターIDに加えて、トラフィックソースやビジタースコープのカスタム変数など、ページや訪問を超えて保持されるデータは自サイトのドメインで発行される1st-Party Cookieに格納されます。
iPhoneやiPadなどの3rd-Party Cookieを拒否する環境でも計測できるというメリットがある反面、Cookieの数と容量に制限があるため、あまり多くのデータを保持できません。Google Analyticsのカスタム変数が5つしかないのは、このためでしょう。

SiteCatalystとCookie

SiteCatalystは、ユニークビジターを特定するためのビジターIDだけをCookieに保存し、その他の各種データをサーバー側で保管します。この仕組みのおかげで合計150個という大量のカスタム変数を使えるのですが、データ保管のためのディスク容量が必要になるので、アクセスに応じて料金が増えます。

日本では、楽な3rd-Party CookieでSiteCatalystを実装することが多いようです。この場合、ビジターIDをSiteCatalystサーバー側で採番し、そのドメイン(2o7.netやomtrdc.net)で送受信される3rd-Party CookieにビジターIDを格納します。そのため、3rd-Party Cookieを無効化したブラウザからのアクセスではビジターIDがページ間で引き継がれず、訪問がつながらなくなります。PVは増えても訪問が増えないのです。IPアドレスとブラウザの種類(UA)の組み合わせで重複を除外するため、かろうじて訪問者数(UU)は増えます。

国内で導入されたSiteCatalystのほとんどは3rd-Party Cookieを採用しているため、実はiPhoneやiPadの訪問がカウントされず、前後のパスやeVar、トラフィックソースのコンバージョンも計測できていないという事実はあまり知られていません。

依頼すれば、SiteCatalystでも1st-Party Cookieを使えます。
ただし、SiteCatalystの通常の1st-Party Cookie方式には、2つのデメリットがあります。

1.GAのように異なるドメイン間でCookie内容を共有する仕組みが提供されていない

マルチドメインの大きなサイトだと、ドメインが切り替わった時に1st-Party Cookieの内容が引き継がれないために別ユーザーとして認識され、訪問が途切れて計測されたりユニーク訪問者数が増えたりします。

2.SiteCatalystのサーバーにサブドメイン割り当てる必要がある

ビジターIDをサーバー側で発行するという仕組みは変わらないため、SiteCatalystのデータ収集サーバーに自社のサブドメイン割り当てる必要があります。例えばGILTではomniture.gilt.jpというドメインを新たに取得し、SiteCatalystの収集サーバーに割り当てるようDNS設定を行いました。ただし、他者が管理するサーバーに自社のサブドメインを割り当てるのは、IT部門にとっては受け入れられないことがあります。自社ドメインのCookie内容を収集したり、悪意あるCookieを仕込まれるなどのセキュリティ的なリスクが増えるためです。

ハイブリッド方式

そこで、収集サーバーはサードパーティドメインのまま、1st-Party CookieでビジターIDを保持するハイブリッド方式について紹介します。

1.ビジターIDを独自発行する

GAと同様、JSで乱数を発生させ、ビジターIDとして明示的に指定する方式です。生成したIDは1st-Party Cookieに保存しておきます。ビジターIDさえ指定できれば、計測サーバーの3rd-party Cookieが拒否されても訪問がつながるようになります。楽天やリクルートさんが実装している方式ですね。すでに計測中のサイトの場合は、UAがSafariの時にのみビジターIDを発行し指定するようにすれば、既存の3rd-Party Cookieとも同居可能です。

2.GAのビジターIDを流用する

eVar7のサイトで実装してみた新方式(世界初?)です。Google Analyticsが生成し1st-Party Cookieに保存したビジターIDをCookieから取り出し、そのままSiteCatalystのビジターIDとして流用するのです。SiteCatalystとGoogle Analyticsの訪問者数(UU)がほぼ一致するようになります。

また、Google AnalyticsのCookieには、訪問回数や閲覧ページ数、流入元などのデータが格納されているため、それらも流用が可能です。 Google AnalyticsはSiteCatalystよりも前から導入されていることがあるので、GAのCookieに格納された訪問回数を使えば、途中から導入したSiteCatalystでもサイト立ち上げ時にまでさかのぼった新規・リピートの判定が可能になります。(通常は導入直後に全ユーザーが新規ユーザーになり、徐々にリピートが増えていきます)

サンプルコード

var a = s.c_r('__utma').split('.')[1];

if (a) s.visitorID = RegExp.$1;

GAの「__utma」Cookieの内容をs_code.jsに組み込まれたc_r関数で読み込み、s.visitorIDにセットしています。


Real Time Web Analytics