BigQuery on Marketechlabo

GA4の計測検証をBigQueryを使って行う

Wed, 06 Jan 2021 00:00:00 +0900

GA4の計測の検証はBigQueryエクスポートを使って行うのが普通になる。検証の方法にはいくつかあるのだが、ほかの方法だと欠点がある。リアルタイムレポートではイベントが発生し、パラメータに値が入ってきているのはわかるが、どのイベントでどのパラメータの値が入っているかまではわからない。DebugViewは有効化しないと使えない。

BigQueryエクスポートを使うとすべてのサイト訪問に対して計測して数分以内には各パケット（イベント）でどのパラメータにどの値が入っているかがわかるし、詳細な検証ができる。 GA4のBigQueryデータはパラメータやユーザープロパティがネストされているため、クエリでは毎回それをフラット化する手続きをする必要があり、やや面倒。検証の目的に合わせて使うクエリがパターン化されるのでこの記事ではそれを紹介する。

検証用のおすすめ設定

ログのストリーミング出力設定

GA4のBigQueryエクスポート設定でログ出力をストリーミングにする。これを有効にすることでイベント発生から数分以内にログがBigQueryに取り込まれる。この指定をしないと1日1回しかデータが取り込まれず、翌日の朝にならないと検証ができない。設定方法は以下の「頻度」の「ストリーミング」のチェックを入れる。

計測のバージョン番号をパラメータ設定する

送信する変数（イベントパラメータ、ユーザープロパティ）をバージョン管理するといい。 イベントパラメータに現在の設定のバージョン番号を記録し、全イベントでそれを送る。 GTMで送信するパラメータ／ユーザープロパティを変更する都度、バージョンを更新する。計測された値がどの設定によるものなのか、簡単に照合できる。

全イベントで共通して送るのでイベントタグでなく設定タグに入れておく。

計測バージョン番号の確認

各計測バージョンがいつからいつまで計測されていたのか、計測されたイベントの数（行数）を確認する

select
 p.value.string_value v_name,
 min(timestamp_micros(event_timestamp)) min_time,
 max(timestamp_micros(event_timestamp)) max_time,
 count(0) n_events
from `prj.analytics_99999999.events_*` t1, unnest(event_params) p
where p.key = 'config_version'
group by 1
order by 2 desc

ページビューIDについて

同じページビューで発生したイベントをグルーピングするためのIDとして、GA4のBigQueryエクスポートにはbatch_page_idが含まれている。同じページビューで発生したイベントはこの値が同じになるため、「あるページでバナーを閲覧→そのバナーをクリックした」などの行動を把握できる。

以前はカスタムのページビューIDをGTMで設定する必要があったが、batch_page_idがデフォルトで計測されるようになったため、通常はこちらを使えばよい。

ページの読み込み開始タイムスタンプをパラメータ設定する

ページの読み込み開始からイベント発生までどのくらい時間が経過したのか、検証の観点からもユーザ行動把握の観点からも必要である。イベント発生のタイムスタンプは常に計測される（event_timestamp）が、経過時間の起点としてページの読み込み開始タイムスタンプをイベントパラメータに入れておくと、その差分からイベント発生までにかかった時間がわかる。

ブラウザに格納されているページの読み込み処理のタイムスタンプにはいろいろ候補があるが、Navigation Timing API Level 2のPerformanceNavigationTimingを使うのがよい。

function(){
 var entries = performance.getEntriesByType('navigation');
 if (entries.length > 0) {
 return Math.round(entries[0].startTime + performance.timeOrigin);
 }
 return null;
}

そのままGTMのカスタムJavaScript変数として登録すればいい。

計測されているパラメータ数を見る

イベントごとに計測されているパラメータの種類を一覧にする

select
 event_name,
 p.key key,
 count(0) cnt
from `prj.analytics_99999999.events_*`, unnest(event_params) p
group by 1,2
order by 1,2
;

Google BigQueryでお手軽機械学習（BQML）

Mon, 18 Jan 2021 00:00:00 +0900

BigQuery MLは生成AI（Geminiなど）との連携やVertex AI統合など多様な機能を提供しているが、企業の日常業務で扱う構造化データ（売上、顧客、在庫など）の予測分析において、最もコストパフォーマンスが高く実用的な手法は依然として勾配ブースティング木（XGBoost系）である。この記事では、SQLだけで完結するMLパイプラインの構築方法を実例とともに解説する。

BigQuery ML（BQML）では以下のモデルが使える：

線形回帰 - 類似のリモートデータでトレーニングされたモデルを使用して、新しいデータの数値指標の値を予測する。ラベルは実数で、正の無限大、負の無限大、NaN（非数値）にはできない。
ロジスティック回帰 - 入力がlow-value、medium-value、high-valueのいずれであるかなど、2つ以上の有効な値を分類する場合に使用する。ラベルには最大50個の一意の値を指定できる。
K平均法クラスタリング - データセグメンテーションに使用する。顧客セグメントの識別などに使える。教師なし学習なのでモデルのトレーニングを行う際にラベルは必要なく、トレーニングや評価用にデータの分割を行う必要もない。
行列分解 - 商品のレコメンデーションシステムの作成に使用する。過去の顧客行動、トランザクション、商品評価を使用して商品のおすすめを作成し、これらのレコメンデーションを使用してカスタマイズされたカスタマーエクスペリエンスを提供できる。
主成分分析（PCA） - 主成分を計算し、それらを使用してデータに基底変換を実行するプロセス。一般に、データのバリエーションをできるだけ多く保持しながら、各データポイントを最初のいくつかの主成分にのみ射影して低次元のデータを取得することで、次元数を削減するために使用される。
時系列 - 時系列予測と異常検出に使用する。ARIMA_PLUSモデルとARIMA_PLUS_XREGモデルは、複数のチューニングオプションを提供し、異常値、季節性、休日を自動で処理する。
ディープニューラルネットワーク（DNN） - 分類モデルと回帰モデル用にTensorFlowベースのディープニューラルネットワークを構築する。
ワイド＆ディープ - レコメンデーションシステム、検索、ランキングに関する問題など、スパース入力による大規模な回帰と分類問題（多くの特徴値を持つカテゴリ特徴）に役立つ。
オートエンコーダ - スパースデータ表現をサポートするTensorFlowベースのモデルを作成する。BigQuery MLのモデルは、教師なし異常検出や非線形次元削減などのタスクに使用できる。
ブーストツリー - XGBoostに基づく分類モデルと回帰モデルを作成する。
ランダムフォレスト - トレーニング時の分類、回帰、その他のタスク用に、複数の学習方法のディシジョンツリーを構築するために使用する。
AutoML - 表形式データの分類モデルと回帰モデルを高速かつ大規模に構築してデプロイする教師ありMLサービス。

当初は線形回帰とロジスティック回帰だけだったが今では実用的な手法が増えた。何よりもXGBoostが使えるようになったのが大きい。

XGBoostのメリット

XGBoostは語弊を恐れずに言うと特に何も考えなくてもそれなりの精度が出る、素人でもそこそこのアウトプットを出せてしまう手法である。これまでの線形回帰やロジスティック回帰は前提条件が扱いが難しい手法だった。

XGBoostがお手軽というのは、

正規化不要
カテゴリ変数と連続量を意識しなくてもいい
欠損値があってもいい

つまり特徴量の前処理の面倒な部分がかなり軽減されている。与えられた変数を特に加工しなくても使える。XGBoostはそういったことが不要な、お手軽で大変便利な手法である。

この記事ではBigQueryでお手軽に機械学習を体感してみようということで、XGBoostを使ってBQMLを説明する。

方法

データセットの準備

対象データは学習（train）／評価（evaluate/validate）／テストで予測するデータに分割する。目的変数と説明変数に加え、分割用の列subsetを作り

subset = 'TRAIN': 学習用データ
subset = 'EVALUATE': 評価用データ
subset = 'TEST': 予測用データ

という値を付与しておく。今回はBigQueryの公開サンプルデータであるbigquery-public-data.ml_datasets.ulb_fraud_detectionを使って不正取引の予測をするモデルを作る。

Classが目的変数となる不正取引フラグ
特徴量はV1～V28とAmount（取引額）。V1～V28はオリジナルの特徴量を主成分分析で集約したもの
これを学習：評価：テスト＝8:1:1で分割する

create or replace table `my-project.test_dataset.ulb_fraud_detection` as
with t1 as (
 select
 row_number() over() id,
 *,
 rand() rnd
 from `bigquery-public-data.ml_datasets.ulb_fraud_detection`
), t2 as (
 select
 * except(rnd),
 case
 when rnd < 0.8 then 'TRAIN'
 when rnd < 0.9 then 'EVALUATE'
 else 'TEST'
 end subset
 from t1
)
select * from t2 order by id;

BQMLの機械学習手順

まずBQMLの操作手順だが、機械学習の手順に沿い

Googleアナリティクス4のBigQueryエクスポート仕様

Thu, 11 Mar 2021 00:00:00 +0900

GA4のBigQueryエクスポートの仕様とデータの扱い方を説明する。GA4のログはネストされたレコードなど特殊な形式になっており、そのままでは扱いにくいのでいくつかテクニックがある。

BigQueryへのエクスポート設定

GA4の管理画面で設定するが、手順はこちらの記事を参照。 https://www.marketechlabo.com/ga-app-web-property-to-bigquery/

テーブルの場所

プロジェクト：GA4のBigQueryエクスポート設定で指定したプロジェクト
データセット「analytics_999999999」（「999999999」の部分はプロパティID）
テーブル名
- 前日までのデータ（日付別に）「events_20210101」
  - 「20210101」の部分は日付
  - GA4のBigQueryエクスポート設定画面の「エクスポートタイプ」で「毎日」のチェックを入れている場合に出力される
- 今日のデータ、前日未集計分のデータ「events_intraday_20210102」
  - 「20210102」の部分は日付
  - エクスポートタイプ設定で「ストリーミング」のチェックを入れている場合に出力される
  - 「ストリーミング」と「毎日」を両方オンにしている場合は毎日のテーブルが生成されるとこのテーブルが削除される

出力時刻は午前7-9時ごろ。レポートのタイムゾーンに依存するため、米国のままにしていると夜11時ごろに出力される。GA4ではなくFirebase Analyticsの場合はUTC。タイムゾーン設定がない。

日付でシャーディングされたテーブル

GA4のBigQueryエクスポートでは日単位でテーブルが分かれている。

前日まで：events_20210101, events_20210102, …, events_20210127
当日：events_intraday_20210128

このように一つの内容（エンティティ）を表すテーブルを実体としては異なる複数のテーブルに分けて分散格納することをシャーディング（sharding）という。BigQueryでは共通の接頭辞で、末尾が_YYYYMMDD形式の日付で異なる名前のシャーディングテーブルはウェブ画面上では一つのテーブルであるかのようにまとめて表示される。

シャーディングされたテーブル群ではクエリをかける際、日単位で対象のテーブルを絞り込めばメモリの節約ができる。またクエリでも以下のようにfrom句でテーブル名を指定する際にワイルドカード*を付けると、そのワイルドカード条件にマッチするテーブル名、つまり前方一致でマッチするテーブル名のすべてを対象にできる。

select
 ...
from
 `prj.analytics_999999999.events_*`

そしてwhere句で_table_suffixを使ってワイルドカードの部分の文字列を指定することができる。

select
 ...
from
 `prj.analytics_999999999.events_*`
where
 _table_suffix between '20210101' and '20210110';

上はテーブル名末尾の日付文字列部分が20210101から20210110の間（2021年1月1日から2021年1月10日までのログ）を対象にしたクエリだが、結果は以下と同じ。

select ... from `prj.analytics_999999999.events_20210101`
union all
select ... from `prj.analytics_999999999.events_20210102`
union all
 :
select ... from `prj.analytics_999999999.events_20210110`

_table_suffixはアスタリスクの部分にマッチする文字列を表す。つまり下の2つのfromは同じものを意味する。

from `prj.analytics_999999999.events_*` where _TABLE_SUFFIX = '20210101'

from `prj.analytics_999999999.events_20210101`

_table_suffixを指定してクエリ対象のテーブルを絞り込むことによって、処理するデータ量つまりクエリコストの節約ができる。単純にfromでワイルドカードを指定したまま_table_suffixを使った絞り込みを行わないと全期間のテーブルがクエリの対象になり、そのデータサイズに対して課金される。クエリを実行する際は必ず_table_suffixで期間を絞り込もう。

一方でパーティショニングも同様にデータを分けて格納しているが、テーブルの実体としては一つである。シャーディングもパーティショニングもクエリを実行する際、日付単位で対象のテーブルを絞り込めばメモリの節約ができる。

なおシャーディングテーブルは基本的に同じ列構成になるのだが、GA4の場合、同じシャーディングテーブル群であってもある日を境に列が追加されることがある。その場合select *をすると列が一致しないというエラーが発生するので、列名もワイルドカードではなく個別に指定しなければならない。

主な項目

GA4のログは1行1イベントを表す履歴データである。1行の中にネストされたデータ構造を持つ列もある。

ユーザー
- ユーザー識別子
- ユーザープロパティ: user_properties.***
イベント
- イベント名: event_name
- タイムスタンプ: event_timestamp
- バッチ処理関連
  - ページビューの識別子: batch_page_id
  - 同一ページ内での何番目の計測パケット送信なのか: batch_ordering_id
  - 同じ計測パケットの中でのイベントの順序: batch_event_index
- イベントパラメータ: event_params.***
トラフィック
- ユーザーの最初の流入元: traffic_source.***
- 各イベント行における流入元: collected_traffic_source.***
- セッションの流入元: session_traffic_source_last_click.***
デバイス関連: device.***
地域: geo.***
eコマース関連変数
- 取引に関する情報: ecommerce.***
- 商品に関する情報: items.***
同意関連: privacy_info.***
ストリームID: stream_id（ウェブ、アプリなど1つのGA4プロパティで複数のストリームがある場合に識別する）

ユーザー

ユーザの識別子として2種類の列がある。

GA4無料版と有料版のBigQueryエクスポートの違い

Wed, 23 Mar 2022 00:00:00 +0900

2種類のBigQueryエクスポート

GA4のBigQueryエクスポートデータには以下の2種類がある。

イベントデータ
ユーザーデータ

ユーザーデータは1行1人で、user_pseudo_id単位で集約したデータと、user_id単位で集約したデータのそれぞれのテーブルが生成される。所属するオーディエンスの情報やユーザ（user_pseudo_id / user_id）単位の通算指標が含まれる。分析によく使うのがイベントデータで、1行1イベントでイベントパラメータなどがネストされて含まれている。

エクスポートの頻度

イベントデータの出力頻度は以下の3種類がある。

ストリーミング＝リアルタイム。重複や使えない列あり（トラフィック関連の列）
毎日→翌日に、前日分をまとめて、重複除外処理やトラフィック情報のアトリビューション処理済みの形で出力される
毎日（高頻度）＝「毎日」のデータを当日高頻度で出力する。「ストリーミング」と「毎日」の中間だが、トラフィック関連の列は出力される

これらは設定画面の「頻度」に対応している。

この中で「毎日（高頻度）」は有料版限定のオプションになる（無料版の管理画面では選択肢が表示されない）。

ストリーミングデータの問題点

ストリーミングデータでは重複や欠損の行が一部含まれる可能性があるのと、流入元アトリビューション処理ができておらず、traffic_source.***列とsession_traffic_source_last_click.***が欠損して出力される。 https://support.google.com/analytics/answer/9358801

このテーブルには、その日に発生したセッション アクティビティのレコードが保持されます。ストリーミング エクスポートはベスト エフォート型の処理であり、イベントの遅れやアップロードの失敗などにより、データに漏れが生じる場合もあります。データは 1 日を通して継続的にエクスポートされます。セッションが複数のエクスポート周期にまたがっていると、テーブルにはそのセッションのレコードが複数保存されることがあります。
BigQuery のストリーミング エクスポートには、新規ユーザーについては次のユーザー アトリビューション データは含まれません。
traffic_source.name（レポート ディメンション: ユーザーのキャンペーン）
traffic_source.source（レポート ディメンション: ユーザーの参照元）
traffic_source.medium（レポート ディメンション: ユーザーのメディア）

1日1回の再計算の中ではこれらを処理し、より正確なデータを生成しなおす。より正確なデータや、Googleのアトリビューションと同じロジックの流入元データtraffic_source.***（「ユーザーの参照元」など）とsession_traffic_source_last_click.***（「セッションの参照元」など）の情報が欲しければ毎日のデータを使う必要がある。

BigQueryエクスポート設定のパターンと出力されるテーブル

BiqQueryエクスポート設定では2個のチェックボックスがあった。2個のいずれかを選択するのではなく、それぞれチェックを入れる形式である。つまり以下の3パターンの出力設定がある。

ニアリアルタイムのデータのみ
1日1回再計算データのみ
ニアリアルタイム＋1日1回再計算

それぞれについて生成されるテーブル名を見ていく。まず**データセット名はいずれもanalytics_計測ID**となる

ニアリアルタイムデータのみ

生成されるテーブル名

events_intraday_YYYYMMDD

（YYYYMMDDの部分は毎日の日付が入る）（例）

2022年3月1日の日中は
- events_intraday_20220301: 2022年3月1日のリアルタイムデータ
2022年3月2日の日中は
- events_intraday_20220301: 2022年3月1日の全データ（不完全かも）
- events_intraday_20220302: 2022年3月2日のリアルタイムデータ
2022年3月3日の日中は
- events_intraday_20220301: 2022年3月1日の全データ（不完全かも）
- events_intraday_20220302: 2022年3月2日の全データ（不完全かも）
- events_intraday_20220303: 2022年3月3日のリアルタイムデータ

というテーブルが存在することになる。

GA4/Firebaseのログをフラット化する汎用クエリ

Thu, 27 Jan 2022 00:00:00 +0900

GA4（Firebase）のログを扱う際、ネストされているイベントパラメータやユーザープロパティをフラット化しないと使いにくい。ところが格納されているパラメータやプロパティは決まっているわけではないため、通常はそれをハードコーディングで指定することが多い。つまり使用しているパラメータやプロパティに応じてその都度クエリを手動作成することになる。しかしそれでは面倒なので、どんなイベントパラメータやユーザープロパティを使っていても、それがどんな型であっても、オールマイティにフラット化するクエリを作る。存在するパラメータやプロパティに基づいて動的にクエリを作って実行する。このクエリひとつあればどんなケースにも対応できる、汎用的なものである。

イベントパラメータ（ユーザープロパティ）名を使った動的クエリ

フラット化の詳細はこちらを参照。 https://www.marketechlabo.com/ga4-bigquery-export-spec/

たとえばネストされたイベントパラメータga_session_id（整数型）とpage_location（文字列型）をフラット化するクエリは

select
 user_pseudo_id,
 event_name,
 (select p.value.int_value from unnest(event_params) p where p.key = "ga_session_id") ga_session_id,
 (select p.value.string_value from unnest(event_params) p where p.key = "page_location") page_location
from `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`;

なおこの記事ではGoogleが公開しているサンプルデータセットbigquery-public-data.ga4_obfuscated_sample_ecommerceを使っている。実際のプロジェクトでは自身のプロジェクトとデータセットに差し替えること。

この中で動的になるのは以下の部分

(select p.value.【動的：型】 from unnest(event_params) p where p.key = "【動的：パラメータ名】") 【動的：パラメータ名】,

ここに入る値は

ga_session_idの場合、p.value.int_valueと"ga_session_id"
page_locationの場合、p.value.string_valueと"page_location"

である。なおBigQueryではマルチバイト文字を列名にする際はバッククォートで囲む必要があり、列名の部分に日本語がある場合バッククォートを入れないとエラーになる。動的に実行する場合はパラメータ名をそのまま列名にすることになるため、パラメータ名に日本語を入れると不都合である。このような動的処理をすることを踏まえるとパラメータ名には日本語を使わないほうがいい。

イベントパラメータではなくユーザープロパティの場合も同様にできる。つまり

イベントパラメータ（ユーザープロパティ）名と型の一覧を取得し、ループで文字列として代入し、SQL文を生成する
そのSQL文をクエリとして実行する

ことが求められる。

同じイベントパラメータに複数の型が混在する対策

変数の型によって格納されるカラムは異なる。

変数の型	列名
`string`	`event_params.value.string_value`
`int64`	`event_params.value.int_value`
`float64`	`event_params.value.double_value`

（タイムスタンプやdateなど、これ以外の型はイベントパラメータでは扱われない）

同じパラメータに複数の型が混在するケースがある。例えば16進数として生成された値では、たまたま数字だけで構成された値は整数（int64）になるし、A-Fの文字が入ると文字列（string）になる。それぞれp.value.int_valueとp.value.string_valueという別の列に格納される。つまりそれぞれの列から値を取得することになる。

さらに出力を「1パラメータ＝1列」として格納するため型を合わせる（キャスト）必要がある。

select
 user_pseudo_id,
 event_name,
 (select
 case
 when p.value.string_value is not null then safe_cast(p.value.string_value as string)
 when p.value.int_value is not null then safe_cast(p.value.int_value as string)
 when p.value.double_value is not null then safe_cast(p.value.double_value as string)
 else null
 end
 from unnest(event_params) p where p.key = "param1") param1
from `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`;

ところがどの型にキャストすればいいのかが問題になるが、

ウェブログからSQLで指標を計算する8構文～GA4のBigQueryを題材に

Thu, 05 Nov 2020 00:00:00 +0900

Googleアナリティクス4プロパティが登場し、誰でもBigQueryにログを出力できるようになった。ログ分析を始める環境は揃ったわけだが、ログ分析のノウハウはあまり世に出ていない。SQLを使ってこれらを分析する方法を少し紹介する。どんな高度なログ分析をするにしても、これが基本となる。

ウェブ分析の指標

ウェブ分析の基本は

ページビュー数
セッション数
人数

のカウントである。複雑な分析も、結局カウントしているのはこの3つの指標に集約されることが多い。Eコマースになると購入金額の合計なども入ってくることはある。

そしてこれに「○○した」という条件が付いて

イベント○○が発生した回数
- ○○したページビュー数
  - パラメータ△△の値が□□だったイベント○○が発生した回数（ページ□□のページビュー数）
○○したセッション数
○○した人数

をひたすらカウントする。たとえば

資料ダウンロードボタンをクリックした回数
80％以上スクロールしたページビュー数
自然検索から流入したセッション数
コンバージョン完了ページを見た人数

である。これらもページビュー数／セッション数／PV数のカウントであるのは同じで、「○○した」条件に絞り込んでカウントしているだけである。

そして絶対数だけでなく率の指標

○○したセッション率（セッション単位CVRなど）
○○した人数率（ユーザ単位CVRなど）

を計算して歩留まりを見る。これにさまざまなディメンションをかけて比較するだけで、見ている指標はほとんどこれだけなのである。

指標をBigQueryからSQLで計算する

無条件の単純なページビュー数／セッション数／人数のカウント

GA4に限らずログ分析の原則として、1行1ページビューになっていればページビュー数は行数のカウント

COUNT(ユーザID)

セッション数はユニークなセッションIDの数のカウント

COUNT(DISTINCT セッションID)

ユーザ数はユニークなユーザIDの数のカウント

COUNT(DISTINCT ユーザID)

となる。

GA4の形式の場合、ページビュー数（ページビューイベントが発生した回数）

SELECT
 COUNT(
 CASE
 WHEN event_name = 'page_view' THEN user_pseudo_id
 ELSE NULL
 END
 ) AS n_pageviews
FROM
 `prj.analytics_999999999.events_*`;

event_name = 'page_view'である行数をカウントする。

総人数

SELECT
 COUNT(
 DISTINCT user_pseudo_id
 ) n_visitors
FROM
 `prj.analytics_999999999.events_*`;

ユーザを特定する列user_pseudo_id（明示的にSDK内でユーザーIDを設定している場合はuser_idを使う。いずれも文字列型）があるので、これをユニークカウントする。

総セッション数

SELECT
 COUNT(DISTINCT
 CONCAT(
 user_pseudo_id,
 '-',
 CAST(
 (SELECT ep.value.int_value FROM UNNEST(event_params) ep WHERE ep.key = 'ga_session_id') AS string
 )
 )
 ) AS n_sessions
FROM
 `prj.analytics_999999999.events_*`;

GA4の仕様で、単体でユニークなセッションを特定するIDを指す列はない。ユーザごとのセッションを特定する（あくまでユーザ内なのでグローバルにセッションを特定できるわけではない）変数がページビューイベントのパラメータga_session_id（整数型）になる。