WEBの勉強ノート
Loading

Google Analytics ナビゲーションサマリーと閲覧開始後の遷移の違い

2010 年 8 月 7 日 土曜日

Google Analytics

「ナビゲーションサマリー」と「閲覧開始後の遷移」の機能の違いが分からなかったので調べてみました。

ナビゲーションサマリー

Google Analytics の公式ブログによると、以下のような機能とのことです。

*ナビゲーションサマリー
[ナビゲーションサマリー] は、レポートの対象ページを中心に直前に閲覧していたページの URL と、次に閲覧したページの URL を上位 10件 まで確認できます。また直前に閲覧したページ、次に閲覧したページがサイト内のページでない場合は、それぞれが閲覧開始数、離脱数として集計されているので、参照元、移動先からページのナビゲーションを分析するのに適したレポートです。

image

最もアクセス状況のよいページから、ユーザーが次にどこのページに行ったか、などを確認しています。意外なニーズが見つかることもあるかもしれません。

「上位10位」とありますが、私の見間違いでなければ遷移先は11位まで表示されていますね。。引用している記事は2008年のものなので仕様変更があったのでしょうか。

閲覧開始後の遷移

同じく Google Analytics の公式ブログから引用します。ページ遷移という名前で紹介されています。名前の変更があったみたいですね。

*ページ遷移
当該ページから閲覧を開始したセッションのみを対象にして、対象ページを起点に次に閲覧した1ページと、そのセッションの離脱ページ (閲覧終了ページ) を URL で確認できます。対象は上記の2 URL ですが全ての移動先ページ、離脱ページを網羅しているので、広告などのリンク先ページの評価に適しています。

image

「ここで終了」という意味がやっとわかりました。解析しているページの次のページと、そのセッションの最後のページがリストになって表示されているということですね。

「ナビゲーションサマリー」と「閲覧開始後の遷移」の数値の違い

解析をしていると、ナビゲーションサマリーと閲覧開始後の遷移の画面で表示されているページのリストや数値に矛盾があるなあ、と思っていたのですが、肝心なことを見ていませんでした。

  • ナビゲーションサマリーはページビューを元にしたクリック率を表示
  • 閲覧開始後の遷移は、セッション数の割合を表示

ナビゲーションサマリーで遷移元、遷移先、分析しているページが同じページ?

こちらは Google Conversion University で見つけた内容です。ナビゲーションサマリーの画面の中で、分析しているページ、遷移元、遷移先が同じページである場合があります。ぱっと思いつくのが、ユーザーがリロードしているのでは、というものですが、それだけではなかったのでメモしておきます。

例えば、ページ内の画像のサムネイルにリンクを張り、クリックすることで大きな画像を見せる場合。Lightbox的な Ajax を利用したものではなく、単に画像ファイルへのリンクを張っている場合です。

ユーザーが画像をクリックすると、画像ファイルが表示されます。画像ファイル自体にGoogle Analytics のコードを張ることはできないので、画像が表示されてもアクセスとしてカウントされません。

たいていの場合ユーザーは戻るボタンで戻ります。このとき、元のページで再度 Google Analytics の Javascript が実行され、アクセスとしてカウントされます。つまり、同じページが2回カウントされるという現象が起きます。

Google Analytics は、キャッシュされているページを表示した場合でも Javascript によって PV をカウントするためこのような現象が起こります。

参考にしたサイト

ページ遷移とナビゲーションサマリーレポートの違い

http://analytics-ja.blogspot.com/2008/08/definition-of-navigation-summary-and.html

Conversion University

http://www.google.com/support/conversionuniversity/bin/static.py?hl=en&page=iq_learning_center.cs&rd=1

Google Analytics のデータ共有とアカウント

2010 年 3 月 15 日 月曜日

Google Analytics

アカウントの種類と権限

Google Analytics には 2つのタイプのアカウントがあります。”user” と “Administrator”。

- User (View reports only)

レポートの閲覧ができるかどうか、プロファイルごとに設定することができます。このプロファイルを見せて、このプロファイルは見せないという設定が可能です。

User のアカウントでは、閲覧を許可されたプロファイルの設定変更や、そのプロファイルに紐付く新しいプロファイルを作成することはできません。アノテーションの書き込みはできるようです。

- Administrator (Account Administrator)

Administrator が追加されると、その Analytics アカウントの管理者となります。プロファイルではなく Analytics アカウントの管理者となるため、その Analytics アカウントに属するすべてのプロファイルを、閲覧、設定変更が可能となります。

新しい Administrator 追加後に、もとの Administrator を削除することもできるため、管理している Analytics アカウントを他の Google アカウントへ譲渡することもできます。

共有するユーザーの追加

ログインしてすぐのプルファイルの一覧画面の「ユーザーマネージャ」をクリックします。

image

「Add User」をクリック

image

追加するアカウント (XXX@gmail.com) を入力して、アクセスタイプ (権限)、User タイプの場合は閲覧を許可するプロファイルを選択。「Save Changes」をクリックして完了。簡単です。

image

Google?Conversion University

Google Analytics のアカウントとプロファイルの関係

2010 年 3 月 14 日 日曜日

Google Analytics

Google Analytics には、前提となる Goolgle アカウントとそれに紐付く Analytics のアカウント、プロファイルがあって、それぞれが何なのか分からないまま使っていたり。また、複数のサイトの管理を行うとき、Analytics のアカウントを増やせばよいのか、Google アカウントを増やせばよいのか、など迷うことも。今回、この辺をまとめてみます。

ほとんどの情報は Conversion University (英語版) から得ています。運用方法などは、初心者のメモとしてお読みください。

Google アカウントと Analytics アカウントとプロファイルの関係

まずは、それぞれの関係性から。Google アカウントの中に複数の Analytics アカウントが所属できて、 さらに Analytics アカウントの中にいくつかのプロファイルが入っている。

HTML にコードを張り付けた時、UA-XXXXXXXX という番号が入っているけど、この番号と Analytics アカウントが 1対1で対応。プロファイルを作ると UA-XXXXXXXX-1、UA-XXXXXXXX-2 という風にプロファイル番号がくっつく。

複数のサイトを管理する時 Analytics アカウントを増やす?プロファイルを増やす?

私は、サイトごとに Analytics アカウントを作るのが良いと思います。Google のお勧めも 1つのサイトに 1つの Analytics アカウントのようです。理由として、

- 管理者のアカウントを追加すると全てのプロファイルの管理者となる

ユーザー権限のユーザーならプロファイルごとに閲覧できるかどうかを設定できるけど、Administrator 権限のアカウントを追加すると、その Analytics アカウント内の全てのプロファイルの管理者となります。

まったく別の組織のサイトのレポートがひとつの Analytics アカウントの中にプロファイルとして入っていると、管理者権限のアカウントは全部見られることになってしまいます。当然管理者なので、設定の変更もできてしまいます。

- Adwords のアカウントと Analytics のアカウントは 1対1

Adwords の解析もしたい場合、複数のサイトを 1つの Analytics アカウントとプロファイルで管理していると、そのうち1つのサイトでしか Adwords を使えないです。

プロファイルごとにサイトを管理している場合、プロファイルごとに別の AdWords のアカウントを設定、ということはできません。

- サブドメインのサイトは?

複数のサイトの管理と同じです。そのサブドメインのサイトを他のアカウントで別に管理する可能性があるか、独自の AdWords のアカウントを使用することがあるかで決定します。

- プロファイルの使い方

自分のアクセスを除外するフィルタなど、フィルタを作成する場合、必ず加工していないデータのプロファイルを残します。Google Analytics のデータは、すでに取得してあるデータに対してフィルタをかけるのではなく、フィルタがかかった状態でデータを取得するため、後からフィルタを解除しても元のデータを得ることができないためです。

いつどんなデータが必要になるとも限らないのでバックアップとして生データを残します。その上でフィルタをかけたり、サブドメインのサイトを追加したりします。

アカウント、プロファイルの数の上限

- 1つの Google アカウントに 25個のAnalytics アカウントを作成することができる

- 1つの Analytics アカウントには 50個のプロファイルを作成することができる

数が足りなくなっても、別な管理者を加え、元の管理者を外すことで Analytics アカウントを別な Google アカウントに移すこともできるので数で困ることはなさそう。

実際に25個以上作成しようとすると、以下のメッセージが表示されました。

image

新しい Google アカウントを作る時

通常、Google アカウントを作る時、メールアドレスを求められます。が、自分のアドレスはあらかた使ってしまっていたりします。そんな時は、Gmail の登録から入ると、メールアドレスなしでも Google アカウントを作成できます。

Google Analytics の基本的な仕組みと「こんな時はトラッキングできる?」

2010 年 3 月 9 日 火曜日

Google Analytics

Google Analytics の基本的な仕組みと、ユーザーがCookie をブロックしていたらトラッキングを行うことができるか、など、Google Analytics でトラッキングができない場合などをまとめてみました。

Google Analytics はビーコン型のアクセス解析ツール

サーバーログ型 : WEBサーバーのアクセスログを解析

ビーコン型 : ユーザーのブラウザから解析用サーバーにデータを送信して解析

トップページ – サイト内のあるページ – トップページ、のように、戻るボタンなどで1回表示したページ戻ってきたとき、ブラウザがデータをキャッシュしているため、通信が発生しない場合があります。サーバーログ型はキャッシュでページが表示された場合、その PV をカウントすることができません。

Google Analytics のようなビーコン型なら、キャッシュで表示されたページでもカウントすることができます。ただし、Javascript が動かない環境や、Javascript が動作する前にユーザーがページを離れてしまうとカウントすることはできません。

Google Analytics の基本的な仕組み

1.ユーザーがWEBサイトにアクセスする

2.ブラウザでGoogle Analytics のJavascriptコードが実行される

3.クッキー読み取り(設置)

4.見えない画像をリクエスト

5.Google Analytics のサーバーでデータが処理される

6.Google Analytics でレポートを表示

WEBサイトの表示後、埋め込まれたGoogle Analytics のコードが実行され、データを収集。見えない画像のリクエストのパラメータとして、Google Analytics のサーバーにデータを送ります。

こんな時はトラッキングできる?

- cookie をブロックしているユーザーはトラッキングできるか

Google Analytics は 1stパーティクッキーを経由して、すべてのデータを送信します。よって、3rd パーティクッキーのみのブロックなら、トラッキング可能。1st パーティクッキーのブロックもされると、トラッキングできなくなる。

- クッキーを削除されたら

トラッキングは可能。クッキーに保存されていた前回の訪問日などが取得できなくなるため、新規ユーザーと認識される。

- ユーザーが Javascript を OFF にしている

トラッキングできない。同様に、Javascript に対応していない携帯ブラウザなども、通常の方法ではトラッキングできない。

- ページ内で Javascript のエラーが起きたら

ページ内で Javascript のエラーが起きると、残りのコードは実行されなくなる。Google Analytics のコードがそのエラーより後であれば、トラッキングできなくなる。

robots.txt で Disallow: ではなく Noindex: を使う意味

2009 年 5 月 27 日 水曜日

サーチエンジンにインデックスさせたくない場合に、robots.txt を使ってインデックスさせないようにすることができます。たとえば、何かの謝罪のページや、会員向けページとか、いろいろ。その robots.txt でインデックスさせない設定の Disallow: と Noindex: が違う意味を持つようです。

robot.txtのNoindexは、クローラをアクセスを妨げるものではありません。
アクセスは拒否せず、インデックスだけを拒否します。
「中身を見るけれども、内緒にしておく」ということです。

アクセスして、リンクがあればリンクをたどりリンク先へPageRankを渡します。
※ただし、リンクにnofollow属性が付いていたり、meta noifollowタグが記述してあれば、リンク先をたどらないので、PageRankは渡されません。

すなわち、meta noindexタグと同じ振る舞いをします。

suzukikenichi.com : robots.txtのNoindex(Disallowではない!)を使ったPageRankスカルプティング

簡単にまとめると

Disallow:

  • クローラのアクセス自体を拒否して、インデックスを防止
  • クローラがアクセスしないので、次のページへページランクを渡せない

Noindex:

  • クローラのアクセスは許すけど、インデックスはさせない
  • インデックスしないけど、クローラはアクセスするのでページランクは渡せる
  • ただし、サポートしているのは Google だけ

Google のウェブマスター/サイト所有者 ヘルプ を見てみると、たしかに、小さく書かれていました。でも、この文章から、上記の動作になることはさっぱりわかりませんでした。。

ページのコンテンツが他のサイトからリンクされていても、Google のウェブ インデックスに一切登録されないようにするには、noindex メタ タグを使用します。Googlebot がページを取得するとき、noindex メタ タグを認識してウェブ インデックスにそのページが表示されないようにします。また、Google のウェブ インデックスでは、robots.txt ファイルに「noindex」を記述して、クロール対象外の URL リンクへの参照を Google ウェブ検索結果の表示から外すこともできます。

http://www.google.com/support/webmasters/bin/answer.py?answer=35303&query=Noindex&topic=&type=

 

古いドメインのほうが有利であるわけではない

2009 年 5 月 10 日 日曜日

以前から、新しいドメインより古くからあるドメインのほうが SEO に有利だといわれてきたように思いますが、そういうわけではないようです。

よくドメインレジストラなどが宣伝文句で、ドメイン登録年数が長いと検索ランキングで有利!といったことを言うのですが、登録年数が3年だろうと5年だろうと関係ありません。

SEM リサーチ : ドメインの年齢はランキングに影響するか? – Google Matt Cutts氏

ということは、エイジングフィルタに引っかかる最初の 3-6 か月程度を過ぎれば、どのドメインも変わりはないということですね。

h2タグの下にh1があっても問題ないか?

2009 年 5 月 10 日 日曜日

h2 の下に h1 を置きたい場合はそんなに経験してないですが、h2 の下に h4 を置きたい、なんていう場合は結構あります。それが SEO にどう影響するかということは前から気になっていました。

h2 の下に h1 があることは問題ないようです。

ウェブの40%に何らかの構文エラーがあるとの統計もあり、Googleはそうした文法間違いを織り込んだ上でクローラでウェブを収集している。したがって、h1タグ(要素)がh2タグ(要素)の下にあっても問題にはならない。

SEMリサーチ「h2タグの下にh1があっても問題ないか?「ない」- Google Matt Cutts氏」

質問に答えている Matt Cuts さんは、Google の WEB スパムチームのヘッド。ブログも運営しています。
http://www.dullest.com/blog/

Google Analytics のデータ保存期間

2009 年 5 月 10 日 日曜日

最近よく使うので、どのくらいの期間、データが残されるのか調べてみました。

現時点では、25か月を超えた過去のデータであっても消えることはないようです。しかし、料金を支払うことによってデータの保存期間を延長するようなサービスも提供されていませんし、Urchinなどの他のサービスで再利用できる形でのデータのエクスポート機能なども提供されていません。

http://web-tan.forum.impressrd.jp/e/2008/08/19/3758

確かにヘルプには保存期間に関する記載はないようです。データのエクスポートは定期的にしたほうがよさそうですね。