頭を悩ませずに Google アナリティクス 4 のレポートをアップグレードする方法

Google アナリティクス ユニバーサル (GAU) のユーザーは、2023 年夏に Google アナリティクス 4 (GA4) に切り替える必要があります。これに関する主な問題は、データ モデルとメトリック計算ロジックが、GAU と比較して GA4 で根本的に異なることです。 GA4 に切り替えた後、履歴データの一部は GAU 構造に保持され、新しいデータは GA4 構造に保存されます。 このため、企業は切り替え後、前年比 (YoY) の指標を評価するために真剣に取り組む必要があります (中間レベルのデータ アナリストの場合、少なくとも 100 時間以上の作業)。

これは、アナリストにとって、Google アナリティクス ユニバーサルと Google アナリティクス 4 の指標を一致させるために、SQL クエリのページを作成して配置することに日々費やすことを意味します。 ただし、これを回避する方法があります。 アナリストは、SQL クエリを頻繁に書き直すことなく、アドホック レポートを数分で作成できます。この記事では、その方法を説明します。

ユニバーサル アナリティクスは 2023 年 7 月 1 日に廃止され、Google アナリティクス 4 に置き換えられます。Google アナリティクス 360（GA の有料版）のお客様の場合、移行期間は 2024 年 7 月 1 日まで延長されました。どのバージョンの GA を使用しているかに関係なく、レポートが新しいデータ スキーマに更新されるのは時間の問題です。

この切り替えを考えると、アナリストにとって最も困難なタスクの 1 つは、Google アナリティクス ユニバーサルと Google アナリティクス 4 のデータを統一された形式で提供することです。

このタスクを複雑にする状況:

• メトリクスの計算ロジックは、GAU と GA4 で大きく異なります。 特に、これらの製品バージョンでは、従来のメトリックでさえ異なる方法で計算されます。 GAU と GA4 からすべての指標を 1 つのグラフにドラッグして、すべてがスムーズに進むことを期待することはできません。
• Google BigQuery のデータ スキーマも大きく異なります。 ユニバーサル アナリティクスはセッション ベースのデータ スキーマを適用しますが、Google アナリティクス 4 はイベント ベースのデータ スキーマを持ちます。
• ダッシュボードには、YoY 指標と季節傾向が含まれます。 問題は、これらすべての指標を備えたダッシュボードを使い続ける方法です。

具体例を見てみましょう。 次のダッシュボードがあるとします。

このダッシュボードの最も重要な部分は、現在と過去の期間の特定の指標の比較を表す季節性指標です。 マーケティング ダッシュボードで YoY メトリックをサポートするには、履歴データと運用データが同じ形式である必要があります。

この場合、アナリストの課題は、N+ のレガシー SQL クエリをアップグレードして、マーケティング チームに信頼できるレポートを提供することです。 SQL クエリの小さな修正でも影響を受ける可能性があるすべてをテストしてデバッグするのは困難です。

移行リスクも考慮する必要があります。 レポートを新しいソース (GAU から GA4 へ) に転送した後、アナリストはデータ スキーマとメトリック計算ロジックの根本的な違いを説明できない場合があります。 たとえば、セッションの形成方法は異なります。GA4 では最初のユーザー ソースのみが考慮され、セッションにつながる他のすべてのソースは無視されます。 したがって、一部のトラフィック ソースはレポートに表示されません。

最初は、これに気付かないことがあります。 しかし、2 ～ 3 四半期のうちに、不適切なダッシュボードが原因で広告費が非効率になり、30% 以上の予算漏れが発生します。

ダッシュボードの準備と作成はジェンガを思い出させます。 レポートのブロックを置き換える必要があるたびに、アナリストは指を交差させ、構造全体が崩壊しないことを願っています。

OWOX では、お客様のレポートをユニバーサル アナリティクス (または GA 360) データ スキーマから Google アナリティクス 4 データ スキーマに移行する際に、同様の問題を解決することに成功しています。 そのため、ソリューションといくつかの SQL クエリをブログの読者と共有したいと考えています。 この情報がお役に立てば幸いです。

レポートを作成するための当社のアプローチは (レポートが作成されるビジネス分野に関係なく)、モデル化されたデータではなく生のデータに基づいています。

データ モデルは、データ エンティティ、その属性、およびエンティティ間の関係を記述します。 たとえば、Web サイトでのユーザーのアクションは特定のセッションに統合され、1 人のユーザーが 1 つのセッションで複数のオンライン コンバージョンを達成できます。

アクション、ユーザー、セッション、オンライン コンバージョンの 4 つのオブジェクトと、セッションとアクション間の 1 対多、ユーザーとオンライン コンバージョン間の 1 対多、セッションとオンライン コンバージョン間の 1 対多の 3 つの接続があります。オンライン変換。

データ モデルは、現実世界に対する私たちの認識を反映し、次のような質問に答えます。それはどのように関連していますか？データを扱う際に適用される条件と制限は何ですか? 人々がお互いを明確に理解するには、データモデルが必要です。

データ モデリングは、データ モデルの要件を満たす形式にデータを変換するプロセスです。

• 以下によって、分析作業の価値と効率を高めます。
• レポート構造と指標計算ロジックの変更をスピードアップ
• レポートとダッシュボードのサポート コストの削減
• レポートの議論と承認の簡素化
• 次の方法でレポートのデータ品質を向上させます。
• パラメータと指標の計算ロジックを実装する際の重複の回避
• 正確なデータのソースとなる 1 つのデータ レイヤーを持つ

データ モデルは、オブジェクトとその計算ロジック (すべてのレポートに有効) を記述するため、多数のツールを置き換え、レポートのロジックを記述します。

OWOX BI は生データを分析可能な形式に変換し、データ準備の時間を節約します。 ユニバーサル アナリティクスと Google アナリティクス 4 のデータをレポートにシームレスに統合します。

Google アナリティクス データに基づいて構築されたデータ モデルの例を次に示します。

ご覧のとおり、セッション、トランザクション、ページ、デバイスなど、いくつかのオブジェクトがあります。

ここで最も興味深く重要なことは、これらのオブジェクトの構造が相互に接続されておらず、データ ソースとは何の関係もないことです。 これらのオブジェクトをライブデータで埋めるためにどのソースが使用されているかは問題ではありません (Piwik、Adobe、Google アナリティクスなど)。 データ ソースに関係なく、モデルはビジネスを表すデータ モデルと同じオブジェクトを返します。 これは、実際に使用するオブジェクトとメトリックを示しています。

実際の世界でどのように見えるか見てみましょう。

ユニバーサル アナリティクスからエクスポートされたセッションや Google アナリティクス 4 からエクスポートされたイベントなど、未加工データの上に SQL クエリを記述する代わりに、モデル化されたデータを作成できます。 セッション、ユーザー、ページ ビューなど、現実世界のオブジェクトやエンティティを表す、汎用的でわかりやすいテーブルが一番上にあります。

具体的な例とデータ スキーマを考えてみましょう。

生データの例を次に示します。 これらは、Google アナリティクス ユニバーサル (左) と Google アナリティクス 4 (右) の Google BigQuery からのデータ スキーマのスクリーンショットです。

上で書いたように、データ スキーマは異なります。 このデータを Google Data Studio ダッシュボードにリンクする方法を見つける必要があります。

私たちの経験に基づくと、モデル化されたテーブルを作成することは、データの準備を簡素化するための最良の方法です。 それらは次のようになります。

これらは、上記のデータ モデルのオブジェクト リストです。 オブジェクト リストは、Google アナリティクス 360 と Google アナリティクス 4 で同じであることがわかります。

これは、同じクエリを使用してダッシュボード クエリをこのデータに接続できることを意味します。 このクエリの構造は同じです。

生データではなくモデル化されたデータに基づいてレポートを作成することを検討する重要な理由を見てみましょう。

1.データは果物のようなものです。ブレンドする前にデータをきれいにする必要があります。 アナリストは、さまざまなサービスやシステムからデータを収集します。 当然、そのデータの構造と形式はソースによって異なります。 レポートを作成するには、さまざまなソースからのデータを正しくマージする必要があります。 コネクタやさまざまな ETL サービスを介してアップロードされたデータ自体は不正確であり (エラー、重複、不一致を含む)、統一されたロジックと構造が欠けています。 不正確で断片化されたデータはクリーンアップし、分析に対応した形式に正規化する必要があります。

OWOX BI を使用すると、データを手動でクリーニング、構造化、および処理する必要はありません。 このサービスは、生データを分析対応の形式に自動的に正規化します。

2.レポートごとにビジネス ロジックをコピーして書き直す必要はありません。たとえば、次のことは必要ありません。

• トランザクションの重複排除
• ボットと内部トラフィックをフィルタリングする
• チャネル グループ化ルールを定義する
• 新規ユーザーとリピーターの基準を定義する
• UTM パラメータの追跡を修正

すべてのデータ アナリストは、次のようなマーケターからの要求を聞いたことがあるはずです: 過去のデータに基づいて、チャネル グループ化ルールを調整または改善したい、または 新規ユーザーとリピーターの基準を特定したい。 Google アナリティクスでは、独自の方法で、または過去 6 か月以内に購入したユーザーのみを返すことを検討したいと考えています。

生データに基づいてレポートを作成する場合は、すべてのデータ変換と準備作業をレポート レベルで実行する必要があります。 つまり、ビジネス ロジックをすべてのレポートにコピーするのに多くの時間を費やす必要があります。

モデル化されたデータでレポートを作成する場合、ビジネス ロジックをコピーする必要はありません。 モデリング段階で一度作成します。

3.モデル化されたデータに基づいてレポートを作成すると、アドホック分析が高速化されます。新しい SQL およびオーケストレーション変換を記述して、年次分析を可能にする時間を節約できます。

4.データ モデリングのおかげで、すべてのレポートに対して信頼できる唯一の情報源を作成できます。レポートのデータ ソースを変更すると、問題のあるすべてのクエリを解決する必要がなくなります。 セッション、トランザクション、およびイベント データについては、このソースに依存できます。

5.レポート層を簡素化します。モデル化されたデータの上にレポートを作成することは、ネストされたフィールドやレコード フィールドを処理するよりも簡単で、ウィンドウの複雑な関数や JSON 抽出関数を記述することもできます。

1.モデル化されたデータはもう 1 つの中間層です。 調整には時間がかかり、モデル化されたデータの監視とデバッグも行う必要があります。

2.正規化のための複雑な JOIN。

3.余分なデータ処理。データをモデル形式に変換するには、データをクエリする必要があります。 日付にはパーティション テーブルを使用することをお勧めします。 日付ディメンションを中心に構築されたパーティション テーブルを使用すると、必要なデータのみを更新できます。 すべての巨大なテーブルを書き直す必要はなく、Google BigQuery で処理されたすべてのデータとギガバイトまたはテラバイトのデータに対して料金を支払う必要はありません。 必要なパーティションをアップグレードして更新するだけです。 このアプローチは、すべてのデータ テーブルを処理するよりも経済的です。

これらの短所に対処できるように、Google アナリティクス 360 と Google アナリティクス 4 のデータをモデル化するための SQL テンプレートを用意しました。 この記事で提供されている追加資料をダウンロードすることで、それらを確認できます。

レポートを新しい Google アナリティクス 4 データ スキーマに更新するのは簡単ですか? モデル化されたデータを使用します。 生データでレポートを作成する代わりに、GA Universal および GA 4 スキーマの上に、ユニバーサルでわかりやすいフラット テーブルを作成できます。

これを行うと、データをコピーして正規化ロジックを多数の SQL クエリに挿入する必要がなくなります。 これは、データ モデリングの段階で 1 回行います。 すべてのプロジェクトに特効薬というわけではありませんが、特別なレポートを定期的に必要とするプロジェクトにとっては最適な方法です。

モデル化されたテーブルをセットアップして調整する場合は、OWOX BI のデモにサインアップしてください。 データに基づいてプロジェクトで同様のテーブルを準備する方法の詳細を喜んで共有します.