【UPDATE(2010/11/23)】
問題はすでに解決されたと公式アナウンスがありました。
過去のデータは再処理されません。
インスタントプレビューによるアクセスを除外したいときは、公式アナウンスで紹介されている記事に書かれている”Option 1: Advanced Segment“の手順に従ってアドバンスセグメントを作成します。
インスタントプレビューが一部のアクセス解析ツールのページビューを増加させてしまっているという問題が発生しています。
アクセス解析ツールにはGoogle Analyticsも含まれています。
1つ前のインスタントプレビューFAQの記事で書いたように、インスタントプレビューの作成には2種類のパターンがあります。
1つはGoogleの通常のウェブ検索クローラであるGooglebotによるもの、もう1つはプレビュー専用のクローラであるGoogle Web Previewによるものです。
後者のGoogle Web Previewのアクセスがページビューを発生させてしまうのです。
Googlebotのクローリングとあわせてインスタントプレビュー用のプレビューデータが取得されます。
データが存在するときは、それをもとにプレビューを表示します。
しかし、プレビューデータが存在しないときに検索結果ページでユーザーがプレビューを見ようと虫眼鏡アイコンをクリックすると、Google Web Previewが対象ページにアクセスしてその場でプレビューを生成します。
まさしく“インスタント”ですね。
Google Web PreviewはJavascriptを実行できます。
つまりGoogle Analyticsのトラッキングを発動させてしまうのです。
下のキャプチャは、Google Web Previewのユーザーエージェントである「Safari/525.13」のアクセスです。
インスタントプレビューが導入された11月10日に数が伸びています。
平均3くらいだったのが10を超えています。
データの数が少ないので断言はできませんが関係が疑われます。
徐々にアクセス数が下がっていますが、これはGooglebotによる通常のクロールでのプレビュー取得が完了してGoogle Web Previewによる“その場”でのプレビュー取得の回数が減ったからではないでしょうか。
Google社員のJohm Mueller(ジョン・ミューラー)氏によれば、Googleはこの問題を認識しておりGoogle Web PreviewがGoogle AnalyticsのJavascriptを実行しないように対処策を講じているそうです。
ただ、いつになるかは分からないとも付け加えています。
We’re working on a solution for this, to prevent Google Instant Preview on-demand fetches from executing Analytics JavaScript. I’m not sure about the timeframe, …
僕のブログくらいのアクセスなら無視できる数字ですが、検索からのアクセスが膨大なサイトではインスタントプレビューが実行される機会も多いでしょうからより正確なデータを求めるなら注意が必要かもしれません。
“即席”でGoogle Web Previewを除外するとしたら、ブラウザの種類とIPアドレスでフィルタするしかないですかね？
「Safari/525.13」は人間のユーザーも使っているようですから、Googleの使っているIPと組み合わせないと除外しなくていいアクセスまで除外してしまいます。
Google Analyticsは正確なUAを取得できませんでしたよね？
使った経験はありませんが、SiteCatalystではこうやるとインスタントプレビューを除外できるそうです。