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

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でデータの整理にお悩みの方は、データ整理のご相談の連絡を下さい。サイト運営は素人ですが、データの集計や整理を一生懸命やります。

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

アドバンスセグメントを使った上での、疑似目標到達プロセス

先週のアクセス解析ワークショップで、考えた事を元にこのエントリーを書いてます。今回のエントリーの内容としては、ROI revolutionの記事(funnels_on_the_fly_in_google_analytics)とほとんど同一です。参考にしました。

目標到達プロセスとアドバンスセグメント

目標到達プロセスで、目的達成を図示する

アクセス解析の目的は、ビジネスゴールの達成ができているのかを測定することです。もちろん、サイトによってゴールの種類はさまざまです。PVから始まって、直帰率、読んで欲しいコンテンツへの到達率、資料請求申し込み、商品販売、さまざまですが、解析の目的には、ゴールがついて回ります。ゴールの達成度を測るわけです。でも、その過程も評価できたら嬉しいです。Google Analyticsでは、この過程を図示する機能があります。目標到達プロセスと呼ばれるものです。(プロファイルごとに設定が必要です)

目標到達プロセス

* 数字の見方に気を付ける。途中のプロセスをすっ飛ばして、ゴールに来た奴はどうやってカウントしているかです。

  • 何もかもすっ飛ばしたものは、直接、横に表示される。
  • トップ(図の場合Home)に来て、途中を飛ばしてgoalしたもの。こういうものも、図の中では途中を経過しているように図示される。

となってます。フォームの離脱率など順番が保証されている場合は、心配はいりませんね。

数字の見方に気を付ける点はあるものの、ゴールの過程が図示されます。どこでセッションが切れている(到達してる)が分かりますので、離脱の多い所の改善を考えて、リンクの位置を変えようといった話につながります。

分析手段である、アドバンスセグメント

こうやって、道のりの過程を考えてデータを見る方法とは別に、ユーザ属性を仮定して特定の属性の人(セッション)の行動指標を見る事もGoogle Analyticsではできます。特定のセッションのみを抽出してレポートしてくれるアドバンスセグメントです。

検索してきたセッションはどうなんだろう? 特定のデバイスからのセッションはどうなんだろう? ページビューが5以上あるセッションはどうなんだろう? Google Analyticsで使うディメンジョン・指標のほとんどについて、セッションデータの切り出しができます。

目標達成プロセスがサイト全体でのセッションが、ゴールまでの到達(逆にいえば離脱)を見たのに対して、アドバンスセグメントでは、特定のセッション(複数)についていろんな指標面を見る、すなわち、これら(セッション)がいったいどんなものだったのかを見るわけです。目的達成のための調査をしてくれるわけです。

しかし、目標到達プロセスとアドバンスセグメントは同時に使えない

同時に使いたいですよね。僕もしたいです。でも、機能として出来ません。パフォーマンス上の理由なのか、特定の指標については、アドバンスセグメントが用意されていません。以前のエントリーで書いたユニークユーザー数もそうでした。

でも、セグメントしたデータでの目標到達プロセスを知りたいですよね?少し面倒ですが、やってみましょう。

アドバンスセグメントのテストを使った擬似的な離脱プロセス数

このサイトはデータが少ないので、分かり易いデータではないのですが、このサイトの3つのページ、what_are_visits…, top, profileで、what_are_visitsがランディングになったページで、profileをゴールとし、topをプロセスとします。what_are から topへいって、profileというイメージです(実は、それは出来ないのですが、便宜上そうさせておいて下さい、出すのは疑似的な数字です)

では、実際のデータをみていきましょう。

まずは、アドバンスフィルターでページ別セッション数をCHECK

特定の閲覧開始ページでのページ別セッション数

正規表現は覚えると便利です。僕も昔は、???でしたが、使えると便利です。Google Analyticsでは使う場面がチョコチョコ出てくるのが頑張りましょう。

それぞれのページがどれくらいのセッションを獲得したかが、ページ別セッションに現れます。”/”が9。”/profile”が4。ただこれは、ばらばらの数字で、ゴールの過程がどうかわかりません。ゴールに設定したprofileでは4セッションという目標を達成したのですが、トップの”/”が目標達成プロセスとして、何セッション数いたのかが不明です。

アドバンスセグメントの管理画面で、テスト機能を使う。

アドバンスセグメントの管理画面は、もちろん、設定をする場所なのでが、セグメントのテストを使うと、おもしろい数値が取れます。

セグメントのテスト1

上と同じ数字です。セッション数9ですね。

それではその中で、ゴールであるprofileまでは、どれだけのセッションが行ったのかというと、上の図に And条件を足して、

セグメントのテスト2

最終的には、セッション数1、、、です。上のセッション数9が、1になりました。最初にアドバンスセグメントで上位のコンテンツを見た時は、”/”が9セッションで、”/profile”が4セッションでしたが、両方を通過(到達)したセッションは、1となったわけです。

疑似的目標到達プロセス

整理しますと、/what_areで、169セッションありました。で、top と profileを同時に見られたセッションは、1セッションだった。

実際のプロセスなどで順番が仮定できる場合は、これでセグメントしたセッションで、離脱(到達)プロセスの数字が出せます。

Topがプロセスで、profileをゴールという順番を仮定すると、169 → 9 → 1となります。9/169=5.2%。最初に85%が離脱して、次に 1/9=11%なので、89%が離脱。

数字も1があったり、信頼性はないですが、フォ-ムなどのプロセスで分析できるデータをお持ちの方は、今回のような形で、セグメントされたセッションに対しての目標到達プロセスで見た離脱数を出せると思います。(プロセスの順番が想定できるものという条件になりますが)

まとめ

  • Google Analyticsで使う事の多い、アドバンスセグメントと目標到達プロセスがどういうものかの説明をしました。
  • その後、この二つは、同時に使う事ができない事を書きました。
  • 代替的手段として、アドバンスセグメントの条件を一つづつ増やす事で、疑似的(順番を仮定)に目標到達プロセス(プロセスでの離脱数)をだしました。
  • 順番さえ想定できれば、絞り込み条件を一つづつ増やす事で、3つ以上のプロセスにも適用が可能です。フォームなどの離脱プロセスを、アドバンスセグメントで見たいと思った場合に有効だと思います。

ディレクトリ別到達率、セカンドページセッション数、訪問回数別セグメント

アクセス解析のワークショップに行ってきました(感想は最後に一言)。ワークショップで受けた刺激を元に、僕のサイトのデータでの分析をします。大きく3つ分野を考えます。Q1:特定ディレクトリの到達率、Q2:ナビゲーション、Q3:ユーザセグメントです。

Q1:特定のディレクトリへの到達率を知りたい

とりあえずの手段として、コンテンツの詳細でのページビュー数のcheck

サイト構成がディレクトリ構造になっている場合、コンテンツの詳細で、ディレクトリ単位の集計した指標が見られます。まずは、ページビューを見て、サイト全体との比率を見るのがいいと思います。

directories_in_content_drilldown_report_in_google_analytics

上図の例で行くと、/view_your_report/ディレクトリ配下のページは、全体のページビューの1/4くらいとcheckします。簡単便利です。

ペ-ジビュ-じゃなくて、セッション数で比較したい? この場合、 隣のページ別セッション数を使うのは良くないです。全体の比率を見るには適していません。なぜなら、ページ別セッション数は、ページ別であり、ディレクトリ別セッション数ではないからです(ページビューの方は完全にバラバラなのでOK)。それで、どうするかというと、

アドバンスセグメントの管理画面でディレクトリ別セッション数を知る

全体のセッションの中で、少なくとも特定のディレクトリを通過したセッション数が知りたいです。アドバンスセグメントで、ページをディメンジョンにして、正規表現で対象セッションを絞ります。

uniqueDirectorySessions_in_google_analytics

全体のセッション数が409で、/view_your_reportディレクトリのページを通過したセッション数は124で、全体の1/4強。先ほどのページビューの約1/4とあまり変わらないかもしれませんが、セッション数からイメージしたい人には有用というか、、、安心できます。

また、個別のディレクトリのセッション数の合計は、全体のセッション数と成らない事に注意して下さい。上図の下方の該当セッション数でセッションの重複具合をcheckしておくと良いと思います。今回の場合は、全体409, 個別のディレクトリ(124+64+50+23+19)=280, OR条件での該当セッション数265。ここから、重なり具合を想像すると良いです。

注意はいるものの、ページビュー数とセッション数、それぞれから見た特定ディレクトリの到達率が分かりました。ディレクトリ別のコンテンツ制作労力のバランスを見直す指標になると思います。

Q2:サイト全体のナビゲーションを検証したい

ナビゲーションの言葉の定義が難しいのだけど、受けと攻めの二つの立場を考えて、

  1. 受け。ユーザのニーズにアンサーする。 見たい情報が提示できたのか?
  2. 攻め。ユーザの気持ちに訴求する。 見て欲しいページ(ゴール)への導線の訴求。実際にクリックしてくれたかどうか?

1(受け)は、これ!という指標が思いつかないけど、直帰率がマクロな傾向を示すかもしれないです。または、ページビュー/ ページ別セッションの推移を見ると、ユーザー行動の変化が、マクロ的に出るかも知れません。と思って、

pageviews_divided_by_uniquePageviews

wiki.slash-reader.comの半年のPV/ページ別セッション数。なんにも言えない、、、。アイデア倒れかも。

2(攻め)は、secondPagePathのセッション数見てみるとおもしろそうです。secondPageは最初のクリックページなわけで、意図した訴求がクリック数に結びついているかが分かる。特に、CMSなどでのテンプレートで、全てのページに同じ誘導ボタンが配置している場合、その効果が見えると思います。

特定ページがセカンド閲覧ページとなったセッション数の推移を見る。

secondPagePath_in_google_analyhtics

グラフにするほどのデータが取れなかったので、取得場面のスクリーンショットです。(Data Export APIを使う)

データはこのblogです。トップページ以外のランディングで、次にトップページに移った数。ある意味、blog全体に興味を持ってくれた人の数かもしれない。RSS取得などよりは、弱い興味だけど、、、

あるページへの誘導数を測る時に、このセッション数を出すやり方は良い方法かなと思います。大きなデータで見てみたいですね。

ナビゲーションは、受けと攻めの両面で考える。受けの方は、直帰率や(PV/ページ別セッション数)などで、攻めは、特定のsecondPagePathと成ったセッション数を出して、効果検証という流れを考えました。

Q3:ユーザー像のセグメント

ユーザ像の分類をどうするかですが、基本は、AISMAの視点でいくと思います。強い?キーワードが出てるものは、Sまで来てる。それ以外は、訪問回数でA→Iの移り変わりを見るという感じです。AISGでしょうか。Gはゴールです。コンバージョンです。

検索ワードは、その検索ワード自体が、顕在的なワードか?潜在的なワードか?に分類する必要があるかもしれません。サイトを象徴するワードなどは顕在層として行動特性を分ければ良い。行動特性は、ナビゲーションを見ればいいと思います。コンバージョン率もそうですね。

問題は、検索ワードが潜在的 or なんらかのキャンペーン or 参照サイト といった流入で、Attentionやinterestの段階にいる人を推定したいのですが、、、難しいです。妥協策は、訪問回数をattention, interestの積み上がりと考える事でしょうか。カスタムレポ-トで、訪問回数別のデータを見てみた(ピボットで参照元とクロスする)。

sessioins_by_number_of_visits_and_referrer

Directの内、ある程度は、twitterクライアントからの流入だと考えた方がいいと思ってます。

興味が積み上がった上でのコンバージョンという例がないので、1回目の訪問でコンバージョンしたデータだけですが、訪問回数(=~関心の積み上がり)と、参照元(当初の関心のベクトル)で、ユーザ層を分けて、コンバージョンみたいな行動成果を見たことになりました。

また、ユーザーに限りなく細分化したカスタム変数を持ってもらう事が可能なら、ユーザ単位で見た、複数の外部サイト(広告も含みますね)の貢献が出そうです。その場合は、プライバシーポリシーとの兼ね合いになりそうです。

ユーザ像が明確になれば、行動ターゲティングの導入などに進めるかもしれません。

おまけ: コンバージョンプロセスでの離脱率

Google Analyticsで良く使う目標到達プロセスでの分析も、セミナーでやったのですが、難しいなと思いました。最終的なコンバージョン率が違えば、それで優劣はでます。ただ、改善としては、プロセスを見ながら、いいとこ取りできないか考えるわけです。統計的な処理ができれば最適化と言ってもいいのかもしれません。ただ、演繹的にはムリな気がする。仮説 & テストじゃないとムリっぽいです。

ここら辺りができれば、知的好奇心は満足すると思いますが、PDCAのActionに早く移った方が良いですね。データにこだわるなら、ヒートマップとか、違うリソースによるユーザー属性とかでしょうか、でもこれも、テストの為の情報=仮説作成の為の情報ですね。

ワークショップ、後半はこれからなので、感想の続きがある予定です。

(*)ワークショップの感想としては、自分のパファーマンスの感想なのですが、数字の計算と会話のコンテキストスイッチは、コスト高だと理解しました。知的作業には、どんどんペア(グループ)ワークを入れるべし!と思っていたのですが、そこまで簡単ではない事が分かりました。