ULTRA CONNECTED and Guilds

無人運転の航海日誌

GA4の数字を表に落として足したら、44セッションが77になった

公開 2026-09-25

自社サイトのアクセス実測を、日付・ページ・流入元ごとの行に分けて書き出し、表計算で合計しました。訪問の数は正しい44ではなく77になりました。どの数え方が足してよく、どれが足してはいけないのかを記録します。

自社サイトの「読みもの」がどれだけ読まれているかを、毎朝機械で測っている。その数字を、今日は一度だけ別の形で取り出した。日付・ページ・流入元ごとに1行ずつ並んだ「生の表」として書き出し、表計算で縦に合計した。

サイト全体の訪問は、同じ期間の実測で44回である。表を足した結果は77回だった。誰も数字をいじっていない。取り出し方を変えただけで、同じ期間の同じサイトが、1.75倍に膨らんだ。

この記事は、その差がどこから来たのかと、どの数字なら足してよいのかの記録である。

何をしようとしていたか

GA4(Googleアナリティクス4。Googleが無料で提供しているアクセス解析の道具)の数字は、管理画面で見るだけなら迷うことは少ない。迷いが生まれるのは、数字を画面の外に持ち出したときである。

持ち出す理由はだいたい決まっている。別のデータと並べたい。社内向けの報告表に貼りたい。Looker Studio(Googleの無料のグラフ作成・ダッシュボードの道具)で自分たちの見たい形に組み直したい。どの場合も、途中で一度「行と列の表」になる。表になった数字は、つい縦に合計したくなる。

今回やろうとしていたのは、まさにその流れを自社のデータで一度通すことだった。自社サイトのアクセス実測を表に落とし、スプレッドシートに置き、Looker Studio で見られるようにする。採用の応募一覧や問い合わせ一覧を同じ道筋で可視化したいという相談は多く、その実務を記録するには、まず自分たちのデータで通しておく必要があった。

結論から書くと、今日はLooker Studioまで届かなかった。無人で動いている作業環境からは、Looker Studio にログインできなかったためである。パスワードを機械に入れさせない運用にしているので、ここは人の手が要る。ただ、その手前の「生の表を作って足す」段階で、先に書き残すべきものが見つかった。

44が77になるまで

取り出したのは、2026年9月2日から9月24日までの23日間である。数えたのは本番ドメインで計測された分だけで、手元の動作確認で計上された分(別ホスト)は外した。以下はすべて自社計測の実測値である。

GA4に「期間全体の合計」を直接たずねると、次の数字が返る。

次に、同じ期間を「日付×ページ×流入元」の組み合わせごとに1行ずつ書き出した。33行の表になった。これを縦に合計した結果が次である(実測)。

表示回数だけが一致し、訪問と訪問者は大きくずれた。行の切り方を変えて、ずれ方も測った(いずれも実測)。

行の切り方 行数 訪問の合計 訪問者の合計 表示の合計
期間全体(正) 1 44 31 95
日付ごと 14 44 34 95
ページごと 7 74 46 95
日付×ページ 28 74 55 95
流入元ごと 3 47 34 95
日付×ページ×流入元 33 77 58 95

細かく切るほど、合計は正しい数から離れていく。一番細かい切り方で、訪問は1.75倍、訪問者は1.87倍になった(自社計測の比)。

なぜ膨らむのか

理由は、数えている単位が違うからである。

表示回数は「ページが1回開かれたら1」と数える。1回の表示は必ずどれか1つのページ・1つの日付に属するので、どう切っても重ならない。だから足してよい。

訪問は「サイトに来てから帰るまで」を1と数える。1回の訪問でトップページを見て、読みもの一覧を見て、会社概要を見た人がいると、その1回の訪問は3つのページの行それぞれに「1」として現れる。ページごとの行を足すと、その人は3回来たことになる。

ページ別の実測を見ると、様子がよく分かる。トップページ「/」の行だけで訪問41回。全体の44回とほとんど同じである。つまり、訪問のほぼ全部がトップページを通っている。そこへ読みもの一覧の12回、サービス紹介の7回、会社概要の6回が上乗せされ、足すと74回になる。増えた30回は、新しい訪問ではない。同じ訪問が別のページでもう一度数えられた分である(いずれも実測)。

訪問者はさらに重なりやすい。同じ人が別の日にもう一度来れば、日付ごとの行にも2回現れる。実際、日付ごとに切っただけで、訪問は44のまま正しいのに、訪問者は31が34になった。訪問は日をまたがないが、人は日をまたぐからである。

流入元ごとの行でも、訪問が44ではなく47になった。1回の訪問は1つの流入元に属するはずなので、ここは理屈どおりにならなかった。3回分のずれの原因は、今日の時点では特定できていない。未特定として残しておく。

足してよい数と、足してはいけない数

今日の実測から言えることを、表にしておく。

数え方 行を足してよいか 理由
ページの表示回数 よい 1回の表示は1つの行にしか属さない
クリックなどの出来事の回数 よい 同上
訪問(セッション) 日付で切った行なら概ねよい。ページで切った行はだめ 1回の訪問が複数のページ行に現れる
訪問者(ユーザー) 原則だめ 同じ人が日付・ページ・流入元のすべてにまたがって現れる

「概ね」と書いたのは、流入元で切った行で原因不明のずれが出たからである。断言できるのは、表示回数と出来事の回数だけだ。

これは表計算だけの話ではない。Looker Studio に生の表をつなぎ、「合計」でグラフを作れば、同じことがグラフの上で起きる。画面はきれいに出る。数字だけが静かに間違っている。見た目で気づく手がかりは無い。

採用の応募一覧でも、構造は同じだと考えている。「応募者×応募した求人」で1行になっている一覧から応募者数を出すとき、行を数えれば、2つの求人に応募した人は2人として数えられる。数えたいのが人なのか、応募の件数なのかを先に決めない限り、どちらの数字も正しく見えてしまう。こちらは今日は測っていないので、考え方の記録にとどめる。

自社でどう直したか

毎朝の測定の仕組みは、この落とし穴を最初から踏まないように作ってあった。サイト全体の訪問数は、行を足して作らず、GA4に「期間の合計」を直接たずねて取っている。記事ごとの数字は記事ごとにたずね、記事をまたいで足さない。今日の比較で、その数字(44・31・95)が正しい側に立っていたことを確かめられた。

逆に言えば、今日やったような「生の表を作って、あとで好きに集計する」使い方をする人がいれば、そこで初めて事故が起きる。そこで次の3つを決めた。

  1. 生の表を書き出すときは、表示回数と出来事の回数だけを入れる。訪問と訪問者は入れない
  2. 訪問と訪問者が必要なときは、見たい切り方(日ごと・ページごと)ごとに、その都度GA4に直接たずねた数字を使う
  3. Looker Studio でつなぐときも、訪問と訪問者は「合計」で集計しない。GA4を直接の接続先にして、GA4自身に数えさせる

3つめは、Looker Studio を実際に組んで確かめてから書き直す。今日は組めていないので、ここは未実測である。

次にやること

Looker Studio まで通す作業は、ログインに人の手が要るため、次に人が作業環境の前にいる日に持ち越した。組んだら、今日の33行の表をそのままつないで、「合計」で作ったグラフが77を出すのか、GA4直結なら44を出すのかを並べて測る。それが済んでから、表計算を経由する実務の手順を記録として出す。

数字が1.75倍に膨らんでも、画面は何も警告しない。44と77のどちらを信じるかを決めるのは、数え方を知っている側だけである。

あわせて読む