Clarityの使い方を流入別に解説｜広告・検索・スマホの行動を分けて見る

Clarityで録画を見ているのに、どこを直せばよいか決まらない。

そんなときは、広告から来た人、検索から来た人、スマホで見ている人を、同じ集計に混ぜていないか確認してみてください。

同じページでも、訪問前に見た情報や画面の大きさが違えば、必要な説明や操作の順番は変わります。

Clarityの流入別分析は、流入条件を決め、端末とURLをそろえ、同じ条件をセグメントとして保存するところから始めます。

この記事では、フィルターの設定から、録画の比較、改善案の記録までを順番に解説します。

最後には、チームで使える「保存するセグメントの設計表」を完成させられます。

操作名は2026年10月5日に確認した公式資料に基づき、URLや集計値は説明用の架空例です。

Clarityで流入別に分析する目的

流入別に分ける目的は、広告や検索に順位を付けることではありません。

どの訪問者が、どの情報や操作で止まっているかを具体的にするためです。

広告と検索の期待を分ける

たとえば「導入費用を確認する」という広告を見た人が、サービス紹介ページに来たとします。

この人には、費用や適用条件への道筋が重要かもしれません。

一方、「業務を効率化する方法」という検索から来た人は、まず解決方法を知りたい可能性があります。

どちらも同じボタンを押さなかったとしても、足りない情報が同じとは限りません。

分析前に、流入ごとの仮説を短く書きます。

流入の例	訪問前に見た内容	確認したい操作
費用を訴求した広告	初期費用と料金プラン	料金条件への到達
課題解決の記事への検索	改善方法の説明	手順や関連記事の利用
比較資料の案内メール	比較表を読めるという案内	資料の確認と取得

これは分析の出発点であり、訪問者の気持ちを確定した表ではありません。

録画で確認できるのは、表示されたページ上の操作です。

「不安だった」「興味がなかった」という心理まで、クリックだけで決めないようにします。

調べる対象は、まず1つのページと1つの操作へ絞ると進めやすくなります。

たとえば「広告から来たスマホ利用者が、料金条件を確認できているか」という問いです。

比較するURLをそろえる

広告のLPと検索向け記事をそのまま並べると、流入の違いにページ構成の違いまで加わります。

最初は同じURLの、同じ版のページで比較します。

期間中に料金表や固定ボタンを変更した場合は、変更日も残してください。

URLの条件では、ページを最初に開いた人を見るのか、途中で訪れた人まで含めるのかを分けます。

ClarityのPathには、入口を指定するEntry URLと、訪問を含む記録を指定するVisited URLなどがあります（参考：Clarityのフィルター）。

LPへの着地後を調べたいなら、Entry URLを基準に考えます。

別ページから料金ページへ移動した人も調べたいなら、Visited URLで対象を広げます。

この2つを、集計の途中で同じ条件として扱わないでください。

また、広告用のパラメータが付いたURLと、付いていないURLが分かれる場合があります。

Clarityには完全一致や部分一致などの演算子があるため、対象にしたいURLだけが含まれるか確認します（参考：URL条件の指定方法）。

「pricing」を含む条件で、料金ページに加えて解説記事まで入っていないかを見る、といった確認が必要です。

条件を設定したら、録画を数件開き、実際の入口と訪問ページが意図どおりか確かめます。

Clarityの流入条件を設定する

ClarityのプロジェクトでFiltersを開き、Trafficの条件を確認します。

まずは1つの流入だけを選び、条件を増やす前の件数を把握してください。

参照元とUTMの違いを確認する

Referring siteは、取得できた場合の参照元ページを示します。

一方、Source、Medium、Campaignは、UTMパラメータを使って流入を分けるための条件です（参考：ClarityのTrafficフィルター）。

参照元が検索エンジンだからといって、自然検索か広告かを、その情報だけで必ず判別できるとは限りません。

広告用の情報が付いているか、どの条件で分類しているかを確認します。

以下は、外部からLPへ送るリンクの架空例です。

https://example.com/service?utm_source=newsletter&utm_medium=email&utm_campaign=autumn_report

項目	この例の値	チームで決める意味
utm_source	newsletter	配信元
utm_medium	email	流入の方法
utm_campaign	autumn_report	施策の名前

UTMは、リンクに付けた施策情報を整理するためのものです（参考：GoogleのキャンペーンURL解説）。

ClarityではTrafficの該当項目に値を選び、Applyを押して対象が絞られたことを確認します。

自然検索を大きなまとまりで見たい場合は、ChannelのOrganic Searchも候補になります。

ただし、参照元の情報自体が渡されない訪問もあるため、空欄や不明な記録を、推測だけで広告や検索へ振り分けないでください。

不明分は別に残す方が、比較の限界を説明できます。

広告名の表記をそろえる

同じ広告施策に複数の名前が付くと、条件を保存しても一部の訪問しか含まれなくなります。

まず、広告管理側で使っているリンクと、Clarityで見えている値を並べます。

大文字と小文字、ハイフンとアンダースコア、古い名称が混ざっていないか確認してください。

GoogleのUTM資料でも、値の大文字と小文字を区別し、命名を統一することが案内されています（参考：UTMの命名ルール）。

次のような管理表を1つ作ると、担当者が変わっても条件を再現できます。

管理項目	記入例
施策の表示名	秋のレポート案内
source	newsletter
medium	email
campaign	autumn_report
遷移先	サービスLP
適用開始日	配信を開始した日
担当者	リンクの変更を管理する人

メールアドレスや氏名など、訪問者を直接識別する情報をUTMに入れないでください。

URLはコピーや共有、アクセスログなどを通じて残るため、施策を表す情報に限定します。

リンクを作った後は、配信前の確認用リンクから遷移し、最終的なページでもパラメータが保持されるか点検します。

途中のリダイレクトで情報が消えるなら、分析条件を増やす前に遷移の設定を直します。

Clarityで端末別の行動を分ける

流入が同じでも、PCとスマホでは見える範囲や押せる場所が変わります。

広告と検索を比べるときも、先に端末構成の違いを確認します。

スマホとPCを別に見る

FiltersのUser infoからDeviceを選び、MobileとPCを分けて確認します。

ヒートマップでも、対象端末に合う画面を選んでください。

Clarityのクリックマップは、PCのクリックとモバイルのタップをそれぞれ扱います（参考：Clarityのクリックマップ）。

PCで料金表が横に並んでいても、スマホでは下に長く積み重なる場合があります。

同じスクロール位置の割合に、同じ説明があるとは限りません。

比べるときは、割合だけでなく「料金条件の見出し」「申込ボタン」といった実際の要素を基準にします。

スマホでは、固定ボタンが本文を隠していないかも点検します。

録画でボタン付近のタップが続いていたら、実ページでも同じ幅と向きで操作してください。

端末ごとの点検	見る場所
最初に見える説明	ページ上部の見出しと画像
押せる範囲	ボタンやリンクの間隔
重なり	固定CTA、メニュー、同意バナー
入力中の表示	キーボード表示時のフォーム
情報の順番	横並びから縦並びになった内容

録画の再現表示だけで原因を確定せず、公開ページの操作と照合すると、実装担当へ伝えやすくなります。

流入と端末を組み合わせる

基本の比較は「広告×スマホ」と「検索×スマホ」のように、端末をそろえて作ります。

次に、同じ広告の中でスマホとPCを比べます。

こうすると、流入の違いと画面の違いを一度に説明しようとせずに済みます。

ただし、条件を細かくするほど対象の記録は減ります。

広告名、端末、ブラウザ、地域、曜日をすべて重ね、数件しか残らない状態では、全体の傾向を判断しにくくなります。

最初はURL、期間、流入、端末の組み合わせを中心にします。

記録が少ない場合は、調べる問いに必要のない条件から外してください。

期間を広げる場合は、ページの変更や広告内容の切り替えをまたいでいないか確認します。

「記録が少ないため傾向は未確定」と残すことも、分析結果の1つです。

人数が足りないからといって、意味の違う広告をまとめて1つの群にしないようにします。

Clarityのセグメントを保存する

毎回使うフィルターの組み合わせは、セグメントとして保存します。

保存するのは、結果に名前を付けることではなく、比較条件を再利用できる状態にすることです。

再利用する条件を決める

通常のDashboard、Recordings、Heatmapsのいずれかで条件を適用します。

続いてSave as segmentを選び、Save as newから名前を入力してSaveを押します。

次回はSegmentsの一覧から選べます（参考：Clarityのセグメント作成）。

名前は「広告」だけより、「サービスLP・メール案内・スマホ」のように、対象が分かる形にします。

保存後は一度条件を解除し、保存したセグメントを選び直してください。

目的のURL、流入、端末が適用されたかを見るためです。

比較する期間も、その都度確認します。

「直近の日数」で見る場合と「確定した開始日・終了日」で見る場合では、後日開いたときに期待する対象が異なります。

次の設計表を保存条件の控えとして使えます。

設計項目	架空の記入例
セグメント名	サービスLP・メール案内・スマホ
分析の問い	料金条件を見て申込みへ進めるか
URLの扱い	サービスLPを入口にした訪問
流入条件	source、medium、campaignの指定値
端末	Mobile
期間	分析時に開始日と終了日を記録
除外	社内テストの識別条件
対象件数	条件適用後の表示値を記録

セグメントはプロジェクト内で共有されるため、名前の変更や削除はチームへの影響も確認します（参考：セグメントの共有と更新）。

他の人が週次報告で使っている条件を、相談なく別の意味に変えないようにしてください。

除外条件も記録する

社内の確認操作が混ざると、ボタンが頻繁に押されているように見える場合があります。

すでにテスト訪問をラベルなどで識別しているなら、対応する除外フィルターを使う方法があります（参考：Clarityの除外フィルター）。

これは分析対象から外す設定であり、収集そのものを止める設定とは区別します。

ClarityのIP blockingは特定IPの追跡を止める仕組みですが、IPv6や変動するIPなどに制約があります（参考：ClarityのIP除外）。

在宅勤務やモバイル回線まで、会社のIP設定だけで除外できると思わないでください。

設計表には、何を除外したかだけでなく、除外できない可能性も残します。

また、同じセグメントでも、画面によって対応していない条件は無効になる場合があります（参考：セグメントの対応条件）。

録画からヒートマップへ移動した際は、条件の表示を確認してください。

件数が変わったときに、データが壊れたと考える前に、対象範囲や無効になった条件を見直します。

Clarityで流入ごとの録画を比べる

条件が決まったら、録画を同じ観点で見ます。

目立つ失敗だけを集めず、目的の操作へ進めた記録も確認します。

期待する操作への到達を比べる

Recordingsで保存したセグメントを適用し、一覧から記録を開きます。

More detailsでは、記録の詳細と操作の時系列を確認できます（参考：Clarityの録画の見方）。

料金を訴求した広告なら、次の順序で観察します。

1. 最初にどの説明が表示されたか
2. 料金や条件の場所へ移動したか
3. 説明とボタンの間を行き来したか
4. 申込みの画面へ進んだか
5. 途中で別のページへ移動したか

それぞれを、見えた操作として記録します。

「料金に不満」という推測より、「料金条件を開いた後、前のページへ戻った」と書く方が再確認できます。

ヒートマップを並べたい場合はCompareを使い、左右に同じURLと異なる流入条件を設定します。

この画面では各側の端末やフィルターを変更できますが、初期の期間も確認してください（参考：Clarityのヒートマップ比較）。

Compare内ではセグメントの新規保存やクリック要素からの録画表示が使えないため、必要に応じて通常表示へ戻ります。

観察メモには、共有相手が同じ条件を開けるように、期間とセグメント名を添えます。

異なる条件の数値を混ぜない

ヒートマップのクリック数と、録画の件数、GA4のユーザー数は、同じ単位ではありません。

1回の訪問で同じボタンを何度も押せば、クリック数は増えます。

また、Clarityのクリックマップに出るクリックの構成比を、そのまま訪問者のクリック率として扱わないでください（参考：クリックマップの集計項目）。

次の表は、記録したセッション単位で比較するための架空例です。

条件	対象セッション	目的操作があったセッション	割合
広告・スマホ	200	40	20％
検索・スマホ	50	15	30％

広告の方が操作の件数は多く、検索の方が割合は高いという見方になります。

ただし、この差だけで検索流入の方が優秀だとは決められません。

訪問前の関心や既存顧客の割合など、揃えていない条件があるためです。

さらに、ClarityとGA4を連携しても、両者の集計が同じ定義になるわけではありません。

Clarityの公式資料では、GA4のセグメントをサポートしないことも示されています（参考：ClarityとGA4の連携条件）。

Clarityで保存した条件と、GA4で作った比較を、名前だけで同じ対象だと判断しないでください。

Clarityの流入別分析を施策へつなげる

観察を終えたら、改善する場所と、その理由を1つにまとめます。

流入ごとの違いを見つけただけでは、ページをどう直すかはまだ決まっていません。

広告文との食い違いを点検する

広告で伝えた内容が、着地したページでもすぐに確認できるかを見ます。

「費用が分かる」と案内しているのに、最初の画面が抽象的な紹介だけなら、料金への道筋を検討できます。

ただし、説明を上に移すことが常に正解ではありません。

料金を理解するための前提や対象条件が必要なら、それも近くに置きます。

次のように、観察から変更案までを分けて書きます。

記録するもの	架空の記入例
観察	広告・スマホの記録で料金リンクの往復があった
実ページの確認	リンク先に対象条件がなく、別のFAQに記載
仮説	料金を判断するための情報が分散している可能性
変更案	料金の近くに対象条件への短い案内を追加
確かめる成果	条件確認後の申込完了

説明を増やした結果、ボタンが見えなくなるようでは別の問題を作ります。

公開前にスマホでも確認し、情報と操作の両方を点検してください。

次の配信期間で確かめる

変更後は、保存したセグメントを使い、同じ観点で観察します。

URL、流入条件、端末、ページの版、対象件数を記録し、前回から変わったものを明記してください。

広告の予算や配信対象も変えた場合は、ページ修正だけの効果とは言えません。

前後の比較では、改善の兆候と、原因を確定できない部分を分けます。

変更による効果を比較したい場合は、対象者の割付や判定条件を整えたA/Bテストも検討します。

具体的な進め方は、ヒートマップをA/Bテストに使う方法で解説しています。

まずは「同じLPに来た広告・スマホ」と「検索・スマホ」の2つを、設計表へ書き出してください。

そして、目的の操作に進めた記録と、途中で止まった記録を同じ項目で見比べます。

Clarityの使い方で大切なのは、細かく分けること自体ではなく、同じ条件で観察を繰り返し、次に直す場所を決められることです。