GAのCookie活用でSiteCatalystをスマホ対応させる方法
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つのデメリットがあります。
１．GAのように異なるドメイン間でCookie内容を共有する仕組みが提供されていない
マルチドメインの大きなサイトだと、ドメインが切り替わった時に1st-Party Cookieの内容が引き継がれないために別ユーザーとして認識され、訪問が途切れて計測されたりユニーク訪問者数が増えたりします。
２．SiteCatalystのサーバーにサブドメイン割り当てる必要がある
ビジターIDをサーバー側で発行するという仕組みは変わらないため、SiteCatalystのデータ収集サーバーに自社のサブドメイン割り当てる必要があります。例えばGILTではomniture.gilt.jpというドメインを新たに取得し、SiteCatalystの収集サーバーに割り当てるようDNS設定を行いました。ただし、他者が管理するサーバーに自社のサブドメインを割り当てるのは、IT部門にとっては受け入れられないことがあります。自社ドメインのCookie内容を収集したり、悪意あるCookieを仕込まれるなどのセキュリティ的なリスクが増えるためです。
ハイブリッド方式
そこで、収集サーバーはサードパーティドメインのまま、1st-Party CookieでビジターIDを保持するハイブリッド方式について紹介します。
１．ビジターIDを独自発行する
GAと同様、JSで乱数を発生させ、ビジターIDとして明示的に指定する方式です。生成したIDは1st-Party Cookieに保存しておきます。ビジターIDさえ指定できれば、計測サーバーの3rd-party Cookieが拒否されても訪問がつながるようになります。楽天やリクルートさんが実装している方式ですね。すでに計測中のサイトの場合は、UAがSafariの時にのみビジターIDを発行し指定するようにすれば、既存の3rd-Party Cookieとも同居可能です。
２．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にセットしています。