セッションリプレイでSaaSの初期設定を改善｜登録後に止まる操作を探す

SaaSの登録者が増えても、初期設定が終わらなければ、サービスの価値を十分に体験してもらえません。

そこで役立つのが、登録後の操作をたどれるセッションリプレイです。

ただし、途中で止まった録画を集めるだけでは、何を直せばよいか決まりません。

最初に達成してほしいことを決め、同じ条件の成功・未完了を比較し、止まった工程を調べる順序で進めます。

この記事では、SaaSのオンボーディングを改善するための計測設計と、録画の見方を整理します。

オンボーディングとは、利用者がサービスを使い始め、必要な操作を身に付けるまでの案内や初期設定のことです。

工程別の調査シートも用意したので、自社の登録後の流れへ置き換えて使ってください。

以下のレポート作成サービスや数値は説明用の架空例で、実在サービスの成果を示したものではありません。

SaaSの初期設定で調べる成果を決める

最初に、「何ができたら初回成功と呼ぶか」を決めます。

登録ボタンを押したことだけを成果にすると、その先の問題を見落とします。

登録と初回成功を分ける

アカウントが作られた状態と、利用者が目的の作業をできた状態は異なります。

架空のレポート作成SaaSなら、メールアドレスの登録は入口です。

データをつなぎ、レポートを生成し、内容を確認できて初めて、使う意味を感じられるかもしれません。

この記事の例では、「自分のデータで作った最初のレポートを開く」を初回成功と定義します。

これは説明用の定義であり、すべてのSaaSに同じものを当てはめる必要はありません。

Amplitudeも新規利用者の活性化を考える際に、製品の価値を最初に体験する行動までの流れを調べる考え方を紹介しています（参考：新規利用者の活性化）。

自社では、利用者が登録時に期待している作業を一つ選んでください。

そのうえで、クリックではなく、実際に作業が成功したことを確認できる条件を決めます。

「生成する」を押しただけでは、生成処理が失敗しているかもしれません。

画面の表示、処理の成功、結果の利用をどこまで成果に含めるか、開発・運用・サポートでそろえます。

最初の価値を定義してから、そこへ進む操作を調べるのが基本です。

必要な工程を並べる

初回成功へ至る工程を、実際の画面順に書き出します。

架空のレポート作成SaaSなら、「登録→プロジェクト作成→データ接続→生成成功→結果閲覧」という流れになります。

各工程に、開始と完了を確認する方法を対応付けます。

工程	確認する状態	計測イベント名の設計例
登録	アカウント作成が正常に完了	account_created
プロジェクト作成	必要な設定を保存できた	project_created
データ接続	接続先と正常に通信できた	connection_succeeded
レポート生成	処理が正常終了した	report_generated
初回成功	対象のレポートを初めて開いた	first_report_opened

この表のイベント名は独自の設計例であり、ツールを入れるだけで自動的に記録される標準イベントではありません。

実装する際は、発火条件・重複の扱い・対象となる利用者を決めて検証します。

画面のボタンを押した時点と、保存や生成が成功した時点を混同しないでください。

Amplitudeのファネル分析では、指定したイベントと順序によって完了を定義できます（参考：ファネル分析の作成）。

ただし、実際には工程を前後できるサービスもあります。

先にサンプルを見る、接続を後回しにする、といった正規の別経路があるなら、それも図に含めます。

一直線の手順しかない前提で集計すると、別経路で成功した利用者を未完了に数えることがあります。

セッションリプレイの対象を抽出する

初期設定の問題を探すときは、慣れた利用者の操作を混ぜないようにします。

「新しい訪問者」と「新しく登録したアカウント」も区別してください。

新規登録者の記録を分ける

録画ツールのNew userという表示が、そのままSaaSの新規登録者を意味するとは限りません。

Clarityは標準ではブラウザや端末ごとに利用者を識別するため、同じ人でも別の端末から訪問すると別の識別になる場合があります（参考：Clarityの利用者識別）。

オンボーディングの調査では、自社で記録した登録日や初回設定の状態を基準に、対象を決める必要があります。

例えば、「対象期間に登録し、まだ初回レポートを開いていないアカウント」という条件です。

Clarityではカスタムタグを使い、録画やヒートマップを独自の条件で絞り込めます（参考：Clarityのカスタムタグ）。

設定するなら、登録時のグループやオンボーディングの版など、調査に必要な分類を先に決めます。

メールアドレスや顧客名を、そのままタグの値にする必要はありません。

識別子を送る場合は、利用目的と取得範囲を確認し、推測しにくい社内用の識別子などを検討してください。

タグを付けただけで、別の訪問をまたいだ完了率まで正しく計算されるわけではありません。

利用者を追う集計と、ある場面の録画を選ぶ作業を分けて設計します。

最初はテスト用のアカウントで、想定した分類が付くことを確認します。

成功と未完了を比較する

未完了の人だけを見ていると、正常な操作も問題に見えることがあります。

同じ登録時期・プラン・権限・初期状態で、初回成功した人の記録も確認してください。

比較の時間幅もそろえます。

昨日登録した人と、一週間使った人を同じ「未完了」で比べると、前者はまだ設定中かもしれません。

Amplitudeのファネル分析では、開始から完了までに許す時間をコンバージョンウィンドウとして設定します（参考：ファネルの完了期間）。

自社の集計でも、例えば「登録から七日以内」のように、判断する期間を決めてください。

七日は説明用の例であり、導入準備にかかる時間に合わせて選びます。

対象期間が過ぎていない利用者は、完了判定の途中として扱います。

また、管理者の承認待ちと、画面操作で行き詰まった状態も分ける必要があります。

録画がないアカウントについても、操作しなかったと決めつけないでください。

同意、取得設定、保存期間などによって、調査に使える記録が残っていない可能性があります。

比較表には「成功」「期間内未完了」「判定期間中」「記録不足」を分けておくと、数字の意味が伝わります。

初期設定で止まる場所を探す

工程の集計で調べる範囲を決めたら、その手前と後の操作を録画で見ます。

長く止まっている場所を、すべて「理解できない場所」と決めないことが大切です。

説明を往復する操作を見る

設定画面とヘルプを繰り返し開く操作は、説明の不足を探す手がかりになります。

例えば、データ接続画面で「ワークスペースID」を求められ、ヘルプへ移動して戻る動きが続く場合です。

その場合、「どこから値を取得するのか分かりにくい」という仮説を立てられます。

ただし、ヘルプを読んで正しく設定できたのであれば、必要な確認をしているだけかもしれません。

成功した記録と比べ、往復した後に何が起きたかを確認します。

画面が変わらない時間も、そのまま迷っていた時間とは言えません。

別のタブで準備していたり、担当者からの返事を待っていたりする可能性があります。

Clarityの録画では、ページが表示されている状態と隠れている状態に関するイベントを確認できます（参考：プレーヤーのページイベント）。

それでも、利用者の考えや画面外の作業までは分かりません。

メモは「説明ページへ移動した」「戻って同じ項目を変更した」と、見えた操作で残します。

理解しにくい用語や説明の位置は、次に確かめる仮説として分けてください。

外部連携の前後を調べる

SaaSの初期設定には、外部サービスへの接続が含まれることがあります。

このとき、自社サイトの録画だけでは、外部サービスで何が起きたかを全部確認できません。

Clarityには外部iframeなど再現に制約がある内容もあり、見えない区間を録画から補うことはできません（参考：録画プレーヤーの制約）。

自社が計測していない別サイトの操作についても、推測で手順を埋めないようにします。

調査では、「接続を開始した」「自社へ戻った」「接続結果が成功だった」を別々に記録します。

戻ってきたことだけで、連携が成功したとは限りません。

権限が足りなかった、必要な対象を選ばなかった、処理が中断した、といった状態を区別します。

接続結果は、自社の処理が把握できる範囲の成功・失敗情報と照合してください。

その際、認証コードやアクセストークンを録画のタグや調査メモへ保存する必要はありません。

架空の調査メモなら、「外部接続後に戻ったが、接続成功の状態は確認できない」と書けます。

外部側の表示が分からない場合は、テスト用アカウントと正規の接続方法で再現します。

SaaSのエラーと迷いを分ける

画面を分かりやすくしても、処理自体が失敗していれば初期設定は進みません。

説明の問題と技術的な不具合を、別の課題として整理します。

再現できる不具合を確認する

同じボタンを繰り返し押している場面では、反応の有無を確認します。

待機表示が出たのか、エラーメッセージが出たのか、保存された状態が変わったのかを記録してください。

ClarityのJavaScript errorsフィルターは、エラーを検出した記録を探す手がかりになります（参考：Clarityのエラー条件）。

ただし、そのエラーが操作を止めた原因とは限りません。

対象の版・権限・入力条件をそろえ、テスト環境で同じ操作を試します。

「連携できません」と表示された場面でも、権限不足を適切に案内しているのか、正常な接続を誤って失敗扱いしているのかで対応が変わります。

期待する動作と実際の結果を分けて、開発者へ渡してください。

また、セッションリプレイに入力内容が見えない場合も、問題調査のためだけにマスキングを外す必要はありません。

Clarityのマスキングは、入力内容などを隠す仕組みです（参考：マスキングの対象と設定）。

再現には架空のテストデータを使い、実際の顧客データをチケットへ貼り付けないようにします。

詳しい報告方法は、JavaScriptエラーを再現手順へまとめる方法で紹介しています。

質問やサポート履歴を合わせる

録画で分からないことは、利用者の質問やサポートの記録から補います。

ただし、必要以上に個人情報や別案件の情報を共有しないようにしてください。

調査する工程に関する質問を、内容ごとに分類します。

例えば、「接続に管理者の権限が必要か」「サンプルだけでも試せるか」「処理が終わるまで何を待てばよいか」という分類です。

録画で説明ページを往復している場面と、同じ工程の質問が重なれば、確認すべき点を絞れます。

それでも、問い合わせた人の困りごとを、利用者全員の困りごとへ広げないようにします。

サポートへ連絡せずに諦めた人や、自力で完了した人もいるためです。

GOV.UKの調査分析の説明でも、観察した事実を集めてから、意味や発見を整理する流れが示されています（参考：ユーザー調査の分析）。

記録の欄を「観察」「利用者の発言」「解釈」「次の確認」に分けると、推測を事実と取り違えにくくなります。

理解度が重要な論点なら、短いユーザビリティテストで、その操作をどう考えたかを確かめます。

録画を何本も見続けるより、未確認の問いを一つ解く方が役立つ場面もあります。

オンボーディングの修正案を作る

初期設定は、すべての機能を紹介する場ではありません。

初回成功に必要なことを、必要な順序で進められるようにします。

後回しにできる設定を分ける

最初に、各入力項目が初回成功に本当に必要かを確認します。

架空のレポートSaaSなら、接続情報は必要でも、全メンバーの招待は後からできるかもしれません。

ただし、必須の権限確認や利用者の同意を、離脱を減らすために省いてはいけません。

「今必要」「後でよい」「条件により必要」の三つに分け、理由を残します。

GOV.UKの質問ページの設計では、質問する理由を明確にし、本当に必要な情報だけを求める考え方が示されています（参考：必要な質問を整理する）。

自社のSaaSでも、項目を削る前に、その情報をどの機能が使っているかを確認してください。

後回しにした設定には、後から戻れる場所と、必要になるタイミングを用意します。

「後で設定」を押しただけで初回成功と数えないことも重要です。

サンプルデータで試せる場合は、サンプルでの体験と自分のデータでの成功を分けて集計します。

そうすれば、初期画面を通り抜けただけなのか、実際に使える状態まで進んだのかを確認できます。

説明の位置を変える

説明を増やす前に、必要な操作の近くに説明があるかを確認します。

接続先のIDを入力する画面なら、「どこで取得するか」「どの形式で入れるか」をその場で分かるようにします。

W3Cのフォーム解説では、入力に必要な説明や書式などを提供する方法が紹介されています（参考：フォームの説明）。

入力し始めると消えるプレースホルダーだけに、大切な条件を任せないようにしてください。

説明の文章を変える場合も、利用者が使う言葉と、画面の用語を対応付けます。

「接続対象を指定」より、「レポートを作りたいプロジェクトを選択」の方が、自社の利用者に伝わるかもしれません。

これは仮説なので、実際に操作してもらい、意味が伝わるか確認します。

次の工程別調査シートに、観察から検証までをまとめられます。

工程	観察・未確認の点	修正候補と確認方法
プロジェクト作成	名称の入力で説明へ戻る	入力例を近くに置き、用途の理解を確認
データ接続	権限不足の案内後に止まる	必要な権限と依頼先を示し、再試験
レポート生成	待機表示を繰り返し押す	処理中の状態と終了時の案内を点検
結果閲覧	生成後に一覧へ戻る	結果を開く導線を明確にし、到達を確認

この表は架空の記入例です。

自社の記録を入れるときは、対象条件・録画の位置・担当・実施した版も追記してください。

初期設定の改善を評価する

初期画面を早く通過できたことだけでは、改善を評価できません。

初回成功と、その後の利用やサポートへの影響まで見ます。

初回成功率と時間を確認する

初回成功率は、対象とする新規登録者のうち、定めた期間内に初回成功した人の割合として計算できます。

分母には、必要な判定期間を確保できた対象者を使います。

架空の例で、登録後七日間を観察できた100アカウントのうち40アカウントが初回レポートを開いたなら、初回成功率は40%です。

この数字は説明用であり、目標値や業界平均ではありません。

初回成功までの時間も、登録を起点にするのか、設定画面を開いた時点にするのかで変わります。

外部サービスの承認を待つ時間を含むかも、先に決めてください。

Amplitudeのファネルでは、ユニーク利用者とイベント合計で数え方を切り替えられ、時間の集計にも対象の条件があります（参考：ファネルの集計に関するFAQ）。

自社のレポートでも、何を一件と数えたかを明記します。

特に、完了した人だけの平均時間が短くなっても、完了できる人自体が減っていたら良い変化とは限りません。

成功率と、成功した人の所要時間を並べ、未完了の人も確認してください。

前後比較では、登録経路、プラン、権限、案内した手順の版をそろえます。

広告や利用者層も変わった場合は、変化を一つの画面修正の効果と断定しないようにします。

サポート負担も確認する

手順を短くした結果、後から設定の問い合わせが増えることがあります。

説明を省いたために、間違った接続先や意図しない設定で進んでいないかも確認してください。

サポートの件数は、登録者の増減に影響されるため、件数だけで比較しません。

対象の登録者数に対する問い合わせの割合と、内容の変化を併せて見ます。

同じ人からの複数の問い合わせをどう数えたかも残してください。

また、問い合わせが減っても、連絡先が見つからなくなっただけという可能性があります。

初回成功率、問い合わせ内容、必要なら短い聞き取りを組み合わせて判断します。

修正後には、対象の版で新しい記録を見て、想定した操作ができるか確認します。

自分でテストした結果と、実利用者の記録から分かったことは分けて記録してください。

評価すること	確認する指標・記録
初回成功	対象者と期間をそろえた成功率
進めやすさ	工程別の停止と、成功までの時間
正しい設定	誤設定や、後からの設定し直し
サポート	対象者あたりの問い合わせと内容
続けて使えるか	初回成功後の再利用や必要な操作

最初からオンボーディング全体を作り直す必要はありません。

まずは初回成功を一つ定義し、止まる人が多い工程を一つ選んでください。

成功・未完了の録画を同じ条件で比べ、工程別調査シートへ書き込むところから、具体的な改善が始められます。