で、そもそもこれは、setVar変数の代わりとして期待されているものです。
もともとグーグルは匿名性をうたっているので、ユーザー個別には
データをみることができません。
でも、ユーザー属性ごとに見たいって要望はあったわけです。
だからユーザー定義という機能があって、setVar(“jyosei”)なんてやって、
女性という任意の属性をユーザーに付与して代替していました。
※setVarについては、また別の機会に書きます
でもsetVarの欠点って、ユーザ属性を1つしか設定できなくて、
しかも別の値を設定してしまうと上書きされてしまうこと。
あとはセッションレベルでの管理はできないこと。
それはなぜかっていうと、ユーザーの永久クッキーとして、
一つの値を設定する仕組みだから。
例えば、女性、という属性をクッキーに保存した後、
購入者っていう属性を更にクッキーに追加しようと思っても、
これはもう、できないわけです。値が上書きされてしまうから。
もしくは「ショッピングカートに入れたのに、やっぱり止めてしまった人」
なんて属性もとれません。これを取ろうと思ったら、セッション単位の管理が必要なので、
ユーザー定義(setVar)ではできません。
もしこれをやろうと思ったら、イベント機能や仮想ページビュー機能を使うしかなかったわけです。
で、今回のマルチカスタム変数の登場です。
マルチカスタム変数の役割は、
「あなたのユーザーブラウザのクッキーに、５つまであなたの好きな属性を設定できるよ」
ってことです。
具体的にはこう書きます。
pageTracker._setCustomVar(
1, // This custom var is set to slot #1
"Items Removed", // The name acts as a kind of category for the user activity
"Yes", // This value of the custom variable
2 // Sets the scope to session-level
);
pageTrackerの関数の一つですね。
set系なので、ユーザーのブラウザに値をセットするだけ。
同時に計測したければ、そのあと、track系の関数で、
値をGoogleAnalyticsに飛ばしてあげる必要があります。
まぁ通常はデフォルト状態（要はga.jsの中に）で
全部のページに最初から_trackPageview();が入っているので
大丈夫ですね。
なんかややこしく見えますが、考え方を知れば怖くないです。
順追って説明していきますね。
これの一番大事なところは一番上の
index
という値です。
この値は何かっていうと、スロットと言って、要は自分が
ユーザーを区別したい種類のＭＡＸ個数＝５個なわけです。
ややこしいけど、５種類に区別ができるようになったよ、
というのが今回の目玉です。１から５で指定します。
まずはこのスロットの概念を捉えてから他の値を見ないと、
だんだん頭が混乱してきます。
で、５種類に区別できるようになってからがポイントです。
そこから、Visitorレベル、セッションレベル、ページレベル
っていう単語が出てきます。
以下、機能を説明するんじゃなくて、
概念というか、このカスタム変数の使い方をステップでご紹介します。
で、大前提として、まずはこの↓図を覚えておいてください。
この図で一番大事なのは、
GoogleAnalyticsが、一番上の階層に
『Visitor』を持ってきている、っていうことです。
つまり、この図が表しているのは、
Visitorを中心にして、
その人が
１回目のセッション（一番左）では２ページ見た。
２回目のセッション（真中）では１ページ見た。
３回目のセッション（一番右）では３ページ見た。
そんな風に時系列、階層別で管理していることを表しています。
でまずスロットの概念が大切なので、スロットからご説明しますが、
スロットが５つ持てるのはお話したとおり。
で、その各スロットには、先ほどの階層モデルを入れることができます。
どういうことかというと、こんな３つのレベルのクッキーが、
ユーザーにセットされるのだと思ってください。
—————–
【スロット１のクッキー】
Ｖｉｓｉｔｏｒは？ 性別＝女性
今のセッションは？ ログイン＝ＹＥＳ
今見ているページは？ category=Life&Style
—————–
で、それはこれから手順を追ってご説明するので安心してほしいのですが。
もうひとつ事前にスロットで抑えてほしいことに、セッションとページの関係です。
先ほどの図のように、GoogleAnalyticsでは、セッションが別になれば、ページの計測も別になる、
つまりセッションの方がページよりも上位の階層である、という考え方があります。
そこで、仮に僕があるサイトを訪れた時に、
以下のようにクッキーをセットされたとします。。
１．トップページでは
—————–
【スロット１のクッキー】
Ｖｉｓｉｔｏｒは？ 性別＝男性 ※これは以前からセットされている永久クッキー
今のセッションは？
ログイン＝ＮＯをセット今見ているページは？
—————–
２．まずカテゴリー「Life&Styleを見たので。。
—————–
【スロット１のクッキー】
Ｖｉｓｉｔｏｒは？ 性別＝男性 ※これは以前からセットされている永久クッキー
今のセッションは？ ログイン＝ＮＯ
今見ているページは？
category=Life&Styleをセットして即trackでGAに飛ばす
—————–
３．ログインしたので。。
—————–
【スロット１のクッキー】
Ｖｉｓｉｔｏｒは？ 性別＝男性
今のセッションは？
ログイン＝ＹＥＳをセット
今見ているページは？
—————–
４．カテゴリーWine&Sakeを見たので。。
—————–
【スロット１のクッキー】
Ｖｉｓｉｔｏｒは？ 性別＝男性
今のセッションは？ ログイン＝ＹＥＳ
今見ているページは？
category=Wine&Sakeをセットして即trackでGAに飛ばす
—————–
ここで離脱します。
…
この場合、どのようにGAのレポートに表示されると思いますか？
ポイントは、僕の１回の物理的なセッションで、セッション変数「ログイン」がＮＯからＹＥＳに書き変わったことです。
この場合、GoogleAnalyticsとしては、物理的なセッションと論理的なセッション変数を統一して考えたいところなので、最初の『ログイン＝ＮＯ』は無視します。
つまり、今回のセッションは『ログイン＝ＹＥＳ』だった、というように管理します。
そうすると、下層にあるページは見なかったことになりリセットされますので、ログイン前に見ていたページ「category=Life&Style」は無視され、閲覧したというカウントはされません。
これは気をつけて設計しないと、思わぬ数の数え間違いをするので、注意しましょう。
つまり、３階層のモデル図を意識することはかなり大事だということです。
だから当然今回のカスタム変数は、どうとでも使えますが、
「Visitor=ユーザー」を中心に設計した方が断然わかりやすくなります。
５つあるスロットには、
各Visitor属性＝ユーザー属性を入れることができる
ってわけです。
では、以下考え方のステップを書きます。
ユーザーにどんなクッキーを埋め込んでいるのか、想像しながら読んでくださいね。
★マルチカスタム変数(setCustomVar)の使い方
■Ｓｔｅｐ１
ユーザーを５種類の属性にわけて考えたいとしたら、
どういう風にわけるかを考えます。
ここでいうユーザーっていうのは、
本当のユーザーという意味で、つまりは
Visitorレベルの話です。
例えば、初回アクセス元、性別、年齢、住所、購入者
っていった具合です。
これらはそれぞれ別のクッキーに保存され上書きされないので、
例えば、ぼくがセットされるのであれば、
スロット１：初回アクセス元＝Ａさんからのアフィリエイト
スロット２：性別＝男性
スロット３：年齢＝３０代
スロット４：住所＝神奈川県
スロット５：購入者＝ＹＥＳ
といった属性を同時に持つことができます。
これは今までから画期的な進歩。
更に、必ずしもユーザー属性だけじゃなくて、
先ほどもお話しましたが、例えば、こんな風にスロットを分けることも可能です。
スロット１：初回アクセス元
スロット２：性別＝男性
スロット３：途中でショッピングを諦めた？＝ＹＥＳ
スロット４：住所＝神奈川県
スロット５：購入者＝ＹＥＳ
スロット３をVisitor属性ではなく、セッションレベルで管理するのに使います。
どういうことかというと、スロットというのは、つまりユーザー毎に”区別できる数”のマックスなので、別にVisitor属性は空欄のままでも使えるってことです。
この場合、スロット３のクッキーはセッション単位で管理されるべきであり、
セッションの途中でショッピングを始めた瞬間に（つまりカートに入れた瞬間）にまずは値にＮＯにセットします。これでこのセッションは「ショッピング中」というフラグが立ちます。
でも、もしショッピングを途中で諦めた場合、つまり「やめるボタンを押した場合」はＹＥＳにするわけです。そうすると、このセッションは「ショッピングを途中で止めたセッション」として認識されます。
このように管理すれば、その人がショッピングを止めた後、どのようにそのセッション内で行動したのかが区別して見れるようになります。
こうやってセッションレベルで管理するのにスロット３を割り振る、っていうことです。
でも、この管理の仕方だと、途中でショッピングの決済プロセスを諦めた人が、いきなりブラウザを閉じた場合には、「ショッピングを途中で止めたセッション」としては管理できないですよね。
まぁでもブラウザを閉じた場合には、その後をトラッキングする必要もないので、別にＯＫとも言えます。つまり、ショッピング中のセッションだったけど、ゴールまでたどり着かなかった人、という計測になります。
なおセッション単位で管理されるので、スロット３のクッキーの値は、次回訪問時には当然クリアされています。
で、ここまでを踏まえて、実例でちょっとご説明していきます。
例えば、僕がＡさんからのアフィリエイトで
楽天サイトを訪れるとします。
でここは便宜上、楽天さんがGoogleAnalyticsを
導入しているとしてください。
その場合、楽天さん側の仕込みとしては、
そのＡさんから飛んでくるページに
こういう設定を入れます。
pageTracker._setCustomVar(
1, // This custom var is set to slot #1
"accessfrom", // The name acts as a kind of category for the user activity
"AsanAffiliate", // This value of the custom variable
1 // Sets the scope 1 to visitor-level
);
パラメーターの詳しくはまた後からお話しますが、
とりあえずは、１スロット目に
accessfrom（Access From：どこから来たか)
の属性を割り振り、AsanAffiliate(Ａさんのアフィリエイト）
を設定しています。
これで、僕のブラウザのクッキーに
slot1:Visitor:accessfrom=AsanAffiliate
が記録されます。
これはおそらくいつものＧｏｏｇｌｅだと、
永久（２年間）有効ですね。
で、Visitor要素としては、初回はこれで終わりです。
なんでかっていうと、残念ながらVisitor属性は
「次回のセッションから有効」
なんです。
つまり、初回のアクセス時にはマークしてくれません。
次回のセッションから有効なんです。
本当は楽天さん側としては、その後の行動を追いたいですよね。
例えば具体的にいえば、
asanAffiliateから来た人は、
キャンペーンページを見てくれるのか？
っていうことです。
でもVisitor属性は次回から有効なので、
このレポートの見方はできません。
仕方ないので、この場合は、今まで通り、
asanAffiliateから来た人が見るページの
「閲覧開始レポート」「ナビゲーションサマリー」などを見て、
その後、どのページに遷移していくのかを見るなどの対策をとります。
では、次回訪問時からを考えてみましょう。
次回訪問時には、僕の
slot1:Visitor:accessfrom=AsanAffiliate
属性は有効です。
では、その時にキャンペーンページを見てくれるのか？
その場合、各キャンペーンページに、
このページを見た、というセッティングを入れます。
つまりページレベルの設定です。
例えば、ポイントカードキャンペーンページに、
以下のような設定を入れます。
pageTracker._setCustomVar(
1, // This custom var is set to slot #1
"campagin", // The name acts as a kind of category for the user activity
"pointcard", // This value of the custom variable
3 // Sets the scope 1 to visitor-level
);
ここでポイントは
『スロット１』を使っているということです。
これも間違いです。
確かにこのように使えますが、
先ほどお話したように、
同一スロットの場合、AND条件ではレポートが見れません。
だから、このようにAND条件でレポート見たい場合は、
別スロットを使った方が賢明です。
そうすれば、あとからアドバンスセグメントで
AND条件で絞り込めると思います（まだ試していませんが。。）
設計ポリシーから考えれば、
なんかおかしいですけどね。。
重ね重ね残念です。。
（2009/12/8 追記）
キャンペーンページを見たというページ属性は、
スロット１のVisitor属性の下層なので、
当然同じスロットを使っても矛盾や間違いは生じません。
つまりこの場合のセッションでは、
asanAffiliateから来た人というカウントが１あがって、
pointcardというページを見たというカウントが１あがります。
で、さらにいきます。
仮に、ポイントカードキャンペーンページを見た後、
別の例えば旅行のキャンペーンページを見たらどうなるのでしょうか？
その場合は、
AsanAffiliateから来たというセッションは１、ページビューは２。
pointcardというページを見たというセッション＆ページビューは１。
更にryokouというページを見たというセッション＆ページビューも１です。
なんとなくつかめてきたでしょうか？
セッションの話はこれからしますね。
■Ｓｔｅｐ２
さて、先ほどは２回目のセッションで、２つのキャンペーンページを見たという考え方をしました。
例えば、僕がasanAffiliateから楽天にアクセスした後、２回目で
ポイントカードキャンペーンページと、旅行キャンペーンページを
見たわけです。
でも。。
通常はそんなことないですよね。
アフィリエイトからきたら、最初はポイントカードは見るかもしれないけど、
通常はそこで離脱して、また別の機会に訪れた時に、
今度は旅行ポイントカードを見るとか。。
つまり、セッション別に見たくなる。
いったい、どんなセッションの時にキャンペーンページを見るのか？
ってことです。
その場合に使えるのが、２階層目の
セッションなわけです。
例えば、先ほどの楽天のＡさんが紹介してくれた
アフィリエイトページに、以下のタグも同時に埋め込みます。
pageTracker._setCustomVar(
1, // This custom var is set to slot #1
"session", // The name acts as a kind of category for the user activity
"1stsession", // This value of the custom variable
2 // Sets the scope 1 to visitor-level
);
このようにしておくと、
僕のブラウザのクッキーには、
session=1stsession
という情報も保存されます。
先ほどのVisitor属性は次回セッションから有効でしたが、
このセッション属性は、その回から有効になります。
つまり、これは初回セッションだけで有効です。
そうすると僕が持っているスロット１の属性は
————————————–
Ａさんのアフィリエイトからきて、
且つ、初回のセッションだ
————————————–
という属性です。
で、この時にポイントカードのキャンペーンだけ見て離脱すると、
初回のアクセス後のレポートには
Ａさんのアフィリエイト経由のアクセス数：
accessfrom=AsanAffiliate は0 ※まだ次回セッションが始まってないから
初回セッション数：
session=1stsession は１
ポイントカードキャンペーンページを見た数：
campagin=pointcard は１
という値が記録されます。
次に僕が再訪問します。
そして、今度は旅行のキャンペーンページを見たとします。
今回は、セッション属性はセットしません。そうすると
Ａさんのアフィリエイト経由のアクセス数：
accessfrom=AsanAffiliate は1
初回セッション数：
session=1stsession は0
旅行キャンペーンページを見た数：
campagin=ryokou は１
という値がセットされます。
セッション属性は、物理的なセッション毎にクリアされるので、今回は初回セッションではないですよね。
こうやって、管理がされていきます。
この考え方を理解した上で、セッションレベルの管理をどう使うかを考え、それにどのようにスロットを割り振るかを考えます。
■Ｓｔｅｐ３
さて、今まで概念をお伝えしてきましたが、
決して今までお伝えしたのが効率の良い管理方法かというと、
そうではありません。
例えば、さっきのステップ２では、初回セッションをあえて、
今回のマルチカスタム変数で設定しましたが、実際は、
そんなものはＮｅｗＶｉｓｉｔｏｒ※新規ユーザレポート
（アドバンスドセグメントを使って）で見ればいいわけで、
別に設定する必要はありません。
つまりステップ３ではこういうことです。
「結局、どういう切り口でユーザーを区別して見たいかまとめる。」
どうがんばっても５種類しかスロットがなく、それ以上は分けられないので、
その範囲内で、Visitor,Session,Pageを意識し、効率のよいわけかたを考えないといけないというわけですね。
これが最終ステップです。
元も子もないですが、結局、最後は今までお伝えした概念をフル活用して、人が考えるしかないです。
ヒントとしては、今のサイトで何がわかったら嬉しいのかを考えて、まずは１つ目のスロットからやってみるということですね。全部を欲張らない。
あとは、わかりやすいVisitor属性だけをまずは使ってみる。
例えばぼくであれば、まだ米国GAにも導入されていないので、まだ具体的には使っていないのですが、計画としては、以下２つのユーザー属性を割り振ります。
————————————-
スロット１のVisitor属性に。。
一番最初にどこからアクセスしてきたユーザかをセット
スロット２のVisitor属性に。。
何かアクションを起こしたことのある（購入履歴のある）ユーザーか、否かをセット
————————————-
中小企業としては、これくらいで十分なんじゃないかと思うんですよね。
無理にセッションやページレベルの管理なんてしなくても。
もともとログイン機能がなかったり、そんなにページ数が多くないサイトが多いですからね。
ユーザー定義が２つ以上同時に持てるようになった！ってことだけで、十分なんじゃないかと。
で、この２つ。
１．最初にどこから来たユーザーか（どの媒体が効果的かわかる）
２．何かアクションを起こしたことのあるユーザーか（つまりお得意様かどうか）
で行動分析ができれば、かなり効率的にサイトの最適化ができると思います。
なぜなら、両者ともお金に直結する部分だからです。
今のＧＡのフラストレーションって、最初にどこから来たユーザーが
URL生成ツールをつかって、いちいちOverride属性を設定しなくちゃいけないこと。
つまり、Overture（今はYahoo!か。。）でいうところの「アシスト数」を取ることができない。
そうすると、どこに広告費をかければいいかわからないし、コンバージョンしたところばっかりピックアップしても。。って思っていました。
できれば、各スロットのクッキーの値ごとに、保存期間が設定できるといいですよね。
でないと、さすがに、２年前にＹａｈoo！から来たユーザーがコンバージョンした！Yahoo!がアシストした！ってことがわかっても、あまり意味がないですからね。
本当は９０日くらいで一回消滅してほしいです。
どちらにしろＧｏｏｇｌｅの本リリースでは、そういう設定があるのかも知れません。
とにかく、まだ本機能は見ていないので、凄く楽しみですね。
では長文で読みづらくてすみませんでした。
また本格的に使い始めたら、追記したりレポートします。
