上記の記事を読んでもクリック数とセッション数の不一致の原因がよくわからない場合、レイテンシが原因である可能性があります。レイテンシが原因である場合には、次の特徴があります。
- クリック数とセッション数の不一致が特定のキャンペーン、広告グループまたはキーワードで生じるのではなく、複数のキャンペーン、広告グループまたはキーワードで生じている。
- すべての有効な Google 広告キャンペーンで、セッションの数がクリックの数より常に少なく計測される。
- デバイス別（パソコン、タブレット、モバイルなど）の分割表示では、プラットフォームごとの不一致が見られます。
この記事の内容:
- 速さが求められる理由
- 配置の問題
- サイトのレスポンスの遅さが招く結果
- すぐに実行できるショート クリック対策
- サイトの速度を調べる方法
- サイトの速度を速くする方法
- リダイレクトの削除とリンク先 URL の更新
- CSS スプライト
- コンテンツ配信ネットワーク（CDN）を使用する
- HTML、CSS、JS ファイルを圧縮する
- よくあるリクエストをキャッシュする
- Infinite Scroll や Lazy Load for Jquery のような ajax やプラグインを使用する
- Gzip 圧縮
- ユニバーサル アナリティクスにアップグレードする
- より高速なウェブ ホスティング サーバー
- その他のおすすめの方法や提案
速さが求められる理由
一般的に、インターネットにアクセスしているユーザーは速さを求めています。それは、さまざまな調査結果からも明らかです。たとえば KissMetrics の調査では、「ページのレスポンスが 1 秒遅れると、コンバージョン数が 7% 減少する」、「47% の消費者は 2 秒以内にウェブページが読み込まれることを期待している」ことが明らかになりました。
したがって、ウェブサイトの読み込みが遅ければ、ユーザーはそのウェブサイトから離れて競合会社のページに移動してしまいます。競合会社のコンテンツの読み込み速度が速ければ、多くのユーザーがそちらに流れるでしょう。
配置の問題
Google アナリティクスのトラッキング コードをページの HTML ソースのどこに配置したらよいかというご質問をよくいただきます。答えは、直帰するユーザーをどれほど正確に測定したいかによります。クリックされてからセッションが記録されるのに数秒かかる場合、そのセッションがトラッキングされない可能性は非常に高くなります。通常は、トラッキング コードを </head> 終了タグの直前に配置することをおすすめしています。
サイトのレスポンスの遅さが招く結果
ショート クリック: ショート クリックは、ユーザーが広告をクリックしてから、Google アナリティクス トラッキング コードのリクエストが発生する前に、ユーザーが [戻る] ボタンをクリックするかブラウザを閉じる場合に発生します。この場合クリックは Google 広告で記録されますが、それに対応するセッションは Google アナリティクスでは記録されません。
通常、ウェブサイトのレスポンスが遅く、Google アナリティクス トラッキング スニペットの前に実行されるリクエスト数が多いほど、ショート クリックによるセッション データの記録漏れは発生しやすくなります。
ショート クリックとは、言い換えれば、ユーザーがウェブサイトから直帰したことを意味しています。したがって、このような直帰セッション（ショート クリック）もきちんとトラッキングしなければ、直帰率は不自然に低くなってしまいます。
モバイル端末とショート クリック: 通常モバイル端末は、パソコンのネットワーク接続（ADSL またはケーブル）より速度の遅いネットワーク インフラストラクチャ（3G ネットワーク）を使用しています。したがって、モバイル端末をターゲットに設定している場合、ショート クリックを防ぐためにウェブサイトのレスポンスを速くすることはさらに急務となります。
すぐに実行できるショート クリック対策
すぐに実行できる対策は、Google アナリティクス トラッキング スニペットを HTML ソースのできるだけ上の方に配置することです。可能な場合、どの JavaScript ファイルよりも上に配置してください。
上のスクリーンショットでは、Google アナリティクス トラッキング スニペットが実行される前にいくつかの JavaScript ファイル リクエスト（同期タグ）が発生することがわかります。最適化のテクニックについては後述しますが、この時点で簡単に実行できる対策は、Google アナリティクス トラッキング スニペットを他の javascript ファイルよりも上に移動することです。アナリティクス トラッキング スニペットは非同期 JavaScript タグなので、Google アナリティクス サーバーからの遅れがあったとしてもページ表示を妨げることがありません。それでアナリティクス トラッキング スニペットを上に移動しても、ページの表示時間が遅くなる心配はありません。
この対策が一時的にでも有効と言えるのは、それまで記録できなかった、Google アナリティクス スニペットが実行される前にページを離れるユーザーのセッションが記録できるようになるからです。ただし長期的には、根本的な問題であるウェブサイトのレスポンスの遅さを解決して、ユーザーの直帰を防ぐ必要があります。
サイトの速度を調べる方法
前述のように Google アナリティクス トラッキング コードを HTML ソースの上の方に配置することはある程度助けになりますが、問題を根本から解決するにはウェブサイトのレスポンスを早くすることが必要です。
以下の方法でウェブサイトのレスポンスの速度を調べることができます。
テスト 1:
キャッシュを空にし（必要に応じてキャッシュと Cookie をクリアする）、新しいタブを開いて、リンク先 URL をブラウザのアドレスバーに入力し、Chrome デベロッパー ツールを起動して、[Network] タブを開きます。
ウェブサイトを読み込み、リクエスト リストを確認します。次のように表示されます。
_utm.gif（標準のアナリティクス）か collect（ユニバーサル アナリティクス）を見つけて、右側に表示される [Timeline] セクションを確認します。上の図では、最初のリクエストが実行されて（ここでクリックが記録される）から Google アナリティクス リクエスト（ここでセッションが記録される）までに 8 秒かかったことがわかります。
この 8 秒以内にユーザーが [戻る] ボタンをクリックすると、Google アナリティクスではこのウェブサイトでのセッションが記録されず、Google 広告ではクリックが記録されます。
KissMetrics の調査結果である「ユーザーの半数は、ページが 2 秒以内に読み込まれることを期待している」ことを考えると、 このウェブサイトは改善の余地があります。
テスト 2:
Google アナリティクスでは、サイトの速度レポートの一部として自動的にページの読み込み時間のデータが取得されます。
サイトの速度レポートでは、特定の Google 広告リンク先 URL のレイテンシを確認できます。この例では、この URL のサイトの読み込み速度は約 25 秒で、非常に遅いことがわかります。
さらに、このページの直帰率も高いことがわかります。つまり、このリンク先 URL のパフォーマンスは、ショート クリック（記録されない直帰）が発生しているうえに、記録されている直帰率も高いという点で、あまりよいとは言えません。
理想的には、ページの読み込み速度は 3～4 秒にする必要があります。
サイトの速度レポートは、ページの読み込み時間を確認するのに役立ちますが、デフォルトでは、サンプルはトラフィックの 1% に基づいています。1 日にサイトにアクセスするユーザーが 100,000 人以下のように比較的少ない場合、サンプルレートをもう少し高くする（5% など）ことをおすすめします。レートを高くすることで、ページの読み込み時間などサイトの速度を表す指標の精度が増します。
レートを高くすると追加のリクエストが作成されることになりますが、ほとんどの場合ユーザー エクスペリエンスに悪影響を与えることはありません。
サイトの速度を速くする方法
Google アナリティクスのサイトの速度レポートでは、読み込み速度についての提案が示されます。クリック数が最も多いリンク先 URL を入力して、ページの読み込み速度を速くする提案を確認してください。
リダイレクトの削除とリンク先 URL の更新
リダイレクトでは Google 広告の自動タグ設定パラメータが継承され、そのパラメータが最終的なリンク先 URL に渡されますが、クリックが発生してから Google アナリティクスでセッショッンが記録されるまでにさらにレイテンシが生じます。
サイトによっては、Google 広告のクリックと最終的なリンク先 URL の間に複数のリダイレクトが設定されています。
Google 広告のリンク先 URL を更新して、最終的なリンク先 URL の前にリダイレクトが発生しないようにしてください。
別のケースとして、クライアントがクリック サーバーなどの仲介サービスを使用して、Google 広告のクリックを記録している場合があります。通常、このようなサービスは第三者のレポート プラットフォームによって使用されます。
複数のプラットフォームでレポートを記録することには利点がありますが、このサービスがボトルネックとなってユーザー エクスペリエンスを遅くすることがあります。クリック数と Google アナリティクスで記録されるセッション数が一致しない場合は、一定の期間そのクリック トラッカー サービスを削除して、クリックとセッションの比率が改善されるかどうかを確認してください。結果に応じて、第三者プラットフォームでトラッキングを引き続き使用するか、代わりにもっと速いプロバイダを探すかなどを考慮してください。
CSS スプライト
CSS スプライトを使うと、複数の画像リクエストを 1 つにすることができます。
上の図のウェブサイトには、小さな画像アイコンやファイルへの複数の画像リクエスト（.png ファイル）が複数含まれています。CSS スプライトを使用すると、すべての画像を 1 つの大きな画像として 1 つのリクエストで処理し、CSS を使ってウェブサイトの特定の領域に画像のどの部分を表示するかを決めることができるので、画像リクエストを何度も行う必要がなくなります。1 つの大きな画像リクエストの方が、複数の小さな画像リクエストよりも速く処理されます。
コンテンツ配信ネットワーク（CDN）を使用する
コンテンツ配信ネットワークは、より高い拡張性と信頼性を実現しながら、ウェブサイトを高速化できる優れたソリューションです。このネットワークでは、頻繁にアクセスされるファイルやコンテンツを世界中の複数のサーバーに分配して配置します。
通常ウェブ ホスティング サービスは、いずれかの物理的な場所に固定して配置されます。たとえばウェブ ホスティング サービスが東京にある場合、東京に住むユーザーにはウェブサイトのコンテンツは速く配信されますが、オーストラリアやヨーロッパのユーザーは、東京から配信されるファイルを受信するのにレイテンシを経験することになります。CDN を使うことで、オーストラリアやヨーロッパに住むユーザーも自分の所在地の近くのサーバーからファイルを受信することができます。
ウェブサイトを世界中の複数のサーバーに分配することで、サーバー停止などのインフラストラクチャ問題の影響も軽減することができます。
CDN は、JavaScript ファイル、CSS、HTML、画像や動画のコンテンツなど、通常あまり変更が生じない静的なコンテンツに最適です。ファイル内の行間が削除されるため、JavaScript、CSS、HTML ファイルはできるだけ小さなサイズに圧縮されます。
Google では、Google PageSpeed と呼ばれる独自の CDN サービスを提供しています。
HTML、CSS、JS ファイルを圧縮する
CDN サービス（上述）以外にも、他のモジュール、プラグイン、無料ウェブサービスを使って、行間を削除したり複数のファイル（CSS ファイルなど）を 1 つのリクエストにまとめたりすることでコンテンツを自動的に圧縮することが可能です。
よくあるリクエストをキャッシュする
多くの人がアクセスするウェブサーバー スタックでは、Linux Apache MySQL PHP（LAMP）が使用されています。
上の図から、HTML でレンダリングされたページがユーザーに返されるまでに実際には次のステップが関係していることがわかります。
- ウェブサーバーがリクエストを受信します。
- 次にウェブサーバーはリクエストを PHP を介して送信します。これによりアクセスするファイルやデータベース行が決まります。
- PHP はこのリクエストをパッケージ化して、関連する HTML ページを構築します。このページがユーザーに返されます。
キャッシュすることのメリット
多くの場合、「よくある質問」ページのようなページのコンテンツは、ユーザーがページをリクエストするたびに変更されるわけではありません。上の図に示されたすべてのステップを踏むよりも、一度だけページを構築して、そのページを一時 HTML ファイルとしてキャッシュすることができます。これにより、ウェブサーバーが PHP を介してページを生成し、データベースに対してクエリするという同じタスクを何度も繰り返す代わりに、ほとんどのユーザーに静的 HTML ファイルを配信することができます。結果として、ウェブサーバーが絶え間ないマルチタスクから解放されるので、すべてのユーザーにすばやく対応することが可能になります。
無料のモジュールを使って、このタスクをウェブサイトで実行することができます。
上記の PHP は一例ですが、多くの他のウェブサーバーでも同様の仕組みが採用されているため、同じようなモジュールを使用してページのキャッシュを実行することができます。
Infinite Scroll や Lazy Load for Jquery のような ajax やプラグインを使用する
一部のウェブサイトは、ページを下にスクロールするに従ってコンテンツが読み込まれる仕組みになっています。YouTube では、関連動画のサムネイルがその例です。またコメント セクションでは、追加のコメントをリクエストしない限り最初のいくつかのコメントだけが表示されます。
このような技術を適切に使用するなら、最初に読み込まれるページサイズを小さくすることによりリクエストを軽減できるので、ユーザーはページの操作をすぐに始めることができます。ユーザーがコンテンツをさらに見たい場合に下にスクロールすることで、追加のアイテムの読み込みがトリガーされます。
この方法を導入する場合は、操作性と使いやすさについて考慮する必要があります。詳しくは、LazyLoad と InfiniteScroll の記事をご覧ください。
Gzip 圧縮
HTML、CSS、JavaScript などのページに対して実行できる Gzip 圧縮形式は、古いウェブブラウザではサポートされていませんでしたが、モバイル端末を含む最新のブラウザではサポートされるようになりました。この機能の最大の特徴は、スイッチを切り替えるだけで使うことができるという点です。
Gzip の詳細については、こちらの動画をご覧ください。
ユニバーサル アナリティクスにアップグレードする
標準のアナリティクス（ga.js）からユニバーサル アナリティクス（analytics.js）にアップグレードしていない場合は、最新の Google アナリティクス プラットフォームであるユニバーサル アナリティクスに移行することをおすすめします。ユニバーサル アナリティクスにアップグレードすると、最新のサービス機能をご利用いただけるだけでなく、次の点でパフォーマンスが向上します。
- モジュールベースのトラッキング コード ライブラリ: analytics.js では、e コマースのようなトラッキングには外部モジュールが使用されます。このモジュールは、すべてのウェブサイト トラッキング（ga.js でのトラッキング方法）では既に含まれていません。これによりファイルサイズの点で analytics.js のフットプリントを削減できるため、ファイル転送速度が高速になります。
- Cookie への依存を軽減: ユニバーサル アナリティクスでは、キャンペーンとセッションのデータはクライアント側ではなくサーバー側で計算されるので、ファイル リクエストごとに転送される Cookie データの量を軽減することができます。これにより、多少とはいえ目に見えるパフォーマンスの向上が得られます。
より高速なウェブ ホスティング サーバー
ウェブサイトの速度が遅いと、ビジネス チャンスを逃すことがあります。そのようなことを避けるため、より高速なウェブ ホスティング サーバーへのアップグレードをおすすめします。
その他のおすすめの方法や提案
この記事ですべての最適化のテクニックを取り上げることはできませんが、他にもたくさんの方法があります。その他のおすすめの方法や提案については、こちらの記事をご覧ください。
最後に留意する点として、ウェブサイトの速度やレスポンスを向上したとしても、ユーザーが使用するインターネット接続やモバイル ネットワーク接続が遅いという問題に直面する場合があると言う点が挙げられます。これは、遠隔地や農村部、発展途上国など、制限のあるまたは旧式の電気通信インフラストラクチャを使用する場所で起こる可能性のある問題です。
そのような状況では、ウェブサイトのレスポンスをできるだけ速くすることが重要ですが、ウェブサイトの最適化を図っても、ユーザーの接続が遅いことが原因でショート クリック問題を避けることができない場合があることにご留意ください。
