[🛠] ブログ統計ダッシュボードの混乱を整理する

✨ GPT-5.5の要約 　

公開統計ページで訪問と閲覧数が混ざって見えていた問題を直し、30分セッション基準の訪問数とページ表示基準の閲覧数を分けて、モバイルでも読みやすいダッシュボードにした記録。

公開ブログ統計ページを作った直後から、ひっかかる部分があった。

数字は出ていた。

でも数字の名前が混ざりやすかった。

訪問者、訪問、閲覧数、セッション、page view。ブログ画面では似て見える言葉だ。でも実際の集計では全部違う。公開カウンターでここを曖昧にすると、数字が表示されていても信用しにくい。

最初は「今日の閲覧数」「今月の閲覧数」「全体の閲覧数」のように単純でいいと思っていた。でもサイドバーで見せたい値は、記事が何回開かれたかより、今日ブログに何回訪問があったかに近かった。

そこで構造を分け直した。

訪問
-> 30分の非アクティブで切れるセッション

閲覧数
-> ページや記事が開かれた回数

4943は訪問数ではなかった

まず直すべきだったのはbaselineの意味だった。

Google Analyticsから取り込んだ4943のような値はscreenPageViewsだった。つまりページ閲覧数だ。これを全体の訪問者数や訪問数として見せると、間違った数字になる。

だからWorkerとドキュメントを一緒に整理した。

totalPageViews
-> GA screenPageViews baseline + D1 page views

totalSessions
-> GA sessions baseline + D1 sessions

訪問と閲覧数を同じbaselineに乗せてはいけない。そこでセッションbaselineを別にseedするrouteも追加した。

/admin/seed-session-baseline

GitHub ActionsのWorkerデプロイにもセッションbaseline seedの段階を入れた。Workerだけデプロイされてbaselineが空だと、公開画面の全体訪問数が壊れて見えるからだ。

/trackの応答をすぐ使う

最初の構造は少し遠回りだった。

クライアントが/trackでカウントを増やし、そのあと/analyticsをもう一度読んで画面を埋める流れだった。これだとキャッシュや順序の都合で、今反映した訪問がすぐ画面に出ないことがある。

だから/trackの応答に最新のanalytics payloadも一緒に返すようにした。

流れはこう変わった。

ページロード
-> POST /track
-> Workerがセッション/閲覧数を反映
-> 同じ応答に最新analyticsを含める
-> クライアントがそのpayloadでサイドバーと現在ページの閲覧数を描画

以後の定期更新はそのまま/analyticsを読む。

最初の画面では、反映直後のpayloadを優先して使う。その後は読み取りAPIで最新状態を追う。

セッションはページ移動ごとに増えてはいけない

閲覧数は記事を移動するたびに増えてよい。

でも訪問は違う。同じ人が同じブログセッションで3本の記事を読んだだけで訪問が3回になるのはおかしい。そこでWorkerにsessionsテーブルを追加し、visitor hashと最後の活動時刻でセッションをつなげた。

基準は30分だ。

最後の活動から30分以内
-> 同じセッション

30分を超える
-> 新しいセッション

これでサイドバーの今日/今月/全体の訪問数はpage viewより揺れにくくなる。逆に記事別閲覧数は今まで通りpage path基準で増える。

多言語ページも同じ原則だ。

/daily-review/.../と/en/daily-review/.../は同じ記事の別言語版だ。閲覧数keyはcanonical pathに合わせ、同じセッション内で言語を切り替えても訪問数を増やさない。

ダッシュボードを表に近づけた

最初の統計ページはKPIカードと棒リスト中心だった。

悪くはなかったが、訪問と閲覧数を同時に見せると構造が曖昧になった。カードが増えるとモバイルで長くなり、どの数字がどの期間の訪問で、どれが閲覧数なのか一目で見えにくかった。

そこで上部の比較領域を表に近づけた。

期間        訪問        閲覧数
選択期間    n           n
今日        n           n
今月        n           n
全体        n           n

全体も2行に分けた。

全体
-> 2026/06/09以降の直接集計

全体
-> 2026/06/09以前の統計を含む

この2つは意味が違う。

直接集計は、公開可能なdimensionがD1に積まれ始めた後の値だ。以前の統計を含む値はGA baselineを足した公開総計だ。1行に混ぜると数字は大きく見えるが、詳細dimensionとは合わない。

だから説明文も分けた。

訪問: 30分以内の再訪問を除外。閲覧数: ページが開かれた回数。
直接集計は2026/06/09から。

直接期間入力を扱いやすくした

統計ページでは日付をよく変える。

最初はrange=today、range=month、range=total、range=customボタンだけで十分だと思っていた。でも直接期間を見るには開始日と終了日を何度も直す必要がある。

そこで入力を少し道具らしくした。

YYYY/MM/DD表示
隠しdate picker
年/月/日のsegment選択
ArrowUp / ArrowDownで日付調整
マウスwheelで日付調整
開始日と終了日の範囲clamp

見た目は小さな入力2つだが、日付変更のストレスはかなり減った。

customボタンを押したときだけ期間入力を見せる方式もやめた。日付入力は常に表示し、presetボタンを押すとその期間に合わせて日付が動く。

その方が予測しやすかった。

詳細dimensionはタブに分けた

詳細dimensionを全部展開すると散らかる。

ページ、訪問者環境、流入、地域/言語はどれも必要だが、一画面に全部並べると読みづらい。だからタブに分けた。

ページ
訪問者環境
流入
地域/言語

ページpathは長くなりやすいので、labelにtitleを入れ、折り返しや省略でレイアウトが壊れないようにした。/で始まるpage dimension値はリンクにした。

目標は派手なdashboardではなかった。

スマホで開いても、どの記事が読まれているか、今日の訪問がいくつか、閲覧数がどれくらいかをすぐ見られればよかった。

多言語ラベルも合わせた

統計ページは韓国語だけではない。

/en/analytics/、/ja/analytics/、/zh-Hans/analytics/などのactive localeページがある。だから「訪問」「閲覧数」「30分セッション」「GA閲覧数 + D1」のようなラベルも各localeのfront matterに合わせた。

ここを抜かすと、構造は変わっても他言語ページに古い文言が残る。

多言語ブログでは、機能を1つ直すときページ1つだけを直すわけではない。同じ画面が複数localeにあるので、ラベルの意味も一緒に動かす必要がある。

確認したこと

主にレンダリングと数字の意味を確認した。

node --check cloudflare/ga-stats-worker.js
node --check assets/js/custom/analytics-dashboard.js
node --check assets/js/custom/visitor-stats.js
bundle exec jekyll build
Cloudflare Worker deploy
GitHub Pages deploy

確認基準はこうだった。

サイドバーはsessionsを訪問として表示するか
記事別閲覧数はpage viewを維持するか
全体訪問と全体閲覧数が別baselineを使うか
直接集計全体とGA込み全体が分かれているか
直接期間入力がtoday/month/total presetと衝突しないか
モバイルで期間/訪問/閲覧数の表が横にはみ出さないか

この作業のあと、統計ページは前より静かになった。

数字は増えたが、むしろ迷いにくい。訪問は訪問で、閲覧数は閲覧数だ。全体は全体でも、直接集計全体と過去込み全体は違う。

重要なのは数字を大きく見せることではなかった。

それぞれの数字が何を意味するのかを隠さないことだった。