データの取得

具体的な取得項目名は、ディメンジョン側にvisitLengthとpageDepathを使います。 指標側のtimeOnSiteやpageviewsではありません。個別に分類して見たい場合はディメンジョンを指定して、欲しい指標を取ります。今回の欲しい指標は訪問数(visits)になります。
また、新規・リターンユーザー別のvisitorTypeでのデータの違いを見るために、ディメンジョンにvisitorTypeを指定します。
これで、データとして、滞在時間(秒数), ページビュー数, 新規・非新規別の訪問数がでます。

データの加工

今回は散布図にしたいので、訪問数分だけ、データの行を複製します。
(*そのままでも、バブルチャート表示用のデータになります)
今回は、粒度の細かいデータに変換します。
その後、グラフで出力します。

以下が、その出力したグラフになります。

以下は、コードです。
認証部分 + プロファイルID は各自で埋めて下さい。

library(rga)
rga.open(instance = "ga",
         where = "/home/shirai/rga/shirai/.ga",
         client.id = "指定してください", 
         client.secret = "指定してください")
start.date = "2011-03-30"
end.date = "2013-04-14"
ID <- "ga:指定してください"
dt <- ga$getData(ID, start.date, end.date,
                 dimensions="ga:visitLength,ga:pageDepth,ga:visitorType",
                 metrics = "ga:visits,ga:timeOnSite,ga:pageviews",batch=TRUE)

##散布図用にデータを拡張？する
ret <- dt[unlist(lapply(1:nrow(dt), function(i)rep(i, dt[i,4]))),]
dt0 <- dt[,c("visitLength","pageDepth","visits")]
ret0 <- dt0[unlist(lapply(1:nrow(dt0), function(i)rep(i,dt0[i,3]))),]
for(i in 1:2)ret[,i] <- as.numeric(ret[,i])

##通常のplot表示
png(file="~/tmp/pageDepth_visitLength_in_googleAnalaytics1.png")
plot(ret$pageDepth, log(ret$visitLength/60,10),xlab="ページビューー数",ylab="滞在時間(分)")
dev.off()
##アウトプットがイマイチ
## alphaを入れて、jitterを入れる
p <- ggplot(ret[ret$visitLength!=0 & ret$visitLength<1200 & ret$pageDepth<16,],
            aes(pageDepth,visitLength/60, colour=visitorType))
png(file="~/tmp/pageDepth_visitLength_in_googleAnalaytics2.png")
p + geom_point(alpha=1/10,position="jitter") + xlab("ページビュー数") + ylab("滞在時間(分)")
dev.off()

## 平均で見る。前のグラフにimposeする方法わからず、、、
avgSOT <- ddply(dt, .(as.numeric(pageDepth),visitorType), summarise, ats= sum(as.numeric(timeOnSite)/sum(as.numeric(visits))))
names(avgSOT) <- c("pageDepth","visitorType","AvgTimeOnSite")
png(file="~/tmp/pageDepth_visitLength_in_googleAnalaytics3.png")
ggplot(avgSOT[avgSOT$pageDepth<16,], aes(pageDepth, AvgTimeOnSite/60, color=visitorType))+geom_line() + xlab("ページビュー数") + ylab("滞在時間(分)")
dev.off()

RGAでページビュー数 VS 滞在時間 の散布図を描くはgoogle analyticsについてで公開された投稿です。

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

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

ページ遷移データをグルーピング化するはgoogle analyticsについてで公開された投稿です。

Google Analyticsでエクセルなどでデータをいじる場合、　僕がよくやったのは、ディメンジョンを多めにセットしておいて(データ行は一万行を超えないようにする、indexするのが面倒な場合)、データを得た後、エクセルのピボットで軸を入れ替えながら、突出したポイントを探すことでした。エクセル2010でスライサー使えば、アドバンスセグメント＋カスタムレポートという形が簡単かつ柔軟に実現できる。

それで、データに浸かっていじってれば、そのうち、イメージができることはできるけど、時間かかります。　そういう場合に、よく言われるのは、予め仮説を持って、その検証のみに時間を使う。サイトに対する今までの見識を持って仮説を出し、データでの裏付けを探す。見識がなければ、世間で一般的に使われる指標を一般的なディメンジョンで分類するという形になると思います。または、テストできる環境を整え、指標を対比する。。。などだったと思います。

で、それとは違うアプローチとして、データマイニングがあります。仮説なしで、結論みたい？なものをだしてもらう。ほとんどは凡庸な結論だけど、時々、宝ものが出てくるかもしれない。。。冒頭の本は、そのアプローチ、データマイニングのやり方を説明してくれてます。この本は、数式抜きでやり方を丁寧に説明してくれてるし、書き方からも読者に理解させようとする気が伝わってきます。とても良いです。

で、その中の分析木をやってみました。ただ、分析木は、マイニングというより、シンプルな結論の提示という気がします。なので、この本にあるように、mvpartというライブラリを使います。コードは最後に提示します。

冒頭のグラフが図で、結果そのものが下記。
split:分岐基準、n:その基準での観察数(セッション数), loss: n回は間違え分類した。(分類名が続いてる。今回なら、bounce, nobounces)

========================================================

n= 226

node), split, n, loss, yval, (yprob)
* denotes terminal node

1) root 226 79 bounce (0.65044 0.34956)
2) visitCount>=6.5 22  1 bounce (0.95455 0.04545) *
3) visitCount< 6.5 204 78 bounce (0.61765 0.38235)
6) landingPagePath=/cookie/utma,2010-03-11-16-53,igation_analysis,ng-apis/gaq-push 132 41 bounce (0.68939 0.31061)
12) visitCount< 3.5 130 39 bounce (0.70000 0.30000) *
13) visitCount>=3.5 2  0 nobounce (0.00000 1.00000) *
7) landingPagePath=/ 72 35 nobounce (0.48611 0.51389)
14) medium=(none),organic 48 22 bounce (0.54167 0.45833)
28) visitCount< 4.5 44 19 bounce (0.56818 0.43182) *
29) visitCount>=4.5 4  1 nobounce (0.25000 0.75000) *
15) medium=referral 24  9 nobounce (0.37500 0.62500)
30) visitCount>=2.5 2  0 bounce (1.00000 0.00000) *
31) visitCount< 2.5 22  7 nobounce (0.31818 0.68182) *

=========================================================

２２６セッションで79が直帰と間違え分類で、
訪問回数で6,5で分かれて(22(間違え1) – 204(間違え78))
ランディングページで分かれて、(トップページと、それ以外, 132 – 72)
その子供たちは、また訪問回数やら、メディアやらで分岐される。

数字自体は、まあそうだろうなあ、、というもので、それで終わりだけど、ガイドラインにはなると思う。

分類項目の設定は、こちらで決めたり、訪問回を連続変数にしたりしてるのは、予断があるわけだし、最大の問題点として、分析単位がセッションになっていて、ユーザー単位になってない点があります。同一のユーザーが複数回記録されているデータというのは留保しないといかん。

ただ、それでも、ある一定の基準に沿って、ディメンジョンの項目を整理して、差異の大きい部分だけを抽出しているので、データから結論を得るプロセスとしていいのではないかなと思います。

あと、枝分かれの基準のジニ係数の計算をちょこっとだけやってみる。
(詳しく（正しく？)は、上記の本、データマイニング入門の本を読んでください)

最初の枝分かれは、訪問回数の6.5 ト表示なので、1-6, 7以上と分かれてる。

そのジニ係数は、

7回以上で  1 – ((22/23)^2 + (1/23)^2) => 0.087

６回以下で  1- ( (78/204)^2 + (126/204)^2) => 0.472

これを加重して、(23/226) * 0.087 + (204/226) * 0.472 =>  0.435

元々のルートのジニ係数は、1 – ((79/226)^2 + (147/226)^2) => 0.455

なので、分岐基準は、0.02となる。他の切れ目でやって、分岐基準が小さくなることを確認したいけど、パスします。。。

以下コード。
RGoogleAnalyticsは、cranにはないので、ダウンロードしてinstallする。
あとは、email, password, tableidを、各自でセットするれば、同じように動くと思う。画像ファイルの保存場所と。

library(RGoogleAnalytics)
library(mvpart)

##GAのデータを取得する
ga <- RGoogleAnalytics()
ga$SetCredentials(mailaddress, password)
query <- QueryBuilder()
query$Init(start.date = "2011-01-01",
           end.date   = "2011-12-15",
           dimensions = "ga:medium,ga:region,ga:date,ga:hour,ga:visitCount,ga:landingPagePath",
           metrics    = "ga:entrances,ga:bounces",
           sort       = "ga:date",
           table.id   = "ga:xxxxxxxxx")
data <- ga$GetReportData(query)$data

##データの整理
if(!is.null(data$visitCount)) data$visitCount <- as.numeric(data$visitCount)
data$date <- as.Date(data$date, "%Y%m%d")
data$wday <- weekdays(data$date)
data$wnum <- format(data$date, "%w")

##Langind Pageを上位(entrance数)５つに絞る
top5.lp <- arrange(
                   ddply(data, .(landingPagePath), summarise, sum=sum(entrances)),
                   -sum
                   )[1:5,"landingPagePath"]
dt0 <- subset(data, landingPagePath %in% top5.lp)
##URLが長いのがあるので、後ろから15文字だけにする
dt0$landingPagePath <- sapply(dt0$landingPagePath, function(x){ l <- nchar(x); substr(x, l-15, l)})

##top5.reg <- arrange(ddply(data, .(region), summarise, sum=sum(entrances)), -sum)[1:5, "region"]
##dt1 <- subset(dt0, region %in% c("Tokyo","Osaka","Aichi","Fukuoka","Kanagawa"))

##１セッションで１レコードの形にする
dt0 <- within(dt0, nobounces <- entrances-bounces)
a0 <- adply(dt0, 1, function(x)data.frame(engage=rep("bounce",x$bounces)))
a1 <- adply(dt0, 1, function(x)data.frame(engage=rep("nobounce",x$nobounces)))
dt0 <- rbind(a0,a1)

##いらないディメンジョン、指標を外しておく。以下の書式？なら元から無い項目でもOK
dt0 <- dt0[, !names(dt0) %in%
           c("visits","bounces","nobounces","date","region","hour","wday","wnum","entrances")]

##RPARTの部分
ret <- rpart(engage ~ ., data=dt0, method="class",cp=0.01)
png("~/Dropbox/cart.png",width=800,height=600)
rpart:::plot.rpart(ret, uniform=T, branch=1, margin=0.15)
rpart:::text.rpart(ret, all=T,pretty=0,fancy=T,digits=3,use.n=T)
dev.off()
plotcp(ret)

CARTで結論を絞るはgoogle analyticsについてで公開された投稿です。

リスティング広告（サーチ)の流れ

出稿する側は、キーワードとそれにヒモ付た広告を出す。（管理上、いろんなグルーピング機能があって、それらの上位グループ(広告グループ、キャンペーン)で制御が色々入れられる)。

ユーザーが検索する。　と、検索語にマッチしたキーワードに紐づいた広告が表示される。　ユーザーから見ると、検索語を打ち込む => 広告文を見る => ランディングページ訪問という流れ。

ここで大事だと思った点の一つは、ユーザーは出稿側がシステムに出す出稿キーワードは見ないし知らないという点。(完全一致はそのままなので、広告を出す側のキーワード設定とユーザーの検索語が一致するが、) 。

というのは、リスティング広告の管理をしてると、キーワード単位(マッチタイプ、テスト機能で分化管理、グループ、キャンペーンで統合管理されるが)で考えがちだと思われるのだけど、ユーザーサイドの行動である実際のクエリーを出発点に組み立てる事は大事だと。ユーザーは自分のクエリーをだして、広告文をクリックして、サイトに行く。ユーザーの頭に出稿する側のキーワードは入ってない。部分一致の場合。

ユーザーの行動プロセスを起点に考えると、上記のような流れ。で、その前提でデータを見えるようにしないとイカン。

もちろん、google, yahooの入札システムサイドでも上手く立ちまわる事は大切(CPC, 順位などの管理)だ。 そして、こちらも巨大なブラックボックスで、仮説、検証サイクルが廻る事にはなる。

で、

クエリーデータを得る、マッチタイプで分ける

上記の点を念頭にしたとき、僕としては、以下の２点、A,Bを抑えたときに、作業が楽になった。

A .クエリーデータの取得(Google Analyticsで)
B. adwords側でのクエリーデータのマッチタイプ別の分別管理。(yahooは楽にならなかった、、、)

A. クエリーデータの取得(Google Analyticsで)

1.yahooリスティング

これは、独自に取らないと行けない。また取れてもadwordsのようにリスティング側のデータを教えてくれないので、クエリーデータを取るだけになるが、それでもやる必要がある。

方法としては、一般にはutm_source, utm_medium, utm_camapignを付けてということになっているが、あんまり有効な方法には見えない。この方法だと、クエリーデータはリファラーから取って、cookieのutmzのutmctrに入るはずだけど、utmパラメータを設定すると、リファラー内のキーワード情報は、日本語のまま入ってしまう。で、エンコードしてcookieに入らないと、最終的なデータで文字化けやデータ不取得となることがあるのだ。通常の場合(utmパラメータを使わない)と違う仕様にした理由は分からない。マルチバイトの人が声を上げてないだけかもしれないし、他に理由があるのかもしれないし、僕の勘違いかもしれない。　でも、この辺りのデータ不備で悩んでる人は多いと思う。

で、utm_xxxx を使わないとすると、、、ヤフーリスティング側の仕様を利用する方法が良い。

yahooリスティングからクリックされた時には、ヤフーがパラメータを付けてくれる。それを使う。

クエリー情報、キーワード情報、マッチタイプ情報、キャンペーンID情報、広告グループID情報、広告ID情報　をURLパラメータとして付加してくれてる。これを素直にGAに入れれば良い。

その方法としては２つ。サイト内検索を使う。 or   トラッキングAPIを使う。

サイト内検索は、２つのパラメータ情報を取得できる(独立した？ディメンジョンで） ので、キーワード+クエリー、クエリー＋マッチタイプとい形で取得しておく。サイト内検索の設定に、ovraw, ovkey, ovmtcとかを設定すれば良い。サイト内検索でのディメンジョン情報は、ゴール指標と結びついているので、コンバージョン測定もやり易い。問題はcookieに情報が入るわけではないので、再訪問データとのかけ合わせが出来ないけど、これは通常のデータ分析でも難しいので、要らない（僕は)。

トラッキングAPIは、このへんだけど、やったことない。その上、問題があって、URLパラメータの情報は、ヤフーが日本語にして(エンコードせずに)付加してくれてるので、上で書いたデコード問題が発生しそう。ただ、クエリー情報以外の情報（キャンペーンID,広告グループID、広告IDとか)を収納できそうなので、これと、後で、ヤフーリスティング側からのIDの情報とJOINすれば、かっちりとしたデータが取れるとは思う。　集計してそのデータが活かせるかは、分からないけど。

と書いたように、サイト内検索の機能を使うのが手軽で良い。正統的な方法のutm系のパラメータとも共存して測定できるし。 ただ、APIを使う人は、ランディングページのパラメータを取り出して、エクセルなどで処理すれば、こんな方法は要らないかもしれない。

サイト内検索はパラメータによるデータの振り分け機能と考えると、GAの応用の幅が広がる。

あと、GAで実際に集計するプロファイルからは、yahooリスティングのパラメータを除去しておかないと、ランディングページの種類が大量になり、コンテンツ単位の集計は破綻すると思うので、プロファイル設定はキチンと手を入れておく必要。生データ用は、別のプロファイルで残しておく。

ヤフーはこれくらいはさっと思いついてやった。GAに詳しかった？人の立場としては…  ただ、応急処置的だし、javascriptでもっとやりたいとも思ったけど、、、全部自分で管理できないので、それは無理だし、それ以上のデータを持っても、サイトのパフォーマンス上げられる自信もなかった。リスティングの運営は手間暇かかるし、ビジネス的にはリスティングの運営のがお金に響くので、リスティング運用に時間をかけるのが本筋。また、リスティングの情報は質が高い(解釈しやすいし、相場情報になってる)

ヤフーリスティングは、情報が国内に限られるので、adwordsよりノウハウをネットで探すのが難しかしい。ただ、サポートは手厚いので、キチンとサポートを利用できる体制だと運用が楽かも。そういう意味ではある程度、組織だって運営できる所に利点があるのかな。代理店制度とかそのへんはよく分からない。

2. adwords

クエリーデータを起点にデータを取得するの続き。

アドワーズに関しては、自動設定にしておけば、クエリーデータは、アドワーズ側のレポートで見られるし、GAにも送ってくれる。なので、上記のヤフーの計測レベルは既に達成されている。

ただ、GA側のadwordsデータを使うと、もっといろいろ利点があるので書く。

まず、アドワーズのクエリーレポートはデータが来るのが遅い。一緒に提示されるデータで遅い物があるのか、クエリーデータがでるのに、２，３日掛かったような気がする、、、

一方、GAの方は、通常のクリックデータと同じなので、通常？、一時間以内にはデータが乗る。

なので、アカウントのスタート時とか、大規模の修正を掛けたときはGA側でクエリーのデータを追うべきだ。キーワードの除外設定は早ければ早いほど予算を残せるし、有効なクエリーを見つけて、キーワード登録するのが早ければ早いほどコンバージョンが実績で残る。

また、APIを使うのが前提になるけど、adwordsのクエリーディメンジョンに、他のディメンジョンも追加できるし、通常のメトリックスやゴール指標もデータとして乗っかるので、かなり細かく追っていこうと思えば、できる。追っかけて成果を出す解析スキルはないけど、、、、

あと、アドワーズレポートとの違いはまだある。クリック単位ででデータ（ディメンジョン、指標)が見られるけど（正確にはGAのディメンジョンで細分化出来る範囲で）、順位ディメンジョンの他にトップポジション、右ポジションという、広告配置位置のディメンジョンでも指標がだせるので、パフォーマンスの違いが測定できるし、adwordsで順位が一位だが、RHSになってるものもチェックできる。（必要なら広告ランクを増して、TOPに持っていかないとイカン)

* 先週あたり、アドワーズ側でもデータが出るようになったらしい。ただ、それでも、GAの方がデータの粒度を細かくできる。多くのディメンジョンのあるデータキューブ(アナリティクのデータはそう考えると良いはず。多次元データベース)みたいなのに組み込まれるわけだし。だと。 サイト内データ指標ともある程度ひもづくし。できない組み合わせもあったけど。

と、GA側のデータなら、adwordsのデータはかなり細かく、そして迅速に分かるので、有効に使うえる。

あと、GAとは関係ないけど、adwordsの管理の話を少し。

B 部分一致と完全一致は、分別して管理するのが良いはず

リスティングを経験する中で、最初に戸惑ったウチの一つは、部分一致と完全一致の所だったような気がする、、、他にもあっただろうけど、、、

メイン？なキーワードは、完全一致と部分一致の両方で出稿していくことになると思うけど、除外設定の知識も最初はなかったので、設定に悩んだ記憶がある。除外設定をしったあとは、完全一致と部分一致を区別するには、（部分一致+ 完全除外一致) で部分一致の出稿すれば、完全と部分の分離ができると分かって楽になった。

基本的に複数の広告グループで、完全グループと部分グループを別々に作るのが良いと思う。他の人の現場の方法は知らないけど、ここもそう言っててる。http://certifiedknowledge.org/blog/3-strategies-for-organizing-your-match-types/　(キャンペーン単位で分けるのもありかもしれない。　(このサイトは有用な情報が多い。他にも良い記事がある。)

この辺りは、adwordsの話。　ヤフーリスティングは除外設定が、フレーズ一致的な除外に固定されているの、上記のことはできず、入札単価の調整などになる。でも、単価調整方式だとCTRの履歴がどうしても歪みがちで、広告ランクが部分一致側に高く出て、マッチタイプの分別コントロールが非常に難しくなることがあると思う。　いい対策はないかと、ネットで探しても、この辺りで良い情報は見つからなかった。除外もキレイに出来ないし。この辺りの秋に改正されるらしい。

しかし、ヤフーリスティングとadwordsを同時に利用すると、adwordsすごいなあと思う。全体のシステムもすごいのだろうけど、adwordsのような数字でいっぱいなものが、ウェブのインターフェースで運用できるのにも驚いた。ウェブ上で情報をブラウズして操作するシステムで、自分が知る限り最高のモノの一つだと思う。salesforceとかを使うともっとすごいシステム(UI)ってあるのだろうか？　うーん、証券システムかなあ、、こっちもすごいかもしれない。バックエンドは知らない。

まとめ

リスティングについて、ほぼゼロベースの知識で望んだ時の経験の記憶の棚卸です。GAのついての知識はあったので、それを活かす形でやった記憶の掃き出しです。 新しいGAのことについて(新しいUIとか間接効果とか)は知らないので、聞かないでください。

そういえば、アドワーズのサーチファネルも、クエリーパスを時々見ると、ある種の感覚的なヒントがつかめると思う。定量的な分析はスキルが不足してる。僕には。

あと、リスティング広告の運用については、無駄なクリックの削減が大きなテーマだと思う。で、その最初の一歩は、出稿キーワードと検索クエリの対応関係をつかむとやりやすいかなと。出稿キーワードの感覚も掴めるし。　GAを使うと、ヤフーリスティングの管理画面よりその辺りが明確に見えてきます。そして、adwordsも、adwordsのレポートデータより、GAのレポートのが便利な点が多いです。

あと、ヤフーリスティングに関しては、要らないサイトを除外できる機能は必須機能だと思う。全体のクリックの２割がヘン？なサイトにクリックされてたとしたら、25%余分な贅肉がついたCPAで、競合と勝負してることになる。それで、運用がジリ貧な循環になり、本来できた運用ができなくなって撤退となる可能性すらあるわけで、単純な知識の差で永続的な差が付きかねない。

また、全然クリックされなくても、品質インデックスに悪影響を与えない可能性も無くもないので、クリックされない外部サイトも早めに除外する方が良いかも(yahooは外部サイトのクリック履歴を組み入れないと宣言してない。adwordsは除外設定自体が無いけど、QSにはカウントしないと宣言してる)

以上です。

あと、アドワーズの全般に向こうのフォーラムに出たベストプラクティスを、メモ書きしたものがあった。リンクを張っておきます。https://sites.google.com/a/abc-analytics.com/adwords/forumno-besutopurakutisuno-matome

リスティング広告は、データがスグに出るし、競合との勝負という点があるので独善的になりにくいし、adwordsに関してはテスト機能＋レポート機能も強化されて、思いつきレベルでもいろいろ試せるし(テストでなくても試せるけど、比較はしにくい)。サイトの継続的な改善にはまずはリスティングというのは良い方法だと思った。その後もニーズを探るのもリスティングが良さそうでもある。ヤフーリスティングもGAとうまい具合に統合できるといいなあと思った。

リスティング広告運用についての雑感はgoogle analyticsについてで公開された投稿です。

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

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

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

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。データ型は、テーブル型でもいいし、３カラムのデータフレームでもいい。今回は、まずはapv(average-page-views)を抜いて、３カラムデータフレーム。

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

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

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

ggfluctuation(abc[,-4])

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

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

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

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

ggplot2でお手軽ヒートマップはgoogle analyticsについてで公開された投稿です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上の数式を説明します。

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

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

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

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

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

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

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

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

最初の画面で、

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

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

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

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

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

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

まとめ

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

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

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

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

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

アドバンスセグメントで擬似加重ソート(Excel のTable機能)はgoogle analyticsについてで公開された投稿です。

Table of Contents

#RGoogleAnalyticsをファイル内にダウンロードしておいて使う。
source("/home/shirai/ga/r/RGoogleAnalytics/R/RGoogleAnalytics.R")
source("/home/shirai/ga/r/RGoogleAnalytics/R/QueryBuilder.R")

#今回の目的のggplot2、同時に plyrとreshapeもloadされる。
library(ggplot2)

#オブジェクト的な使い方? dataframeの要素に関数がある
ga <- RGoogleAnalytics()
#mail, pwを自分の設定ファイルから取得する
ac <- read.csv("/home/shirai/.gacc.csv",header=T,stringsAsFactors = F)[1,]
#認証を通す
ga$SetCredential(ac$mail,ac$pw)

#queryオブジェクトを作ってリクエストを作る。ビルドパターンって奴?
query <- QueryBuilder()
id <- "ga:21600568"
start.date = "2010-01-01"; end.date = "2010-12-30"
query$Init(start.date=start.date, end.date = end.date, table.id = id,
          dimensions = c("ga:date"),
          metrics = c("ga:visits,ga:pageviews,ga:timeOnSite"))

#データ取得 $dataにデータが、それ以外にはレコード数とかもある
output <- ga$GetReportData(query)
data.b <- output$data

#使い易いように、カラム名を加工、日付データは日付型に
names(data.b) <- sub("ga:","",names(data.b))
data.b$date <- as.Date(data.b$date, "%Y%m%d")

#滞在時間は平均滞在時間に、pageviewは平均PVへ、いるものだけ残す
data.b <- transform(data.b, avStay = (timeOnSite/visits))
data.b <- transform(data.b, avPV = (pageviews/visits))
data.b <- data.b[, c("date","visits","avStay","avPV")]

#ずるして、avPVは3000(5分)以上はNAに。　異常値なので
data.b$avStay <- ifelse(data.b$avStay > 1800, NA, data.b$avStay)

#パッケージのreshape機能。いわゆる？行持ちのデータ(日付 x データ種類 x 数値)に
data.b.molten <- melt(data.b, id="date")
head(data.b.molten) #ちょっと出力
#|       date | variable | value |
#| 2010-01-01 | visits   |     9 |
#| 2010-01-02 | visits   |     7 |
#| 2010-01-03 | visits   |     9 |
#| 2010-01-04 | visits   |    20 |
#| 2010-01-05 | visits   |    32 |
#| 2010-01-06 | visits   |    18 |
#
#ggplotで出力(x軸にdate,y軸にvalue:数値,
p <- qplot(date, value, data=data.b.molten, geom="line", main = "基本数値")

#ここで、グループ別に図示する機能 facet_gridを使う, 縦軸スケールは個別で
p <- p + facet_grid(variable ~ ., scale="free_y")

#見た目を調整して、ファイルに出力
p <- p + opts(axis.text.x = theme_text(size=5))
p <- p + opts(strip.text.x = theme_text(size=5))
p <- p + scale_x_date(major="1 month", format="%m月")
ggsave("basic.png", height=6, width=6, dpi=96)

#組み合わせ
    query$dimensions("ga:visitLength,ga:medium,ga:month")
    query$metrics("ga:visits")
    output.mm <- ga$GetReportData(query,max.rows=100000)
    d.mm <- output.mm$data
    colnames(d.mm) <- sub("ga:","", colnames(d.mm))
    #organic, referral, (none) に絞る
    d.mm1 <- subset(d.mm, medium %in% c("organic","referral","(none)"))
    #visits単位のレコードに
    d.mm2 <- data.frame(lapply(d.mm1[1:3], rep, d.mm1$visits))
    d.mm2$visitLength <- as.numeric(d.mm2$visitLength)
    p <- ggplot(d.mm2, aes(x=medium, y=visitLength, color=medium)) + stat_boxplot()
    p <- p + facet_grid(.~month) + ylab("滞在時間(秒)")
    p <- p + opts(axis.text.x = theme_text(angle=90,hjust=0, vjust=0))
    ggsave("boxplot_medium_month_visits.png",width=8,height=5,dpi=96)

cast(d.mm2, medium~month,  length)

cast(d.mm2, medium~month,  function(x)round(mean))

cast(d.mm2, medium~month,  function(x)round(median))

##dimensionとmetricsを設定して取得。他の項目はそのまま
query$dimensions("ga:landingPagePath,ga:visitLength,ga:keyword")
guery$metrics("ga:entrances")
#前回のindexがclearされないみたい。1に戻しておく。
query$start.index(1)
out.k <- ga$GetReportData(query,max.rows=100000)
str(out.k)

List of 3
 $ data         :'data.frame':  13061 obs. of  4 variables:
  ..$ ga:landingPagePath: chr [1:13061] "/" "/" "/" "/" ...
  ..$ ga:visitLength    : chr [1:13061] "0" "0" "0" "0" ...
  ..$ ga:keyword        : chr [1:13061] "(not set)" "abc-analytics.com" "analytcs.com" "analytics tracking code input" ...
  ..$ ga:entrances      : num [1:13061] 96 1 1 1 1 3 1 1 2 1 ...
 $ aggr.totals  :'data.frame':  1 obs. of  1 variable:
  ..$ aggregate.totals: num 15379
 $ total.results: num 13061

d.k <- out.k$data
names(d.k) <- sub("ga:","",names(d.k))
d.k1 <- data.frame(lapply(d.k[1:3], rep, d.k$entrances))
str(d.k1)

top5.pages <- names(rev(sort(d.k1$landingPagePath))[1:5])
d.k2 <- subset(d.k1, landingPagePath %in% top5.pages)
#使わないファクターをdrop
d.k2 <- droplevels(d.k2)

top30.kw <- names(rev(sort(table(d.k2$keyword)))[1:30])
d.k3 <- subset(d.k2, keyword %in% top30.kw)
d.k3$visitLength <- as.numeric(d.k3$visitLength)
d.k3 <- droplevels(d.k3)
str(d.k3)

p <- qplot(data=d.k1, x=visitLength,y=KW1, alpha=I(1/2))
p <- p + facet_grid(LP1 ~ ., scales="free_y", space="free",labeller=function(l,x){substr(x,1,20)})
p <- p + coord_trans(x="log10")
p <- p + opts(strip.text.y = theme_text(angle=0))
p
ggsave(filename="landing_keyword_length.png", width=10, height=10, dpi=96)

plyrで集計 ggplot2でグラフ化はgoogle analyticsについてで公開された投稿です。

統計用言語なのですが、グラフ出力も充実しており、latticeというパッケージを使うと分類した上でのグラフ表示が一行でだせます（マニュアル見る時間がかかるけど)。なので、グラフを図示していきます。

下のような感じでデータを取得します。

#認証tokenを取得
auth <- getAuth(email, password)

#アカウント＋プロファイル情報を取得
acs <- getAccounts(auth)
>str(acs)
str(ac) 'data.frame': 45 obs. of 4 variables:
$ ac.ids : chr "xxxx";,"xxxx" ...
$ ac.names: chr "名前1" ,"名前2" ...
$ pr.ids : chr "1111111","222222" ...
$ pr.names: chr "xxxx","xxxx", 

#プロファイル名で検索
> ac[grep("abc.*wiki",ac$pr.names),]
ac.ids ac.names pr.ids pr.names
10 188512 abc-analyticsさん 25.... abc-only-wiki-except-me
12 188512 abc-analyticsさん 255xxx... 

#キーワードを取得（デファルトで過去一ヶ月)
data <- getData(auth,id=2551xxxxx,metrics=c("visits"),dimensions=c("keyword"))
[1] "https://www.google.com/analytics/feeds/data?ids=ga:25513728&dimensions=ga:keyword&metrics=ga:visits&start-date=2010-09-03&end-date=2010-10-03"
[1] "visits"
[1] "(1-874)/874"
[1] 2
                                         keyword visits
14                                     (not set)    341
573 googleanalytics タイトル別のコンテンツ index     29
651                                         utma     17
851                        目標到達プロセス 画面     16
36                                     _gaq.push     15
221                         funnel visualization     14
662                                         utmz     11
853                     目標到達プロセスの放棄数      8
316                        google analytics wiki      8
30                                          _gaq      8
> str(data)
'data.frame':    874 obs. of  2 variables:
 $ keyword: chr  "(not set)" "googleanalytics タイトル別のコンテンD
[1] "visits" num 341 29 17 16

それで、時間帯別の表示をlevelplotという機能を使って表示していきたいと思います。

セッション数を時間帯と地域別で取得

data <- getData(auth,id=25513728,
+ metrics=c("visits","goal3Completions"),
+ dimensions=c("date","hour","region"),
+ start.date="2010-08-30",end.date="2010-10-03",
+ max.results=10000)
[1] "https://www.google.com/analytics/feeds/data?ids=ga:25513728&dimensions=ga:date,ga:hour,ga:region&metrics=ga:visits,ga:goal3Completions&start-date=2010-08-30&end-date=2010-10-03&max-results=10000"
[1] "visits"           "goal3Completions"
[1] "(1-10000)/1060"
[1] 5
          date hour region visits goal3Completions
702 2010-09-21   15  Tokyo     11                3
92  2010-09-01   09  Tokyo     11                2
607 2010-09-16   18  Tokyo      9                1
920 2010-09-29   15  Tokyo      8                0
608 2010-09-16   19  Tokyo      8                2
178 2010-09-03   12  Tokyo      8                0
105 2010-09-01   14  Tokyo      8                0
923 2010-09-29   16  Tokyo      7                0
520 2010-09-14   19  Tokyo      7                0
474 2010-09-13   17  Tokyo      7                2

グラフにする。

levelplot(tapply(data$visits,list(data$hour,data$date),sum),  col.regions=colorRampPalette(c("white",  "red"))(256),layout=esuln

週末と夜間は空白に近い。

曜日別に傾向があるかもしれない。見てみる。

wdays <- c("a日","b月","c火","d水","e木","g土”) #表示順を揃えるため

levelplot(tapply(data$visits,list(data$hour,wdays[as.numeric(strftime(data$date, "%w"))+1]),sum),  col.regions=colorRampPalette(c("white",  "red"))(256))

まあ、なにもない。深夜に起きる人は、木曜くらいから出始めるのか？というか、祝日補正してないせいだろう。

また、サイトによっては、キャンペーンやコンテンツ投入のタイミングが見えるかもしれない。

んじゃ、とりあえず、メディア別にして、期間を長くして平均を見てみる。

d.m <- getData(auth,21600568,metrics=c("visits"),dimensions=c("hour","date","medium"),start.date="2010-01-01",max.results=10000)

d.m.a <- d.m[d.m$medium %in% c("organic","referral","(none)"),]
> levelplot(tapply(d.m.a$visits,list(d.m.a$hour,wdays[as.numeric(strftime(d.m.a$date, "%w"))+1],d.m.a$medium),mean), col.regions=colorRampPalette(c("white",  "red"))(256),sub="曜日別|メディア別”)

検索活動は集中するくらいしかわからない。今年の平均だけど、、

これでも、具体的なユーザー像にはならない。

そこで、ある特定のキャンペーンを行った場合の波及効果みたいなのをみたいが、出せるデータがないので、このブログの公開記事の閲覧数の減衰具合みたいなのを見てみる。

d.m <- getData(auth,21600568,metrics=c("entrances"),dimensions=c("hour","date","landingPagePath",”medium”),start.date="2010-08-01",max.results=10000)

rev(sort(tapply(d.m$entrances,d.m$landingPagePath,sum)))[1]
 /multi-cookie-tracking                                                                  338

と一番多い、multi-cookie-tracingを見てみる。メディアタイプを、オーガニックと参照リンクに絞って表示

d.m <- getData(auth,21600568,metrics=c("entrances",”newVisits”),dimensions=c("hour","date","medium"),start.date="2010-01-01",max.results=10000) 

d.m.a <- d.m[d.m$medium %in% c("organic","referral"),]
> levelplot(tapply(d.m.a$entrances,list(d.m.a$hour,d.m.a$date, d.m.a$medium),mean), col.regions=colorRampPalette(c("white",  "red"))(256),sub="特定ページメディア別”)

９月１日の深夜に出して、リンク中心にアクセスが上がって、その後は検索にかかるようになる。しかし、検索に乗るのも早いものだ。

次のものは、新規に絞ってみたもの。本当に新規でないのもあるだろうけど。検索による継続的な流入はある。

d.m <- getData(auth,21600568,metrics=c("entrances",”newVisits”),dimensions=c("hour","date","medium"),start.date="2010-01-01",max.results=10000) 

d.m.a <- d.m[d.m$medium %in% c("organic","referral"),]
> levelplot(tapply(d.m.a$newVisits,list(d.m.a$hour,d.m.a$date, d.m.a$medium),mean), col.regions=colorRampPalette(c("white",  "red"))(256),sub="特定ページメディア別”)

あとは、、、、

会員情報などとマッチングしてるサイト(外部ソースとの照合は規約違反かも)なら、ユーザー属性別のアクセス状況などは、比較表示しやすいと思います。

検索ワードで属性を分けたり、地域と時間情報と天候情報(外部から引っ張る)で属性を仮定したりと思ったのですが、余裕ができたらやってみたいと思います。

とりたてて何か発見ができたわけではないですが、Rを使うと、こんな感じで手短にグラフ出力ができます。ただ当然ながら、学習曲線はキツイ。ここまで来るのに相当な学習時間がかかりました。データ分析ではなく、データ表示だけなのに、、、

以下コードです。RCURLとXMLが必要です。

こちらに移動しました。

RでGoogle Analtyics: 時間帯別グラフはgoogle analyticsについてで公開された投稿です。

*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

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

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

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

複数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;’という形。

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

サブドメインでの計測では、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に書いたものへのリンク

マルチトラッキング(複数cookie)について考えるはgoogle analyticsについてで公開された投稿です。

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 は、頭に出なかった、、、

訪問回数別セッション数(vs 参照元)の残存率を見るはgoogle analyticsについてで公開された投稿です。