1店舗なら、GA4を開いて数字を見る。
10店舗なら、Spreadsheetへ貼り付けて何とかする。
では、1,000店舗を超えたらどうするか。
私は現在、1,000店舗を超える小売サイトのアクセスデータを、キャンペーン単位で定例集計しています。
必要なのは、店舗ごとのユーザー、セッション、PV。さらに流入をアプリ、Googleビジネスプロフィール、その他などへ分類し、最終的には店舗別に比較できる形へまとめることです。
GA4 Data APIやGASを使えば自動化できます。
でも、実際にやってみて一番難しかったのはAPIではありませんでした。
「毎月、同じ意味の数字を作る」ためのルールを固定すること。
大量データの集計では、コードより集計仕様の方が重要です。
元になるデータは、GA4だけではない
この集計では、GA4の数字だけ見ても完成しません。
大きく3種類のデータを組み合わせます。
店舗マスター
店舗IDと店舗名など、対象店舗の基準になるデータです。
施策対象リスト
今回どの店舗で、どの施策を実施しているかを確認します。
GA4データ
Data APIで、対象URL・期間・指標・流入元などを取得します。
この3つを照合して初めて、
「対象1,100店舗超について、施策期間中のアクセスを同じ定義で集計する」
ことができます。
APIから数字が取れた＝集計完了、ではありません。
自動化する前に、集計仕様を文章にする
私はまず、コードを書く前に次を決めます。
- 対象URLの規則
- 除外URL
- 対象期間
- 店舗IDの取り方
- 対象店舗の確定方法
- users / sessions / viewsの定義
- source / mediumの分類
- 欠損時の扱い
(other)やデータ品質の確認方法
ここが曖昧なままGASを書くと、間違った数字を高速で作る仕組みができます。
自動化の前に、「この条件なら今月も来月も同じ数字になる」と説明できる状態にします。
最終表は、こんな形になる
実際の納品形式は案件に合わせますが、構造としてはたとえば次のようになります。
| store_id | store_name | app users | app sessions | app views | GBP users | GBP sessions | GBP views | other users | … |
|---|---|---|---|---|---|---|---|---|---|
| 0001 | 店舗A | 120 | 145 | 180 | 32 | 38 | 45 | 18 | … |
| 0002 | 店舗B | 98 | 110 | 150 | 25 | 28 | 35 | 12 | … |
クライアントが欲しいのはAPIレスポンスではありません。
店舗ごとに比較し、異常や傾向を確認できる形です。
だから、取得用の形と、読むための形を分けます。
Raw → Clean → Calc → Pivot → Final に分ける
定例集計のSpreadsheetは、役割ごとに分けています。
Raw
APIから取得した元データ。
原則、人が直接編集しません。
Clean
店舗ID、URL、source / mediumなどを揃えます。
Calc
業務上必要なカテゴリへ再分類したり、計算列を作ったりします。
Pivot
店舗×流入カテゴリのように、確認しやすい形へ変換します。
Final
提出用です。
この分離のメリットは、どこで数字が変わったか追えることです。
Finalの数字がおかしければ、Pivot、Calc、Clean、Rawと戻れます。
一枚のシートにすべての数式を詰め込むより、検証しやすくなります。
source / mediumを、そのまま提出しない
GA4から取れるsource / mediumは、分析には必要ですが、そのままでは業務上読みにくいことがあります。
たとえばレポートでは、
- app
- GBP
- other
の3分類で十分でも、元データには複数のsource / mediumがあります。
そこで、
apps / chirashi → appGoogleビジネスプロフィール由来の条件 → GBPそれ以外 → other
のように、集計ルールを定義します。
重要なのは、分類そのものより、後から同じルールを再現できるように残すことです。
1,000店舗あると「1件のミス」が見えなくなる
少数店舗なら、数字を見て「この店だけゼロなのはおかしい」と気づけます。
1,000店舗を超えると、異常が埋もれます。
そこで、毎回いくつかの検算を入れます。
- 対象店舗数はマスターと一致するか
- 対象なのにデータ0の店舗は何件か
- マスターにないstore_idが紛れていないか
- 想定外のsource / mediumが増えていないか
- 全体PVと店舗別集計の規模感が大きくズレていないか
(other)が出ていないか- サンプリングやデータ品質の注意表示はないか
自動化したから確認しないではなく、自動化したからこそ確認項目も固定するという考え方です。
「最大PV/分」を調べたとき、取得条件の違いも問題になった
別の分析では、施策期間中のアクセス集中を調べるため、1分単位の最大PVを確認しました。
単日条件では最大22PV/分。
複数日をまとめた取得では最大30PV/分という結果が出て、データ品質の状態も異なりました。
このとき大事だったのは、「22と30、どちらが本物？」と決めることではなく、
期間・粒度・取得条件に加え、サンプリングや(other)などデータ品質の状態を揃えて比較する必要があると確認したことです。
大量データでは、クエリ範囲や粒度によってサンプリング等の処理条件が変わり、表示結果に差が生じる場合があります。
条件変更は、コードではなく「仕様変更」として残す
実務では、途中で条件が変わります。
「この流入だけ対象にしたい」
「やっぱり元のルールへ戻したい」
「来月から対象URLが変わる」
普通にあります。
ここでスクリプトだけ修正すると、半年後に、
「なぜ8月だけ数字が違う？」
となります。
だから私は、
- 変更日
- 変更内容
- 変更理由
- 適用開始月
を履歴として残します。
集計ロジックはコードではなく、分析仕様の一部です。
ユーザー数の合計は、別途考える
店舗別ユーザーを足しても、サイト全体のユーザー数とは一致しません。
同じ人が複数店舗を見ていれば、店舗ごとに重複するからです。
つまり最終表を作るとき、
「各店舗UsersのSUM」
と
「対象店舗全体のUnique users」
は別の数字です。
このような指標の性質まで考えないと、きれいな表なのに意味が違うレポートができあがります。
自動化の価値は「時短」より「再現性」
Data APIやGASを使えば、もちろん作業時間は減ります。
でも、私が一番価値を感じているのはそこではありません。
先月はAさんがこの条件で集計。
今月はBさんが別のフィルタ。
来月は前月ファイルをコピーして一部だけ修正。
手作業だと、こういうズレが起こります。
仕組みにすると、
毎月、同じ条件で、同じ加工をして、同じ確認をする
状態を作れます。
これは時短より、比較可能性の問題です。
自動化して、人が「読む」時間を残す
最終的にやりたいのは、Spreadsheetを完成させることではありません。
なぜこの店舗だけ伸びたのか。
設置施策との関係はありそうか。
異常値ではないか。
前月と比較して何が変わったか。
そこを人が考えることです。
機械に任せたいのは、毎月同じルールで数字を作るところ。
人が時間を使いたいのは、その数字から次の判断をするところ。
1,000店舗を超える集計を続ける中で、私の中ではこの分担がかなり明確になりました。
関連する知見
レポート自動化だけでなく、集計仕様・検算・判断できる形まで設計します。
