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

ナビゲーションサマリー

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

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

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

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

閲覧開始後の遷移

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

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

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

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

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

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

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

こちらは 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 には 2つのタイプのアカウントがあります。”user” と “Administrator”。

- User (View reports only)

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

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

- Administrator (Account Administrator)

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

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

共有するユーザーの追加

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

「Add User」をクリック

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

Google?Conversion University

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個以上作成しようとすると、以下のメッセージが表示されました。

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

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

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 のコードがそのエラーより後であれば、トラッキングできなくなる。

リアル店舗の場合

簡単な例として、パン屋さんをはじめようとした場合、どんな順番で何を考えてゆくのかを妄想してみた。

コアコンピタンス

たぶん、パン屋さんを実際に始めようと決心するころには、おそらく何らかの「売り」があるんじゃないかと思う。たとえば、フランスパンだけは負けない、とか、少ない設備で超たくさん製造できるとか。そうした中心となる強みを土台に、こんなパンを売り出そう、とか、こんなお店で、とか色々始まって行くんじゃないかと思う。

場所と顧客

で、実際に店を出そうとすると、まず考えるのは「どこに店をだすか」ということじゃないかなと思う。人通りの少ない所じゃダメだし、パンなんて買ってる場合じゃない人たちばかりのところでもだめ。つまり、パンがほしい人たちのいるところにお店を出す必要がある。当たり前だけど。

たぶん、パン屋さんなら、スーパーや商店街の近くとか、帰宅途中に寄れる場所とかになってくると思う。ただし、すでに目の前に別のパン屋さんがあるところに店を出すのはどうだろう？そうしたライバルの状況も考えて店を出す必要がある。

競合

で、いろいろ考えた結果、場所を決めるのだけど、競合が全くいない状況というのは考えにくい。すでに数件あったり、コンビニやスーパーがあったりする。そこで、どうやって勝ち残っていくのか。

やはり、味がいい、値段が安い、店の雰囲気がいいなど、他よりも優れた価値が必要になる。

まとめてみる

まとめると、以下のようなことが重要になってくる気がする。

• 自分の強み＝コアコンピタンスがある
• 客がいるところで、かつライバルと競合しにくいところに店をだす
• 競合店と差別化したすぐれた価値を提供する

3C について

世の中では、顧客（Customer)、自社（Company)、競合（Competitor）の関係を 3C と呼ぶらしい。自社の強みを活かした価値が顧客に理解され、競合と比較して優位性がある関係をまずは考えてみる。でもあくまで、本当に大枠の仕組みだけ。

WEB の場合

今度は、WEB の場合に事業戦略の大枠である 3C を考えてみる。おそらく、コンピタンスから大きく変わってくることはないと思う。大きく変わってくるのは、顧客と場所ではないかと。

場所と顧客＝検索エンジン

顧客が WEB サイトを訪れるのに必ずとおるのが検索エンジン。それ以外にも、URL 直打ちとか、メールマガジンとかもあるけど、ほぼ検索エンジンからサイトへの動きであると言える。

そして、リアル店舗の立地を WEB に置き換えるなら、検索エンジンの検索結果のページがまさしく立地になるのではないかと思う。そのページにすでに顧客が存在していて、そこに店を出店するイメージ。

競合

そうすると、今度はその検索結果のページで何位に表示されるかということが重要になってくるのだけど、その検索結果にはすでに大勢の競合がいることがわかる。

ネットでは情報の入手が簡単な分、サービスや価格の比較が簡単。価格.com なんてその最たるもの。もちろん検索結果の順位を上げることも必要だけれど、同時にリアル店舗と同様に他店と差別化した優位点を打ち出すことが必要になる。

まとめてみる

ここまで、妄想してきて、WEB でも実店舗でも売上を伸ばすために必要なことはほとんど変わらない気がして気が。もちろん本当に大きな外枠の話だけだけど。

• 3C の構造は WEB でも変わらない
• 変わるのはお店の立地という概念が検索エンジンの検索結果になったとこ

検索エンジンとキーワード

キーワード重要性

ここまででみたように、事業戦略の大枠が 3C の関係であるとすると、WEB での事業戦略はキーワードの選択であるといってもよさそうなくらい。キーワードで WEB 上での立地が決まって、自社と顧客と競合の関係が生まれるのだから。

逆を言えば、キーワードの選択を間違うと、まったくひどい場所に店を出すことになってしまう。WEB では自分が入力したのではない別のキーワードの検索結果を見ることなどほとんどないはずなので、別なものを探す人の前にパン屋の情報を出すことになってしまう。これでは全く意味がない。

キーワードの選び方

ここまできて、やっと、キーワードはどうやって選ぼう、という話なってくる。キーワードを選ぶことは店の立地なので、見込める顧客の数（検索回数）、競合の数や質を見極めて決めることになるのだろうと思う。

• 自社が販売する商品にもっとも適合するキーワードはなにか
• それぞれのキーワードはどのくらい検索されているか ＝ どのくらいの顧客がいるか
• 検索結果の件数はどのくらいか ＝ 競合サイトはどのくらいあるか
• 競合サイトのサービス内容・質のリサーチ

次はこのキーワードの決定を具体的にどうするとよさそうかを考えてみよう。

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=

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

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

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

小さなレジストリモデルは、.comや .netなどで採用されています。このモデルでは、ドメイン名を誰が登録しているか、という情報はそれぞれの窓口であるレジストラが保有し、レジストリには伝えられません。レジストリは単に、ドメイン名がどのレジストラによっていつ登録され、いつまでが登録期限かという情報と、DNSの運用に必要な情報のみをもっています。

一方、大きなレジストリモデルは、.jpや.infoなどで採用されています。このモデルでは、ドメイン名の登録者情報はレジストラ（.jpでは指定事業者）を通してレジストリに伝えられ、レジストリにおいて一元管理されます。保有する情報が多いため「大きなレジストリ」と呼ばれるわけです。

All in one INTERNET magazine : ドメイン名の登録者は誰ですか？／知って得するドメイン名のちょっといい話 #14

 

ドメイン登録者の情報の管理を、レジストラが行う場合とレジストリが行う場合があるんですね。レジストラの経営破たんなどがあった場合、レジストリが登録者の情報を管理していれば、次のレジストラへの移管がスムーズにできるという話も載っていました。

企業ではなく、個人がドメインを取得する場合、.jp のような高めのドメインを取る理由は何だろうと思っていたのですが、.jp の場合、レジストリが情報を管理するので、いざというときも大丈夫ということがありそうです。

レジストリ

レジストリは、各TLD（top level domainのことで、.comとか .jp とか）を管理を行う

レジストラ

レジストラは、ユーザーにドメインの新規登録とか、更新手続きなどのサービスを提供

まだ 10 ページも読んでいないのですが、なるほどと思うことがたくさん。言われてみればもちろんそのとおりなんだけど、普段は全く意識していなかったな、ということが。

商品や販売形態でユーザーが求めているものが変わる

たとえば

• Amazon なら自分が探している本が確実に手に入る
• インターネットで花を贈れば、手間をかけずに適切な予算とタイミングで送ることができる
• ファッションやアクセサリーは、現実のお店より選択肢が多いにちがいない

それに対して、そうしたサービスをインターネット上で展開しようとする事業者側の意識が、単なる顧客接点の獲得であることが多く、ユーザーの意識とかい離してしまっている。ということが最初の章に書かれています。

煎じつめればユーザーの視点に立って、それに最適化したサービス、サイトを作る。ということになってくると思うんだけど、改めて文章で読んでなるほどと思った。あたりまえのことなんだけどね。

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

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

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

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