少ない数値でも直せることを見つけるという見出しと、会社でスマートフォンを確認する男性

NOTES

アクセスが少ないサイトの改善順位|数値・顧客質問・操作不具合を分けて決める

アクセスが少ないサイトで、数件の増減だけに振り回されず改善を進める方法。少量データ・顧客質問・操作不具合の5行判断表で、修正、計測確認、効果判定の保留を分けます。

チップス

先月の問い合わせが2件、今月は1件。ホームページへの訪問が少ない会社では、1件の違いだけで増減率が大きく変わります。「半分になったから見出しを戻そう」と決めても、その見出しが原因だったかは、この数字だけでは分かりません。一方で、スマートフォンで入力エラーの直し方が読めないなら、アクセスが増えるまで放置する理由にはならないはずです。

アクセスが少ないときは、改善をすべて止めるのでも、数字を無視して好みで変えるのでもなく、今の材料で判断できる範囲を分けます。数値で効果を判定する作業、実際の操作を確かめる作業、顧客が知りたい条件を掲載する作業では、必要な根拠が違うからです。

この記事では、集客と受付を兼任する経営者・Web担当者に向け、少量のデータ、顧客の質問、画面の不具合を一つの判断表へ整理する方法を紹介します。扱うのは自社サイトの修正順位です。何件集まれば必ず判断できるといった基準や、施策の効果を保証する方法ではありません。

割合の変化を、まず元の件数に戻す

冒頭の2件から1件という数字は、説明用の例です。割合では半減でも、差は1件です。ここで確認したいのは、同じ長さの期間か、同じページや問い合わせ経路か、数えている対象が変わっていないかです。問い合わせ件数だけを並べても、その前にどれだけ訪問や閲覧があったかは分かりません。

例えば、サービスページを見た人数に対する相談数なのか、サイト全体の訪問回数に対するフォーム完了数なのかで、割合の意味は変わります。人と訪問回数を混ぜたり、先月は電話を含め今月はフォームだけにしたりすると、同じ指標として比べられません。集計の対象と単位を数字の横に残します。

元の件数と条件をそろえても、少数の差だけで原因までは確定できません。休業、紹介の有無、広告の変更、既存顧客からの再相談など、その時期の事情も確認します。思い当たる出来事は変更履歴に書きますが、同時に起きたという理由だけで増減の原因と決めないようにします。

一方、把握した事実まで曖昧にする必要はありません。「同じ集計条件で、記録上の相談が2件から1件に変わった」は観察した内容です。「新しい見出しが相談を減らした」は、そこから先の解釈です。会議のメモでこの二つを別の文にすると、数値の変動を見ただけで変更を取り消す判断を避けられます。

数字がない理由を、行動がなかったことと分ける

解析画面の空欄やゼロを見たら、対象期間の計測設定と表示条件を先に確認します。イベントが記録されていないのか、絞り込みの対象外なのか、表示上の制限なのかでは、次の作業が違います。問い合わせが実際に届いているのに完了件数が出ていないなら、ページの説得力より計測の確認が先になる場合があります。

Googleの説明では、GA4のユーザー属性や検索語句などを含むレポートで、データのしきい値によって一部が表示されないことがあります。適用時はデータ品質の表示を確かめます。すべての少数サイトの全数値が隠れるという意味ではなく、非表示の行を「利用者がいなかった」と読み替えないための確認です。Googleのデータのしきい値の説明

期間を広げると見える情報が増える場合もありますが、途中でフォームや集計方法が変わったなら、その前後を無条件に足し合わせないでください。また、表示できることと、変更の効果を確かに判定できることは別です。しきい値の表示が消えたから施策の優劣が決まるわけではありません。

確認中の数値には「計測確認中」と記し、ゼロとは区別します。設定の修正後から比較できるなら、比較の開始日を残します。過去に記録されなかった行動を、現在の数字から都合よく補って実績にすることは避けます。

五つの材料を、判断できる範囲ごとに並べる

次は、架空の小規模サービス会社S社を使った設計例です。数値、質問、画面の状態は説明用であり、実際の顧客の調査結果ではありません。S社はサービス案内から相談フォームへ進むサイトを運営し、担当者が週の更新作業を選ぶ場面を想定します。

操作の障害は修正、空欄と質問は確認、数値変動と見出しの効果は観察へ分ける架空S社の判断図
架空S社の判断図です。相談件数は説明用の設定であり、実際の顧客データや改善実績ではありません。
確認した材料 今言えること 先に進める作業 まだ決めないこと
同じ集計条件で相談2件から1件 記録上の差は1件 期間・流入・変更履歴を併記 見出し変更が減少原因か
受付記録はあるが完了数が空欄 受付と計測の対応が未確認 計測条件と記録先を確かめる 空欄を実相談ゼロと扱うこと
スマホで入力エラーの直し方が見えない 確認した画面で操作上の障害あり 条件を保存して表示を修正 サイト全体への影響率
対応地域について具体的な質問が届く 質問した人に確認したい条件がある 現行の対象範囲と掲載箇所を照合 全訪問者が同じ疑問を持つか
新旧の見出し案がある 伝え方の候補が二つある 事実・対象・内容との一致を読む 数件の反応での優劣判定

この表は点数の高い順に並べるためのものではありません。根拠の種類に応じて、修正、確認、観察のどれへ進むかを選びます。例えば、再現した入力エラーの問題は修正へ、空欄の原因は計測確認へ、見出しの集客効果は判断を保留して観察へ回します。

同時にできる作業もあります。担当者が計測を確認している間に、受付責任者が対応地域の現行条件を確かめ、制作担当がフォーム表示を直すことは可能です。全員が数字の結論を待って止まる必要はありません。ただし、担当や確認日が空欄のままでは進まないため、実際の管理表には担当と次の確認予定も添えます。

作業時間が限られる場合は、まず相談へ進めない問題があるかを見ます。次に、料金や対象範囲など、判断を誤らせる情報がないかを確かめます。そのうえで、追加調査が必要な候補を並べます。これは成果の大きさを数値で予測した順位ではなく、確認できた支障と必要な調査をもとに、その週の作業を選ぶ考え方です。

S社の表でも、入力エラーが一つの古い端末だけで起きるのか、通常の相談経路でも再現するのかは確認が必要です。確認できた範囲を広げて記録し、影響を推測だけで大きく見せないようにします。修正に大きな変更が必要なら、代わりの相談先を案内できるか、案内内容が現行の受付と合うかも検討します。問題を急いで隠すために、使えることを確かめていないボタンへ付け替えるのは避けます。

再現した操作の問題は、直ったことまで確かめる

S社の入力エラーなら、どのページで、どの端末・ブラウザーを使い、どの項目で何をしたかを残します。「フォームが使いにくい」では、制作者が同じ状態を確かめられません。「必須項目を空欄にした後、画面下の説明に気づけず次へ進めない」のように、操作と見えた結果を組にします。

W3C WAIのフォーム案内は、送信結果を伝えることに加え、エラーの対象と直し方が分かる通知を説明しています。これは操作確認の観点として参照できます。アクセス数の増減とは別に、入力した人がどこを直せばよいか理解できるかを点検する理由になります。W3C WAIのフォーム通知の説明

修正後は、問題が起きた手順をもう一度たどります。説明が読めるか、該当欄へ戻れるか、入力済みの内容を不必要に失わないかを確認します。送信を含めて試す場合は、テストとして受け取る担当と環境を決め、通常の相談と混ざらないようにします。外部の予約先が関係するなら、確認できる範囲も分けます。

ここで出せる結論は「確認した条件で問題が解消した」です。「フォームが直ったので問い合わせが増えた」とするには別の根拠が必要です。動作確認の完了と集客効果の確認を分けて記録すれば、相談件数が翌月も少なかったときに、必要だった修正まで失敗扱いせずに済みます。

顧客の質問は、人数の代表ではなく不足を探す手掛かりにする

「隣の市も対応できますか」という問い合わせが来たら、まず現在の対応範囲を担当者に確認します。そのうえで、質問した人が見たページに対象地域や例外が書かれているか、スマートフォンでも見つかる位置かを確かめます。質問の存在だけで、すぐFAQを増やすとは限りません。

掲載されている情報が古ければ訂正が必要です。条件は正しくても、サービスの選択前に読めない位置にあるなら、掲載場所の変更が候補になります。案件ごとに確認が必要な地域なら、一律に対応可と広げず、何を知らせて相談すればよいかを案内します。

少人数への聞き取りで見つかった疑問は、その人がその場面で困ったという材料です。「訪問者の多くが迷う」といった割合の説明には置き換えません。同じ人から電話とメールが来た場合も、別の二人の意見として数えないようにします。改善メモには個人名より、知りたかった条件と見ていたページを残すほうが検討に役立ちます。

質問を受けて説明を追加した後は、内容が現行条件と一致しているかを受付担当者と読み合わせます。質問が来なくなっても、それだけで疑問を解消できたとは決めません。訪問が減った可能性もあり、質問しないまま離れた人の事情は分からないためです。掲載内容の確認と、後から得られる反応を別々に残します。

数字で選べない見出し案は、伝える内容から絞る

新旧二つの見出しを比べるとき、反応が数件しかなければ、その数だけで勝ち負けを決めるのは避けます。まず、対象読者、提供内容、相談できる範囲が本文と一致しているかを読みます。実際には提供していない対応を約束する案や、対象が分からない案は、成果比較の前に見直せます。

担当者同士の好みが割れたら、ページを初めて見る人に、どんなサービスだと受け取ったかを説明してもらう方法もあります。誘導して正解を言わせるのではなく、理解できたことと分からなかった点を記録します。少人数で見た結果は、その確認範囲の理解の手掛かりとして使い、訪問者全体の反応率として示しません。

一度に見出し、料金、フォーム、広告を変えると、後で数字が動いても何が関係したかを考えにくくなります。急ぐ訂正や不具合修正は進めつつ、伝え方の候補は変更箇所と目的を絞って記録します。単純な前後比較だけで因果が確定するわけではありませんが、何を試したかを残すことは次の判断に必要です。

閉じた資料とノート、画面を伏せたスマートフォンの机上イメージ。実際の顧客データではない

修正後は、表示・理解・数値を別の欄で確認する

作業の完了報告には、公開した日だけでなく、何を確認したかを添えます。フォームなら同じ操作でエラー案内を読めたこと、地域案内なら責任者が現行条件と照合したこと、見出しなら読者とサービス内容の対応を確認したことです。これらを一律に「改善済み」とまとめないようにします。

数値の欄には、比較対象、期間、件数、途中の変更を残します。必要ならもう少し観察しますが、期間を延ばせば必ず答えが出るとは限りません。季節やサービス内容が変わって比較しにくくなった場合は、継ぎ足して結論を出すより、新しい条件から観察を始める判断もあります。

保留の項目には、次に何が分かれば決められるかを書きます。S社なら「計測担当が完了の記録条件を確認する」「受付担当が地域の質問と閲覧ページを残す」「見出し案の内容一致を確認した後、同じ対象範囲の数値を見直す」といった予定です。保留は放置ではなく、判断に足りない材料を明示した状態にします。

アクセスが少ないサイトでも、確認できる事実はあります。記録上の変化を丁寧に扱い、実際に操作を妨げていること、現行の説明とずれていること、まだ確かめる必要があることを分ければ、次に頼む修正の範囲が具体的になります。

参照資料:Google アナリティクス「データのしきい値について」、W3C WAI「User Notification」。2026年9月21日確認。公開資料の説明を参照。顧客のアクセス解析、フォーム送信、実利用者調査は実施していません。