Contentsquareとは？ヒートマップ・録画・導入条件を解説

ヒートマップも録画も使いたいけれど、Contentsquareのどの機能が自社に必要なのか分からない。

導入を検討するときは、機能の数よりも「誰が、何を判断するために使うか」を先に決めると比較しやすくなります。

Contentsquareは、Webサイトやアプリの行動分析、利用者の声、プロダクトの利用状況などを扱うプラットフォームです。

この記事では、公式資料をもとに機能の役割を整理し、社内で使える導入要件表と試用の進め方を紹介します。

記載内容は2026年10月4日に確認した情報に基づき、契約画面での実機検証や導入効果の測定を行った体験談ではありません。

Contentsquareで扱う課題を整理する

「サイトを良くしたい」だけでは、必要な機能と評価方法が決まりません。

まず、売上・問い合わせ・利用継続のうち、何を改善するための調査かを書き出します。

Web改善とプロダクト分析を分ける

広告から来た人が申し込み前にどこで止まるかを調べる仕事と、登録後の利用者が翌月もサービスを使うかを調べる仕事は、見る期間も行動も異なります。

Contentsquareでは、ページ内の操作や録画を扱うExperience Analyticsに加え、継続利用などを分析するProduct Analytics、アンケートなどを扱うVoice of Customerが案内されています（参考：製品とプランの説明）。

それぞれを同じものとして契約せず、調べたい問いから必要な範囲を選びます。

調べたい問いの例	必要な観察	社内で相談する担当
申し込みボタンまで届いているか	ページ内の表示・操作	Web担当・デザイナー
途中で別のページへ戻るのはどこか	訪問経路・該当場面の録画	Web担当・開発担当
登録後も主要機能を使っているか	複数回の利用・継続状況	プロダクト担当
操作した人が何を不便と感じたか	利用者の回答	調査担当・顧客対応担当

この表は導入を整理するための例であり、各項目がすべて同じプランに含まれるという意味ではありません。

既存ツールとの役割を決める

すでにGA4やBIで把握できる数値は、先に一覧にします。

そのうえで、既存のレポートだけでは決められないことをContentsquareの試用課題にします。

例えば「スマートフォンの申し込み率が下がった」までは既存の分析で分かっているなら、次に必要なのは同じ数値をもう一度作ることだけではありません。

対象ページの操作やエラー、フォームへ進むまでの動きを調べ、修正候補を説明できるかが評価対象になります。

既存の確認事項	追加で確かめること
広告別の流入と成果	成果が少ない条件で、どの操作が止まるか
申込フォームへの到達数	入力前に説明へ戻っている場面があるか
購入完了の件数	購入前のページや操作と結び付けられるか

数値を照合する際は、セッションの定義や同意状態、除外条件が違う可能性も確認します。

CVRの分母を整理したい場合は、コンバージョン率の計算方法も参照してください。

Contentsquareの行動分析機能を確認する

機能名を覚えるより、「全体の経路」「ページ内の要素」「個別の動き」の順で役割を分けると理解しやすくなります。

どれか一つの画面だけで、利用者が離脱した理由まで確定させないことが大切です。

ページ内の操作を確認する

Zoning Analysisは、ページ内の要素を対象に操作の指標を確認するための機能です。

公式の初学者向けガイドでは、ページや端末を選び、保存したゾーニングや現在・過去のページの状態をもとに分析する流れが説明されています（参考：主要機能の使い分け）。

見る前に、「どの版のページを、どの期間・端末のデータで比べるか」をそろえます。

ボタンの位置を変えた前後のデータを混ぜると、同じ場所を比べているつもりでも対象が変わってしまいます。

クリックやタップが多い要素を見つけたら、その指標の分母と集計対象を確認します。

クリックの多さだけで売上への貢献を判断せず、成果に進んだ条件と合わせて検討します。

訪問経路と録画を合わせる

Journey Analysisで訪問経路を確認し、気になるページや要素からSession Replayへ進むと、集計結果の背景を調べやすくなります。

公式ガイドには、経路やゾーンから関連するリプレイを開く操作が案内されています（参考：経路・ゾーニング・録画の連携）。

導入時には、次のような調査が自社の対象ページで行えるかを試します。

1. 対象の端末・期間・訪問条件をそろえる。
2. 気になる経路やページ内の要素を選ぶ。
3. 関連する録画で操作の前後を確認する。
4. 観察できた事実と、考えられる原因を分けて残す。

例えば「料金ページと機能ページを行き来した」は観察した事実ですが、「料金が高くて迷った」は別途確認が必要な解釈です。

一つの録画を全訪問者の代表とみなさず、同じ条件で似た動きが見つかるかも調べます。

Contentsquareの導入に必要な条件

導入の準備では、計測する場所と、収集してよい情報を別々に決めます。

担当者が曖昧なままタグを設置すると、あとで取得範囲や権限を直す作業が増えます。

サイトとアプリを分ける

Webサイトはトラッキングタグを設置し、ネイティブアプリは対応するSDKの導入条件を確認します。

スマートフォンのブラウザで開くサイトと、ストアから入れるアプリを同じ導入方法として扱わないようにします（参考：WebタグとMobile SDKの技術資料）。

Webの公式手順では、管理者がプロフィールから「Projects and users」を開き、「Tracking」で対象のタグを確認できます（参考：タグの設置手順）。

直接設置やタグマネージャーなどから方法を選び、対象ページで収集を確認します。

開発担当には、通常のページ遷移だけでなく、SPAの画面切り替えや埋め込み画面の有無も渡します。

Reactなどへの対応が案内されていても、自社固有の画面が意図どおり記録されるかは個別の検証が必要です（参考：Webの互換性と制約）。

個人情報と権限を確認する

自動マスキングがあることと、送信する情報を確認しなくてよいことは同じではありません。

公式の個人情報ガイドでは、自動処理の対象だけでなく、識別情報や属性など、渡した値が自動ではマスクされない項目も説明されています（参考：個人情報の取り扱い）。

URL、画面上のテキスト、入力内容、独自に送信する属性を確認し、不要な情報は送らない設計にします。

誰が閲覧し、誰が分析条件を変更し、誰が契約や連携を管理するかも分けます。

公式ヘルプではViewer・Analyst・Expertなどのプロジェクト権限と、アカウントのAdminが説明されています（参考：アクセス権限の一覧）。

以下は、社内確認に使うための導入要件表です。

担当部門	決めること	確認の証拠
Web・マーケティング	対象ページ・改善したい成果	対象URLと計測条件
開発	タグ・SDK・画面遷移の対応	検証した操作と結果
情報管理・管理部門	取得範囲・保存・閲覧権限	確認した設定と契約条件
分析担当	分母・除外・比較する期間	指標定義と分析条件
運用責任者	改善の判断・担当の引き継ぎ	判断記録と担当者一覧

Contentsquareの連携要件を決める

「連携できるか」だけでなく、「何を、どちら向きに、どの目的で渡すか」を書き出します。

連携先の名前があるだけでは、自社で必要なデータが扱えると判断できません。

成果を測るデータを選ぶ

問い合わせなら受付完了、ECなら購入完了など、事業上の成果に対応する状態を決めます。

送信ボタンのクリックだけを成果にすると、入力エラーで完了しなかった操作まで混ざるおそれがあります。

ECの公式実装資料では、取引ID・売上・通貨などの送信方法が案内されています（参考：Eコマースの計測）。

どの値を送るかを決めるときは、完了画面の再読み込みや外部決済からの戻りも検証項目に入れます。

同じ注文が重複して数えられていないか、成立した注文が記録されていないケースがないかを、対象条件をそろえて照合します。

実際の売上台帳と行動分析の数値が違った場合は、まず計測対象・同意・送信のタイミングを確認します。

外部出力と共有を確認する

分析結果を開発の修正依頼や定例会議に使うなら、その受け渡しまで試用に含めます。

画面を見る担当者だけが分かっていても、修正する人に条件が伝わらなければ改善へ進めません。

以下は、製品の標準機能を断定する一覧ではなく、契約前に確認するための質問です。

利用場面	確認する質問
社内の報告	対象条件を添えて共有できるか
不具合の調査	該当箇所を担当者が同じ条件で確認できるか
BIなどとの連携	必要な粒度・期間・頻度で出力できるか
外部の制作会社への依頼	必要な範囲だけ閲覧させられるか
契約終了や担当変更	取得済みデータと共有先をどう扱うか

技術資料にはセッションの文脈を連携に利用する方法もありますが、他システムの識別子と同じものとは限りません（参考：外部連携の技術資料）。

必要な契約範囲や識別方法は、実装担当と提供元に確認します。

Contentsquareの試用項目を決める

試用では、すべての機能を触るより、導入後に解きたい問いを一つ選びます。

「録画が見られた」で終わらせず、担当者が修正案と確認方法まで説明できるかを見ます。

解きたい課題を一つ選ぶ

次の表は、スマートフォンの資料請求ページを対象にした架空の試用計画です。

実際の導入事例や改善実績ではありません。

試用項目	記入例
対象	スマートフォンの資料請求ページ
課題	フォーム開始後に完了しない操作がある
観察	対象条件での経路・入力前後の動き
成果の定義	サーバーで受け付けが成立した状態
調査の完了条件	修正候補・根拠・次の検証方法を整理できる
対象外	原因を確認せずに入力項目を削減すること

試用する期間と必要な訪問数は、対象サイトの規模や課題に合わせて決めます。

少ない記録で理由が判断できなければ、無理に結論を出さず、条件や観察期間を見直します。

フォームの成果設計は、EFOの計測項目と進め方にもまとめています。

操作画面の再現を確認する

導入後に調べたい画面ほど、最初に再現性を確認します。

ログイン後のページ、モーダル、SPAの画面切り替え、外部サービスを埋め込んだ場所などを、実際の対象環境で試します。

互換性の資料には、iframeの設定条件やアニメーションの一部制約も掲載されています（参考：対応範囲と部分的な制約）。

再現されない場所があった場合は、製品の不具合と決める前に、設定・対象バージョン・取得条件を切り分けます。

見やすくするためにマスキングを安易に解除せず、伏せる情報を維持したまま判断に必要な操作が分かるかを確認します。

検証する操作	残す記録
通常ページからフォームへ移動	ページの対応関係と遷移
入力エラーからやり直す	エラー表示と前後の操作
モーダルを開いて閉じる	表示の再現と操作対象
同意状態を変更する	想定した収集・停止の動き
管理者以外で分析を見る	必要な閲覧と設定変更の範囲

Contentsquareの契約判断を残す

試用の結論は、機能が多かったかどうかではなく、自社の課題を運用可能な形で調べられたかで残します。

要件が満たせなかった場合も、どの条件が合わなかったのかを記録しておくと、次の比較が容易になります。

対象規模と必要機能で見積もる

公式料金ページではFree・Growth・Pro・Enterpriseが案内され、機能や上限はプランによって異なります（参考：最新の料金とプラン）。

収集するセッションの上限と、録画の対象・保存期間を同じ数字として読まないようにします。

自社の月間利用規模だけでなく、必要なプロジェクト数、Webとアプリの範囲、使いたい分析機能、連携条件も渡して確認します。

上限に達した場合の扱いや、試用終了後に残る機能も契約前に整理します。

見積もりで渡す条件	社内で確認する内容
対象サイト・アプリ	本番・検証環境と対象範囲
利用規模	月ごとの変動と集中的に調べたい時期
必要な機能	調査で必須のものと、あれば便利なもの
保存の要件	集計と録画それぞれで必要な期間
導入・運用	初期設定、教育、問い合わせの支援範囲

公開価格だけで、自社の必要条件を満たす総額が決まるとは限りません。

運用の責任範囲を決める

導入後に分析を見る人、修正を決める人、設定を管理する人を決めます。

一人がすべてを担当する場合でも、役割ごとに作業を分けておくと引き継ぎやすくなります。

週次の確認では、気になった録画の数だけを報告するのではなく、調査した問い・確認できた事実・次の修正候補を残します。

ページの更新時には、分析対象やマスキング、成果の定義が変わっていないかも確認します。

Contentsquareの導入を進める最初の一歩は、上の要件表に対象ページと社内の確認先を書くことです。

その一枚を使い、必要な機能・試用の合格条件・運用担当をそろえてから比較を進めてください。