|
2023年7月1日のUA (Universal Analytics)終了*1に備えて、GA4 (Google Analytics 4)への移行が進んでいる。
- セッションに基づく分析から、ユーザーに基づく分析へ
- イベント単位の分析へ
といった情報が、Googleを代弁するかのように発信され続けている。
単一のユーザーがPCからスマートフォンまで、多彩な端末を使用する現在、アクセス解析にこのような大規模な変化をもたらすことは、長期的な視点ではwebをより良くするものであり、必要とされる変化である、とGoogleは考えているのかもしれない。
あるいは、このようにも考えられる。もはやセッションに基づいたデータ集計と統計情報はGoogleにとっては重要ではなく、ユーザーに基づいたデータ集計と統計情報を必要としている。だから、そのような情報を収集できるようにGA4を開発し、半ば強いるかのように、それをユーザーに使わせることで、Googleは目的としている情報を得る。
いずれにせよ、私にとっては大きなお世話なのだ。もちろん、このサイトにGA4は導入済みだが、それは数か月、1年単位の集計、分析にこそ有意義であれ、日々の状態確認、
- 今日、どのようなサイトからリンクされた
- 今日、どのようなサイトからアクセスされた
- 今日、どのようなページがアクセスを集めている
このような、特に”今日”にフォーカスした集計を確認するのに、GA4は全く向いていない。「できない」と言っても過言ではないほどだ。
データ集計が追いついていないのだろう。作成したレポート*2を参照したところで、翌朝7時に「昨日」のレポートすら表示できないのだ。
そこで試してみたのがumami*3だった。特に次の観点から、先述の欲求を満たすのに適したアクセス解析ツールだ。とても使い心地が良い。
friendlier, privacy-focused alternative to Google Analytics
Umami collects only the metrics you care about and everything fits on a single page
この投稿では、Herokuの無料枠を利用してumamiをホストするための手順を紹介する。
前提
この投稿で紹介する手順は、umamiのインストール文書に掲載されている「Running on Heroku」*4を改変したものだ。一部の作業内容、順序が異なっている。
本来であれば、インストール文書に掲載されている「Deploy to Heroku」が機能する。それが機能しなかったために手動対応した過程を、この投稿では説明している。
最初は「Deploy to Heroku」を試し、それが機能しなかった前提で、この投稿で紹介する手順を試してほしい。
ここで紹介する手順は、次の環境が整っていることを前提としている。この投稿では、これらについて説明しないので、各自で対応してほしい。
手順
Heroku - PostgresSQL
データベース作成
次にumami用のデータベースを設定する。次の操作で”Heroku Postgres”を導入する。”Plan name”では”Hobby Dev - Free”を選択する。
Overview > Configure Add-ons
 |
 |
 |
Attached as DATA BASE > This app as DATA BASE
ここで、先に一時停止していたappの画面に戻り、umamiをデプロイする。
Manual deploy > Deploy Branch
テーブル作成
データベースに必要なテーブルを生成するためのSQLスクリプトを実行する。この操作はHeroku CLIを利用したコマンドとして実行する。そのため、PowerShellやTerminalのようなCUIを介して操作する。
まず実行するコマンドのテンプレートを紹介する。
heroku run psql -h [Host] -d [Database] -U [User] -f [File] -a [App Name]
[]で指定するパラメータを、各自の必要な値に置き換える必要がある。これらの値は、”Database Credentials”で確認できる。
Settings > Database Credentials
Credentialsの各項目、コマンド上のオプション、パラメータは、次のように対応している。
| Credentials | option | parameter |
|---|---|---|
| Host | -h | Hostに指定された値 |
| Database | -d | Databaseに指定された値 |
| User | -U | Userに指定された値 |
”File”、”App Name”は、”Database Credentials”には掲載されていない。”File”には、次に指定する値を代入する。
”App Name”は、先に対応した「Heroku - new app」で指定した名前を代入する。この投稿の添付画像では”espio999-umami”と指定されているが、実際の値は各自で異なる。
| option | parameter | |
|---|---|---|
| File | -f | sql/schema.postgresql.sql |
| App Name | -a | 「Heroku - new app」で指定した値 |
準備が整ったら、出来上がったコマンドを実行する。
コマンド実行中にパスワードを尋ねられる。それはCredentialsに記載されている”Password”の値の入力を要求されている。Herokuアカウントのパスワードではないので、勘違いしないように。
umami - 監視対象サイトの登録
ここまでの作業が完了すると、umamiが機能する。”Open app”でumamiを起動する。
初回ログインでは、次のアカウント、パスワードを使用する。これらはログイン後、任意のものへ変更することができるし、変更しておくべきだ。
|  |
監視対象となるwebサイトを登録するため、”Add website”を選択する。この投稿では、このブログを登録している。
 |
 |
さらに”Go to settings”から、監視される側のサイトへ実装する追跡コード（監視用のscriptタグ）を取得する。
 |
 |
追跡コードは、監視対象となるwebサイトやブログ内の適切な場所へ挿入する。追跡コードの挿入後のアクセスから、umamiの記録が始まる。
ダーク・テーマや、集計対象を特定期間、リアルタイムで切り替えることもできる。
|
 |
 |
umamiのデータベース
umamiのデータベースは次の5つのテーブルで構成されている。
| account | umamiのユーザーアカウント | マスター・テーブル |
| event | 監視対象イベント | マスター・テーブル |
| pageview | ページビューの記録 | |
| session | セッションの記録 | |
| website | 監視対象サイト | マスター・テーブル |
umami/schema.postgresql.sql at master · umami-software/umami · GitHub
特にpageview、sessionテーブルには、監視対象サイトへのアクセスが生じるたびに、レコードが追加されていく。
DBレコードの削除
Herokuでは、PostgresSQLの無料枠として、最大1万レコード（10000 rows）の上限が設けられている。7000レコードを超えると、Herokuから警告のメールが届く。Herokuの無料枠で運用し続ける前提では、上限に達する前に不要なレコードを削除する必要がある。
削除対象となるのはpageview、sessionテーブルのレコードだ。「テーブル作成」と同じ要領でSQLを実行する。例えば、直近1週間（7日間）のデータを残し、それ以前のデータを削除する場合、次のSQLを実行する。
delete from pageview where created_at < now() - interval '7 days'; delete from session where created_at < now() - interval '7 days';
「テーブル作成」と同じように、このようなSQLを記録したファイルを実行しても良いし、Heroku上で直接実行しても良い。その場合、「テーブル作成」とは異なり、次のように”-f”無しでログインすること。ログイン後に、先述のSQLを直接実行する。
heroku run psql -h [Host] -d [Database] -U [User] -a [App Name]
