マルチトラッキング(複数cookie)について考える

*2010/09/10 追記を入れました。

*2010/09/14 _linkでアドレスバーからcookieにデータを取り込む際、日本語データがある(検索ワードなど)と、うまくデータの引継ぎができないと思います。(フォーラムに質問した)。使う方は気をつけて(?)ください。chrome, firefoxの場合。IEはOK。 エンコードしてればよかった。

僕自身はあまりマルチトラッキングについて馴染みがないのですが、時々、マルチトラッキング絡みの質問を、フォームから受けるようになってきたので、いろいろと頭の中を整理しました。読んでください。

また、マルチトラッキングがニーズとなるのは、ドメインやディレクトリで分けてデータを収集したいということなので、具体例も画像付きで書きました。下の方。

全体の仕組み

大まかな前提を。 google analyticsはビーコン型のアクセス解析ツールです。gifリクエストをサーバーに飛ばして、データを収集してレポートしてくれます。モバイル計測の場合を除き、javascriptで操作します。トラッカーオブジェクトを作り、データ置き場としてのcookieを操作しつつ、gifリクエストを発行します。

同じ情報を複数アカウントに

ですので、同一情報を複数のアカウントに送りたい場合は、トラッカーオブジェクトを複数発行して、このオブジェクトにアカウント情報をそれぞれいれてやって、送信すればいいだけです。

公式サイトには英語のものしかないですが、用例があります。http://code.google.com/intl/ja/apis/analytics/docs/tracking/asyncUsageGuide.html#MultipleCommands

ただ、ドメイン別・ディレクトリ別に情報を取って、専用のプロファイルに送りたいですよね。

3つのパターン。サブドメイン、クロスドメイン、サブディレクトリの場合を見ていきます。

ただ、もう少し、講釈を続けます。

複数cookieを実現する設定

*これは、僕自身の考えに基づいて書いています。計測がうまく行かないかもしれないので、うまく行かない場合は、ダメじゃないか!と怒るか、もしくは、ぜひ連絡ください

ケース: aaa.xxx.comというサイトと、bbb.xxx.comというサイトを管理していて、この二つの横断的な情報を収集しつつ、aaa, bbb個別の情報を得たい場合です。

通常の方法としては、

_gaq.push([“_setAccount”,”UA-xxxxxx-yy”]); 
_gaq.push([“_setDomainName”,”.xxx.com”]); 
_gaq.push([“_trackPageview”]) 


という形を、aaa, bbbの両方に同じようにおけば、これで計測できるわけで何も問題ないですし、フィルターで切り分ければ情報を分けることも可能です。aaa, bbb別にアクセス情報を見られます。ただ、cookieをaaa,bbbで共有するために、サブドメイン独自でのセッション情報の管理(ユニークユーザ、新規・既存・リファラーなど)ができません。

そこで、cookieを3つ、aaa専用 bbb専用 aaa-bbb共用という形で用意して、専用の3つのプロファイルという形を用意します。

aaa.xxx.com bbb.xxx.coom
_gaq.push([“ab._setAccount”,”UA-for-aaabbb”]);

_gaq.push([“ab._setDomainName”,”.xxx.com”]);

_gaq.push([“ab.trackPageview”]);

_gaq.push([“a._setAccount”,”UA-for-aaa”]);

_gaq.push([“a._trackPageview”]);

_gaq.push([“ab._setAccount”,”UA-for-aaabbb”]);

_gaq.push([“ab._setDomainName”,”.xxx.com”]);

_gaq.push([“ab.trackPageview”]);

_gaq.push([“b._setAccount”,”UA-for-aaa”]);

_gaq.push([“b._trackPageview”]);

これで、3つのcookie(utm(a,b,c,v,z))セットができます。

このコードの説明をこれからします。

_setDomainNameの二つの機能

このsetDomainNameは、内部的に二つの働きをします。

cookieの所属ドメインの決定と、cookieの値にドメイン情報を持たせることです。

cookieの基本的な仕様は、ドメイン、パス別に指定して作成することができますが、javascriptからはドメインとパスはみえません、読む場合は見えないのです。ですので、cookieの値にドメイン情報を持たせることは意味を持ちます。(ドメインハッシュ値は他にもセキュリティ用途もあるみたいですが、よくわかりません)

s1-test-analytics.com

google-analytics-cookie

s2.test-analytics.com

WS000005

画像の文字が細かいですが、.test-analytics.com(両方に存在)と、s1.test-analytics.com, s2.etst-analytics.comの3つがあります。

左側の赤四角が、ドメイン情報を現してます。.test-analytics.comなら 113074331。s1.test-analytics.com:154559162, s2.test-analtics.com: 155607801。

と、setDomainNameは、cookieのドメインと、cookieの値の最初の10桁数字(ドメインハッシュ値)を決めています。cookieの最初の値が、ドメイン固有(ハッシュ衝突がないとして)の値ですので、この値を見て、複数cookie時に、該当cookieを判断しています。ネームスペース的な機能とでも言えばいいでしょうか?

サブドメイン+メインドメインの個別管理の実際を見てみる。

では、cookieが3つできてることは確認できたので、今度はドメイン別に機能しているかをみてみましょう。

次のようなケースを想定します。

セッション1: s1に訪問後、s2を訪問。

セッション2: s1のみ訪問

セッション3: 再度、s1のみ訪問

セッション4: s2のみ訪問(外部リンク経由(phar.awe.jp)

セッション5: s1を訪問

この場合、全体をカバーする情報は、5セッション。s1では4セッション。s2では2セッションと記録される形になって欲しいです。参照情報は、全体では(phar.awe.jp) s1はDirect, s2は(phar.awe.jp)となって欲しいです。

実際に図を見ていきます。

セッション1 s1を訪問。

WS000010

同一セッション内で、s2を訪問。 s2の参照情報は、s1.test-analytics.comに。

WS000011

セッション2に。(セッションの更新は、utmcのcookieを削除で行う) 両方のutmaのカウンタ(Valueの最後)は2に。

WS000012

セッション3 同じようにカウンタがインクリメントされ、3に。

WS000013

セッション4 phar.awe.jpから s2に遷移。全体のもの、s2のcookieが更新される(カウンタ(utma)、参照情報(utmz))

WS000014 

セッション5 s1を訪問(セッション4で、s2を訪問した情報は、test-analytcs.comの方のみ反映されている。

WS000015

と、想定通りになりました。 .test-analytics.comで全体のセッション管理を。s1,s2は個別でセッション管理されてます。s1からs2の移動も外部参照元となりますし、訪問回数は、s1,s2は個別に管理されてます。

サブドメインは、これで問題ないですね。では、クロスドメインの例を見てみましょう。少し複雑で、問題含みです。

クロスドメイン計測での、全体計測と個別ドメイン管理の実現

どこまでニーズがあるのかわかりませんが、これもみていきましょう。livedoorでは、この形で運用してるみたいですね。 あと、公式サイトのクロスドメイン計測の形です。シングルトラッキングで、前提が多少入りますが、ここらの情報は検索すればあちこちにあるのでいいと思います。

それで先程、クロスドメインがサブドメインより、少し複雑と書いたのは、cookieは他のドメインの値は読めないので、特殊なことをしてるし、サブドメイン計測とは同等の機能とはならないからです。

とりあえず、設定を考えましょう。二つのドメイン計測で、全体計測と、個別計測を実現する。

test.analytics.com phar.awe.jp
_gaq.push(“a._setAccount”,”UA-for-any”]);

_gaq.push(“a._setDomainName”,”none”]);

_gaq.push(“a._setAllowLinker”,true]);

_gaq.push(“a._trackPageview”]);

_gaq.push(“b._setAccount”,”UA-test-analytics”]);

_gaq.push(“b._trackPageview”]);

_gaq.push(“a._setAccount”,”UA-for-any”]);

_gaq.push(“a._setDomainName”,”none”]);

_gaq.push(“a._setAllowLinker”,true]);

_gaq.push(“a._trackPageview”]);

_gaq.push(“b._setAccount”,”UA-phar-awe”]);

_gaq.push(“b._trackPageview”]);

これで、この両者のドメイン間に onlick=’_gaq.push([“a._link”,this.href]);return false;’という形。

*2010/09/10 どうも、setDomainが”none”のものと、通常のものの実行順番が、上記のものと反対になると”none”で設定した方が上手く動かないように見える。バグなのかそういう仕様なのかは謎だけど、”none”を先にして、setDomainName無しをあとにした方が良いよう。もともと、クロスドメインで値を受け渡しするのは、ポリシーに反する部分もあるだろうから、異なるドメインの計測はやらない方が良いんだろう。

サブドメインでの計測では、cookieがメインドメインの元で共有され、変更が反映されてました。でも、クロスドメインはそれができません。urlのパラメータを読み込む形での受け渡しです。ですので、この受け渡しがないと、値の変更を反映できません。

とにかく、実際の図をみていきましょう。セッションを全体で3回行います。test-analyticsに2回。phar.aweに2回。またぐセッションがそのうち一回です。

最初のセッション。 参照元(utmz)は、s2.tes-analyticsからリンクを張りました。

WS000016

_gaq.push([“a._link”,this.href])でクロスドメイン遷移。細かいですが、参照元は全体では s2。個別では test-analytics.comからと別れてます。

WS000017

セッション2。test-analytics.comを訪問。カウンタ(utma)が増えただけ。

WS000018

セッション3 phar.awe.jpを訪問。サブドメイン計測ではcookieが共有されていたので、カウンタが上がっていたのだが、クロスドメインはそれがないので、全体計測の方のカウンタ(umta)が3にならず。2のまま。

WS000019

と、全体で3セッションあったのだが、全体を計測する utma(ドメインハッシュ Valueが1の方) では、

2回目の訪問が二回あって、3回目の訪問がない結果となる。また参照情報の変更も、url上のパラメータ渡しがないと、cookie値を共有する機会がないので、不整合な結果を作りやすい。

ショッピングカートのように、必ず特定のドメインからの遷移であれば問題はないでしょうが、結論としては、

クロスドメインでの全体・個別の分別管理は問題が多そうと、僕は思います。

さて、最後にもう一つトピックを取り上げます。ディレクトリでの全体・個別をマルチトラッキングで管理するです。ディレクトリの分別管理はニーズが多そうですが、固有の問題があります。

サイト全体・特定ディレクトリでの全体計測・個別計測のマルチトラッキング

実は、僕が手伝ってるサイトでも、先日これをやろうとしたのですが、うまく行かなくて悩んだのです。

cookieの値がヘンだなあと、、

実は、ドメインの違いに関しては、google analyticsのcookieがドメイン情報を持っていたので、区別できたのですが、パスの情報は入れてくれてないのです。なので、複数cookieはできません。作る事はできても、カウンタのインクリメントは、どっちをするか不定です。参照情報のutmzは一個しかできません、最初に設定したパスで出るのみです。何も指定してなけば、”/” 。これは、最初にsetCookiePathで”/DDD/”としたのでこうなりました。

WS000020

utmaは、二つ作ってはいますが、判別手段がないため、次回の更新はどちらかの値を取得して、二つとも、同じ値に更新です。実質的に、サイト全体での管理しか、しないことと同じになります。utmzを”/”で指定すればです全体ですし、utmzが”/DDD/”のみになれば、全体のセッション管理が狂います。

で、手段がないのかというと、ドメインを分けてやれば、個別管理できます。

http://www.lunametrics.com/blog/2009/03/06/cookies-tracking-multiple-accounts-ga/

@t32k さんの昔のエントリーも発見

なので、ここで細かく書いてもしょうがないので、コードだけ書いておわりにします、、、、

と思ったのですがlunameticsのコードだと、ドメイン名が同じなのでcookieが独立して動かない(ga.js側が)と思います。ドメインを分けるには、サブドメイン表記を使うか、クロスドメインの”none”を使うかだと思います。ここでは、noneを使う形の載せます、、、、

と思ったのですが、setDomainName(“none”)を使うと、セッションの更新がうまく行かない気が、、上のクロスドメイン時では問題なかったので、setCookiePathといっしょに使うと、動きがヘンになる????

なので、setDomainName(“.test-analytics.com”)とsetCookiePath(“/DDD/”)を一緒に使う形にします。

通常の場所 特定ディレクトリ(今回は/DDD/)
_gaq.push([“a._setAccount”, “UA-all”]);

_gaq.push([“a._trackPageview”]);
_gaq.push([“a._setAccount”, “UA-all”];

_gaq.push([“a._trackPageview”]);

_gaq.push([“b.setAccount”, “UA-DDD”]);

_gaq.push([“b.setDomainName”,”.test-analytics.com”]);

_gaq.push([“b.setCookiePath”, “/DDD/”]);

_gaq.push([“b.trackPageview”]);

setDomainName(“none”)で作ったcookieは、FQDN所属(leading period ‘.’なし)のcookieになるので、ほかの場面でクロスドメイン用に、”none”を使う場合は使えません。サブドメンの設定を使うしかないと思う。

実際の例

セッション3回。/DDD/index.htmlを二回。/index.htmlを一回。

セッション1: /DDD/index.htmlを訪問。

WS000024

注意: 所属Domainは双方同じ .test-analytics.comになってますが、ドメインハッシュ値は113… と115…と違います。これはデフォルトsetDomainNameなしを使うと、内部としては “test-analytcs.com”と “.”なしでドメインハッシュを計算するため。 .を付けとけば違うハッシュ値をとれる。で、今回は所属ドメインンが同じだが、パスが違うためcookieは存在できる。

セッション2: index.htmlを訪問

WS000025

セッション3 /DDD/index.htmlを訪問

WS000026

全体で3回訪問した。全体を把握する方の,115001218は、カウンタ(utma)が3になってる。個別ディレクトリ管理の113074331は、2回と想定通り。めでたし、めでたし。

まとめ

ここまで、読んでくれる人がいるか疑問です(僕なら飛ばし読みだ)が、まとめです。感想の箇条書き。

  • 複数cookieを使えば、セッション管理を独立して行えるので、ドメイン別、ディレクトリ別に具体例をcookieの値を見ながら検証しました。レポート側では検証していません。なので、落とし穴がまだあるかもしれません。
  • サブドメインの全体・個別の独立管理は、たぶん実用に応すると思います。
  • クロスドメインでの全体・個別の独立管理は、セッション単位で分析するのには問題含みな気がします。
  • ディレクトリでの全体・個別の独立管理は、トリッキーながらも、そのトリッキが使える状況の下では、きちんと数字が取れそうだと思います。
  • google analyicsの先頭のドメインハッシュ値は、ネームスペース的役割を果たします。キー(名前)が一緒でも、こちらで同一名cookieの判別を可能にします。
  • ディレクトリ情報は、ドメインハッシュ値に含まれてないので、別ドメインのcookieを用意して、cookieの分別管理を可能にできます。
  • setDomainNameの役割、cookieの所属ドメイン、ドメインハッシュ値の作成の二つの機能を頭にいれておく。参考に、前にwikiに書いたものへのリンク

コンバージョン率の推定範囲を把握しておく


* 正規分布で近似できるのは、np>5 だそうなので、100回施行で5回コンバージョンが想定されるくらいから、正規表現のイメージ(偏差*2で95%範囲)を持てるという事。でいいと思う、、、100回で2%だと、np<5なので、より裾野が広いイメージ?というか、コンバージョン数が0, 1, 2, 3, 4, 5, 6 くらいまでをそれぞれ計算すれば、いいと思います。 一般的には、F分布(謎)を使うようです。

————————————————————————————————————————————-

アクセス解析はなんですか? と聞かれた時に、よくある答えは、コンバージョンレートを計測し、向上策を考える事です。 というのはよくある答えですし、実際、サイトの数字を見るときは、まず、コンバージョンレートを見るようにしてます。

それで、これとこれのコンバージョンレートが違いますね。という話になると思います。比較の対象は、期間の比較であったり、キーワード、メディア、ランディングページの違いだったりすると思います。

どれくらい数字が違えば、認識・行動に移れるのか?

イメージから行動に移るには、数字の差が ”たまたま” なのか、”構造的” なのかを把握しないといけません。上の表は、標準偏差が ”1 or 2”の範囲で、どれくらいかを示したものです。正規分布を仮定しているので、この上下の範囲に64%が入る事になります。2の範囲で95%です。

意思決定的には、8割方の感覚でいけばいいと思います。また、コンバージョンレートの比較といっても、あくまで、それぞれのセッションを平等に扱って考えているわけで、選んだセッションに偏りがあると考える方が妥当かもしれません。 その場合は、因子分析に移ればいいのだろうか??? だれか、手順書を書いて欲しい。

数字を見る

WS000002

閲覧開始ページ別のコンバージョンレートです。タブの名前は、遊びで創ったもので、他のだれかがこの数字を担当してるわけではありません。

今回は、5ページ以上見るをコンバージョンとしています。ここでは、平均ページビューがだせないのですが、サイト全体の平均ページビューは、2.3くらいです。

上の表を使ってみると、トップページのコンバージョン率は、10.47%ですが、7-13%くらいまでは、振れを見といた方が良さそうです。 近い数字で、businessのページは、9.41%ですが、開始数が85なので、5-13%くらいの範囲を想定しないといけないです。what_areのページも、6.09%ですが、3-10%くらい違うと、、、

まあ、2シグマで見てたら、違いが分かる人にはなれそうにないのですが、閲覧開始数がこの10倍あれば、偏差はルート10で、3分の1くらいになるので、7-13が、9-11くらいの範囲になって、違いが言えるようになると思います。このサイトは、一日のアクセスが30-50なので、この10倍くらいのサイトなら、それなりに2,3パーセントの違いに言及できるようになると思います。

google analtyicsでは、インテリジェンスで統計数字が出てきて、アラートを出してくれるのですが、指標を時系列分析やら、誤差項やらを入れて、分析してそうな気がしますが、たぶん、説明を受けてもわかりそうにないです。

とりあえず、コンバージョンしたかどうかの、二者択一についての数字の分布を想定して、数字の振れをイメージしておきましょうという話でした。 間違っていたら、コメントください。 統計の話は、理解・非理解の二者択一なので、コメントにうまく返答出来ないかもしれませんが。

大事なのは、アクションなのですが、数字に統計的な違いがあるといえば、アクションさせる力になると思います。

GAのデータ理解。SQLとのアナロジー

妄想エントリーです。非常に観念的な話で実践的ではないですが、それ故に有用(分かった気になれる)になることもあり得る。

“突っ込まれbility” が発揮出来るエントリーになるといいのですが。

アナロジーは、

  • GAのディメンジョンは、SQLでいうところのgroup by。
  • GAの指標の方は、SQLでいうところの selectの集計関数を使った結果。

僕のSQLの理解は怪しいので、このアナロジーは間違ってるかもしれないけど、こういうイメージで、昔、ピンときた。sqlの経験は、はっきりいうと、sqliteで株価データをいじってテクニカル指標を出してたくらいしかないので、sqlを語ってはいけないのかもしれないけど。

で、前提としては、GAのデータ集合はセッションをデータ行として並べてるイメージです。

WS000001

GAのレポートは、集約関数が常に使われているイメージ

GAのレポートを見るときは、常にSQLの集約関数の結果がでてるイメージで行く。

select count(*) from ga-table group-by (traffic|user|content)

こんな感じで、トラフィックやら、ユーザー(新規・リピーターとか)、ページでのセッション数を見てる。

アドバンスセグメントなんかは、

  • ディメンジョンでセグメントする場合は、where句が付く感じ。
  • 指標でセグメントする場合は、having句で絞る感じでしょうか?

カスタムレポートは、

  • select部分に、いろんな集計関数(平均ページビューならaverage, 滞在時間ならsum, 他は大体 countとか。
  • group byにディメンジョン。サブディメンジョンにはサブクエリー?違う気がしてきたけど、、

終わり。

突っ込むところ満載なのかもしれないけど、inspiredされる人が居るかもしれないので、エントリー。

しかし、どうやって、こんなに早いデータ表示をしてるんだろうとは思う。googleといえば、big tableなわけでRDBSでない。RDBSならこんなスピードはでない? 知らないし、理解できないけど。 このデータ処理のレスポンスタイムはすごい。