GA4（Google Analytics 4）などのデータをSlackで通知する方法とそのメリット
BigQuery と Google スプレッドシートを使って Slack ボットを作成する方法を最終的には紹介しますが、そもそも定期的にデータに関する情報を受け取るメリットを考えてみましょう。
WebサイトのデータはLooker StudioなどのBIツールで見える化されていることがほとんどだと思います。
多くの場合は、データ情報は関係者で共有することを目的として、現場でアクションを起こすためには利用されないこともあるように感じます。
おそらく、重要な施策や改善には、都度、担当者や外部ベンダーがインサイト（洞察）を分析することが多いのではないでしょうか。そのため、BIツールで見える化したレポートは形骸化されやすいことは否めません。
それでは、SlackやTeamsなどで日常的にwebのデータを通知するメリットは何でしょうか。
形骸化しやすい従来型のレポートと違って、データ情報の通知はアクションを起こすために、アイディアを生み出すために、どんな数字を通知すればいいのかを考えて作られます。
現場からさらに声を拾って、どんな情報が欲しいかヒアリングして、より良いデータ提供をしていくことができます。
データの通知に関しては、従来型のレポートとはベクトルが違うのです。
ただ、従来のレポートを否定するわけではありません。併用して使うことで、従来のレポートで、通知の深掘りができる役割へと変える必要が発生します。これは好循環です。
今回はGA4のデータをslackに通知する方法に焦点を当てて、どのような方法があるのか紹介します。
GA4のデータを受け取る方法とそのメリットとデメリット
GA4のデータをslackで自動通知をするために、検討できる主な方法は下記の4つになります。（Teamsでも自動通知はできますが、今回は対象データはGA4で、通知先はslackに限定して検討しました）
GA4のデータをBigQueryに送り、GCP(Google Cloud Platform)を活用してpythonで分析し、pythonからslackへ通知する方法
GA4 のデータをGoogle Analytics Data API (GA4)を使い、GAS (Google Apps Script)と連携し、slackに通知する方法
GA4のデータをBigQueryに送り、BigQuery でクエリを実行し、GASとBigQueryを連携し、slackに通知する方法
GA4のデータをBigQueryに送り、スプレッドシートのconnectからBigQueryに連携してクリエ実行し、GAS でスプレッドシートを読み取り、slackへ通知する方法
1.GA4のデータをbigQueryに送り、GCPを活用してpythonで分析し、pythonからslackへ通知する方法
1に関してはpythonを使えるので技術力があれば、分析の幅が広がります。特にGA4だけでなく複数の大規模のデータを保有している場合はpythonを使った分析は有効になるでしょう。このデメリットは技術的なスキルやノウハウに依存することと、GCPが有料になる可能性があることです。
導入のハードルは高く、設計をしっかり行って導入することが良いでしょう。
2.GA4 のデータをGoogle Analytics Data API (GA4))を使い、GAS と連携し、slackに通知する方法
2に関しては料金的には確実にリーズナブルに抑えられる方法と言えるでしょう。なぜならば、BigQueryもGCPも使っていません。この方法のデメリットとしてはGASでスプレッドシートにデータを出力し、そのデータをGASで取得してから通知しなければいけません。少し複雑になってしまいます。
3.GA4のデータをbigqueryに送り、bigquery でクエリを実行し、GASとBigQueryを連携し、slackに通知する方法
3に関しては、スケジュールを設定し、クリエを実行しスプレッドシートを作成するにはGCPを活用しなければできません。(BigQueryサンドボックスではスケジュールができないので、スケジュール設定したい場合はGCPへのアップグレードが必要です) 。スケジュールを設定し自動でクリエを実行して作成したスプレッドシートをGASによって取得し、slackに通知します。SlackへのbotはGASにより通知は自動化できます。
4.スプレッドシートのconnectでbigquery連携してクリエ実行し、Gasでスプレッドシートを読み取り、slackへ通知する方法
4に関しては、スモールスタートにとてもおすすめの方法です。Google スプレッドシートのインターフェース内にある「connect」からBigQueryと連携し、BigQuery テーブルにリンクし、クエリを入力して必要なデータを抽出したりできるようになります。あとはGASでスプレッドシートの情報を読み取り、slackへ自動で通知できるようにします。
4の場合も、GCPでBigQueryのデータを整形したものをGoogleスプレッドシートのconnectでbigquery連携できることが望ましい事象もあり、GCPを将来的に活用することも考えられるでしょう。整形しないで、Googleスプレッドシートのconnectとbigqueryの連携してクエリを実行する方法では制限させることもありますし、力技で対応することも増えるでしょう。ただ、スモールスタートの際は、GCPを使わずに無料で始められ、それなりの通知が実装できるのでオススメです。
BigQueryに連携します（事前にBigQueryにGA4のデータを集積しました）
Slackのappを作り、appへアクセス権限を付与します（Slack botというappを作りました）
GASから経由でSlack API を利用してslackに通知します
Slack に作成したslack botより通知されました
この方法は、BigQueryサンドボックス（無料）ではスケジュールができない点をクリアにしてくれるため、スモールスタートに適しています。この方法で制限を感じ、スケールの大きな分析や通知を行いたいとなった場合は、GCPを契約し、高度な分析に移行していく事ができます。
サードパティのツールはどうなのか？
全く技術を必要としないツールを導入する事も検討できるでしょう。しかし、長い目で見たときに有効ではないと考えられます。特定のアクションしか通知できない、メールしか送れない、カスタマイズした通知ができないといった課題が、出来合いのツールやappでは発生することが多くあります。
また、外部ベンダーと協力するにせよ、技術的なチャレンジをし、柔軟性のある選択することで、ノウハウを貯め、データを活用した事業活動を向上していく事につながると考えられます。
BigQuery とGCPの料金の概要
BigQueryの使用料金
BigQuery のアーキテクチャはストレージとコンピューティングに分離されていることから、BigQuey の料金は「ストレージ料金」「分析料金（コンピューティング料金）」の 2 つの要素があります。
コンピューティング料金
処理されるクエリデータは毎月 1 TiB まで無料です。
クエリが参照するテーブルあたりのデータ最小処理容量は 10 MB、クエリあたりのデータ最小処理容量は 10 MB とします。つまり、基本的には一回のクエリの実行あたり10MBの処理になることが多い。
1TiBをMBに変換すると、 1TiB = 1,024GiB = 1,048,576MiB = 1,073,741,824MB
1ヶ月あたりの無料処理量を10MB単位で区切ると、 1,073,741,824MB ÷ 10MB/処理 = 107,374,182.4 処理
10MB処理の上限回数を算出すると、上記の結果は小数点以下を含んでいるため、実際には実行できる処理回数は整数部分のみとなります。
よって、10MBの処理を月に107,374,182回実行できることになります。
GA4の処理では、あまり気せずに無料で使うことができることがわかります。
ストレージ料金
ストレージ料金は、BigQuery に読み込むデータを保存する費用です。アクティブ ストレージと長期保存に対して料金が発生します。
アクティブ ストレージには、過去 90 日間で変更されたテーブルまたはテーブル パーティションが含まれます。
長期保存には、90 日間連続して変更されていないテーブルまたはテーブル パーティションが含まれます。そのテーブルのストレージの料金は自動的に約 50% 値引きされます。アクティブ ストレージと長期保存のパフォーマンス、耐久性、可用性に違いはありません。
ストレージは毎月 10 GiB まで無料です。
無料ストレージ容量を論理バイト数に変換すると、 10 GiB * 1024 MiB/GiB * 1024 KiB/MiB * 1024 B/KiB = 10,737,418,240 B
1日分のデータ量を論理バイト数に変換すると、 1.3 MB * 1024 KiB/MB * 1024 B/KiB = 1,331,200 B
無料ストレージ容量で保管できる日数を算出すると、 10,737,418,240 B / 1,331,200 B/日 = 8,075 日
よって、1.3 MBのデータが毎日蓄積された場合8,075 日分を無料で保管できることになります。
また、BigQueryサンドボックス（無料版）では、データの保存期間は60日間と定められています。昨月対比を行う場合は注意が必要です。
支払を登録してサンドボックスからアップグレードしても、ある程度は無料で使えます。クエリを実行して保存してもまだ余裕があります。
Google Cloud の使用料金
新規に契約すると、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分が提供されます。これには、Google が推奨する事前構築済みのソリューションも含まれます。また、 20 以上のプロダクトを無料で提供されます。
無料クレジット を超えると、Google Cloud の従量課金制の料金体系で、使用したサービスに対してのみ料金が発生します。前払い料金や、解約手数料は不要です。料金はプロダクトや使用量によって異なります。
あらかじめ料金もマネージし、予測できるようになってから導入する方が良いでしょう。
データをメッセージすることの可能性
APIによる連携で、データの受け渡しは従来から存在しましたが、現在はよりやすい環境が整ってきています。DWH（データウェアハウス）と連携し、SQLクエリを実行し、分析し、レポートし、定期的に自動通知することも実現しやすくなっています。
一方で、どうやってデータをビジネスへ活かすのかというと難しくなっているようにも感じます。レポートというと報告することが目的になってしまい形骸化しやすいという課題は従来からあります。
データ駆動にしようとリソースを注ぎ込むほど、この従来からある課題が浮き彫りになり、費用対効果の面がわからないと指摘する人が現れます。しかし、指摘する側も答えは持っていないことも多く、頓挫してしまうこともあるでしょう。
まずはSlackなどで日常的にwebのデータを通知することで可能性を探ることからスタートすることで、データ駆動の文化を醸成し、ビジネスに活かせる可能性が広がります。
日常的にデータに触れる環境を作る：レポートだけでなく、Slackでデータを見る習慣を作る。
データの共有と議論：Slack内でデータについて議論し、気づきを得る。
高度な自動化へのステップ：データ分析とアクションを自動化する仕組みを作る。
「データを分析し、自動でアクションを行える状態」は、高度化と言える領域です。一足飛びに、高度化はハードルが高すぎるので、まずはデータを日常的に見たり、気づきを得えたりすることからスタートすることが良いでしょう。
データを日常的に扱い通知を行うことで、従来のレポートも通知の深掘りができる役割へと変える必要もあり、データ活用の可能性は広がります。
