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

全体の仕組み

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

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

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

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

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

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

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

複数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を３つ、aaa専用 bbb専用 aaa-bbb共用という形で用意して、専用の３つのプロファイルという形を用意します。

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

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

_setDomainNameの二つの機能

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

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

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

s1-test-analytics.com

s2.test-analytics.com

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

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

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

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

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

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

セッション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)となって欲しいです。

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

セッション１ s1を訪問。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/”)を一緒に使う形にします。

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

実際の例

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

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

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

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

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

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

まとめ

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

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

Google Analyticsの、他のサービスと違う有名な仕様として、外部リファラーが無い場合のリピーターのリファラー情報は、前回のリファラー情報とするというのがあります。

直接訪問は前回のリファラー情報でレポートとして上がるという事です。最初からノーリファラーなら、ノーリファラーですが。

僕は、他のアクセス解析サービスはよく知らないので、どちらが有用なデータ表示方法かは分からないのですが、GAの仕様を決定した人は、こっちが良いと思ってそうしたんだと思います。

この方法で良いなと思える点

本当は、ユーザー単位で、トラフィック情報の変遷を見ることが出来れば、万事解決なのですが、GAは大きな会社のサービスなので、いろんな事に配慮しなければならず、ユーザー単位のトラフィック情報を見ることはできません。ユーザーグループを作って、カスタム変数に記録すれば、グループ単位では見られるようになりますが、それは置いておきます。

それで良い点はというと、直接訪問を必ず、どこかの参照元の情報に帰属させてる点です。アクセス解析の目的は、コンバージョンの向上にあるわけで、その要因となる流入元情報の寄与を割り振ってるわけです。２，３回目は、bookmarkから来たんだろうけど、一回目は、、、というデータ処理を省くことができるわけです。

もちろん、リピーターは、複数の外部サイトからやってることも多いわけで、その場合は上書きされていくので、きちんとした？データにはならないわけですが。

参照元別の残存率 = コア化するユーザー率を見る

訪問回数と参照元情報をディメンジョンに、セッション数を指標にします。

データは、仮想の数字です。サイトの数字を参考にして、乱数を降った擬似的なデータです。 縦軸（Y軸)は、１０の対数です。４なら１万。2なら100。 ２，３回目までくるのは、1%とかの世界ですね。１以下で10以下です。

あと、データ集計期間の長さによってデータが偏るので、そこも注意した方が良いです。その集計期間の訪問回数というのは、Google Analyticsでは出せないです。出る数字は、全ての測定期間で、何回目の訪問だったかです。

参照元別で残存率が違う場合、主要な参照元の５回目残存率なんかは、気にしても良いかもしれません。この場合だと、Eなんかは2.8(630くらい)から1.8(63くらい)くらいと、１０％くらいは残ってくれてます。ほかは、Dなんかは、５回目で、3(1000以上)から１以下(10)になります。

最終的には、コンバージョン率と絡めて、数字を吟味する必要はあるのですが、参照元によって残存率が違う、訪問回数が進むにつれ、1/10, 1/100になっていくけど、参照元に依っては生き残る率が高いのがあるのを気にするのもいいかもしれません。

Google Analyticsのノーリファラーを前回のリファーラー情報に割り振る仕様も、こういう見方をする場合は、データ処理が楽だと思います。

もちろん、あるユーザーの二回目セッションは参照元がAで、三回目はBという事もあるので、訪問回数の残存＝ ユーザーの残存率 とはならないですが、ある程度は類似するはずです。また、このデータ集計期間に、一回目が入らずに二回目から登場のパターンもありえます。GAは、ある期間内で、何回目の訪問だったかは教えてくれません。

ということで、参照元別に訪問回数別のセッション数を見て、この参照元はコアのユーザーに成ってくれやすい。 裏を言えばリピートしない、というのを把握する話でした。

実はどこかのサイトのデータ整理をしてて、対数グラフにしたら、それなりに見えたので、blogを書きました。 底を求める方法が分からず、何回か検索した。中学生の僕が見たら、僕を殴りに来たかも、、、630 => 10^2.8 は、頭に出なかった、、、

前回、スクロール計測のレポートを自動配信する話を書いたのですが、今回は、Google Analtyicsのページ遷移データをグラフ化してメール配信する話です。

同じく、google apps script + google chart api でのメールによるレポート配信です。

AuthSubでの作成も作りました。試してみてください。

Google Analyticsにおけるページ遷移のデータ

あるページにおける、遷移上の前後のページは、WEBのレポート画面で見ることができます。ナビゲーションサマリーですね。ナビゲーションサマリーの数字の見方は、以前Wikiの方に書きました。

WEB上のレポート画面では、重複ページの回数を抜いて、パーセンテージにして表示してます。(移動先のデータ(nextPage)のデータがよく分かってないのですが、、)

今回は、Data Export APIでデータを持ってくるので、重複ページを抜かないとと思っていたら、uniquePageviewの数字がそのままの数字なので、端折って、uniquePageviewの数字を使いました。uniquePageviewを使う妥当性について、Forumなどで質問があったみたいですが、数値を見る分には大丈夫そうなので、uniquePageviewを使います。単に重複を抜くためだけですが。

とにかく、ディメンジョンに, “priviousPagepath”と”nextPagePath”。指標に uniquePageviewを使います。

Google Chart APIの GraphViz Chart

前回のデータを表示する時に、chart apiの文書を見てたら、おもしろいチャートの種類を見つけました。 Connectivity graphsとかいてあります。日本語だと 連結グラフ？

これも、パラメータを指定するだけで、グラフをimageにして返してくれます。またしても、パラメータの設定が難しかったのですが、PDFの説明書みたいなのを見ながら設定してみました。微妙に chart apiでの記述と、h本家の記述と違う部分もあると思います。subGraphも設定できるみたいで、それでクラスター表示みたいなのをしようと思ったけど、Google Chart Api側で、動くように設定する方法がわかりませんでした。(* google chart apiでの方法を知っていたら教えてください。)

前回も書きましたが、http://code.google.com/apis/chart/docs/chart_playground.htmlでできるチャート図を確認しながら、設定をいじれるので、便利です。

とりあえずの例

それで、実際にこのサイトのデータで生成してみました。メールレポートの場合は、google apps scriptでHTMLメールを使って、scriptの自動実行時間を指定すれば良いです。参考に、ちょっと違うけど、フォーム受付けを自動返信する話です。今回は、これを時間指定にするだけです。

できたimage画像です。 (画像クリックでできたURLそのものに遷移します)

閲覧開始数のベスト８ページのデータと、ページ遷移の組み合わせで数が多かったベスト１０のデータを抜き出してます。頭に数字があるのは、そのページの期間内の閲覧開始数です。矢印線上にある数字がページ遷移の数です。 数字だけの奴(_108_)は、indexページです。閲覧開始数が108でした。

（自分自身に返ってる奴は、データの初期段階でパラメータが違うものをカットしたせいです。処理が粗いです。説明もゴニョゴニョですが、、）

サイトオーバーレイもいいですが、サイト全体のユーザーの動きはコチラのほうがイメージし易いと思います。

気を付ける点としては、上のリンク先の記事でも説明してるのですが、セッションベースのデータでないので、遷移の数は、ランディングからすぐに遷移した数ではないです。 secondPagePathもデータとしてはあるので、そちらでもグラフはかけそうではあるのですが、、、

あと、chart apiで生成できるピクセル数の大きさは、縦×横で、300000pxまでなのですが、このgraphVizでできるデータはそれを超えてます、、、、また、これはexperimentのマークがついてるので、仕様変更の可能性もありそうではあります。

それでも、自動化できたので、データを見せていただける方には、メールで日次配信します（コメントで遷移図希望と書いて下さい)。今回のは、Google Analtyisの初期設定で取れるデータなので、閲覧権限をもらえれば、それでOKです。 Auth認証でのデータ表示に対応するのは、詳しい人なら簡単にできそうなので、そういう人に任せます。

前回、スクロール率をgoogle analyticsで計測した話を書きました。 レポート部分は、エクセルでの表示だったんですが、今回、自動化のひとつの方法として、タイトルの方法をやったので、報告します。

Google Apps Script(GAS)は、かなりの便利ツール

データを外部から引っ張ってきて、加工して、メール配信というのが、割合簡単にできます。

今回は、google analyticsのデータを引っ張って、加工して、HTMLメールで配信という形の紹介です。

GASの記述は、javascriptです。 google analyticsの集計の設定も javascriptですので、 javascriptは習得しがいのある技術かもしれません。

手順としては、URLFetchで google analytics Data Export  Api からデータを取得して、それを google chart apiを使って、 HTMLメールで送る作業です。

Google Chart APIも、自動化ツールとして価値大。

URLを指定すれば、チャート画像を返してくれます。

ですので、変化する数字を自動的にグラフ化してレポーティングしたい場合に価値が高いです。

パラメータがたくさんあって、マニュアル(解説)が英語なのでとっつきにくいですが、データ、チャートタイプ、ラベル、軸、などの概念とapiでのパラメータが一致すれば、それなりに使えるのではと思ってます。

別別サイトにメモみたいなのを書きましたが、、、あまり参考にならないかも。

GMailの問題？

いろいろいじって、なんとか自動化にこぎつけたのですが、GmailのHTML表示の時に、imageタグの部分が上手く表示されなくて、いろいろ探したのですが、結局あきらめました。 たぶん、文字数の問題のような気がしてるのですが、、、どうなんでしょう。 Yahoo Japanの Web mailなら問題なかったです。

出力画像と スクリプトを貼りつけます。

スクロール計測とそのレポート配信を試してみたい方は連絡下さい(コメントでスクロール計測希望と書いてくだい)。 設定して、週次 or 日次で、特定のディメンジョンで切ったスクロール率のよる閲覧割合をメールレポーティングします。無料です。 以下の画像のような形でのHTMLメールが送られます。

画像レポートの後に、参考に、GASのスクリプトを貼りつけておきます。 貼り付けた以外にも追加の定義(関数、代入式)などがあるので、全部ではないです。

/measure_how_much_viewed_in_google_analytics

/what_are_visits_entrances_uniqueviews_pageviews_in_google_analytics

/

以下、レポート配信に使ったscriptの一部。

   1:  function CRReport(id,name,title,address){

   2:    //id = "ga:21600568", name="shirai", title="wordpress", address="kimiyuki[at?]gmail.com";

   3:    var startdate; var enddate; var dimensions = []; var metrics = []; var filters = ""; var segments = "";

   4:    var entries; var sort;var data;

   5:    var tmp;

   6:    var siteurl;

   7:    startdate = getMyDate(-15); enddate = getMyDate(-3);

   8:    dimensions = ["ga:pagePath,ga:hostname"]; metrics=["ga:visits"]; sort=["-ga:visits"];

   9:    entries =  getDataFromApi(id, startdate, enddate,dimensions, metrics, filters, segments, sort);

  10:    pagePaths = [];

  11:    entries.slice(0,3).forEach(function(entry){

  12:      var el = entry.getElements("http://schemas.google.com/analytics/2009", "dimension");

  13:      el.forEach(function(e){

  14:        if(e.getAttribute("name").getValue() == "ga:pagePath") pagePaths.push(e.getAttribute("value").getValue());

  15:        if(!siteurl && e.getAttribute("name").getValue() == "ga:hostname") siteurl = e.getAttribute("value").getValue();

  16:      });

  17:    });

  18:  

  19:    data = {};

  20:    var w1 = [null,null, null]; var w2 = [];

  21:    pagePaths.forEach(function(path){

  22:      Utilities.sleep(500);

  23:      w1 = [null,null,null], w2=[];

  24:      var dim_sg = "ga:medium";

  25:      dimensions = ["ga:eventCategory", "ga:eventAction", "ga:pagePath",dim_sg]; metrics = ["ga:uniqueEvents"]; sort = null;

  26:      filters="ga:eventCategory==CompRead0523B;ga:pagePath==" + path;

  27:      segments=null;

  28:      entries = getDataFromApi(id, startdate, enddate, dimensions, metrics, filters, segments, sort);

  29:      entries.forEach(function(entry){

  30:          var ds = entry.getElements("http://schemas.google.com/analytics/2009", "dimension");

  31:          var es = entry.getElements("http://schemas.google.com/analytics/2009", "metric");

  32:          var w = new Array();

  33:          ds.forEach(function(e){

  34:            if(e.getAttribute("name").getValue()=="ga:eventAction") w1[1] = parseInt(e.getAttribute("value").getValue().replace("z",""));

  35:            if(e.getAttribute("name").getValue()== dim_sg){w1[0] = e.getAttribute("value").getValue();}

  36:          });

  37:          es.forEach(function(e){

  38:            if(e.getAttribute("name").getValue() == "ga:uniqueEvents") w1[2] = parseInt(e.getAttribute("value").getValue());

  39:          });

  40:          w2.push([w1[0], w1[1],w1[2]]); //値にして設定するため

  41:          w1 = [null,null, null];

  42:        });

  43:      w2 = w2.sort(function(a,b){return a[1] > b[1]});

  44:      if(data[path] == null) data[path] = [];

  45:      data[path] = w2.map(function(x){return x});

  46:        //data[path] = w2.map(function(e){return [e[0], Math.floor((e[1]/total)*100)]});

  47:    });

  48:   // Logger.log(data);

  49:    html = outputChart(data, startdate, enddate, siteurl);

  50:    Logger.log(html);

  51:    MailApp.sendEmail(address, "CompRead","html mail", {cc: "kimiyuki[aat]gmail.com", htmlBody: html});

  52:  }

  53:  

  54:  

  55:  function outputChart(data, startdate, enddate ,siteurl){

  56:    var html = "<div>" + startdate + "から" + enddate + "のセッション数上位３ページの精読率調査です。数字はセッション数です。</div>";

  57:    for(e in data){

  58:      //Logger.log(e);

  59:      //Logger.log(data[e] instanceof Array);   

  60:      //Logger.log(data[e].length);

  61:      //Logger.log(data[e].toString());

  62:  

  63:      //making dimentionable data    

  64:      var dimmed_data = data[e].reduce(function(r, x){

  65:        if(r[x[0]] == null){

  66:          r[x[0]] = x[2];

  67:        }else{

  68:          r[x[0]] += x[2];

  69:        }

  70:        return r;

  71:      }, {});

  72:      //Logger.log(dimmed_data.toSource());

  73:  

  74:      var tmp = [];

  75:      Logger.log("object="); Logger.log(dimmed_data.toSource() + "\n");

  76:      for(c in dimmed_data){tmp.push([c, dimmed_data[c]])};

  77:      dimmed_data = tmp.sort(function(a,b){ return a[1] < b[1]});

  78:      Logger.log("dimmed_data=");

  79:      Logger.log(dimmed_data.toString()+"\n");

  80:      var label = data[e].map(function(x){return x[1]}).unique();

  81:      var data1 = data[e].filter(function(x){return x[0] == dimmed_data[0][0]}).map(function(x){ return x[2]});

  82:      var data2 = data[e].filter(function(x){return x[0] == dimmed_data[1][0]}).map(function(x){ return x[2]});

  83:      var data3 = dimmed_data.length < 3 ? "" : data[e].filter(function(x){return x[0] == dimmed_data[2][0]}).map(function(x){return x[2]});

  84:      //Logger.log(label);

  85:      //Logger.log(data1);

  86:      //Logger.log(data2);                                       

  87:      //html += "<tr><td>" + e + "</br>" + data[e].map(function(x){return x[0] + '=>' + x[1]}).join(',') + "</td></tr>";

  88:      html += "<div><div>";

  89:      html +=  makeChart(label, data1, data2,data3, dimmed_data[0][0], dimmed_data[1][0], (dimmed_data.length > 2 ? dimmed_data[2][0] : ""));

  90:      html +=  "</br>";

  91:      html += "<a href='http://" + siteurl + e + "'>" + e + "</a></div>";

  92:      html += "<div>　　</div>" //全角空白を入れた。間隔を作るため

  93:    }

  94:    html += "</div>";

  95:    return html;

  96:  }

  97:  

  98:  function makeChart(label, data1, data2, data3, dataLabel1, dataLabel2, dataLabel3){

  99:        var max = data1.concat(data2).reduce(function(r, e){return r > e ? r : e;}, 10);

 100:        var chds = "chds=" + "0," + max;

 101:        var chxr = "chxr=1,0," + max;

 102:        var chco = "chco=4d89f9,c6d9fd" + (data3 != "" ? ",63C6DE" : "");

 103:        var chdl = "chdl=" + dataLabel1 + "|" + dataLabel2 + (dataLabel3 != "" ? "|"+dataLabel3 : "");

 104:        var chm = "chm=N,000000,0,,12,0,e|N,00FFFF,1,,12,0,e" + (data3 != "" ? "|N,0000FF,2,,12,0,e" : "");

 105:        var url =

 106:            "<img style='display:block;' src='http://chart.apis.google.com/chart?cht=bhg&chs=250x" + (dataLabel3 != "" ? "990" : "660") + "&chd=t:" +

 107:            data1.join(",") + "|" + data2.join(",") + (data3 != "" ? "|"+data3.join(",") : "") +

 108:            "&" + chds + "&" + chxr + "&" + chm + "&" + chdl + "&" + chco +

 109:            "&chxt=y,x&chxl=0:|" + label.reverse().join("|") + "&chxs=0,ff0000,12,0,lt|1,0000ff,10,1,lt'/>";

 110:    //Logger.log(url);

 111:    return url //.replace("&", "&");  

 112:  

 113:  }

次のページへのリンクをクリックという行為は、

1. そのアンカーテキストに目の焦点を併せる
2. マウスを叩く
3. リンク先のページがloadされる。

という順番で進むと思います。

速読の練習をした人はよく分かると思いますが、１の行為は、文字を探し・焦点を合わせるという、非常にコストのかかる行為です。読むという作業においては。。文脈を追う作業は超短期記憶のつなぎ合わせで、意識のallocation作業は天敵です。

一方で、アクセス数字を見たい人に取っては、ページ単位の計測が基本である以上、ページとコンテンツの粒度は一致してる方がいいと思ったりします。<h2> <h3>といった見出し単位での閲覧率を知りたいと思ったりすると思います。閲覧時間の方が知りたいかも、、、 とにかく、ページ閲覧量と滞在時間ではなくて、コンテンツ消費量とコンテンツ消化速度を知りたいとか思うと思います。

ヒートマップ使ったり、細かく計測タグを作れば、データは得られそうですが、面倒です。

で、とりあえずの一歩として、ページ全体でどの割合までページが表示されたかを、google analyticsで計測してみたので、その経過を書きます。

EventTrackで、表示領域割合をアクションとして送る。

当初、表示割合を計測するのに カスタム変数のページスコープ変数を使えばいいのかと思いました。上手く説明できないのですが、ページスコープは使いにくい機能(*)なので、前に使った手法(ページ別閲覧時間分布の作成)と同じような手法のtrackEventを利用する方法でやりました。

* ページスコープのカスタム変数を設定してtrackPageviewで送ったら、それは新規のページビューになってしまう。動的な行動記録をアトヅケで送れない。

それで、方針としは、

1. 一秒毎に、画面の表示位置(割合)を取得。
2. それが、そのページ閲覧中で最大値を超えていたら、trackEventする。
3. １０％単位で区切る。google analyticsでは集計値しか取れないので、値は積み上げで送る。
   • ３０％まで閲覧されたというデータを送る場合には、0, 10, 20, 30 と送る。
   • なんとなくだけど、データの連続送信制限があった気がしたので、少しsleepを入れておく。
   • このサイトのrs.jsという奴です。データを送る順番をコントロールするために、jsdeferred.jquery.js をいれました。このサイトの説明を参考にした。

データを見る : totalEventsとpageviews

eventの数字を見るときは、totalEvents(イベント数)と uniqueEvents(ユニークイベント数)の二つを見ますが、uniqueEventは、セッション内の同一カテゴリ・アクション・ラベルを一つ(distinct)にします。

自作のDataViewerで見たところ。labelにページURL(path)を入れていたのですが、ディメンジョンとして pathPathも有効なので、labelは他の用途に振り向けてもいいかもしれません。

ちなみに、ABテスト別に見たい時は、カスタム変数を出してフィルタリングします。

ちなみにこの自作ツール、チョコチョコ改良してます。、カスタムレポートを組むより、操作時間は短いはずです。 日別のデータ作成には便利です。 GAのレポート画面だと、日別のデータをグラフにしてくれますが、数字で出すには、カスタムレポート組まないといけない。

レポート化

アクセス解析サミットで清水さんの講演を見て、スクロール計測のレポートの形式を真似ました。

画像にパーセントで線を入れるのにbookmarkletを実行、画像を撮って、エクセルでrept関数。

javascript:hg=document.height;wd=document.width;for(var i=1; i<10; i++){dv=document.createElement("div");dv.innerHTML= "<hr style=’color:#f00; background-color:#f00; height:5px;’/><strong>"+(i*10).toString()+"Percent==></strong>";dv.style.position="absolute";dv.style.top=parseInt((i/10)*hg).toString()+"px";dv.style.left="0";dv.style.width=wd+"px";dv.style.zIndex="1000";document.body.appendChild(dv.cloneNode(true));}

このbookmarkletは適当に作ったもの。 ページ全体画像撮りは、このchromeのextensionを使った。

このレポートを自動化するには、

bookmarklet実行 + 画像収集 ＋ データ抽出 + どこかで画像オブジェクトにする

という作業が必要。

Google Analtyicsで、trackEventを使って、ページのスクロールの割合を見て、レポートにするまで、でした。 アクションは知らない。

Google Analyticsの Data Export APIからデータを引っ張るソフトを作った。

Visual Studio 2008 express editionのPublish機能を使って、パッケージ化した。.Net Framework 3.1 SP が必要。ただ、SetUp中にDownloadされるはず。

作った動機

1. なぜか、web上の Data Feed Query Explorer で、日本語が文字化けするようになった。 フォーラムに投稿したけど、英語力の問題もあって、上手くasset出来なかった。

2. .NETの ライブラリーが更新されたのとのニュースがあった。

ので、今まで、ruby や python や apps script で やってたけど、GUIで使えるソフトにも挑戦しようとして、やってみた。 ちなみに、windowsソフト( visual Studioを使って作る)のは、ほぼ初めてなので、UI、機能、エラー処理とかは、プリミティブです。検索や2chなどを見ながら、コピペなどをしながら作ったものです。

出来ないこと

Data Feeds の方のデータを引っ張ってこれるようにしただけです。 Account Feedsの方は、profileを引っ張れるだけです。本当は、Account Feedsの方で、ゴールの設定やら カスタム変数、アドバンスセグメントの設定などが、引っ張れるれのですが、やってません。

できる事は、profileIDを指定して、そのprofileのデータを取得するだけです。 用途としては、データをコピーして、エクセルに貼り付けるといいと思います。(unicodeテキストの貼付けを選ぶと文字化けしないはずです)

注意

Data Export APIの制限に注意して下さい。たくさん使うと制限に引っかかるようです。

あと、Dimensionは７つ、Metricsは10が一度に取れる上限項目数です。また、Dimension, Metircsの組み合わせで、データ取得不可のものがあります。これらの場合は、このソフトの上のテキストボックスにある、Error Messageに、そのようなメーセージが出るはずです。

僕の事を悪意を持ってない人だと信頼できて、ソフトの不出来を許容できる方に使ってもらうのが望ましいです。ただ、いろいろ感想を言ってもらえれば、改善へのモチベーションになるので、なにかあれば、@phar までおっしゃって下さい。

使い方

メールアドレスとパスワードを入れて、GetProfiles ボタンを押すと、自分の管理・閲覧できるprofilesがでます。

その後で、データが欲しいProfileのIDをクリックして、選択した状態にして、getDataを押すと、データ取得です。 下の GridDataViewという所にデータが出力されます。 後は、全選択してコピーして、エクセルで、形式を選択して貼付け- unicodeテキストでの貼付け を選ぶと、日本語の問題なくペーストできると思います。

あと、記録するにcheckを入れると、メールアドレスとパスワードを保存します。逆に、空欄にしてからcheckを入れれば、以前に記憶されたものが、空白で上書き(消去)されます。

実際に使っているキャプチャーは、wikiの方に上げるつもりです。

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

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

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

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

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

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

数字を見る

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

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

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

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

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

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

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

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

アナロジーは、

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

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

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

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ならこんなスピードはでない？ 知らないし、理解できないけど。 このデータ処理のレスポンスタイムはすごい。

GWOは、Google Website Optimzer。GAは、Google Analytics。ともに、Googleが提供するウェブサイトの効果計測の為のツールです。この二つのツールの使用は、機能として非常に似ているので、両者の良い部分を併せてみようと言うのが、今回のエントリーです。ちなみに、GWOで何をOptimize（最適化)するのかというと、コンバージョンレートを最適化（ためのテスト)します。A/Bテスト、もしくは多変量テストで数字を見比べて、適するテストを選択するわけです。

まず、両者の比較から入ります。

GAの方が分析用の機能は豊富

GWOは、ユーザー単位(cookie)でのコンバージョンを測るという機能を提供するのですが、同じことは、GAでもできます。カスタム変数をユーザーレベルで設定すれば、そのユーザーグループでのコンバージョン率も測れます。

さらにGAは、Analyticsとウタッテルわけですので、他の指標もグループ別に分析できるわけです。

ユーザーグループ別の、滞在時間、テストページ以外の閲覧ページなどが可能です。さらに、trackEventを発行していけば、javascriptが補足するイベントをどんどん計測できるわけです。trackEventは、４つのパラメーターをとれますので、その中にsetTimeout, setIntervalなどで時間の値を組み込んでもいいです。そして、これらを、ユーザーグループ別に計測できるわけです。また、フィルター機能で自分のアクセスを除外したりするのも簡単です。

しかし、GA単独で事が足りるか？ というと、そうも行かないかもしれません。

GWO側の優位点は？

実は、GWOにあまり詳しくないので、自信がないのですが、GWOの利点は、

• テストの実装が簡単
  • 基本は、オリジナルページにcontrol scriptを埋めてやると、そこでテストページの振り分けをしてくれる。GAは、自分で作る必要がある。
  • 特に、多変量テストは、自前で作ったり、管理するのは大変だと想像します。(やったことない、、)。Follow-up Experimentという仕組みもあるようです。よくわからないけど、多数の組み合わせの中の勝ち残りと、オリジナルで、最終確認テストができるという意味？
• 結果の解釈に説得感がある
  • 統計の解釈なので、みんな自信がないと思います。僕もないです。勝ち、負け、と示してくれるのは大きいです。A/Bテストの判定については、以前エントリーを書きました。
  • 上で書いたFollowUpテストがついているので、説得力あるレポートができる。
• なんとなく安心
  • GAで、cookieに依って違うページを見せるのは少し気持ちが悪いです。検索エンジンに良く思われないのではないか？と思ってしまいます。GWOだからOKという理屈はないですが、なんとなく安心ではあります。

とGAとGWOの利点を見ました。以後、両者の利点をいいとこ取りに挑戦です。

手順

GWOでテストを作り、そのGWOのcookie値をGA側のカスタム変数に入れて、GAでも分析できるようにします。GWOには、combination関数というのがあって、テストの振り分け判別用の値が取れるみたいですが、オリジナルページ(control script内)でしかとれないようです。MVTを行う場合には、ページ振り分けがあるわけではないので問題ない。　ですので、関数を使わずにcookieを直接読んで、値を設定することにします。

具体例は省略します(＊このサイトのトップページが、現在テスト対象になってます。そのうち外します)。

GAと同じです。ウェブプロパティIDが違うので、別々にキチンと設定してやればいいはずです。

今、WEBで検索していて見つけたのですが、Poor man’s GWO/Analytics Integration のやり方がいいです。いろいろ改善点があるのですが、カスタム変数に入れるのではなく、ユーザー定義に入れておけば、セカンダリーディメンジョンで見られるので、アドバンスフィルターで検索するなりして、手早くレポートで確認ができると思います。他にも、改善点がいろいろとあるようです。”いつかやる”にしておきます。

レポート画面

ユーザー定義ではなく、カスタム変数に入れてしまったので、レポート画面が面倒くさいですが、カスタムレポートで見たい指標を並べておいて、ゴールのページを通過したセッションをアドバンスセグメントで、括り出しておく形ですがいいです。ユーザー定義を使った場合は、ゴールのページで、ユーザー定義をみればいいと思います。

GAでは、コンバージョン以外の指標を見られるのが、アドバンテージ。

GWOの方は、

GWOでは、統計的な判断をしてくれたレポートにしてくれるのが、アドバンテージ。

GAとユーザーの母数が違いますが、GAの方で当初設定ミスをしたせいだと思ってます。また、GWOの方はフィルターが使えないので、自分のアクセスを除外できないと思います。GWOとGAで完全の統合してしまえばいいとも思いますが、冒頭で挙げたGWOの利点とバッティングするのかもしれません。

*） wordpressでテストを作る時は、ページのテンプレートを作って、そこにコントロールスクリプトを入れてページを作る。そして、もう一つの方は、別にテンプレートを用意する形になるのかもしれません。最初、両方にコントロールスクリプトが入っていて、ページがリダイレクトループみたいになってしまいました。CMSを使っていると、普段は便利なのですが、こういう時は、”調べるコスト”が発生しますね。 同時に”設定ミスリスク”もある所が怖いです。

カスタムレポート作成

ディメンジョンを日別にします。指標は、閲覧開始数、滞在時間、直帰率にしておきます。

サブディメンジョンは入れてもいいですが、入れなくてもいいです。とりあえず使いません。

レポートに戻ったら、セカンダリ－ディメンジョンを参照元にします。

これで、参照元のセッション数、平均対座時感、直帰率がでました。でも、検索エンジンはいらないですよね。

検索エンジンと直帰をしたセッションをアドバンスフィルターで除きます。

セカンダリ－ディメンジョンの参照元で絞り込みます。”文字を含まない” で、google|direct|yahoo|reader とします。

(*他のキャンペーンなども必要に応じて除いてもいいですし、最後のエクセルで除去してもいいです)

フィルタリングできました。

これをファイルにエクスポートして、エクセルで開いてピボットにします。

すかすかですが、エクセル上なので、データの絞り込みなどは容易だと思います。

このエクセルは試用版ですが、スライサーというのを使うと、

フィールドを個別に選びながら表示できました。さすがエクセルですね。

参照サイトはわかったけど、そのサイトの”どのページ“から来たか分からないじゃないか？

ですよね。カスタムレポート作り直しましょう。

サブディメンジョンに参照ＵＲＬを加えて、レポートを出した後に、特定の日を押すと(下図では3月１日)

データはでましたが、今度はドメイン名が出てないです。。。参照ＵＲＬは、”/” 以降の部分しか表示しません。(その場合、参照URLという名前でいいのだろうか？？？)

もちろん参照元　> 参照ＵＲＬという形でカスタムレポ－トのディメンジョンを組み立てれば、クリックして特定のサイトのページ名はだせます。しかし、特定の日 > 特定のドメインで、そこに限定された参照ＵＲＬが見られるだけです。という事は、一括した形でデータをエクセルに落とす事もできません。一日ごと  > サイトごと> にやればいいのですが、大変です。

Data Export APIを使う

Data Feed Query Explorerを使う

http://code.google.com/apis/analytics/docs/gdata/gdataExplorer.htmlに行って、

上のidsの所には、通常のウェブで見てる時に、ブラウザのＵＲＬを見ると、id=xxxx とあるので、それを入れて下さい。プロファイルIDです。あとは、ブラウザをFireFoxにして、table2clipboardというAddOnを入れると、コピーしたものがエクセルにそのまま張り付きます。(* データ数が多いとブラウザが固まるかもしれません。数千件ぐらいのデータは気を付けるべきです)

エクセルに行くのは省きます。

Google Apps Scriptを使う

もちろん、他のスクリプト言語でデータを取り出してもいいです。Google Appsを使っているとGoogle Spreadsheetに apps scriptというエクセルでのVBAみたいなものがあるのですが、それだと、データを集めてspreadsheetにも出力できますし、同時にmailを送る事もできます。(Google Apps Scriptを使って、Google Analyticsのデータを出しているところ)

スクリプトの中で、MailApp.sendEmail()と書けば、メールも送信できます。

スプレッドシートなので、この図のＢ列とＣ列を足して上げれば、参照元のＵＲＬ全体が表示され、訪問回数、直帰数、滞在時間などがでます。もちろん、コンバージョンなどもだせます。

と言うことで、Google Analyticsでデータの整理にお悩みの方は、データ整理のご相談の連絡を下さい。サイト運営は素人ですが、データの集計や整理を一生懸命やります。

カスタムレポートでもデータ出せるよ！ という方法をご存じの方があれば、コメント頂けると嬉しいです。