同じ人が別人に数えられる原因｜クロスデバイス計測の備え

「解析の画面には月に3,000人と出ているのに、問い合わせは5件しかない」「これだけ見られているのに成果が出ていないと言われて、答えに困った」——社内に数字を説明する場面で噛み合わなくなるやり取りです。この人数は、実在する人の数ではありません。見分けられた単位の数であって、同じ人が何人分にも数えられます。この記事では、何を1人と数えているのか、どこまで補えるのかを整理します。

ユーザー数は実人数ではない

アクセス解析の数字を扱うとき、最初に共有しておくべき前提がこれです。ユーザー数という項目名は、実在する人数を意味していません。識別できた単位の数を表しています。

同じ人が会社のパソコンで見て、帰宅後にスマートフォンで見れば、2つの単位として記録されます。同じパソコンでもブラウザを変えれば別の単位になり、閲覧履歴を消せばまた別の単位になります。この積み上がりが、ユーザー数を実人数より多くします。

BtoBではこのずれが特に大きくなります。1つの案件を検討する過程で、担当者、その上司、情報システム部門、経営層が同じサイトを見ます。1社からの訪問が5人分として記録され、それぞれが2つの端末を使えば10単位になります。

この前提を共有しないまま数字を報告すると、認識のずれが起きます。ユーザー数は「のべ何単位の訪問があったか」に近い指標として扱うのが実務的です。実人数を知りたい場合は、別の方法が必要になります。

何を「1人」と数えているのか

識別の仕組みを理解しておくと、どの数字がどこまで信頼できるかが判断できます。仕組みは複数の層に分かれています。

基本になるのはブラウザに保存される識別子で、GA4ではクライアントIDと呼ばれます。これはブラウザごとに発行されるため、同じ端末でも別のブラウザを使えば別のIDになります。スマートフォンとパソコンでは当然別になります。

この識別子は保存期間があり、期限が切れると新しいIDが発行されます。数か月ぶりに訪れた同じ人が、新規ユーザーとして記録されることがあるのはこの仕組みによります。ブラウザの設定や保存領域の削除でも同じことが起きます。

つまり、この層だけに頼ると精度は限定的です。ブラウザ単位の識別は、短期間の行動を追うには十分だが、長期の追跡には弱いという性質を持ちます。

加えて、ブラウザの仕様変更もこの層の精度に影響します。追跡を制限する機能が標準で有効になる流れが続いており、保存期間が短縮されたり、条件によって識別子が保持されなくなる場合があります。数年前の前提で数字を読んでいると、実態とのずれが広がります。新規ユーザーの比率が不自然に高い場合は、この影響を疑ってください。仕様の変更は事前に告知されるものの、マーケティング担当者に届く形では通知されないため、指標の急な変化として現れます。

この層の精度は今後さらに下がる方向にあると考えて、上位の層を用意しておくのが備えになります。

GA4の識別の順番

GA4では、複数の情報を優先順位をつけて使います。この順番を知っておくと、どこに手を入れれば精度が上がるかが分かります。

GA4ではUser ID、Googleシグナル、クライアントIDの順番でユーザーを評価します。上位の情報が利用できる場合はそれが使われ、なければ次の層に落ちるという構造です。何も設定していないサイトでは、最下層のクライアントIDだけが使われます。

この順番が意味するのは、上位の情報を用意すれば精度が上がるということです。User-IDを設定すれば、それが最優先で使われます。設定は無料ででき、追加の費用は発生しません。必要なのは実装の工数です。

順番を理解していないと、施策の効果を誤解します。Googleシグナルを有効にしただけで全端末が紐づくわけではないという点は特に誤解されやすい部分です。それぞれの層で補える範囲が違います。

Googleシグナルで補える範囲

中間の層にあるGoogleシグナルは、設定を有効にするだけで使えます。ただし補える範囲には条件があります。

この仕組みが機能するのは、Googleアカウントにログインしていて、広告のパーソナライズを許可している利用者に限られます。条件を満たす利用者については、端末をまたいだ行動が同じ人として認識されます。設定は管理画面から数分で有効にできます。

一方で、条件を満たさない利用者には効きません。業務用の端末でGoogleアカウントにログインしていない場合、この層は機能しません。BtoBの業務環境では、条件を満たさない訪問が一定割合含まれると想定しておく必要があります。

あわせて、この設定にはデータの表示に関する制約もあります。人数が少ないセグメントでは、詳細が表示されない場合があります。有効にする価値はあるが、これだけで端末横断の計測が完成するわけではないという位置づけです。

User-IDを入れると何が変わるか

最も精度が上がるのがUser-IDの設定です。自社で発行したIDを使って、同じ人を同じ人として記録します。

User-ID機能を使用すると、自社で生成したユーザーIDを個々のユーザーに関連付けることができるため、さまざまなセッション、デバイス、プラットフォームをまたいで各ユーザーの行動を把握でき、ユーザー数をより正確にカウントできます。会員サイトや管理画面を持つサービスでは実装しやすい仕組みです。

変わるのは3点です。ユーザー数が実態に近づくこと、端末をまたいだ行動の流れが見えること、そして同じ人の複数回の訪問を一連の検討として追えることです。3点目はBtoBの長い検討期間を分析する際に効きます。

ただし、User-IDが記録されるのはログイン後の行動だけです。ログイン前の閲覧は、従来どおりブラウザ単位で記録されます。会員登録前の検討期間は、User-IDを入れても端末をまたげないという制約は残ります。

User-IDに使ってよいIDの条件

User-IDとして送る値には条件があります。実装の前に確認しておかないと、後から作り直しになります。

必須の条件は2つです。各ユーザーに自社で作成した一意のIDを割り当て、その後も同じユーザーには同じIDを一貫して割り当て続けること。そして、各ユーザーIDは256文字以内で指定することです。

使ってはいけない値もあります。個人を特定できる情報をそのまま送ることは避ける必要があります。メールアドレスや氏名をIDとして送る実装は、規約と個人情報の扱いの両面で問題になります。会員番号のような、それ自体では個人を特定できない値を使います。

実装前に、社内のどのIDを使うかを決めておいてください。会員システムの内部IDが最も扱いやすく、一貫性も保ちやすい選択になります。ID体系が複数ある場合は、どれを正とするかを先に決めます。

同じIDを複数人に割り当てる事故

User-IDの実装で最も影響が大きい失敗が、IDの重複です。データが混ざると、修正しても過去の分は戻りません。

同じIDを複数のユーザーに割り当てると、データスキューが生じ、実際のユーザーアクションが区別しにくくなります。異なる2人のユーザーに誤って同じUser-IDを割り当ててしまった場合、そのデータが混在してしまいます。

この事故が起きやすいのは、共有アカウントを使っている場合です。1社に1つのアカウントを発行し、複数の担当者が同じ認証情報で使う運用では、複数人の行動が1人分として記録されます。BtoBのサービスでは実際に起こりうる状況です。

対策としては、アカウントの発行単位を人ごとにすることが根本的な解決になります。それが難しい場合は、共有アカウントの行動は分析対象から除外するという判断も選択肢になります。混ざったデータを使い続けるより、対象を絞ったほうが判断の精度が上がります。

実装の流れ

User-IDの実装は、次の順番で進めると手戻りが少なくなります。技術的な作業とルールの整備が並行します。

4番目の設定を忘れると、実装しても反映されません。タグでIDを送るだけでは足りず、管理画面側の設定が必要です。実装した後に数字が変わらないという相談の多くは、この設定漏れです。

5番目では、数字が減ることを想定しておきます。同じ人が1人としてまとまるため、ユーザー数は下がります。ユーザー数の減少は精度が上がった結果であり、悪化ではないことを社内に事前に伝えてください。

ログインのないサイトはどうするか

会員機能を持たないサイトでは、User-IDを使えません。この場合の考え方を整理します。

結論としては、端末をまたいだ完全な計測は諦めます。そのうえで、指標の読み方を変えるほうが現実的です。ユーザー数を実人数として扱わず、行動の傾向を見る指標として使います。

代替として使えるのは、企業単位の情報です。アクセス元の組織情報を取得するサービスを使えば、どの企業から見られているかを把握できます。BtoBでは、個人を特定するより企業を特定するほうが施策に直結します。

あわせて、フォームでの取得を接点にする方法もあります。資料ダウンロードや問い合わせの時点でIDが発生するため、そこから先は追跡できます。匿名の期間は傾向を見るだけにして、識別できた後を丁寧に追うという設計です。

BtoBで特に影響が出る場面

識別のずれは、どの業種でも起きます。ただしBtoBでは影響が出やすい場面が特定できます。押さえておくと、数字を読むときの補正ができます。

1つ目は、1社から複数人が訪問する場面です。担当者が上司に共有し、その上司が別の端末で見る。1件の検討が5単位、10単位として記録され、関心の高さを実態より大きく見せます。特に大手企業からの検討では、この積み上がりが顕著になります。

2つ目は、社内ネットワークからのアクセスです。同じ回線から複数の社員が見ても、識別子はブラウザごとなので別単位になります。逆に、自社の社員の閲覧が混ざっている場合は、除外の設定をしないと数字が膨らみます。

3つ目は、検討期間が長い場合です。半年かけて検討する案件では、識別子の期限切れによって同じ人が新規として再登場します。BtoBの長い検討期間は、識別子の保存期間より長いことがあるという前提で新規とリピートの比率を読んでください。

端末をまたいだ行動が見えると何ができるか

計測の精度を上げる目的は、数字を正確にすることではありません。施策の判断が変わるかどうかが問題です。何ができるようになるかを整理します。

最も価値があるのは、検討の流れが見えることです。最初はスマートフォンで記事を読み、後日パソコンで資料をダウンロードし、さらに後日フォームから問い合わせる。この流れが1人の行動として見えると、どの接点が最初の入口だったかが分かります。

流入元の評価も変わります。端末をまたいで記録されない状態では、最後に見た端末の流入元だけがコンバージョンに紐づきます。実際には別の端末で見た記事が入口だったとしても、その貢献は記録されません。広告と記事の評価が歪む原因になります。

この改善が意味を持つのは、施策の予算配分を判断する場面です。入口として機能している接点が分かれば、予算を振り向ける先が変わるという効果があります。精度を上げること自体が目的ではなく、配分の判断を変えるための投資として位置づけてください。

数字ごとの信頼度を分けて扱う

識別の限界を踏まえると、指標ごとに信頼度が違ってきます。この違いを整理しておくと、報告の際に誤解を防げます。

指標	信頼度	扱い方
ページビュー数	高い	そのまま使える。閲覧の量として読む
セッション数	比較的高い	訪問の回数として読む。30分の無操作で区切られる
ユーザー数	低い	実人数として扱わない。前月比の傾向として読む
新規とリピートの比率	低い	識別子の期限切れで新規が増える。参考値に留める
コンバージョン数	高い	実際の送信件数と照合できる。基準として使える

この表で重要なのは、コンバージョン数を基準に据えることです。実際の問い合わせ件数と照合できる指標であり、他の数字の妥当性を確認する足場になります。ユーザー数の議論に時間を使うより、こちらを軸にしたほうが判断が進みます。

あわせて、セッションの区切りも押さえておきます。GA4ではウェブサイトでの操作が30分以上ない場合にセッションが途切れるため、同じ訪問の途中で席を離れると2セッションとして記録されます。セッション数も訪問の実回数とは一致しないという前提で読んでください。

社内への説明の仕方

計測の限界を説明するとき、技術的な仕組みから話すと伝わりません。伝え方を工夫すると、数字の議論が建設的になります。

効果的なのは、身近な例に置き換えることです。「自分が会社のパソコンとスマホで見たら2人と数えられます」と言えば、多くの人はすぐ理解します。仕組みの説明は不要で、結論だけを共有すれば足ります。

そのうえで、どの数字を判断に使うかを提案します。ユーザー数ではなくコンバージョン数と、その前の段階の行動を見るという方針です。判断に使う指標を絞れば、精度の低い数字に振り回されません。

報告資料では、ユーザー数を主要な指標として置かないという選択もあります。精度の低い数字を大きく載せると、そこに議論が集中してしまうためです。載せる場合は「のべ訪問単位」といった注記を添えてください。

やりがちな失敗

クロスデバイスの計測に関して見られる失敗を挙げます。いずれも仕組みの理解不足から起きます。

• ユーザー数を実人数として報告する：営業や経営層との認識がずれ、数字の信頼性が疑われます
• メールアドレスをUser-IDとして送る：個人を特定できる情報の扱いとして問題になります
• User-IDの実装後に数字が減って慌てる：精度が上がった結果であり、事前に共有しておくべき変化です
• Googleシグナルを有効にして完了とする：ログインしていない訪問には効かず、補える範囲は限定的です

3つ目は社内の混乱につながりやすい失敗です。実装の前に「ユーザー数は下がります」と伝えておけば、正しい変化として受け取られます。伝えずに数字が動くと、実装のミスを疑われます。

• User-IDの設定はレポートに遡って適用されない。設定した時点以降のデータが対象
• 計測の仕様は変わることがある。年に1度は公式の情報を確認する

この整理でAIを使う場所

計測の実装は技術的な作業ですが、その前後には整理と説明の作業があります。生成AIが効くのはその部分です。

実装前の整理では、社内にあるID体系の洗い出しと、どれをUser-IDに使うかの検討に使えます。会員番号、顧客コード、商談管理の番号といった複数の体系がある場合、それぞれの一貫性と重複の可能性を整理させると判断材料になります。要件を文章で渡せば、確認すべき点を挙げてくれます。

説明の場面では、計測の限界を非専門者に伝える資料の草案が作れます。「ユーザー数が実人数でない理由を、技術用語を使わずに3行で」と指定すると、社内共有に使える文章が出ます。この説明を毎回口頭でするより、資料として残したほうが定着します。

あわせて、指標ごとの信頼度をまとめた社内向けの一覧も作れます。計測の話は仕組みより「どの数字を判断に使うか」を共有するほうが実用的です。実装の可否にかかわらず、この整理は先に進められます。

よくある質問

User-IDを入れると過去のデータも直りますか？

直りません。設定した時点以降に収集されたデータに適用されます。そのため、実装の前後で数字の水準が変わり、期間をまたいだ比較ができなくなる点に注意が必要です。実装した日付を記録し、それ以前との比較では条件が違うことを明記してください。前年同月比を追っている場合は、1年間は注記が必要になります。

ログインしていない期間の行動は追えますか？

ログイン後にUser-IDが記録されると、同じブラウザでのログイン前の行動は紐づけられる場合があります。ただし別の端末でのログイン前の行動は紐づきません。会員登録前の検討期間を端末をまたいで追うことは、現状の仕組みでは困難です。この期間は個人ではなく企業単位で把握するアプローチのほうが実務的です。匿名の期間を追うことに労力をかけるより、識別できた後の行動を丁寧に見るほうが施策につながります。

ユーザー数を報告に使わないと何を使えばいいですか？

コンバージョン数とその前段階の行動を軸にしてください。資料ダウンロード数、問い合わせ数、特定ページの到達数。これらは実際の件数と照合でき、精度が高い指標です。閲覧の量を示したい場合はページビュー数を使い、ユーザー数は前月比の傾向を見る補助指標として扱えば、認識のずれを避けられます。

まとめ

アクセス解析のユーザー数は実人数ではなく、識別できた単位の数です。GA4はUser ID、Googleシグナル、クライアントIDの順に評価し、何も設定していなければブラウザ単位の識別だけが使われます。User-IDを設定すれば端末をまたいだ計測ができますが、使うIDは一意で一貫性があり256文字以内、個人を特定できない値である必要があります。共有アカウントで同じIDが複数人に割り当てられると、データが混ざって修正できません。ログイン機能がないサイトでは完全な計測を諦め、コンバージョン数を基準に据えて判断してください。ユーザー数は前月比の傾向として読む指標です。まずは社内で、この数字が実人数ではないという前提を共有してください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。