Context
Hemisphereにアクセス解析を入れるため、Umamiを調査した。
Google Analyticsのような大きな分析基盤ではなく、軽量でプライバシー寄りのログ解析を置けるなら、Hemisphereの運用には合いそうだった。特に、NotesやArchiveにどの程度アクセスがあるのか、どの記事や導線が読まれているのかを把握できれば、今後の制作判断に使える。
一方で、Hemisphereは静的サイトとして軽く運用することを重視している。解析のためにサーバー運用やDB管理の負担が大きくなるなら、本末転倒になる。
Investigation
Umami自体は用途に合っている。
Expected role:
lightweight analytics
privacy-friendly tracking
dashboard for page views and referrers
replacement for heavy analytics toolsただし、セルフホストする場合の前提は軽くない。
公式ドキュメント上、ソースから動かす場合は Node.js 18.18 以上と PostgreSQL が必要になる。Docker Compose を使う場合も、アプリケーションと PostgreSQL を含む構成になる。
つまり、単に静的サイトにファイルを1つ追加するだけでは済まない。
Decision
現時点では、Umamiの導入を見送る。
理由は、Hemisphereの現在の運用段階に対して、必要な環境要件と保守対象が重いからである。
Deferred:
Umami self-hosting
Reasons:
requires application runtime
requires PostgreSQL
adds deployment and backup concerns
increases maintenance surfaceアクセス解析は必要だが、そのためにHemisphereの静的運用を複雑化させる段階ではない。
Reasoning
Hemisphereでは、制作ログ、Notes、Archiveをまず継続して残すことが優先である。
アクセス解析は有用だが、まだサイト規模も小さい。現段階では、正確な分析基盤よりも、記事を増やし、導線を整え、公開フローを安定させる方が重要になる。
特に、Umamiをセルフホストする場合は、次の管理が発生する。
- Node.jsアプリケーションの稼働
- PostgreSQLの運用
- 環境変数と接続情報の管理
- アップデート対応
- バックアップ
- 障害時の復旧
これらは、Hemisphereの運用に対しては負荷が高い。
Alternative
当面は、より軽い方法を検討する。
Candidates:
GitHub Pages traffic insights
server-side logs if hosting changes
Cloudflare Web Analytics
simple static beacon later
managed analytics service if neededまずは、静的サイトとしての構成を崩さずに済む選択肢を優先する。
Result
Umamiは候補から完全に外すのではなく、導入タイミングを後ろに送る。
Hemisphereが継続的に更新され、アクセス解析の必要性が実際に高くなった段階で、再度検討する。その時は、セルフホストではなく、マネージドDBやホスティングサービスを組み合わせた構成も比較する。
References
Next
次にやることは、解析基盤そのものよりも、Notes一覧と記事ページの公開フローを固めること。
アクセスを見る前に、まず見る対象を増やす。