こんにちは。バナナデスクです。
「申込が減ったのは、文章に魅力がないからでしょうか」。そう考えて書き直す前に、そもそも訪問が減ったのか、申込の途中で止まったのかを分けてみてください。
ロジックツリーは、曖昧な問題を小さな問いへ分ける道具です。ただし、枝をきれいに描けても、原因が証明されたことにはなりません。「訪問数×申込率」という計算と、「料金が分かりにくかったのでは」という仮説を、別の図として扱うと整理しやすくなります。
数字を分けたいのか、理由を調べたいのかを決める
McKinseyの担当者による問題解決の紹介では、イシューツリーを、問題を構成要素へ分け、追加調査が必要な部分を見つける道具として説明しています。図を作った時点で答えを出すのではなく、調べる問いを明らかにする使い方です。
| 作りたいツリー | 枝の例 | 確かめること |
|---|---|---|
| 数字の分解 | 訪問数と申込完了率 | 式、単位、分母、期間が一致するか |
| 原因の仮説 | 入力エラー、条件の不一致、計測漏れ | 各仮説を支持・否定する記録があるか |
| 打ち手の選択 | フォーム修正、説明追記、計測修正 | 確認した原因に対応するか |
これらを一つの階層に混ぜ、「訪問が少ない」「価格が高い」「フォームを短くする」を並べると、数値、原因、行動が同列になります。まず何を分ける図なのか、上の箱に一文で書きます。
同じ期間・同じ単位で、数字を分解する
ここからは架空データです。9月1〜7日と9月8〜14日の各7日間、日本時間で比べます。対象は同じサービス案内ページから同じフォームへ進む訪問。訪問はセッションで数え、フォーム到達と完了は各セッション内で一度以上起きたかで数えます。完了したセッションは全て到達セッションに含まれる設計です。
| 指標 | 前の7日間 | 後の7日間 |
|---|---|---|
| 対象セッション | 1,000 | 800 |
| フォーム到達セッション | 100 | 120 |
| 申込完了セッション | 50 | 24 |
| フォーム到達率 | 100÷1,000＝10% | 120÷800＝15% |
| 到達後の完了率 | 50÷100＝50% | 24÷120＝20% |
| 訪問全体の完了率 | 50÷1,000＝5% | 24÷800＝3% |
申込完了セッション数＝対象セッション数×フォーム到達率×到達後の完了率です。前は1,000×0.10×0.50＝50、後は800×0.15×0.20＝24になります。
ここで計算できるのは、申込完了を含むセッション数です。実際の受付件数、人数、契約数、売上とは別です。一人が複数回訪問する場合や一回の訪問で複数件申し込む場合もあるため、受注を調べる時は受付IDなど別の単位で照合します。
数字で分かったことと、分からないことを分ける
後の期間は訪問数が20%減っています。一方、フォーム到達数は100から120へ増え、到達率も10%から15%へ上がっています。それでも完了は50から24へ減りました。まず調べる対象として、到達後の過程や計測を挙げられます。
ただし、この表だけで「フォームが悪い」とは言えません。訪問者の目的や流入元が変わった可能性も、完了の記録だけが欠けた可能性もあります。前後比較だけでは因果関係は分かりません。
原因候補の枝には、確認資料と反証を付ける
| 仮説 | 確認する資料 | 支持する例 | 反証・留保 |
|---|---|---|---|
| 送信時にエラーが出る | 期間別エラーログ、端末別テスト | 後の期間から特定端末で送信失敗が記録される | 同じ条件で正常でも、全端末で不具合なしとは言えない |
| 到達した人の目的が変わった | 流入元別の同じ指標、広告文と案内条件 | 新しい流入元だけ到達後完了率が低い | 人数が少ない、計測条件が違う場合は保留 |
| 完了イベントが欠けた | 受付台帳とイベントのID照合、設定変更記録 | 受付はあるが対応するイベントがない | 受付台帳側の重複や期間ずれも確認が必要 |
| 料金・条件を読んでやめた | 条件表示の変更履歴、適切に取得した質問や回答 | 変更箇所への疑問が具体的に示される | 離脱だけで本人の理由を推測しない |
この表の支持例は、これから探す証拠の例で、取得済みのデータではありません。また、入力エラーと条件の不一致は同時に起きることがあります。仮説の枝は必ずしも足して100%になる分類ではありません。重複しうる候補を、互いに独立した原因として数えないようにします。
調べた後は、ツリーを書き換える
説明用に、24件の完了イベントに対し、同じ定義・期間へ揃えた受付照合で32件相当の完了セッションが見つかったと仮定します。差の8件について計測漏れが確認できたなら、「記録上24」から「照合後32」へ表を修正します。この場合、到達後の完了率は32÷120＝約26.7%、訪問全体では32÷800＝4%です。
それでも前の5%には届きません。計測漏れを直したことと、残りの差の原因が分かったことは別です。新しい表の根拠と変更日を残し、他の枝は未確認として扱います。これは再計算のための追加仮定で、実サイトの照合結果ではありません。
最初の一枚には、調べる順番まで書く
この例なら、最初に完了の記録と受付の対応を確認し、次に送信の不具合、流入条件を調べます。計測が崩れた数字のまま文章を比較しても、結果を判断できないためです。順番は、不具合の影響と確かめやすさで変わります。
ロジックツリーを仕上げる時は、末端の枝を一つ選び、「どの資料を、誰が、いつまでに確認するか」を書いてください。きれいな図より、次の調査に進める問いが残っていることが役に立ちます。