ページ遷移データをグルーピング化する

フォーラムで質問を見かけました。
パラメータが付いたURLで、パラメータを除いた合計での遷移数
GAのウェブUI上でページグループの遷移のセッション数を出す方法も回答してありますので、上記のリンク先をご覧下さい。

ページ間の遷移データ(pageviewが指標となる)をいろいろな条件でグルーピング化するという命題だと思います。

この間作った自作のツールを使うと便利にできます。
データ項目は、指標: pageviews ディメンジョン:previousPagePath, nextPagePath
(*nextPagePathはpagePathでも同じ)
PV数ベースではなく、セッション数ベースの値が欲しい時は、指標をuniquePageviewsにして下さい。
その後、expression filterというところで、LIKE演算子を使って絞り込みをします。

ggplot2でお手軽ヒートマップ

式とグラフの備忘録です。

時間系列の記憶は、人間の記憶の中でも頼りになる方。超整理法のアドバンテージは、ここにあったはず。 で、月間レポートを書く場合に、時間系列のヒートマップだと、人間の記憶とレポートの記録が、上手くつながる気がする。なので、ヒートマップ(時系列)が好き。

ggplot2は、簡単にヒートマップが出せる。

例として、このブログのGoogle Analyticsの4月のデータ。
時間、日付け、訪問数、平均PVの4つが入ったデータフレーム。

R> str(abc)
‘data.frame’:    720 obs. of  4 variables:
$ hour  : int  0 1 2 3 4 5 6 7 8 9 …
$ date  : Date, format: “2011-04-01” “2011-04-01” “2011-04-01” “2011-04-01” …
$ visits: int  1 1 0 0 1 0 1 0 2 3 …
$ apv   : num  1 1 0 0 1 0 1 0 1 1 …

ggplot2を読んで、ggfluctuation。データ型は、テーブル型でもいいし、3カラムのデータフレームでもいい。今回は、まずはapv(average-page-views)を抜いて、3カラムデータフレーム。

library(ggplot2)
ggfluctuation(abc[,-4], type=”colour”)

color-heat-map-google-analytics-data

でも、ggfluctuationのヘルプを見ると、type=colourは traditionalの形だそうだ。

今は、大きさそのものを出す方が良いという認識?

ggfluctuation(abc[,-4])

size-heatmap-google-analytics-data

 

ただ、ggfluctuationは、拡張性?に乏しいような気がする。
geom_pointでcolor, sizeを指定して、4種類のデータ(時間帯、日付、訪問数、平均PV)を示す。

ggplot(abc, aes(hour, date, colour=apv, size=visits) + geom_point()

赤みが付くと、平均PVが高い。大きさは訪問数。
セッションの量と質と、時間帯+日付を示す。

今回は、セッションの質を、平均PVにしたけど、
ECサイトなら売上(セッション辺り)とか、CVRとかを使えば良い。直帰率でもいい。

size-color-heatmap-google-analytics-data

アドバンスセグメントで擬似加重ソート(Excel のTable機能)

Google Analyticsだけに限らないTIPSですが、簡単でそれなりに実用的に使える方法だとおもうので、紹介します。

2010年の秋にGoogle Analyticsの加重並び替えが導入されました。Wikiの方の紹介。新機能として紹介されたに似た感じのものを、アドバンスセグメントでやろうとするものです。

ちょっとズルですが、APIでデータを取得するのが前提です。

APIでのデータの取得は、実は簡単で、

    1. Date Feed Explorerを使う(日本語だと止まるので、IDを直接入れる必要がある。)
    2. http://excellentanalytics.com/ を使う。
    3. //abc-analytics.com/data-feeds-query-explorer-in-windows-applicationを使う。

で出来ます。他にも、色々なツールがあります。

今回は、Cの自作ツールを使ってデータを取得しておきます。

閲覧開始ページ、キーワード、開始数、直帰数を取ります。

WS000033

で、タイトルの話のエクセルの貼り付けます。ここから、本題です。

コピペしたあとは、テーブルにします。

  • テーブル名を英語にします。大事です。
  • 一行目に数字を入れるので、空けておきます。

WS000034

もう少し、下ごしらえが続きます。

  • 直帰数になっているので、直帰率をいれます。
  • 一行目に集計値を出すようにします。
    • ここで、テーブル機能が行きます。

entrancesの集計値は、下図のようにススメます。

(テーブル名が英語だと補完が効いて、マウス無しで^^です)

WS000035 WS000036 WS000037

式は、=SUBTOTAL(9,table1[entrances]) になります。

同じようにbounces(直帰数)も計算します。=subtotal(9,table1[bounces]) ですね。

bounceRate(直帰率)は、この2つを割り算します。

ここで、もう一回、画像。

WS000038

ここから、本当の本題であった、加重ソートを入れます。

前提として、100回以上セッションがあった、キーワード+ページは、そのまま。ソレ以下のものを、全体の平均値と按分する方針です。

B1に 分かれ目の数字、100を入れておいて、TrueBounceRateの列を作りましょう。

WS000039

上の数式を説明します。

entrancesが100以上なら、その列のBounceRateのまま。なので [@BounceRate]

以下なら、全体の平均値(E1)と[@BounceRate]を 全体のEntrances(C1)と列のentrances([@enttances])で按分する。

([@bounces]/$B$1 * [@BounceRate] )   +   (1 – ([@bounces]/$B$1)) * $E$1

Googleの加重ソートは、たぶん似たような感じだと思う。

加重ソートはいろいろ本を読んだけど、理論的背景はよく理解できなかった。

2次元の正規分布の場合に、なんやからすると、上記のような単純な式でもOKという話だったと思うけど、よく理解できなかったので、公開レクチャーしれくれる人がいたらお願いします。@phar

で、ここまでは単に計算しただけど、ここからエクセルのテーブル機能が生きて来る。

ランディングページ単位のキーワードでの加重ソート、ある単語が含まれるキーワードデータの加重ソートとかが簡単にできる。

最初の画面で、

WS000040

landingを/api ディレクトリ以下のものに絞る。

WS000041

その後、TrueBouncecRateを昇順に。(自動で順列にならない、、、フィルターするたびに、並べ替えの必要がある。ここは、イケテナイ。)

WS000042

まあ、それでもそれっぽいソートが出来上がる。landingページを絞った上での、加重ソート。

今回は、ディメンジョンがキーワード、閲覧開始ページという組み合わせだけど、ソレは自分でデータを持ってくるときに好きに選べばいい。

また、加重平均の按分の中心になる平均値(直帰率)も、テーブルでフィルタリングすると、subtotalでそのフィルタリングされたデータの平均値で計算し直されるので、都合が良い。

あまり、データ数が少なくなるとだめだけど、そのデータ全体での平均値を適用して計算しなすのは、フィルタリング前のデータの平均値を持ち出すより適切なはずだ。

まとめ

google analyticsには、加重ソート機能がありますが、似たような事をエクセルでしました。

エクセルのテーブル機能を使うことにより、簡単に特定ディメンジョンの加重並び替え(条件は複数でもOK => アドバンスセグメント)ができることを図示しました。 これは、たぶん、今のレポート画面ではできないことだと思います。 ただし、並び替えのアルゴリズムは違うのでしょう。

冒頭のリンクにも 今回のようなことをやった記録があって(加重ソートが出始めたころに書いたやつ) 、実際の GAでの順番と比較したグラフがありますが、そんなにズレはないと思います。

そんなにってどんだけ? 主観です^^。前やったとき、順位相関とか計算してみたけど、それを用いるのが正しいのかさっぱり分からなかったし、数値も直感的に理解できなかったので、、、単純な加重ソートもGAのソートも、結果としてはそんなに変わらないと思いました。

確か、加重ソートをアドバンスセグメントでという話は、結構要望であったと思うので、擬似ですが、それなりに役に立つ作業工程の紹介だと思います。試してみてください。

マルチトラッキング(複数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ならこんなスピードはでない? 知らないし、理解できないけど。 このデータ処理のレスポンスタイムはすごい。

参照元、参照サイトの日別データを取る

yahoo知恵袋の質問を見てたら、一日単位のリファラー(参照サイト?)が取りたいという質問があって、確かに欲しいデータだなと思ったので、手順を書きます。使うのは、カスタムレポートとセカンダリ-ディメンジョンの二つです。最後に、エクセル出力です。

カスタムレポート作成

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

カスタムレポート日別データ

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

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

日別データ カスタムレポーティング

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

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

WS000003

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

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

アドバンスフィルターを適用

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

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

WS000006

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

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

エクセル スライサー

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

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

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

カスタムレポート 参照URL

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

WS000010

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

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

Data Export APIを使う

Data Feed Query Explorerを使う

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

Data Feed Query Explorer で参照サイトとパスを同時に出す

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

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

Google Apps Scriptを使う

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

Google Apps scriptで、google analyticsのデータを出す

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

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

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

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