月次レポートに「クリック単価が高い」「問い合わせが少ない」「この検索語句が多い」と書いたら、次に実装先まで決めます。検索広告の学びをサイト改善へ戻すには、事実、原因仮説、変更箇所、判定方法まで分けます。
検索広告は反応を見る速度が速い分、気づきも増えます。けれど、タスク化しないまま月次レポートに残すだけだと、翌月には別の数字に流されます。
広告レポートの気づきは、事実と原因仮説に分けるまで作業化しない
改善タスクの出発点は、気づきをそのまま作業名にしないことです。「問い合わせが少ないのでLPを改善する」では、何を変えるのかも、なぜ変えるのかも分かりません。
まずは事実を書きます。たとえば「料金、費用、相場を含む検索語句からクリックが発生している」「その流入ではフォーム到達が少ない」のように、確認できたことだけを置きます。
次に原因仮説を書きます。「LPの冒頭や料金セクションで、相談前に必要な費用感を確認できないため離脱しているかもしれない」というように、まだ確定していない見立てとして扱います。
この分け方をすると、作業が具体化します。料金に関する検索語句が多いという事実から、料金説明の導線を直す仮説が生まれます。問い合わせが少ないという結果だけから、ページ全体を作り直す判断には飛びません。
検索語句をページ単位の変更理由へ翻訳する
Google広告の検索語句レポートでは、広告表示につながった検索語句と掲載結果データを確認できます。Google広告ヘルプでも、検索語句レポートからクリエイティブやランディングページの新しいアイデアを見つけられると説明されています。
ただし、検索語句を見つけただけではタスクになりません。その語句がどのページのどの部分に関係するのかを決めます。
たとえば「料金」「費用」「相場」を含む検索が多いなら、戻し先はLP冒頭、料金セクション、料金ページへの内部リンク、問い合わせフォーム前の説明かもしれません。検索語句が「失敗」「比較」「選び方」に寄っているなら、LP変更よりも記事やFAQで先に説明するほうがよい場合があります。
対象外の語句が多い場合は、戻し先は広告設定です。LPを直す前に、除外キーワードの追加や配信範囲の調整で、明らかに対象外の流入を止めます。
広告文の約束とLP冒頭がずれている場合は、LPが戻し先になります。広告文で作った期待に最初の画面が答えていないなら、冒頭の見出しや導線を直します。
相談前の不安が多い場合は、記事やFAQで受け止めるほうが自然なことがあります。すぐ問い合わせる段階ではない検索者へ、先に不安を説明するページを用意します。
サービス範囲の誤解がある場合は、サービスページを見直します。対応できる範囲と対象外条件が曖昧だと、広告文やLPを直しても問い合わせのずれが残るためです。
同じ検索語句でも、戻し先はひとつとは限りません。大切なのは、広告管理画面の数字をWeb制作側へ丸投げせず、検索者の問いをページ単位の変更へ翻訳することです。
タスクには実装前に成功条件と判定期間を入れる
改善タスクには、変更内容だけでなく、何を見れば改善したと言えるのかを入れます。判定方法がないタスクは、実装しても成果を振り返れません。
問い合わせ数だけを成功条件にすると、流入が少ない場合に判断できないことがあります。その場合は、補助指標も置きます。料金セクションの閲覧、フォーム到達、問い合わせ内容、商談化率などです。
たとえば料金への不安を扱うタスクなら、事実には「料金、費用、相場を含む検索語句からクリックがある一方で、フォーム到達が少ない」と記録します。原因仮説は、LPの冒頭で費用感を確かめられず、相談前に離脱している可能性があることです。
変更箇所はLP冒頭に絞り、料金の考え方へ移動できる導線を追加します。成功条件には、料金セクションの閲覧とフォーム到達率が改善することを置きます。問い合わせ内容が以前より具体的になったかも確認すると、数字だけでは見えない変化を補えます。
このタスクは、変更後4週間を目安に判定します。期間を決めずに改善を重ねると、次の変更と混ざり、何が効いたのか分からなくなります。
LP変更、広告文修正、除外、記事化を同じ作業名にしない
検索広告の学びをサイト改善へ戻すとき、すべてをLP変更にする必要はありません。戻し先を間違えると、ページを直しても成果につながりにくくなります。
対象外の検索語句なら、除外キーワードの候補です。広告文の約束が強すぎるなら、広告文を修正します。検討前の不安が見える語句なら、記事やFAQで受け止めます。サービス内容の説明不足なら、サービスページを直します。
この振り分けをせずに「LP改善」とまとめると、制作側はページ内の見た目や配置を直しがちです。しかし問題が広告文の約束にあるなら、LPだけを直してもずれは残ります。問題が対象外語句にあるなら、LPではなく除外設定が必要です。
改善タスクは、作業の種類ごとに分けて管理します。広告設定のタスク、LPのタスク、記事のタスク、サービスページのタスクを同じバックログに置いてもよいですが、戻し先と担当者は分けておきます。
月次レポートの一論点を、背景つきで改善バックログへ移す
検索広告の学びを実行につなげるには、月次レポートの最後に残った論点をサイト改善バックログへ移します。バックログとは、改善候補を優先順位つきで管理する一覧です。
移すときは、作業名だけでなく、背景を残します。どの検索語句から来たのか、どの広告文とLPに関係するのか、何を見て判定するのかが残っていれば、実装時に意図が消えません。
Search Consoleの検索パフォーマンスレポートも合わせて見ると、広告で見えた問いが自然検索側でも表示されているかを確認できます。広告で見つけた不安が自然検索でも出ているなら、記事やサービスページの改善として優先しやすくなります。
月次レポートを閉じる前に、完了した改善タスクを一つ振り返ります。検索語句から作った仮説は当たったのか、変更したページは期待した行動を増やしたのか、次に残った問いは何か。そこから次の一件を選ぶと、広告の気づきはレポート内で止まらず、実装済みの改善から次の改善へ進みます。