Googleアナリティクス4(GA4)には、集めたデータを1件ずつ丸ごとBigQueryに書き出す「BigQuery Export」という機能があります。BigQueryはGoogle Cloudのデータベースで、書き出したデータはSQLで自由に数え直せます。この記事では、GA4とBigQueryのリンクの作り方、無料枠と料金、サンドボックスとの違い、日別のキーイベント(旧コンバージョン)を数えるSQLまでを書きます。読み終わると、サンプル料理教室のGA4のデータが毎日BigQueryに溜まり、費用がほぼかからない状態で、必要になった日にSQLで数え直せるようになります。GA4のプロパティができていて、体験申込・電話タップ・LINE追加がキーイベントになっていることを前提にします。
この記事の内容
先に決めること
BigQuery Exportは、リンクを作った日から先のデータしか書き出しません。迷っているあいだの分は溜まりません。一方で、作り方を間違えると、溜めたつもりのデータが60日で消えたり、知らないうちに請求が来たりします。手を動かす前に次の5つを決めます。
1つ目は、何のために書き出すかです。小さな会社がBigQueryを使う理由は、ほぼ次の3つに絞られます。探索レポートで14か月より前のデータを見たい、カスタムディメンションに登録し忘れたパラメータをあとから数えたい、制作会社や代理店とGA4の数字を突き合わせたい。どれにも当てはまらないなら、今はリンクだけ作って溜めておき、SQLは書かないという判断で構いません。
2つ目は、サンドボックスで始めるか、請求先アカウントをつなぐかです。BigQueryのサンドボックスはクレジットカードなしで使えますが、テーブルが60日で自動的に消えます。長く残すことが目的なら、請求先アカウントをつないだうえで無料枠の範囲で使います。サンプル料理教室の規模なら、請求先をつないでも無料枠に収まり、請求は0円のまま続きます。
3つ目は、誰のGoogleアカウントで作るかです。Google Cloudのプロジェクトと請求先アカウントは、代表個人のGmailではなく、会社のGoogle Workspaceのアカウントで作ります。担当者が辞めたときにプロジェクトごと持っていかれないようにするためです。オーナーは2人以上にしておきます。
4つ目は、データのロケーション(保存する地域)です。リンクを作るときに選びます。あとから変えるには、リンクを削除してデータを別のデータセットへ移し、作り直す手間がかかり、その間は書き出しが止まって空白期間ができることがあります。日本の会社なら東京(asia-northeast1)で困りません。料金の単価は地域ごとに違いますが、無料枠の中で使う限り差は出ません。
5つ目は、毎日の書き出しだけにするか、ストリーミングも付けるかです。小さな会社は毎日だけで足ります。ストリーミングは数分おきに書き出す代わりに、無料枠のない取り込み料金がかかり、サンドボックスでは使えません。
GA4の画面とBigQueryの違い
GA4の画面でできることと、BigQueryに書き出すとできることを並べます。サンプル料理教室で「BigQueryでなければできない」と言えるのは、表の下の3行くらいです。
| 比べるところ | GA4の画面 | BigQueryに書き出したデータ |
|---|---|---|
| データの形 | 集計された表とグラフ | イベント1件が1行の生データ |
| 探索レポートで見られる期間 | データ保持期間(標準のプロパティは最長14か月)まで | 自分で消すまで残る |
| サンプリング | 探索で大きな期間を選ぶとかかることがある | かからない。全行を数える |
| しきい値(少ない数を隠す仕組み) | ユーザー属性などで適用される | 適用されない(公式ヘルプもしきい値を減らす手段としてBigQueryを挙げている) |
| ユーザー数・セッション数 | 推定(HLL++)で数える | 実際の行を数える |
| Googleシグナル由来のデータ | 入る | 入らない |
| カスタムディメンションの登録 | 登録しないとパラメータが見えない | 登録に関係なく全パラメータが入る |
| 登録前・設定前の過去分 | さかのぼらない | リンクを作った日以降の分が溜まる |
| 数字の出し方 | 画面を選ぶだけ | SQLを書く |
BigQueryで数えた数字は、GA4の画面とぴったりは合いません。月に十数件の体験申込なら件数はほぼ同じで、違いが出るのはユーザー数とセッション数です。数字が合わない理由の全体は「ユーザー・セッション・イベント数の違い:GA4の数字が合わない理由」に書いています。
データフィルタで除いた社内のアクセスは、BigQueryにも書き出されません。内部トラフィックの除外を先に有効にしておくと、BigQueryの数字も社内のアクセスを含まない形で溜まります。
料金:何にいくらかかるか
BigQueryの料金は、大きく「データを置いておく料金(ストレージ)」と「SQLを実行して読む料金(クエリ)」の2つです。どちらも毎月の無料枠があり、無料枠は請求先アカウントごとに付きます。値は2026年10月時点の公式の料金ページのもので、単価はページで既定に表示されるアイオワ(us-central1)の値です。東京の単価は料金ページで地域を切り替えて確かめます。
| 何に | 無料枠(毎月) | 超えた分の単価(us-central1) |
|---|---|---|
| ストレージ(アクティブな論理ストレージ) | 10 GiB まで無料 | 1 GiB・1時間あたり $0.000031507(1 TiB を1か月で約 $23.55) |
| ストレージ(長期の論理ストレージ) | 10 GiB まで無料 | 1 GiB・1時間あたり $0.000021918 |
| クエリ(オンデマンド) | 1 TiB まで無料 | 1 TiB あたり $6.25 |
| ストリーミングでの取り込み | なし | 200 MiB あたり $0.01(1行を最低1 KBとして計算) |
90日間書き換えられていないテーブルは自動で長期ストレージに変わり、料金が約半分になります。GA4のテーブルは日付ごとなので、3か月より古い日の分から順に長期の料金になります。
サンプル料理教室の規模に当てはめます。月に数万イベントのサイトだと、実際に運用していると1か月分の書き出しは数十MBです。1年溜めても1GBに届かず、ストレージの無料枠10GiBの1割にもなりません。クエリも、1年分を毎回まるごと読んでも1回あたり1GB以下で、無料枠1TiBを使い切るには月に1,000回以上実行する計算です。つまり、毎日の書き出しだけなら請求は0円のまま続きます。
費用が出るのは、ストリーミングを付けたときと、データポータル(Looker Studio)からBigQueryを読むレポートを大勢が頻繁に開いたときです。後で書く上限の設定で止められます。
サンドボックスとの違い
BigQueryのサンドボックスは、請求先アカウントをつながずに使える状態のことです。無料枠と同じ上限(毎月10GBのストレージと1TBのクエリ)が付いたうえで、次の制限があります。
| 項目 | サンドボックス | 請求先アカウントをつないだ状態 |
|---|---|---|
| クレジットカードの登録 | 不要 | 必要 |
| テーブルの有効期限 | 既定で60日。テーブルもパーティションも60日で自動的に消える | 既定では期限なし |
| ストリーミング | 使えない | 使える(有料) |
| DML(UPDATE・DELETE) | 使えない | 使える |
| BigQuery Data Transfer Service | 使えない | 使える |
| 無料枠を超えたとき | 課金されない(使えなくなる) | 超えた分が請求される |
GA4の毎日のテーブルは、サンドボックスでは作られてから60日で消えます。「14か月より前のデータを残したい」という目的には合いません。サンドボックスは、SQLを試す練習台や、直近2か月だけを見る用途に向きます。長く残すなら、プロジェクトの課金を有効にし、データセットのテーブルの既定の有効期限を外します。
小さな会社で使う場面と、使わなくていい場面
BigQueryはSQLが書ける人がいて初めて役に立ちます。月の数字を代表が1枚で見るだけのサンプル料理教室では、ほとんどの月はBigQueryを開きません。それでもリンクだけは早めに作ります。必要になった日に過去のデータが溜まっているかどうかで、できることが変わるからです。
| 場面 | BigQueryを使うか | 理由と代わりの手 |
|---|---|---|
| 毎月の申込数・流入元を代表に見せる | 使わない | GA4の標準レポートとデータポータルで足りる |
| 前年同月と比べる | 使わない | 標準レポートは保持期間に関係なく過去の集計を見られる |
| 2年前の同じ月を、探索で細かく切って比べる | 使う | 探索は保持期間(最長14か月)までしか見られない |
登録し忘れたパラメータ(例: button_location)を過去にさかのぼって数える | 使う | カスタムディメンションは登録前にさかのぼらない。BigQueryには全パラメータが入っている |
| 代理店の報告と自社のGA4の数字が合わない | 使う | しきい値と推定のない数字を出して、どこで差が出るかを切り分ける |
| 体験申込した人が、申込の前にどのブログ記事を読んだかを1人ずつ見る | 使う | 探索の経路データ探索でも見られるが、件数が少ないとしきい値がかかることがある |
| 予約システムの売上とGA4をつないで分析する | 使うが、小さな会社では急がない | 予約システム側のデータもBigQueryに入れる作業が要る。まずはGA4だけで溜めておく |
| SQLを書ける人がいない | リンクだけ作る | 溜めておけば、必要になったときに外部に頼める |
月に数十件しか申込がない会社では、細かく分けても1つのセルが数件になり、判断に使える差は出ません。BigQueryを開くのは「数字が合わない」「昔のデータが要る」ときで十分です。
リンクの手順
流れは、プロジェクトを作る、課金と上限を整える、GA4からリンクを作る、届いたかを確かめる、の4段です。Google Cloud側はプロジェクトのオーナー、GA4側はプロパティの編集者以上の人が行います。1人で両方持っていると早く終わります。
1. Google Cloudのプロジェクトを作る
- 会社のGoogleアカウントでGoogle Cloudコンソールを開き、左上のメニューから「BigQuery」を選ぶ
- 初めて使う場合は、国を選び、利用規約に同意して「同意して続行」を押す
- 「プロジェクトの作成」を押す
- 「プロジェクト名」に
sample-cooking-ga4のような分かりやすい名前を入れる - 「組織」で会社の組織を選ぶ(Google Workspaceを使っていない場合は「組織なし」)
- 「作成」を押す
- 作ったプロジェクトが画面上部で選ばれていることを確かめる

プロジェクトIDは作成後に変えられず、SQLのテーブル名に毎回書きます。自動で付くIDにサイト名が分かる文字が入っているかを作成前に見ておきます。
この時点ではサンドボックスの状態です。BigQuery APIが有効かどうかは、「APIとサービス」で「BigQuery API」を開いて確かめます。
2. 課金を有効にして、テーブルの有効期限を外す
長く残すなら、ここで請求先アカウントをつなぎます。サンドボックスで試すだけなら、この手順は飛ばして構いません。
- Google Cloudコンソールのメニューから「お支払い」を開く
- 請求先アカウントがなければ作成し、会社のクレジットカードを登録する
- プロジェクト
sample-cooking-ga4をその請求先アカウントにリンクする - 「お支払い」→「予算とアラート」で予算を作り、金額を
1000円などの小さな値にして、50%・90%・100%で通知が来るようにする
予算アラートは通知だけで止まりません。止めるのは次の「割り当て」です。
- 「IAMと管理」→「割り当てとシステム上限」を開く
- フィルタの「サービス」で「BigQuery API」を選ぶ
- 「Query usage per day」にチェックを入れ、ツールバーの「EDIT」を押す
- 「無制限」のチェックを外し、「新しい値」に
1(TiB)を入れる - 「完了」→「リクエストを送信」を押す

Query usage per day は、そのプロジェクトで1日に読めるデータ量の上限で、既定は200TiBです。1TiBにしておけば、誤ったSQLを流してもその日はそこで止まります。上限に達するとプロジェクトの全員がクエリを実行できなくなり、「Custom quota exceeded」と出ます。太平洋時間の午前0時(日本時間の16時か17時)に戻ります。上限は概算で、少し超えることがあります。
サンドボックスのうちにGA4のリンクを作っていた場合、データセットに60日の既定の有効期限が残ります。analytics_ で始まるデータセットを開き、「詳細を編集」で既定の有効期限を外します。作られ済みの日付のテーブルにも期限が付いているので、残したいものは個別に外します。
3. GA4でBigQueryのリンクを作る
- GA4の「管理」を開く
- 「サービス間のリンク設定」の「BigQuery のリンク」を押す
- 右上の「リンク」を押す
- 「BigQuery プロジェクトを選択」を押し、
sample-cooking-ga4にチェックを入れて「確認」を押す - 「データのロケーション」で「東京(asia-northeast1)」を選び、「次へ」を押す
- 「データ ストリームとイベントを設定」で、書き出すウェブストリームを選ぶ
- 書き出さないイベントがあれば、「追加」または「名前でイベントを指定」で除外する(サンプル料理教室では指定しない)。「完了」を押す
- 「頻度」で「毎日」にチェックを入れる。「ストリーミング」は外す
- 「次へ」を押し、内容を確かめて「送信」を押す

リンクを作ると、BigQueryのプロジェクトに analytics_ とプロパティIDをつないだ名前のデータセットができます。プロパティIDが 123456789 なら analytics_123456789 です。その中に、日付ごとのテーブルが毎日1つずつ増えます。
| テーブル名 | 中身 | できる条件 |
|---|---|---|
events_20261028 | その日のイベント全件。1日1回、まとめて書き出される | 「毎日」をオン |
events_intraday_20261028 | その日のイベントを数分おきに書き足していく途中のテーブル | 「ストリーミング」をオン |
pseudonymous_users_20261028 | Cookieで見分けたユーザーごとの属性 | ユーザーデータの書き出しの設定(公式ヘルプのスキーマのページに条件の記載なし) |
users_20261028 | ユーザーIDを送っているユーザーごとの属性 | ユーザーデータの書き出しの設定(公式ヘルプのスキーマのページに条件の記載なし) |
会員ログインのないサンプル料理教室では users_ は使いません。
Google Workspaceの組織でプロジェクトを作った場合、組織のポリシーで「組織外のアカウントに権限を付けられない」設定になっていることがあります。GA4はGoogleのサービスアカウントにプロジェクトへの書き込み権限を付けて書き出すので、この設定があるとリンクの作成で止まります。Workspaceの管理者に、このサービスアカウントだけを許可してもらいます。
4. 毎日とストリーミングの違い
| 比べるところ | 毎日 | ストリーミング |
|---|---|---|
| 書き出しの頻度 | 1日1回、前日分をまとめて | 数分おき |
| テーブル | events_YYYYMMDD | events_intraday_YYYYMMDD |
| 標準のプロパティの上限 | 1日100万イベントまで | 上限なし |
| 料金 | ストレージ料金だけ(無料枠あり) | ストレージ料金に加えて取り込み料金(無料枠なし) |
| サンドボックス | 使える | 使えない |
| 向く場面 | 月次・週次の集計、過去データの保管 | 当日のキャンペーンの申込を数時間おきに見る |
標準のプロパティは、毎日の書き出しが1日100万イベントまでです。上限を超える日が続いたときにどうなるかは、公式ヘルプに書かれていません。サンプル料理教室は1日に数百〜数千イベントなので、届くことはありません。月に数百万イベントを超えるサイトなら、「名前でイベントを指定」で scroll や user_engagement のような分析に使わないイベントを外して上限の下に収めます。
ストリーミングが要るのは、その日のうちに数字が要る会社です。サンプル料理教室では、当日の様子はGA4のリアルタイムレポートで足ります。
5. 書き出しが届いたかを確かめる
- リンクを作った翌日以降に、Google Cloudコンソールで「BigQuery」を開く
- 左の「エクスプローラ」で
sample-cooking-ga4を開き、analytics_123456789を開く events_のテーブルができていることを確かめる。日付ごとのテーブルは1つにまとめて表示され、横に日数が出る- テーブルを選んで「プレビュー」タブを開き、
event_name列にpage_viewやgenerate_leadが並んでいることを見る

最初のテーブルは、リンクを作ってから24時間ほどで届きます。「プレビュー」はクエリを実行しないので無料です。中身を見るだけならSQLを書かずにプレビューを使います。

SQLの例:日別のキーイベント数
サンプル料理教室のキーイベントは、体験申込の完了 generate_lead、電話ボタンのタップ tel_click、LINE友だち追加ボタンのタップ line_click の3つです。10月の日別件数を出します。
- BigQueryの画面で「クエリを作成」(または「+」)を押して、新しいクエリのタブを開く
- 次のSQLを貼り、プロジェクト名とデータセット名を自分の環境に置き換える
- 右上に出る「このクエリを実行すると、○○ が処理されます」の量を確かめる
- 「実行」を押す
SELECT
PARSE_DATE('%Y%m%d', event_date) AS day,
COUNTIF(event_name = 'generate_lead') AS trial_applications,
COUNTIF(event_name = 'tel_click') AS tel_clicks,
COUNTIF(event_name = 'line_click') AS line_clicks
FROM `sample-cooking-ga4.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20261001' AND '20261031'
AND event_name IN ('generate_lead', 'tel_click', 'line_click')
GROUP BY day
ORDER BY day;

events_* の * はワイルドカードで、events_ で始まるテーブルをまとめて読みます。_TABLE_SUFFIX は * に当たる部分(ここでは日付)で、BETWEEN で絞ると、その期間のテーブルしか読まないので処理量も料金も減ります。event_date はプロパティのタイムゾーンでの日付で、GA4の画面の日付と揃います。
BigQueryには「このイベントはキーイベントか」という印は入っていません。キーイベントにしたイベントの名前を、SQLの中に自分で書きます。GA4の画面でキーイベントを増やしたら、SQLの IN (...) にも足します。
画面の数字と揃える
GA4の画面とBigQueryで件数がずれる理由で多いのが、キーイベントの数え方です。電話タップとLINE追加を「セッションごとに1回」で数える設定にしている場合、画面は同じセッションで2回押しても1件ですが、上のSQLは2件と数えます。セッションごとに数えるSQLは次のとおりです。
SELECT
PARSE_DATE('%Y%m%d', event_date) AS day,
event_name,
COUNT(*) AS events,
COUNT(DISTINCT CONCAT(
user_pseudo_id, '-',
CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING)
)) AS sessions_with_event
FROM `sample-cooking-ga4.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20261001' AND '20261031'
AND event_name IN ('generate_lead', 'tel_click', 'line_click')
GROUP BY day, event_name
ORDER BY day, event_name;
events がイベントの回数、sessions_with_event がそのイベントが起きたセッションの数です。セッションは user_pseudo_id(ブラウザのID)と ga_session_id の組で見分けます。
どのボタンから来たかで分ける
ボタンの位置をパラメータ button_location で送っていれば、GA4でカスタムディメンションに登録していなくても、BigQueryには入っています。
SELECT
event_name,
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'button_location') AS button_location,
COUNT(*) AS events
FROM `sample-cooking-ga4.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20261001' AND '20261031'
AND event_name IN ('tel_click', 'line_click')
GROUP BY event_name, button_location
ORDER BY event_name, events DESC;
パラメータは event_params という入れ子の列に、名前(key)と値の組で入っています。値は型ごとに value.string_value・value.int_value・value.double_value に分かれるので、文字は string_value、数字は int_value から取り出します。
応用
データポータルで日別の表を出す
上のSQLの結果は、データポータルのBigQueryコネクタで読めます。ただし、データポータルはレポートを開くたびにBigQueryにクエリを投げます。毎月の1枚を代表が見るだけなら、GA4のコネクタのほうが簡単です。BigQueryを使うのは、GA4のコネクタでは出せない数字(登録していないパラメータでの集計、14か月より前の明細)だけにします。データポータルのレポートの作り方は「データポータル(Looker Studio)でGA4のレポートを作る:毎月の数字を1枚にまとめる」に書いています。
BigQueryをデータポータルにつなぐときは、SQLの結果を毎月1回だけ別のテーブルに保存し、データポータルはその小さなテーブルを読む作りにすると、読むたびの処理量がほぼ0になります。BigQueryの「スケジュールされたクエリ」で毎月1日に実行できます。スケジュールされたクエリはBigQuery Data Transfer Serviceの機能なので、サンドボックスでは使えません。
申込した人がその前に見たページを数える
体験申込があったセッションで、申込の前にどのブログ記事が読まれたかも、user_pseudo_id と ga_session_id で generate_lead と page_view をつなげば数えられます。ただし申込が月に十数件の教室では、GA4の経路データ探索で見たほうが早く済みます。BigQueryで数えるのは、探索でしきい値がかかって数字が隠れたときや、14か月より前の期間を見たいときだけで十分です。画面でできることは「探索レポートの作り方:自由形式・ファネル・経路データ探索」に書いています。
長く残すデータの置き場所として使う
標準のプロパティでは、探索で見られるのはデータ保持期間の14か月までです。保持期間は「GA4の初期設定:データ保持期間・内部トラフィックの除外・Googleシグナル」で最長に延ばしておき、それより前の明細はBigQueryに置いておく、という分担にします。BigQueryのテーブルは、自分で消すか有効期限が来るまで消えません。
できないことと、その代わり
| できないこと | 理由 | 代わりの手 |
|---|---|---|
| リンクより前の過去分を書き出す | リンクを作った日以降の分が溜まる(公式ヘルプに過去分の記載はない) | 今日リンクを作る。過去分の集計値はGA4の標準レポートやData APIで取り出す |
| GA4の画面の数字とぴったり合わせる | 画面は推定・Googleシグナル・しきい値が入る。BigQueryは行の数え上げ | 件数(イベント数)で突き合わせる。ユーザー数・セッション数は「多少ずれるもの」として扱う |
| 同意しなかった人の推定(モデリング)を含める | 推定分が書き出されるかは公式ヘルプに記載がなく、実際に届いたイベントだけと考えて扱う | 同意モードの推定込みの数字はGA4の画面で見る |
| データフィルタで除いたアクセスをあとから戻す | 除いたデータはBigQueryにも書き出されない | フィルタは「テスト」で確かめてから有効にする |
| ロケーションをあとから変える | リンク作成時に選ぶ | 変えられるが手間がかかる。リンクを削除し、データを別のデータセットへ退避し、元を消して希望の場所に同名で作り直し、データを戻してリンクを作り直す。その間は書き出しが止まる |
| サンドボックスでデータを60日より長く残す | サンドボックスの既定の有効期限 | 課金を有効にし、既定の有効期限を外す |
有料の解析ツールには、GA4の生データをSQLなしでグラフにできるものがあります。SQLを書く人がいないまま生データの分析を毎月続けたい会社には向きます。困ったときだけ数え直す1教室のサイトなら、BigQueryに溜めておけば足ります。
よく詰まるところ
| 症状 | 原因 | 直し方 |
|---|---|---|
| リンクの作成画面にプロジェクトが出てこない | GA4を操作している人が、そのGoogle Cloudプロジェクトのオーナーではない | プロジェクトのオーナー権限を付けてもらうか、オーナーの人がリンクを作る |
| リンクの作成で権限のエラーが出る | Workspaceの組織ポリシーで、組織外のアカウントに権限を付けられない | 管理者に、GA4の書き出し用のサービスアカウントを例外として許可してもらう |
| 翌日になってもテーブルができない | 最初の書き出しは24時間ほどかかる。課金やAPIが無効のこともある | 2日待つ。それでも無ければ「BigQuery API」が有効か、リンクがGA4側に残っているかを見る |
| 2か月前のテーブルが消えている | サンドボックスでテーブルの既定の有効期限が60日だった | 課金を有効にし、データセットの既定の有効期限を外す。消えたテーブルは戻らない |
| 当日分を含めると件数が倍になる | _TABLE_SUFFIX >= '20261001' のように上限を書かず、events_intraday_ も読んでいる | BETWEEN で日付の上限まで書く。当日分を見るときは intraday だけを別に読む |
| GA4の画面より電話タップが多い | 画面は「セッションごとに1回」で数え、SQLは回数を数えている | セッション単位のSQLで数える |
| 登録したはずのパラメータがNULLになる | 文字の値を int_value から取り出している(またはその逆) | string_value と int_value を入れ替える。型が混ざるなら COALESCE で両方見る |
| 日付が1日ずれる | event_timestamp はUTCで、日本時間と9時間ずれる | 日付は event_date を使う |
| 少額の請求が来た | ストリーミングをオンにしている、またはデータポータルのBigQueryのレポートを大勢が開いている | GA4のリンクでストリーミングを外す。データポータルは集計済みの小さなテーブルを読ませる |
| 同じSQLを何度も実行すると処理量が毎回かかる | ワイルドカードテーブルのクエリはキャッシュが使われない | 結果を一度テーブルに保存して、そちらを読む |
LIMIT 10 を付けたのに処理量が減らない | 処理量は読んだ列の量で決まり、LIMIT では減らない | 必要な列だけを書く。中身を見るだけならプレビューを使う |
次にやること
毎月の数字は、まずデータポータルの1枚で見られるようにします。
- データポータル(Looker Studio)でGA4のレポートを作る:毎月の数字を1枚にまとめる
- 探索レポートの作り方:自由形式・ファネル・経路データ探索
- GA4の初期設定:データ保持期間・内部トラフィックの除外・Googleシグナル
- ユーザー・セッション・イベント数の違い:GA4の数字が合わない理由