analytics SaaS プロトタイプ

2024年12月、sandbox-analytics-saas で analytics SaaS の Remix プロトタイプを作った。自前の Web 分析（Plausible 的なやつ）を作るとしたら、という前段階の素振り。

作ったもの

核は 計測スクリプトと収集エンドポイント の2つ。

app/utils/analytics.ts に、ページに貼る用のトラッキングスクリプトを文字列で持たせた。

function track(eventName = 'pageview') {
  const event = {
    domain: location.hostname,
    url: location.href,
    referrer: document.referrer,
    event: eventName,
    screenWidth: screen.width,
    language: navigator.language,
  };
  fetch('/event', {
    method: 'POST',
    body: JSON.stringify(event),
    keepalive: true,
  });
}

• Cookie を使わない（プライバシー寄り）
• keepalive: true で離脱時でも送信が落ちにくいように
• history.pushState を上書きして SPA のページ遷移も拾う
• 収集は Remix の app/routes/event.tsx で受ける

docs/ に、20サイトまで一括比較できる構成や、Cloudflare Workers + Hono + Turso でエッジ処理する案、料金モデルまでメモしていた。プロトタイプのコードより、こっちの設計メモの方が分量があったくらい。

学び

手を動かして分かったのは、analytics は トラッキング SDK のサイズ と プライバシー（Cookie の有無） が製品の核心だということ。フレームワーク選定（Remix かどうか）はほとんど本質じゃなくて、「1KB 未満で Cookie なし」をどう守るかが勝負だった。

SPA 対応で pushState をフックする、離脱対策で keepalive を使う、あたりは小さいけど効くポイント。エッジ（Cloudflare）で受けると集計の遅延も抑えられそう、という当たりもついた。

おわり

これ自体は sandbox 止まりだけど、ここでの「軽量タグ + エッジ収集」の感触が、2025年の 2rab-analytics や Cloudflare ベースの analytics 検討へつながっていった。計測の入口を一度自分で書いておくと、既存サービスの仕様を見るときの解像度が上がる。