Google Analyticsのmobile流入は全体比率で終わらせずlanding pageと問い合わせ完了を分けて見る

Google Analyticsでmobileからの流入を調べるときは、site全体の比率だけで改修を決めません。Device Categoryでdesktop、mobile、tabletを分けたうえで、どのlanding pageへ来たか、問い合わせを完了できたかを確認します。mobileの訪問が多いことと、すべてのpageを同じ順序で直すことは別です。

mobile対応は、画面を狭くしても崩れないかだけの作業ではありません。利用者が、料金、対応地域、営業時間、連絡先のような用件を、手元の端末で確認し、次の行動へ進めるかを確かめる作業です。全体の訪問比率は入口に過ぎません。どのpageから来て、どこで止まり、どの問い合わせ経路を使うかまで見て、修正の優先順位を決めます。

Googleの2016年5月の案内は、Google Analyticsを使うweb site全体では、smartphoneとtabletからのtrafficが半数を超えると説明しています。この数字は各siteの利用者構成を決めるものではありません。自社siteでは、実際の流入と、mobileで用件を済ませられるかを別に確認します。

site全体の比率と修正するpageを分ける

site全体のmobile比率は、確認を始めるきっかけになります。修正するpageを決めるには、その端末からよく開かれるlanding pageと、その後の行動が必要です。同じmobile訪問でも、短い案内だけを読む人と、問い合わせ直前まで進む人では、直すべき箇所が違います。

たとえば、mobileの訪問が多くても、問い合わせ完了が少ない理由は一つではありません。formの項目が長い、電話番号が見つからない、移動先のpageが遅い、mobileでは用件を調べてdesktopで問い合わせる、といった可能性があります。訪問数だけでは原因を決められません。

top pageのmobile比率が高いからといって、top pageだけを優先するとも限りません。検索結果や広告から直接来る料金page、service page、地域pageの方が、問い合わせに近い場合があります。利用者が最初に開くpageと、最後に問い合わせるpageを分けて記録します。入口pageが役に立っているかは、表示回数や訪問数だけでなく、次の説明へ進めるかで見ます。

tabletもmobileと同じにまとめる前に、数を確認します。tabletの利用者が多く、画面の使われ方がdesktopに近い場合もあります。端末の分類名だけで、同じ問題が起きていると決めません。各siteでどの端末を優先して確かめるかを、訪問と問い合わせの記録から決めます。

同じ入口pageで端末別の行動を比べる

最初は、mobileからよく開かれるlanding pageを一つ選びます。同じ期間について、mobileとdesktopの訪問数、主要な案内pageへの移動、問い合わせ完了を並べます。pageごとに入口が異なるままsite全体の数字を比べると、端末差なのかpageの役割の差なのか分かりません。

説明用の仮例として、料金pageへmobileから100訪問、desktopから100訪問があったとします。mobileだけ問い合わせ完了が少ない場合は、まずその料金pageからformまでの案内を開きます。次に実機で金額、条件、電話番号、送信buttonを確認します。広告の入札やpage全体の作り替えは、その確認の後です。

比較するときは、期間と計測条件をそろえます。formを直した週と直す前の週を比べるなら、広告費、営業時間、休業日、campaignの変更も記録します。端末別の数字が変わっても、同じ時期に別の条件が変わっていれば、表示修正だけの効果とは言えません。

比較する数字が少ないときは、比率だけで結論を急ぎません。たとえばmobileの問い合わせ完了が数件しかない期間は、一件の違いで割合が大きく変わります。その場合は、pageを実際に操作した結果、受付担当が受けた内容、formの送信記録を合わせて見ます。解析の数字と画面の確認は、どちらか一方の代わりではありません。

pageの問題が見つかったら、直す箇所を一つに絞ります。電話番号を見つけにくいなら、連絡先の位置と文言を直す。料金の条件が読みにくいなら、料金pageの見出しと案内を直す。formが長いなら、返信に必要な項目を確認する。すべてのpageを同時に作り替えるより、問い合わせに近い一つの障害を先に取り除く方が、結果を確認しやすくなります。

mobileで用件を済ませる経路を実際に開く

解析reportを見たら、mobile端末でpageを開きます。表示幅だけでなく、利用者が次の行動へ進めるかを確かめます。

1. Device Categoryでmobileのlanding pageを一つ選ぶ。
2. 同じ期間のdesktopとmobileについて、訪問数と問い合わせ完了を記録する。
3. mobileでそのpageを開き、金額、条件、電話番号、formへのlinkを確認する。
4. 問い合わせformを最後まで操作し、完了pageまたは送信結果を確認する。
5. 直す箇所を一つに絞り、変更日と比較期間を残す。

実機で見るときは、最初のpageだけを開いて終えません。検索または広告からlanding pageを開き、料金や条件を読み、電話またはformへ進み、送信後の画面まで確認します。途中で別pageへ移るなら、そのlinkが見つかるか、戻ったときに入力を失わないかも見ます。画面を横へ動かせるかだけで、問い合わせ経路が使えるとは判断しません。

外部の制作者へ修正を頼む場合も、Google Analyticsのproperty、確認するURL、問い合わせ完了の定義、変更日をsite側で把握します。解析toolを入れていることと、mobileの問い合わせ経路を確認できていることは別です。修正を頼む側は、どの端末で、どのURLを、どの行動まで確認したかを渡します。直す側は、変更した場所と確認した画面を返します。

最初の一手は、mobileのlanding pageを一つだけ選び、実機で問い合わせ完了まで進めるか確かめることです。全pageの比率を眺めるより、直す対象と確認条件を早く決められます。mobile流入が多いことは、作り直しの命令ではありません。利用者が用件を済ませられないpageを見つけ、理由を分け、確認できる範囲から直すための手掛かりです。