GA4におけるBigQuery料金の見積りと開発時のクエリコスト削減方法

Googleアナリティクス4
BigQuery

記事公開日:

GA4におけるBigQuery料金の見積りと開発時のクエリコスト削減方法

Googleアナリティクス4では、無料版であってもBigQueryを利用することができる点が大きなメリットの1つと言えます。

とはいえ、「クラウド破産」というキーワードがあるように、使い方を間違えてしまうと多額の利用料が請求されてしまいます。

本記事では、GA4におけるBigQuery料金の見積り方と、多額の請求を避けるための方法について紹介したいと思います。


BigQueryの料金計算

BigQueryの料金体系は非常に複雑ですが、基本的に「ストレージコスト」「クエリコスト」の2種類の金額がかかってくると思って良いでしょう(厳密にはストレージコストはアクティブストレージと長期保存で単価が変わってきたり、クエリコストにもオンデマンド料金と定額料金のプランがあります)。

ストレージコストは、文字通りBigQuery内に保持するデータサイズに応じて課金される費用となります。毎月10GBのストレージ分が無料枠として設定されており、10GBを超える分について、1GBあたり0.01〜0.02ドルの費用が請求されます。ストレージコストの見積りで難しい点は、BigQueryで管理するデータが日々増え続けることです。サイトのトラフィックによっては1日分のGA4のデータで1GBを超えるケースもあります。そのため、いつ時点の費用を見積もるのかが焦点となります。

クエリコストは、BigQueryで実行したSQLクエリが読み取ったデータサイズに応じて課金される費用です。BigQueryで保持しているデータがたとえ膨大であっても、SQLクエリが読み取るデータが僅かであればクエリコストを抑えることができます。毎月1TBまでの無料枠が設定されており、1TBを超える読み取りデータサイズに対して1TBあたり5ドルが請求されます。クエリコストの見積りが難しいのは、クエリを実装しないと見積ることができないことと、そのクエリの実行頻度によって左右される点です。

GA4におけるBigQuery料金の見積り方

クエリコストには、実装するSQLクエリに依存してしまうため、見積ることは難しいですが、ストレージコストについては比較的見積もりやすいです。

ストレージコストは、前述したようにBigQueryに保存するデータサイズに応じて課金が行われます。GA4データの場合、データサイズは基本的にGA4に蓄積されたイベント数に応じてほぼ比例してデータサイズが消費されます。

SEM Technologyが関わっているGA4プロパティでBigQueryにエクスポートされたデータを確認したところ、イベント数1万件あたり6〜7MBのデータサイズを消費していました。

この数値を使って、例えば自身のサイトの月間のイベント数が500万イベントであった場合、500×6〜7MBとなり、月間のストレージサイズ(増分)は3〜3.5GBと見積る形になります。

これが1年後には1年分のデータが蓄積された状態になるので、とりあえず1年後の見積りを算出するために、36〜40GBくらいのストレージを消費することを想定しておけば良いでしょう。10GBまでが無料で、それを超えた分は1GBあたり0.01〜0.02ドルの費用を要するため、40GBを想定すると、0.3〜0.6ドル/月くらいの費用が必要となります。

多額の請求を避けるための方法

ここまでで、BigQueryの料金体系についてと、GA4の場合のストレージコストの見積りについて見てきました。ここからは、BigQueryでの多額の請求を避けるためにできることについて見ていきたいと思います。ストレージコストについては、データ量を減らさない限り、節約することはできないので、以下の議論ではどのようにクエリコストを下げるかの話になります。

では見ていきましょう。

読み込む対象のテーブル・期間を減らす

読み込む期間を減らすのが真っ先に考えられることです。日常的なモニタリングであれば、過去30〜90日分程度のデータを対象とすれば十分(もしくは、昨対比較のため前年同月データも含める)です。読み込む対象のテーブル・期間を絞り込まないと、使い始めの時期は対象データの保持期間も少なくクエリコストも少なく済むかもしれませんが、だんだんとクエリコストが高くなっていってしまいます。

BigQueryのSQLでは、

SELECT
  *
FROM
  `project.analytics_0123456789.events_*`
WHERE
  _TABLE_PREFIX BETWEEN '20201001' AND '20201231'

のように、読み込むテーブル名の日付部分は、"*"としながら、WHERE句を使って、TABLEPREFIXの値で絞り込みます。 TABLEPREFIXには、テーブル名で"*"と指定した部分がそのまま反映されます。

もし、TABLEPREFIXでの絞り込みを行わないと、全テーブルのデータを読み込んでしまいます。

また、TABLEPREFIXで絞り込む期間については、上のサンプルクエリでは、固定期間としていますが、実運用上は、CURRENTDATE()関数をDATESUB()関数などを駆使して、過去3ヶ月などのようにすることになります。

読み込むテーブルの列を減らす

SELECT句に指定する「読み込む列」を減らすことで、BigQueryのクエリコストを減らすことができます。GA4のBigQueryには、全部で100を超える列を持っています。この100を超える列の全てが必要なケースはまずありません。むしろ、通常の分析で必要な列はこのうち半分にも満たないでしょう。

数10個の列をSELECT句に指定するのは面倒ではありますが、本番用のクエリを実装する際には特に、積極的に列を明示的に指定するのが良いでしょう。

また、下の画面のように、データポータルからカスタムSQLを使わずに標準のGA4のBigQueryをデータソースにした場合、ダッシュボードでどのような列を使っているかに関わらず、全ての列を読み込んでしまうため、注意する必要があります。

サンプリングテーブルの利用

実は、今回の記事はこの方法を紹介するためだけに書いたものです。ここで紹介する方法は、カスタムSQLを開発しているときに主に利用が想定される方法です。複雑なカスタムSQLを開発する必要がある場合、何度も実装・テストのためにSQLクエリを実行します。場合によっては100回近くクエリを実行することもあります。また、開発中の利用の場合、読み込むテーブルの列を減らすのは開発効率が落ちることもあり、現実的ではないことが多く、クエリコスト削減方法の1つが早くも途絶えます。

そこで、カスタムSQLの開発用にオリジナルテーブルをサンプリングしたテーブルを準備する方法を紹介します。

アイディアとしては、オリジナルのデータが1日あたり100万行あったとして、カスタムSQLの開発にこの100万行全てのデータを使わないといけないケースはほとんどありません。そのため、このテーブルを1%でサンプリングした約1万行のデータを全く別のテーブルとして保存し、このサンプリング済みテーブルを使ってカスタムSQLの開発を行えば、オリジナルの1%のデータでテストできるため、クエリコストを100分の1に抑えることができます。

具体的な方法については、以下のYoutube動画で紹介しているので、興味のある方はご覧ください。

Youtube動画:GA4 BigQueryのクエリコスト節約法(サンプリングテーブルの作成)

まとめ

今回は、GA4の目玉機能の1つであるBigQuery連携について、多くの人が気になっている料金面について解説しました。色々書きましたが、BigQueryの料金は基本的に安く設定されているので、よほどの大規模サイトでない限り、月1〜2万円の予算を考えておけば、超えることはないと思います(むしろ、1〜2万円の予算を設定したものの、いざ使い始めたら1,000円にも満たないケースが多いはずです)。

ぜひ、GA4を使い始めた人は、目玉機能のBigQuery連携についても手を出して、活用してみましょう。