Web blog WEBブログ

プロが教える集客や売上を改善するGoogleアナリティクスの使い方【改善方法編】

2018.05.31

こんにちは。WEBコンサルタントの三和です。

今回はGoogleアナリティクスの説明の第3回目。
Googleアナリティクスを活用したWEBサイト改善方法をお伝えしていきます。

Googleアナリティクスを見ているものの、何をどうしたらいいのかわからない、どうやって改善すれば良いのかわからない方は、今回お伝えする"3つの改善ポイント"をぜひ参考にしてみてください。

【改善ポイントその1】WEBサイト改善の基本は「ゴール前」から改善する!

WEB解析から改善する方法は、ゴール前から改善し、最後に集客を改善するのが基本です。

ゴール前というのは、一番コンバージョンに近いところ。

問い合わせフォームやカートなどを指します。

一方、集客はWEBサイトの入り口のことですね。

なぜ、ゴール前から改善すべきかと言うと、目に見える成果が上がりやすいからです。

 

例を示します。

前回のGoogleアナリティクスの操作方法編でお伝えした方法で以下の数値を取得できたとします。

 

サイトAの月間値・お問い合わせページのアクセス数:100回

・問い合わせ内容確認ページのアクセス数:10回

・お問い合わせ数:5回

・エラーページ表示回数:5回

※ユーザー数ベースでもOKです。

 

現在のお問い合わせページからの問い合わせ率は5%となります。

しかし、ここで問題なのが、エラーページが5回も表示されてしまっていることですね。

このエラーページ表示がなければ、お問い合わせ数は10回(つまり倍)獲得できていたかもしれません。

もし10回獲得できていれば、問い合わせ率は10%となり、それだけでお問い合わせ数が2倍に、問い合わせ率で5%も改善できるのです。

これが、もしゴール前から改善せず、お問い合わせページへのアクセス数だけ増やしたとすると、10回のお問い合わせを獲得するために必要なアクセス数は200回となります。

特定ページへのアクセス数を倍に増やすことは簡単なことではありません。

しかも、質の悪いアクセス数を増やしても、問い合わせ率が5%よりも下がってしまうリスクもありますからね。

なので、

・なぜエラーページが表示されたのか?

・エラーになってしまって問い合わせをやめてしまったのではないか?

このような仮説を立てて、エラーページが表示されないように改善策を実行していきましょう。

「なんだ、すごく簡単だな」と思いませんか?

しかし、そんな簡単なことが、実は多くのWEBサイトでできていません。

大きくコンバージョンが改善できるポイントがあるのにも関わらず、多くの方がそれに気がつかず、アクセス数アップなど、入り口部分から改善しようとしてしまっています。

これは、非常に効率と費用対効果が悪い改善方法だと、今ここで正しく認識しておきましょう。

また、お問い合わせフォーム以外にも、ECで言えば、ショッピングカートなどでも同じことが言えます。

なぜカートで離脱してしまっているのか?

細かく数値を分析し、仮説を立てて改善策を実行しましょう。

この工程が、WEBサイト改善の第一歩です。

そのためには、設定編でお伝えしたコンバージョントラッキングが必要不可欠ですので、設定に不備がないようにしましょう。

【改善ポイントその2】あなたのオファーは大丈夫?

もし、一番ゴールに近い部分が改善できて問い合わせ率がアップ出来れば、今度はその前のフェーズの改善に移ります。

お問い合わせページのアクセス数を増やすことはできないか?と考えます。

 

・各ページにお問い合わせページに行ける導線は設けてあるか?

 

多くの方がこのように考えて、お問い合わせページのリンクやボタンの設置を強化する施策を取るかと思いますが、実はこのような施策では改善できないケースの方がほとんどです。

なぜなら、それはユーザーの心理状況を無視した、小手先の改善方法だからなのです。

 

ここで、ちょっと違う視点から改善ポイントを挙げます。

 

・各ページに設置してあるお問い合わせページへのリンクのオファー内容は適切か?

 

この改善ポイントはどうでしょうか?

オファーとは、ユーザーに対して行う「提案」のこと。

Aという商品のページを見ているユーザーからは、当然Aという商品への問い合わせが期待でき、Bという商品ページでしたらBへの問い合わせが期待できますよね。

Aを見ているユーザーにはこのオファーを、Bにはこのオファーを、という感じで、それぞれ最適な内容のオファーを提供できていますか?

ただただ、「問い合わせはこちら」のようなシンプルなプル型のオファーでは、そこに成果が上がらない理由があります。

オファーとは本来、ユーザーに対して「喉から手が出るほど欲しい」内容であるべきなのです。

そのようなオファーが提供できれば、例えお問い合わせページへの導線設計がイマイチであったとしても、コンバージョンしてくれますからね。

サイト内に大量のページがある場合は、多くのページのオファーを改善するには時間と手間がかかってきます。

ですので、お問い合わせ率が高いページやアクセス数が多い人気なページから改善することが効率的なのでお勧めです。

【改善ポイントその3】各フェーズの遷移率→最後に集客の順に改善する

ここまでお伝えしたように、改善の基本はゴール前からどんどん遡り、数値を改善していくことです。

そのためには、ユーザーがゴールに至る最も代表的な過程をしっかり把握しておかなければなりません。

前回までの内容で、上記のようなコンバージョンに至るケースを分析し把握しておきましょう。

これができれば、あとは各フェーズの遷移率とアクセス数をアップさせるだけ。

先に遷移率を改善、次にアクセス数の順番です。

WEBサイトの改善とは、ざっくり言えば、それをゴール前から行っていくだけの作業です。

もちろん、サイトの使いやすさや情報の探しやすさ、デザイン性など、ユーザビリティを改善することももちろん改善ではありますが、それらはコンバージョンという「事業成果」に直結する結果からは”遠い”改善です。

売上改善などの事業成果に結び付くWEBサイトの改善と考えた場合、ユーザビリティを改善するよりも、まず最初に、ゴール前の遷移率から改善していきましょう。

少し話が逸れてしまいましたが、ユーザーがコンバージョンに至るパターンが複数ある場合や、webサイトのボリュームが大きい場合でも基本は一緒。

それぞれのコンバージョンパターンで上のような図を作って改善していくだけなのです。

ECサイトであれば、もっと細かい改善ポイントはたくさんありますが、この遷移率→集客の順番に改善を行うという考え方は全てのサイトの改善で共通しています。

また、これはwebに限ったことではなく、リアルを含めて全てのビジネスに共通する効率的な改善方法です。

是非この機会に覚えておきましょう。

Googleアナリティクスを活用してPDCAを回そう!

PDCAサイクル

GoogleAnalyticsは、あなたのWEBサイトのどのページを、あるいはどの部分を改善すれば良いか?を教えてくれる非常に便利な無料ツールです。

しかし、改善すべき点を見つけただけでは数値が勝手に上がるようなことは当然ありませんから、あなた自身で改善案を考え、実行し、改善されたかをチェックしなければいけません。

つまり、Googleアナリティクスは、あなたがWEBサイトのPDCAを回すことができるように存在しているのです。

先にもお伝えした通り、改善案は成果につながりやすい順番で(つまり数値が大きい箇所やページから)行うことがポイントです。

また、同時に複数の改善策を実行することもお勧めしません

条件が変われば、結果が変わってしまうからです。

ですから、必ずWEBサイトの改善策を行うときは、それ以外の条件は改善策を行う前と同じにしておきましょう。

よくあるミスが「WEB広告」です。

広告のリンク先として設定しているページ内で改善策を施した際に、広告のターゲット設定も同時に変えてしまったら、もし結果が上がったとしても、その要因はページの改善にあるのか、広告のターゲット設定を変えたからなのかわからなくなってしまうからです。

以前と同じ条件下で改善策を行い、正しくチェック(評価)できる状況を作っておくことも、WEBサイト改善を行う上では非常に重要なことです。

残念ながら、WEBサイトの数値測定すらまだまだ満足にできていない会社様も多くいらっしゃいますが、WEBサイトは今回お伝えした方法で改善を取り組んでいただければ、非常に事業成果が上がりやすいツールですので、ぜひ改善に取り組んでみましょう。

まとめ

いかがでしたでしょうか?

ここまで3回にわたって、GoogleAnalyticsを使ったアクセス解析方法をお伝えしてきました。

初回にお伝えした通り、GoogleアナリティクスはWEBサイト上のユーザーの行動をすべて数値化(可視化)することが可能なツールです。

これを使いこなせば、WEBサイトをもっともっと事業成果につながる有益なツールとして成長させていくことができますので、ぜひ今回お伝えした分析方法でGoogleアナリティクスを使ってみてくださいね。

なお、Googleアナリティクスのついてのご質問があれば、随時無料で承っておりますので、疑問質問ございましたらお気軽に弊社マーケティングチームまでご連絡くださいませ。

三和 久晃

この記事を書いた人 三和 久晃 Webコンサルタント