診断を公開したあと、いちばん知りたいのは「最後まで答えてもらえているか」「どこで離脱しているか」です。 ただ、それを測るためだけにGoogleアナリティクスを入れたり、Cookie同意バナーやプライバシーポリシーの整備まで踏み込むのは、正直しんどいです。診断は手軽に始めたいのに、計測のためのプライバシー対応で足が止まる、というのはよくあります。
結論から言うと、診断の効果は外部の解析ツールを入れなくても測れます。 診断シミュレーションProは、回答の動きをセッション単位で集計し、個人情報を保存しないまま自社のDBに蓄積する集計ダッシュボードを本体に内蔵しています。誰が答えたかは持たず、「開始して、どこまで進んで、完了したか」という流れだけを数えます。だからアナリティクスやタグマネージャーを入れなくても、完了率や離脱はその場で見えます。
この記事は、その「個人情報を保存しない計測」で何がどこまで分かるのか、逆に外部解析でないと取れないものは何か、を整理する話です。
計測のために個人を追わなくていい
診断の改善で本当に必要なのは、回答者一人ひとりを特定することではありません。 知りたいのはたいてい次のような全体の傾向です。
- 始めた人のうち、何割が最後まで答えたか
- どの設問で抜けているか
- どの結果がよく表示されているか
これらは、個人を識別しなくても数えられます。 「Aさんが3問目で離脱した」を記録する必要はなく、「3問目での離脱が全体の何割か」が分かれば改善の判断はできます。診断シミュレーションProが個人情報を持たない設計なのは、機能を削ったからではなく、改善に必要なのが個人ではなく分布だからです。
ここを割り切ると、計測まわりの作業はかなり軽くなります。個人を追わない計測は、後から「この保存は同意が要るのか」と悩む場面が減るのも実務的には大きいです。
ダッシュボードで見えるもの
本体の集計ダッシュボードで確認できるのは、次の6つです。
- 開始数
- 完了数
- 完了率
- 平均所要時間
- 設問別離脱率
- 結果表示分布

実務でいちばん見るのは完了率と設問別離脱率です。
完了率が低いときは、設問が多すぎるか、特定の設問で詰まっています。設問別離脱率を見れば、「3問目で抜けている人が多い」のように、どこが原因かまで当たりがつきます。設問内容が長い場合や、選択肢が多すぎる設問はガクッと落ちやすいパターンです。
平均所要時間は、診断が体感として重くないかの目安になります。所要時間が伸びていて完了率も低いなら、設問を削るか順番を見直す判断がしやすくなります。 結果表示分布は、特定の結果ばかりに偏っていないかを見る指標です。
ほとんど表示されない結果があるなら、その結果の条件が厳しすぎる可能性があります。逆に、ある結果に集中しすぎているなら条件がゆるすぎるかもしれません。
数字だけ眺めても動きにくいので、ダッシュボードは設置ページ別に絞り込めて、前の期間と比較できるようになっています。「LPに置いたほうと、記事中に置いたほうで完了率が違う」を見比べたり、「設問を1つ減らした先週と今週でどう変わったか」を確認したりできます。改善は1回で終わらないので、前期間との比較ができるのは地味に効きます。
どうやって個人情報なしで数えているか
仕組みはシンプルで、回答の一回分をセッション単位で扱います。 「このセッションは開始した」「2問目まで進んだ」「完了した」「この結果が表示された」というイベントだけを記録し、それを集計用の数字としてWordPressに積んでいきます。名前やメールアドレスはもちろん、個人を継続的に追いかけるための識別子を残す作りにはなっていません。
外部に送らずWordPressに溜めるので、データが第三者のサーバーに渡ることもありません。 集計データはためっぱなしにせず、ログの保持期間は1〜365日の範囲で設定でき、既定は90日です。保持期間を超えた古いログはcron(定期実行タスク)で自動的に削除されます。手作業で消し込む必要はなく、放っておいても古いデータが無限に溜まることはありません。
短期の改善だけ見たいなら30日程度に短くしてもいいですし、季節変動まで追いたいなら長めにする、という調整ができます。最初は既定の90日のままで十分なことが多いです。
アナリティクスの代わりになる範囲、ならない範囲

ここは正直に切り分けておきます。 「完了率・離脱・結果の偏りを見て診断そのものを改善する」目的なら、内蔵ダッシュボードだけで完結します。診断の中で起きていることは、本体がいちばん正確に把握できる場所だからです。Cookieレスで、外部解析ツールなしでこの粒度が見えるのが、この計測の強みです。
一方で、Googleアナリティクスにしか取れないものもあります。 診断ページにどこから流入したか、診断の前後でサイト内をどう回遊したか、広告やキャンペーンごとの成果、といったサイト全体の動きは、内蔵ダッシュボードの守備範囲外です。これらを追いたいなら、GA側のイベント計測と併用するのが素直です。完全な置き換えと考えるより、「診断の中身は本体、サイト全体の流れはGA」と役割を分けるのが現実的です。
設置して、数字を見ながら直していく
計測は設置とセットで動きます。 設問セットを作るとIDが振られるので、固定ページや投稿に次の1行を貼れば設置できます。
[mqs_simulator id="設問セットID"]
id には自分で作った設問セットのIDを入れます。ブロックエディタなら「診断シミュレーション」ブロックから対象の診断を選んでも置けます。設置するとその時点から、開始や完了がダッシュボードに集計され始めます。
公開してすぐの数字はまだ当てになりません。 ある程度の回答数が溜まってから、完了率と設問別離脱率を見て、抜けている設問を削るか言い換えるかを判断する、という流れになります。最初から完璧な診断を作り込むより、小さく公開して数字を見ながら直していくほうが、結局うまくいきやすいです。個人情報を持たない計測なら、その改善サイクルをプライバシー対応の重さを気にせず回せます。
診断の運用を、外部解析ツールやCookie同意の準備で止めずに始めたいなら、まずは内蔵の集計だけで一度公開してみるのが早いです。完了率と離脱が見えれば、次に何を直すかは数字が教えてくれます。
