アナリティクス 360 で企業向け機能を利用する
アナリティクス 360 は Google アナリティクス 4 プロパティを基盤とし、より多くのカスタマイズ、大きな規模、企業レベルのサポートによって大規模な広告主や広告代理店の測定ニーズに対応します。
このモジュールで学ぶ内容:
・サブプロパティと統合プロパティを使用する
・ユーザー役割を設定してプロパティの機能の利用を制御する
・標準プロパティとアナリティクス 360 プロパティの違いを知る
Ａ、🚀 アナリティクス 360（有料版）は、大規模なデータを扱う企業にとって非常に強力なツールです。
このモジュールの内容を深掘りするために、まずは全体像を整理しましょう。以下の3つのステップで進めていくのはいかがでしょうか？
1. プロパティ構成の柔軟性 🏗️
標準版にはない**「サブプロパティ」と「統合プロパティ」**の仕組みを学びます。これにより、複雑な組織構造（例：ブランド別、地域別）に合わせたデータの管理が可能になります。
2. 高度なガバナンスと管理 🔐
企業レベルで求められる詳細な**「ユーザー役割」**の設定について学びます。特定のデータ（収益データなど）を特定のチームだけに隠すといった、より細かい制御方法を理解しましょう。
3. スケールとサポートの比較 📊
標準プロパティと360プロパティの決定的な違い（データの保持期間、サンプリングの有無、SLA（サービス品質保証）など）を比較し、なぜ大企業に360が必要なのかを探ります。
Analytics アナリティクス 360 とは
アナリティクス 360 は Google アナリティクスの有料のエンタープライズ版です。アナリティクス 360 に装備された機能、および Google アナリティクス 4（GA4）の標準プロパティと 360 プロパティの主な違いを見てみましょう。
Ａ、西田さん、Googleアナリティクス認定資格をお持ちの視点から見ると、360（有料版）は「制限の解除」と「組織管理の強化」が大きな柱であることがわかりますね。
GA4の標準プロパティと360プロパティでは、データの収集上限や保持期間、そして大規模組織向けの管理機能に大きな差があります。これから一緒に、企業レベルのニーズにどう応えるのかを紐解いていきましょう。
まずは、360ならではの強力な機能を探索するために、以下の3つの切り口から選んでみてください。
・データ収集と保持のスケール 📊
イベント数上限の大幅な拡張や、データの保持期間（標準最大14ヶ月 vs 360最大50ヶ月）など、分析の「深さと量」に関する違いを詳しく見ます。
・高度なデータ構造（サブプロパティ・統合プロパティ） 🏗️
複数のサイトを横断して見る「統合プロパティ」や、特定のデータだけを切り出す「サブプロパティ」の仕組みと活用シーンを学びます。
・企業向けのガバナンスとサポート 🔐
ユーザーごとの細かいアクセス制御や、データ処理の速さを保証するSLA（サービス品質保証）など、ビジネス運用上のメリットを整理します。
アカウント構造の柔軟性が向上
ビジネス向けの設定オプションが増加
アナリティクス 360 では、アナリティクス データを最適化するため、サブプロパティと統合プロパティという 2 つの方法が追加されました。では、それぞれの説明に移りましょう。
・サブプロパティ
サブプロパティは、参照元プロパティと呼ばれる他のプロパティから（サブプロパティの）データを取得します。サブプロパティのデータは通常、その参照元プロパティのデータのサブセットです。
・統合プロパティ
統合プロパティには、複数の参照元プロパティからのデータが含まれます。通常のプロパティとサブプロパティのデータを含めることはできますが、他の統合プロパティのデータを含めることはできません。
Ａ、西田さん、Googleアナリティクス認定資格を活かして実務を見据える上で、この「サブプロパティ」と「統合プロパティ」の理解は非常に重要です。大規模な組織（エンタープライズ）では、データの見せ方を柔軟に変える必要があるからです。
標準版（無料版）では、1つのプロパティにデータが集約されるだけですが、360では用途に合わせてデータを「切り出したり（サブ）」「まとめたり（統合）」できるのが強みですね。
これらが実際のビジネスシーンでどう役立つのか、具体例を交えて深掘りしてみましょう。以下の2つのシナリオのうち、どちらから詳しく探ってみたいですか？
１、部門ごとのセキュリティ管理（サブプロパティ） 🏢
例えば、「北海道支店の担当者には北海道のデータだけを見せたい」といった、特定のデータだけをフィルタリングして管理する方法。
２、グループ全体の横断分析（統合プロパティ） 🌐
複数のブランドサイトやアプリをバラバラに運営している企業が、ユーザーの動きを「全社視点」で統合して把握する方法。
サブプロパティを使用する場合
・データ ガバナンス
サブプロパティの最大のユースケースはデータ ガバナンスです。つまり、プロパティに含めるデータまたは除外するデータを管理する目的で使われます。サブプロパティを使用すると、データを含めたり除外したりすることで、特定のオーディエンスまたはユースケースに必要なデータセットを作成することができます。こうしてデータを適切に整理することにより、特定のオーディエンスがデータに簡単にアクセスできるようになります。
・ユーザー ガバナンス
サブプロパティを使用する別のユースケースは、ユーザー ガバナンスです。たとえば、会社に厳格なポリシーがあり、特定の地域に関連するデータのサブセットを同じ地域（北米）からはアクセスできても、別の地域（南アメリカ）からはアクセスを禁止する場合です。これはサブプロパティに最適なユースケースです。各地域のデータはそのプロパティ内に制限されるため、適切な地域の外からはアクセスできなくなります。
Ａ、西田さん、データとユーザーそれぞれの「ガバナンス」についてですね。360を導入する企業の多くが、まさにこの「情報の出し分け」に課題を感じています。
サブプロパティは、元の大きなデータ（参照元プロパティ）から、特定のルールでデータを「フィルタリング」して切り出した専用の箱のようなものです。
例えば、西田さんが札幌の企業のマーケティング担当者として、全国展開しているECサイトの分析を任されたとしましょう。
データガバナンスの例: 広告チームには「広告流入データ」だけのサブプロパティを、分析チームには「全データ」を、というように必要な分だけを見せて作業を効率化します。
ユーザーガバナンスの例: 「北海道支店のスタッフ」には、北海道のユーザーデータだけが入ったサブプロパティへの権限を与え、他地域のデータは見られないように制限をかけます。
この仕組みをより深く理解するために、実際の運用イメージを想像してみましょう。次のどちらのケースが、より実務で役立ちそうだと感じますか？
フィルタリングの仕組み ⚙️
具体的に「どのイベント」や「どのパラメータ」を使って、どうやってデータをサブプロパティに振り分けるのかという技術的な側面。
コストと制限の考慮 💰
サブプロパティを作成すると、ヒット数（イベント数）のカウントや料金、スロットル制限がどう変化するのかという運用上の注意点。
統合プロパティを使用する場合
・製品、ブランド、地域の組み合わせ
統合プロパティでは、複数の参照元プロパティのデータを 1 つにまとめ、複数の商品、ブランド、地域にわたってビジネスを幅広く捉えることができます。たとえば、会社が所有している複数のブランドに個別のプロパティを設定している場合、それらのプロパティを 1 つのプロパティに統合すると、ブランド全体のパフォーマンスを総合的に把握できます。
Ａ、統合プロパティ（ロールアップ プロパティ）の役割についてですね。これは、西田さんがお持ちのGoogle広告やYouTube関連の知見を活かす際にも、非常に強力な武器になります。
例えば、複数のブランドサイトを運営している場合、標準版ではそれぞれのサイトに「誰が来たか」はわかっても、**「ブランドAを見た人が、実はブランドBのYouTube動画も見て、最終的にブランドCで購入した」**という一連の行動（クロスドメイン・クロスブランドの動き）を追うのは困難です。
統合プロパティを使うことで、こうしたバラバラなデータを1つの大きな「地図」のように統合できます。
実務での活用をイメージするために、以下の2つのポイントからどちらを深掘りしてみたいですか？
ユーザーの重複排除（ユニーク ユーザーの把握） 👥
複数のサイトを訪れている「同一人物」をどうやって1人としてカウントし、ブランドをまたいだカスタマージャーニーを可視化するのか。
データの制限と集計の仕組み 📈
統合プロパティにデータが集まる際、元のプロパティ（参照元）のイベント数や設定がどう反映されるのか、あるいは料金計算（スロットル）にどう影響するのか。
西田さんが実務の現場で「ここが複雑そうだな」と感じる方はどちらでしょうか？
企業アカウント設定の例
アンダースさんの保険会社
アンダースさんは、次のような種類の保険を提供する大手の保険会社を経営しています:
・住宅保険
・自動車保険
・生命保険
上記はそれぞれ別の事業部門であり、データも個別に分析する必要があります。しかし保険商品は相互の結び付きが強く、一緒に分析する必要がある場合も少なくありません。
アンダースさんとそのチームがどのようにアナリティクス アカウントを構造化したか見てみましょう。
Ａ、アンダースさんの保険会社のようなケースは、アナリティクス 360 の柔軟な構造を理解するのに最適な例です。「部門ごとの独立性」と「会社全体の統合」という、一見矛盾するニーズを両立させる必要があります。
アンダースさんのチームがとった構成のイメージを整理してみましょう。
🏛️ アンダースさんのアカウント構造案
レベル プロパティの種類 役割
全体 統合プロパティ 🌐 住宅・自動車・生命保険の全データを合算。顧客が複数の保険を検討している様子を可視化します。
事業別 参照元プロパティ 📋 各部門（住宅、自動車、生命）が日常の分析に使うメインの箱です。
詳細 サブプロパティ 🔍 （必要に応じて）「自動車保険」の中から「特定の地域」や「特定の広告キャンペーン」だけのデータを抽出します。
この構造を実現することで、各部門の担当者は自分の数値に集中でき、経営層は会社全体のパフォーマンスを把握できるようになります。
ここで、西田さんが実務でこの設計を運用すると想像してみてください。次のどちらのステップを詳しく確認したいですか？
ユーザー権限の割り当て 🔑
「自動車保険の担当者には、生命保険のデータを見せない」といった制御を、この構造の中でどう設定するか。
データの重複と計測の仕組み ⚙️
統合プロパティでデータをまとめる際、ユーザーが複数のサイトをまたいだ場合に「同一人物」としてどうカウントされるのか。
アカウントの構造
アナリティクス 360 で企業向け機能を利用する
企業アカウント設定の例
サブプロパティと統合プロパティを使用するビジネスをいくつか見てみましょう。
アンダースさんはすべての商品データを同じ参照元プロパティに送信することにしました。しかし、各種の保険を管理するチームはデータを別々に分析できなければなりません。このためアンダースさんとそのチームは、事業部門別にサブプロパティを作成しました。
Ａ、アンダースさんのケースでは、1つの大きな「参照元プロパティ」にすべてのデータを集め、それを「サブプロパティ」で切り分けるという戦略をとりましたね。斉藤さんがお持ちのGoogleアナリティクス認定資格の知識を当てはめると、この構造のメリットがより鮮明に見えてくるはずです。
この「1つの参照元 ➔ 複数のサブプロパティ」という構成にすることで、アンダースさんの会社には次のような利点が生まれます。
サブプロパティ構成のメリット 💡
データの専門化 🎯: 自動車保険チームは、自分たちに関係のない住宅保険のデータに惑わされることなく、専用のダッシュボードで分析に集中できます。
管理の効率化 🛠️: タグの設定（Google タグなど）を参照元プロパティで1回行うだけで、自動的に各サブプロパティにデータが流れるため、二重に設定する手間が省けます。
柔軟な権限管理 🔐: 「生命保険の担当者には生命保険のサブプロパティだけ」というように、閲覧範囲を厳格にコントロールできます。
ここで少し実務的な視点で考えてみましょう。
アンダースさんは「すべての商品データを同じ参照元プロパティに送信する」という決断をしました。もし、逆に**「最初から事業ごとにプロパティを分けて作り、後から統合プロパティでまとめる」**という方法を選んでいたとしたら、どのような違いが出ると思いますか？
データの計測方法（タグ設定） 🏷️
ユーザーの重複排除（同一人物の特定） 👥
コスト（イベント数のカウント方法） 💰
西田さんが一番「ここが運用に影響しそうだ」と思うポイントを教えてください。
ひろ子さんの小売会社
ひろ子さんは小売会社を所有し、経営しています。この会社は次のような商品ライン別にブランドを展開しています:
・自動車用品ブランド
・家庭用品ブランド
・家電ブランド
各ブランドは個別に運営されており、データを個別に分析する必要があります。しかし親会社は全ブランドのデータを 1 つにまとめて表示し、ユーザーや売上高などを全体的に把握したいと考えています。
ひろ子さんとそのチームがどのようにアナリティクス アカウントを構造化したか見てみましょう。
Ａ、ひろ子さんのような複数ブランドを展開する小売業では、各現場の「個別の分析」と、経営層の「全体像の把握」をどう両立させるかが鍵となりますね。
アンダースさんの保険会社の例（1つの参照元を分ける）とは対照的に、ひろ子さんのチームが選んだのは、各ブランドの独立性を高めつつ、後からデータを集計する構造です。
🛒 ひろ子さんのアカウント構造案
レベル プロパティの種類 役割
全体（親会社） 統合プロパティ 🌐 自動車、家庭用品、家電のすべてのデータを1箇所に集約。会社全体の売上高やユニークユーザー数を可視化します。
ブランド別 参照元プロパティ 🏷️ 各ブランド（自動車、家庭用品、家電）がそれぞれのサイトやアプリから直接データを収集する、独立したメインの箱です。
この構造のポイントは、まず現場（各ブランド）にデータを集め、それを親会社が「統合プロパティ」という大きな器で受け取るという流れにあります。
西田さんが以前のやり取りで触れていた「YouTube広告」や「ディスプレイ広告」の成果をブランド横断で評価する場合、この統合プロパティが非常に役立ちます。
では、この構造における**「統合プロパティ」**の挙動について、どちらの側面をまず確認してみたいですか？
１、ユーザーの重複排除 👥
「自動車用品を買った人が、家電ブランドのサイトも訪れた」という動きを、統合プロパティがどうやって「同一人物」として認識するのか。
２、データの反映ルール ⚡
各ブランドのプロパティで行った「カスタム定義」や「コンバージョン設定」が、統合プロパティ側にどう引き継がれるのか。
興味のある方を番号で教えてください！
Q、１，２両方です。
Ａ、西田さん、意欲的ですね！両方の視点を持つことで、エンジニアリング（技術）とビジネス（戦略）の架け橋になれるはずです。
では、ひろ子さんの統合プロパティの例を使って、それぞれのポイントを整理していきましょう。
1. ユーザーの重複排除（ユニーク ユーザーの把握）👥
統合プロパティの最大の魔法は、ブランドをまたいだユーザーの動きを「線」でつなげることです。
同一人物の判定: Googleシグナル、デバイスID、そして西田さんも資格取得で学ばれたであろう User-ID を活用します。
分析のメリット: 「自動車用品を買った人が、1週間後に家電サイトで空気清浄機を買った」という行動が1人のユーザーの履歴として集約されます。これにより、ブランド間の相乗効果（クロスセル）を正確に測定できます。
2. データの反映ルールと設定の引き継ぎ ⚙️
統合プロパティは、元のプロパティからデータを「コピー」してくるイメージですが、いくつか注意点があります。
カスタム定義: 参照元（各ブランド）で設定したカスタムディメンションや指標は、統合プロパティ側でも個別に設定（またはマッピング）する必要があります。
コンバージョン: 参照元でコンバージョンとしてマークしたイベントは、統合プロパティでも自動的にコンバージョンとして扱われますが、統合プロパティ専用のコンバージョンを別途作ることも可能です。
ここで、実務で直面しそうな**「データの食い違い」**について考えてみましょう。
もし、自動車用品サイトでは「購入」というイベント名を purchase とし、家電サイトでは buy_item と設定していた場合、統合プロパティで「会社全体の購入数」を出すにはどうすればよいと思いますか？
タグの修正: 各サイトのイベント名をすべて purchase に統一する。
統合プロパティでの設定: 統合プロパティ側の「イベントの作成・修正」機能を使って、名前を統一する。
計算指標の作成: purchase と buy_item を足し算する新しい指標を作る。
西田さんなら、運用の手間やデータの正確性を考えて、どの方法が最も「品質重視」だと感じますか？理由も併せて考えてみましょう。
アカウントの構造パート 1
ここではひろ子さんの会社が統合プロパティを作成し、3 つのブランド プロパティを統合プロパティの参照元プロパティに指定します。ひろ子さんとそのチームはデータを全体的に把握でき、なおかつ各ブランドは独立しています。
ひろ子さんの親会社は、1 つのアカウントと各ブランドに対応する 3 つの参照元プロパティを持ちます。
Ａ、ひろ子さんのケースは、複数のブランドを個別に運営しつつ、親会社として全体像を把握したいというニーズにぴったりな構成ですね。
この「3つの参照元プロパティ ➔ 1つの統合プロパティ」という流れを詳しく見ていきましょう。
1. ユーザーの重複排除（ユニーク ユーザーの把握） 👥
統合プロパティの大きな利点は、ブランドをまたいだユーザーの動きを「線」でつなげることです。
同一人物の判定: Googleシグナル、デバイスID、そして西田さんも資格取得で学ばれた User-ID を活用します。
分析のメリット: 例えば「自動車用品サイトを訪れたユーザーが、数日後に家電サイトで空気清浄機を購入した」という一連の行動が、1人の履歴として集約されます。これにより、ブランド間の相乗効果を正確に測定できます。
2. データの反映ルールと設定の引き継ぎ ⚙️
統合プロパティは、元のプロパティからデータを「コピー」してくるイメージですが、いくつか重要なルールがあります。
カスタム定義: 参照元（各ブランド）で設定したカスタムディメンションや指標は、統合プロパティ側でも使えるように個別に設定（またはマッピング）する必要があります。
コンバージョン: 参照元でコンバージョンとしてマークしたイベントは、統合プロパティでも自動的にコンバージョンとして扱われます。ただし、統合プロパティ側で独自にコンバージョンを設定し直すことも可能です。
ここで、西田さんが実務で直面しそうな「データの整理」について考えてみましょう。
もし、自動車用品サイトでは「購入」イベントの名前を purchase とし、家電サイトでは buy_item と設定していた場合、統合プロパティで「会社全体の合計購入数」を出すにはどうすればよいと思いますか？
タグの修正: 各サイトの計測設定を変更して、イベント名をすべて purchase に統一する。
統合プロパティでの修正: 統合プロパティ側の「イベントの作成・修正」機能を使って、名前を統一する。
計算指標の作成: レポート上で purchase と buy_item を足し算する新しい指標を作る。
西田さんなら、運用の手間やデータの正確性を考えて、どの方法が最も「品質重視（質を重視する現在のスタイル）」だと感じますか？理由も併せて考えてみましょう。
アナリティクス 360 で企業向け機能を利用する
Ａ、ひろ子さんのケースでは、各ブランドが独自のサイトや戦略を持つ「独立した運営」を前提としていますね。そのため、まずはブランドごとに参照元プロパティでデータを収集し、それを親会社が統合プロパティでまとめるという、ボトムアップ型の構造をとっています。
西田さんが気にされていた「ユーザーの重複排除」と「設定の引き継ぎ」の両面から、この構造をどう最適化するか、具体的な解決策を見ていきましょう。
1. ユーザーの重複排除：ブランドをまたぐ「人」を捉える 👥
複数のサイトを横断するユーザーを同一人物として認識するには、以下の仕組みが統合プロパティ内で働きます。
User-IDの活用: 各ブランドのサイトで共通の会員ID（User-ID）を使用していれば、統合プロパティ側でそれらを紐付け、ブランド A から B への回遊を正確に把握できます。
Google シグナル: User-ID がない場合でも、Google アカウントにログインしているユーザーであれば、デバイスをまたいだ行動も推測・統合されます。
2. 設定の引き継ぎとデータの統一 ⚙️
ブランドごとにイベント名がバラバラ（例：purchase と buy_item）だと、統合プロパティで合算する際に工夫が必要です。
イベントの修正機能: 統合プロパティの設定画面で「イベントの作成・修正」を使い、buy_item を purchase に読み替えるルールを作れば、タグを書き換えずにデータを統一できます。
カスタム定義の再設定: 参照元プロパティで設定した「会員ランク」などのカスタムディメンションは、統合プロパティ側でも同じ名前・インデックスで登録しておくことで、横断的な分析が可能になります。
西田さんがおっしゃった「1（重複排除）と 2（設定）の両方」を解決する上で、どちらの作業がより「品質（精度）」に直結すると思いますか？
１、各ブランドのタグを最初から統一する（上流での標準化） 🏷️
２、統合プロパティ側の設定で吸収する（後処理での柔軟性） 🛠️
西田さんのこれまでの学習経験から、実務で「より確実だ」と感じる方はどちらでしょうか？理由も添えて教えてください。
Q、どちらも重要だと思います。
Ａ、西田さんの仰る通り、品質を追求するなら両方の視点が欠かせませんね！「上流での標準化」と「後処理での柔軟性」は、いわば車の両輪のような関係です。
では、ひろ子さんのケースで、この2つのポイントをどう具体化していくか整理してみましょう。
1. ユーザーの重複排除（ブランドをまたぐ「人」を捉える） 👥
複数のサイトを横断するユーザーを同一人物として認識するには、以下の仕組みが統合プロパティ内で働きます。
User-IDの活用: 各ブランドのサイトで共通の会員ID（User-ID）を使用していれば、統合プロパティ側でそれらを紐付け、ブランド A から B への回遊を正確に把握できます。
Google シグナル: User-ID がない場合でも、Google アカウントにログインしているユーザーであれば、デバイスをまたいだ行動も推測・統合されます。
2. 設定の引き継ぎとデータの統一 ⚙️
ブランドごとにイベント名がバラバラ（例：purchase と buy_item）だと、統合プロパティで合算する際に工夫が必要です。
イベントの修正機能: 統合プロパティの設定画面で「イベントの作成・修正」を使い、buy_item を purchase に読み替えるルールを作れば、タグを書き換えずにデータを統一できます。
カスタム定義の再設定: 参照元プロパティで設定した「会員ランク」などのカスタムディメンションは、統合プロパティ側でも同じ名前・インデックスで登録しておくことで、横断的な分析が可能になります。
ここで、西田さんが実務でこの設計を運用すると想像してみてください。
もし、あるブランドの担当者が「自分たちのサイトだけで使う独自の指標」を追加したいと言い出した場合、統合プロパティ全体の管理を考えると、どちらの方法が「品質と管理のバランス」が良いと思いますか？
１、参照元プロパティだけで設定する: 統合プロパティには影響させず、ブランド独自の分析に留める。
２、統合プロパティにも反映させる: 将来的に他ブランドと比較する可能性を考えて、全社的な基準として登録する。
西田さんの「質を重視する」というスタンスから、どちらの考え方がしっくりくるか教えてください。
Q、２です。
Ａ、統合プロパティ側で柔軟に対応する（後処理）という考え方ですね。実務では、各ブランドの現場担当者が独自のスピード感で施策を回していることが多いため、中央（親会社）がツール側で吸収する形をとることで、現場の柔軟性を損なわずに全体集計が可能になります。
では、実際に統合プロパティを運用する場面を想定してみましょう。
参照元プロパティ（各ブランド）から統合プロパティへデータが流れる際、**「イベント名が異なる」**場合にどう統合するか、その具体的な手順をイメージしてみましょう。
統合プロパティでのデータ整理の手順
データの確認: 統合プロパティに、purchase（自動車用品）と buy_item（家電）の両方が届いていることを確認します。
イベントの作成・修正: 統合プロパティの設定で「buy_item という名前で届いたイベントを、このプロパティ内では purchase という名前に書き換える」というルールを作成します。
統合的な分析: これで、統合プロパティ上ではすべての購入アクションが purchase として集計され、会社全体の売上件数を一つの指標で追えるようになります。
このように設定でカバーすることで、各ブランドのサイト改修（タグの打ち直し）を待たずに、スピーディーに分析を開始できるのが 360 の強みです。
さて、これまでは「データの見え方」について話してきましたが、次は**「誰がそのデータを見られるか」**という重要なトピックに移りましょう。
ひろ子さんの顧客向けポイント プログラム
親会社は、すべてのブランドに共通のポイント プログラムを展開しています。特典を担当するひろ子さんのチームは親会社のレベルで活動しています。全ブランドのポイント プログラム参加者のデータを、同じプロパティで見る必要があります。
このニーズを踏まえ、ひろ子さんとそのチームがどのようにアナリティクス アカウントを構造化したか見てみましょう。
Ａ、共通のポイントプログラムを運用する場合、複数のブランド（参照元プロパティ）から特定のデータだけを抽出して、一つの場所に集約する必要がありますね。
ひろ子さんのチームがこのニーズをどう解決したか、アカウント構造の図解とともに見ていきましょう。
💳 ポイントプログラムの統合管理構造
レベル プロパティの種類 役割
特典チーム用 統合プロパティ 🎁 各ブランドから「ポイントプログラム関連のデータ」だけを集約。全ブランドを通じた会員の行動を分析します。
ブランド別 参照元プロパティ 🏷️ 自動車、家庭用品、家電の各サイト。ここで発生した会員登録やポイント利用のイベントが、統合プロパティへ送られます。
この構造では、親会社の特典チームは「ポイントプログラムに参加しているユーザー」という共通の軸で、ブランドの枠を超えた分析ができるようになります。
ここで、西田さんがおっしゃった**「機密データの保護（権限管理）」**の視点から、この構造のメリットを考えてみましょう。
以下の2つの設定のうち、特典チームの業務をスムーズにするために、より重要だと思うのはどちらですか？
１、データ制限（コスト・収益の非表示） 💰
特典チームにはポイントの動きは見せたいが、各ブランドの「広告コスト」や「詳細な商品原価」などは見せないように制限する設定。
２、サブプロパティによる絞り込み 🔍
統合プロパティに送るデータを「ポイント会員のフラグがあるユーザー」だけに限定し、非会員のノイズを除去して分析しやすくする設定。
西田さんの「実務での使い勝手」という観点から、どちらの制御に興味がありますか？番号で教えてください。
Q、どちらも重要だと思います。
Ａ、西田さんの仰る通り、情報の「入り口（標準化）」と「出口（柔軟な設定）」の両方を整えることが、最も精度の高いデータ管理に繋がりますね。
ひろ子さんのような複数ブランドを抱えるケースでは、全社共通の「ポイントプログラム」という重要な軸があるため、特にその両立が鍵となります。
では、この構造において親会社の特典チームが、どのように「ユーザー」と「データ」を管理していくべきか、具体的なステップを一緒に考えていきましょう。
1. ユーザーの識別と統合 👥
複数のブランド（参照元プロパティ）を横断するユーザーを同一人物として捉えるために、統合プロパティでは以下の仕組みが働きます。
User-IDの同期: 各サイトで共通のポイント会員IDを使用していれば、統合プロパティ側でそれらを紐付け、ブランドをまたいだ行動を1人のユーザーとして集約できます。
Google シグナル: IDがない場合でも、Googleアカウントのログイン状況などからクロスデバイス・クロスプラットフォームの動きを補完します。
2. データの保護とガバナンス 💰
特典チームが必要なデータにだけ集中し、機密情報を守るための設定です。
データ制限（コストと収益）: 360では、特定のユーザーに対して「コストデータ（広告費など）」や「収益データ（売上金額など）」を非表示にする権限設定が可能です。
サブプロパティの活用: 統合プロパティからさらに「ポイント会員のイベントのみ」を抽出したサブプロパティを作ることで、分析のノイズを減らすことができます。
さて、ここで一つ具体的な運用シーンを想像してみてください。
もし、**「自動車用品ブランドの売上金額は機密性が高いので、共通ポイントプログラムを運営する他部署のメンバーには見せたくない」**という要望があった場合、西田さんならどの機能を優先して提案しますか？
１、ユーザー役割による「収益データ」の制限 🔑
（特定のメンバーから金額データだけを隠す）
２、サブプロパティによる「データの切り出し」 ✂️
（金額データを含まない、ポイント関連のイベントだけのプロパティを別に作る）
西田さんの考える「品質と安全性のバランス」から、どちらの方法がより適切だと感じますか？理由も併せて考えてみましょう。
アカウントの構造パート 2
ひろ子さんはチームのニーズに応えてサブプロパティと統合プロパティを組み合わせ、特典を担当するチームが独自のデータセットを使用できるようにしました。参照元プロパティごとに、特典の参加者のみのデータを格納したサブプロパティが作成されます。次に、この 3 つすべてのサブプロパティが、特典データの統合プロパティにプッシュされます。
Ａ、ひろ子さんの戦略は、まさに「情報の取捨選択」と「統合」を組み合わせた、非常に高度な 360 の活用例ですね！
西田さんがおっしゃった通り、**「機密データの保護（収益データの制限）」と「サブプロパティによる絞り込み」**の両方を実現する、非常に理にかなった構造です。
💡 この構造の仕組み
各ブランド（参照元）: すべてのデータを収集。
サブプロパティの作成: 各ブランドから「特典プログラム参加者」のデータだけをフィルタリングして抽出。
特典統合プロパティ: 3つの「特典用サブプロパティ」だけをまとめ上げる。
🎯 この構成のメリット
ノイズの除去: 特典チームは、ポイントに関係のない一般ユーザーのデータを見る必要がなくなります。
セキュリティ: ブランド側の機密情報（特典に関係ない売上など）をサブプロパティの段階で除外しておけば、統合プロパティ側で誤って漏洩するリスクを最小限に抑えられます。
ここで、実務における「フィルタリング」の精度について考えてみましょう。
各ブランドのサブプロパティを作る際、**「特典参加者だけを抽出する」**ためには、どのような条件を設定するのが最も確実だと思いますか？斉藤さんがこれまでに学んだ GA4 の知識から推測してみてください。
１、特定のイベント名: （例：point_earned というイベントが発生したユーザーのみ）
２、ユーザープロパティ: （例：is_member = true という属性を持っているユーザーのみ）
３、特定のページへの訪問: （例：/my-points/ というURLを閲覧したユーザーのみ）
西田さんなら、データの「品質」を保つためにどの方法を推奨しますか？理由も併せて教えてください。
Q、１，２、３どれも重要です。
Ａ、西田さんの仰る通り、品質を追求するなら、すべてのデータを漏れなく、かつ正確に捉えることが不可欠ですね！「点（URL）」ではなく「線（ユーザー属性や行動）」で捉えることで、分析の精度は飛躍的に高まります。
ひろ子さんのケースでは、複数の手法を組み合わせることで、以下のような強固なデータ基盤を築くことができます。
🛠️ 確実な抽出のためのアプローチ
手方 メリット 役割
ユーザープロパティ 👤 永続的 「会員である」という状態を保持するため、過去の行動も含めた分析に強いです。
特定のイベント ⚡ 即時的 ポイント獲得や利用といった「具体的なアクション」をトリガーにするため、活発なユーザーを特定しやすいです。
ページ閲覧 📄 補完的 会員限定ページへのアクセスなど、システムの実装状況に応じた柔軟な抽出が可能です。
これらを組み合わせてサブプロパティを作成することで、親会社の特典チームは「質」の高い、洗練されたデータセットを手にすることができます。
さて、構造についてはバッチリ理解深まったかと思います。次に進む前に、この「サブプロパティ」や「統合プロパティ」を安全に運用するための**ガバナンス（権限管理）**についても少し触れておきましょう。
アナリティクス 360 で企業向け機能を利用する
Ａ、西田さん、ひろ子さんの会社の複雑なアカウント構造を、この図で完璧に整理できましたね。🎨
この図は、**「情報の独立性」と「目的別の統合」**を同時に実現する、アナリティクス 360 ならではの高度な設計図です。
📊 図解：ひろ子さんのハイブリッド構造
図の各パーツが何を指しているか、改めて確認しましょう。
中央の緑のアイコン（□）: 各ブランド（自動車用品、家庭用品、家電）の参照元プロパティです。それぞれの現場で発生する全データを収集します。
下の青いアイコン（▼）: 各参照元から「ポイントプログラム参加者」だけを抽出したサブプロパティです。
右側のオレンジのアイコン（↑）: 3つのサブプロパティをまとめた、特典チーム用の統合プロパティです。
中央上のオレンジのアイコン（↑）: （必要に応じて）全ブランドの全データをそのまま統合した、経営層向けの統合プロパティです。
この構造を「品質」の観点から見たとき、一つ重要なポイントがあります。
図の下にある**サブプロパティ（青いアイコン）**でフィルタリングを行う際、もし元のデータ（緑のプロパティ）に誤りがあると、その上の統合プロパティにも間違ったデータが積み上がってしまいます。
西田さんが以前「どれも重要」とおっしゃったように、「ユーザー属性（ID）」、「イベント」、**「ページ閲覧」**の3つを正確に組み合わせてフィルタリングすることで、初めてこの複雑な構造が正しく機能します。
それでは、この強力な構造を「誰が・どこまで管理できるか」を決める**「ユーザーガバナンス」**について見ていきましょう。
以下のどちらの機能が、ひろ子さんの会社のセキュリティを保つために重要だと思いますか？
プロパティごとの権限割り当て 🔑
「家電ブランドの担当者には、自動車ブランドの参照元プロパティや統合プロパティを触らせない」といったアクセス制御。
特定のデータの非表示設定 🙈
「特典チームには、ポイントデータは見せるが、各ブランドの広告費（コスト）や売上（収益）は見せない」という詳細なフィルタリング。
西田さんの実務的な感覚から、まずはどちらの仕組みを詳しく知りたいですか？
その他の例
サブプロパティと統合プロパティを使用した他のアカウントの設定例、費用に関する考慮事項は、ヘルプセンターをご覧ください。
Ａ、西田さんがおっしゃる通り、精度の高い分析には多角的な視点（イベント、ユーザープロパティ、ページ閲覧）が欠かせませんね。これらを組み合わせることで、ノイズのない「質の高い」データセットが完成します。
さて、アンダースさんやひろ子さんの例で見たような複雑な構造を運用する際、最後に避けて通れないのが**「費用（コスト）」**の考え方です。アナリティクス 360 では、データの「移動」や「コピー」にもカウントが発生します。
ヘルプセンターの情報を踏まえ、実務で重要になるコストの仕組みを整理しましょう。
💰 費用に関する重要なルール
イベントのカウント: サブプロパティや統合プロパティに送られたデータは、参照元プロパティとは別に、それぞれのプロパティで「イベント」としてカウントされます。
課金対象: 360 の契約形態によりますが、基本的には全プロパティの合計イベント数（または各プロパティごとの料金スロット）がコストに影響します。
効率的な設計: 西田さんのように「質」を重視する場合、何でも統合・分割するのではなく、本当に分析に必要なデータだけをサブプロパティに流す設計が、結果的にコストパフォーマンスの向上に繋がります。
これで「アカウント構造」のセクションは一通り網羅できました！最後に、このモジュールのもう一つの柱である**「ユーザーの管理」**について、ひろ子さんの例を借りて確認しましょう。
例えば、**「ポイント特典チームのメンバーには、統合プロパティのデータは見せたいけれど、各ブランドのサイトの『収益（売上金額）』などの機密情報は隠しておきたい」**という要望があった場合、360 ではどのように対処するのがスマートだと思いますか？
１、プロパティの閲覧権限自体を制限する 🔑
２、ユーザー役割の設定で「収益データ」のみを非表示にする 🙈
西田さんなら、運用の柔軟性を考えてどちらの方法を選びますか？理由も併せて教えてください。
Q、２です。
Ａ、西田さん、**「2. ユーザー役割の設定で『収益データ』のみを非表示にする」**を選択されましたね。
素晴らしい判断です！特にひろ子さんのような、共通ポイントプログラムを中央で管理しつつ、各ブランドの独自性も保ちたいという組織では、この「データの種類に応じたアクセス制御」が非常に効果的です。
この機能を使えば、特典チームは「ポイントの利用状況（イベント）」を詳細に分析しながらも、会社の機密事項である「商品の原価」や「広告の投資収益率（ROAS）」といった金額データには触れられないように設定できます。
🔐 360 でのユーザーガバナンスとデータ制限
アナリティクス 360 では、標準版よりも細かくユーザーの権限を制御できます。
収益データの非表示: 特定のユーザーに対して、eコマースの売上や注文金額などの指標を一切見せないように設定できます。
コストデータの非表示: Google 広告などのキャンペーン費用に関連する指標を非表示にできます。
プロパティごとの役割: サブプロパティごとに異なるユーザー役割（管理者、編集者、マーケター、閲覧者など）を割り当てることが可能です。
ここまでで、アナリティクス 360 の大きな特徴である「構造（サブ・統合プロパティ）」と「管理（ガバナンス）」の基本を押さえました。
最後に、西田さんが実務でこの 360 プロパティを提案・運用する際、**「標準プロパティとの決定的な違い」**を整理しておくと、説得力がさらに増します。
理解度をチェックする
どちらがサブプロパティでどちらが統合プロパティですか？
・2 つ以上の参照元プロパティのデータを含むプロパティです。
・他の参照元プロパティからデータを取得するプロパティです。
統合プロパティ
サブプロパティ
Q、統合プロパティ
サブプロパティの順です。即答できました。
Ａ、素晴らしいですね！西田さんの即答、流石です。これまでの整理がしっかりと身についている証拠ですね。🚀
改めて、ひろ子さんの会社の例を参考に、斉藤さんが導き出した答えを定義に当てはめて確認しましょう。
統合プロパティ 🌐：2 つ以上の参照元プロパティ（自動車、家庭用品、家電など）のデータを含むプロパティです。
サブプロパティ 🔍：他の参照元プロパティ（ブランドごとのサイトなど）から特定のデータを抽出して取得するプロパティです。
この構造を理解したことで、アンダースさんの「部門別の切り分け」と、ひろ子さんの「全社的な統合と特定チームへのデータ提供」という、全く異なるビジネスニーズをどう Google アナリティクス 360 で実現するかがクリアになったかと思います。
企業向けのパフォーマンスと機能
プロパティの変化を監視
複数のチームが一緒にアナリティクスのプロパティを使用する場合は、アカウント設定に加えられた変化を入念に監視することをおすすめします。アナリティクス 360 には強力な変更履歴機能があります。新しい Google 広告アカウントがアナリティクス 360 のプロパティとリンクされた場合や、新しいタイプのコンバージョンが作成された場合など、設定が編集されたときには履歴を確認できます。
Ａ、「質」を重視する西田さんにとって、最後に重要になるのが**「データの信頼性」**をどう守るかという点です。大規模な組織で複数の担当者が設定を触る場合、いつ誰が何を変えたかを把握しておく必要があります。
📝 変更履歴機能：設定の「質」を担保する
アナリティクス 360 の変更履歴機能では、以下のような重要なアクションを記録・確認できます。
Google 広告とのリンク 🔗：新しい広告アカウントが接続されたタイミング。
コンバージョンの作成 🎯：新しい成果地点（購入や会員登録など）が設定された履歴。
ユーザー権限の変更 🔐：誰にアクセス権を与え、あるいは削除したかの記録。
この履歴があることで、万が一数値に異常が出た際も、設定変更が原因かどうかを即座に特定し、以前の状態に戻すといった正確な運用が可能になります。
さて、ここまで「アカウント構造」「ユーザー管理」「変更監視」と、360 の主要な企業向け機能を網羅してきました。これらを活用すれば、西田さんが目指す「実務経験を積める企業」でも、即戦力として自信を持って提案できるはずです。
このセクションの最後に、360 の**「処理能力」**に関する驚きの数字を一つ紹介して締めくくりたいと思います。どちらの「パワー」に興味がありますか？
１、膨大なイベント数への対応 🚀
無料版では処理しきれないような、1ヶ月に数十億件を超えるデータも扱えるスケーラビリティ。
２、BigQuery との強力な連携 🧠
ローデータ（生のデータ）を高速でエクスポートし、独自のデータ分析基盤と統合する仕組み。
西田さんの今後のキャリア（GA4認定資格の活用）を見据えて、より深掘りしたい方を番号で教えてください！
Q、１、２ともに興味があります。
Ａ、西田さん、両方に興味をお持ちいただけて嬉しいです！「質」を重視するエンジニアやアナリストにとって、この2つは360を使いこなす上での「最強の武器」と言えます。
それぞれの特徴を整理してみましょう。
🚀 1. 膨大なイベント数への対応（スケーラビリティ）
大規模な企業サイトでは、1日のイベント数が数千万件に達することも珍しくありません。
処理能力: 標準版ではデータの収集制限（1プロパティあたり月間1,000万イベントなど）がありますが、360では月間数十億件レベルのデータも安定して処理できます。
データの正確性: 大量のデータを扱う際、標準版ではレポート作成時に「サンプリング（一部のデータから全体を推測すること）」が発生し、数値に誤差が生じることがあります。360ではサンプリングが発生しにくく、**「100%の生データ」**に基づいた正確な分析が可能です。
🧠 2. BigQuery との強力な連携（データ基盤の構築）
西田さんが取得されたGoogleマーケティング関連の資格を活かすなら、ここが一番の腕の見せ所です。
ローデータのエクスポート: 360では、1日に複数回、ほぼリアルタイムですべての生データをBigQueryへ書き出すことができます。
高度な統合分析: BigQuery上で、アナリティクスのデータと「自社の顧客管理システム（CRM）」や「店舗の売上データ」を結合し、SQLを使って自由自在に分析できます。
この2つの機能を使いこなせれば、単なる「ツールの運用者」ではなく、**「データからビジネスの意思決定を支える戦略家」**として、札幌や首都圏の企業で高く評価されるはずです。
さて、これでアナリティクス 360 の主要な機能についての学習は完了です！西田さんはこれまでに、以下のことをマスターされました。
・アカウント構造（アンダースさんとひろ子さんの例）
・ユーザーとデータの管理（権限と機密保護）
・変更履歴による運用監視
・大規模データと外部連携の強み
データの準備状況を把握
アナリティクス 360 には、データの収集、レポート、処理、アトリビューションなど、多くのプロダクト機能を網羅するサービス レベル契約（SLA）が付属します。BigQuery の日次エクスポートの SLA もあるため、安心して独自の分析が可能です。
Ａ、西田さんの仰る通り、品質を追求するなら設定（変更履歴）だけでなく、データが「いつ、どのように届くか」という確実性も非常に重要ですね。
アナリティクス 360 の大きな強みは、この SLA（サービスレベル契約） にあります。これは単なる努力目標ではなく、Google が企業に対してデータの品質を公式に保証するものです。
📋 360 が保証する主な SLA
対象機能 保証される内容 メリット
データ収集 📡 タグからのデータが 99.9% 以上の確率で正常に受信されること。 計測漏れのリスクを最小限に抑え、信頼性の高いデータを蓄積できます。
レポート表示 📊 管理画面のレポートが 99% 以上の確率で利用可能であること。 必要な時にいつでも分析業務が行える安心感があります。
BigQuery エクスポート 🧠 日次のデータが決められた時間内にエクスポートされること。 独自のデータ基盤（BIツールなど）への反映が遅れず、日次レポートの質が保たれます。
西田さんがこれまでに取得された Google 広告 や Google アナリティクス認定資格 の知識を実務で活かす際、この SLA の存在は、特に大規模な予算を動かす企業において「なぜ 360 を選ぶべきか」という強力な根拠になります。
企業向けの高い上限
アナリティクス 360 はビジネスの成長やニーズの増大に応じて拡張が可能です。Analyticsアナリティクス 360 のプロパティと標準的な Google アナリティクス 4 のプロパティの上限を比べてみましょう。
Ａ、西田さん、アナリティクス 360 の圧倒的な上限値についても学習が進んでいますね！🚀
標準版と 360 では、扱えるデータの「深さ」と「量」がこれほど違います。一覧表にまとめて、それぞれの項目がビジネスにどう貢献するか一緒に見てみましょう。
📊 標準プロパティ vs 360 プロパティ 上限比較
項目 標準アナリティクス アナリティクス 360 ビジネスへのメリット
イベントパラメータ 25 / イベント 100 / イベント 商品の色、サイズ、店舗など、より詳細な情報を一度に送れます。
カスタムディメンション 50 125 会員ランクや著者名など、独自の分析軸を豊富に持てます。
コンバージョン数 30 50 複雑な購入ステップや多岐にわたる目標設定に対応できます。
オーディエンス 100 400 広告配信のターゲットをより細かく切り分けて最適化できます。
データの保持期間 最長 14 か月 最長 50 か月 4年前のデータと比較するなど、長期的なトレンド分析が可能です。
BigQuery Export 100万イベント/日 数十億イベント/日 大規模サイトの全データを漏れなく生データとして活用できます。
西田さんが以前おっしゃっていた「質」の向上という観点から見ると、特に 「データの保持期間（50か月）」 ⏳ は強力な武器になります。
もし西田さんが、札幌の企業のマーケティング担当として 「4年前の同時期のキャンペーン結果と比較したい」 と言われたら、標準版と 360 ではどのような違いが出ると思いますか？これまでの数値を参考に考えてみてください。
プロパティのアップグレード方法
プロパティのアップグレード方法を含め、アナリティクス 360 の詳細は、このヘルプセンターの記事をご覧ください。
Ａ、西田さん、アナリティクス 360 の高い上限値や拡張性について、しっかりと把握されましたね。🚀
標準プロパティでは「あと少しパラメータが足りない」といった制約に直面することがありますが、360 ではビジネスの成長に合わせて余裕を持って設計できるのが大きな魅力です。
さて、先ほどの質問について一緒に考えてみましょう。
⏳ 4年前のデータとの比較
標準プロパティ（最長 14 か月）と アナリティクス 360（最長 50 か月）で、4年前（48 か月前）のキャンペーン結果を比較しようとした場合、どのような違いが出るでしょうか？
標準プロパティ: 14 か月より前のデータは自動的に削除されてしまうため、4年前のデータは管理画面や探索レポートでは確認できません。 ❌
アナリティクス 360: 50 か月（約4年2か月）まで保持できるため、4年前のキャンペーンの詳細なユーザー行動をそのまま比較・分析できます。 ✅
このように、長期的な「質」を維持できるのが 360 の強みです。
🆙 プロパティのアップグレードと次のステップ
ヘルプセンターの記事にある通り、既存のプロパティを 360 にアップグレードすることで、これまでに蓄積したデータを保持したまま、高い上限値や SLA などの企業向け機能を利用開始できます。
これでこのモジュールの学習内容はすべて完了です！西田さんは、大規模な組織でのデータ管理から、高度なセキュリティ、そして圧倒的な処理能力まで、プロフェッショナルな知識を身につけられました。
知識の確認
適切な方を選択してください。
モジュールを完了するには、この設問に正解する必要があります。
アナリティクス 360 プロパティ独自の機能でないものは次のどれですか。
・サブプロパティ
・統合プロパティ
・コンバージョン数とオーディエンス数の高い上限
・BigQuery Export
Q、BigQuery Exportです。
Ａ、正解です！よく理解されていますね。🚀
BigQuery Export は、標準版の Google アナリティクス 4 プロパティでも利用可能な機能です。ただし、先ほどの比較表で見たように、1日あたりのエクスポート上限数には大きな違いがあります。
標準プロパティ: 1日あたり 100 万イベントまで
アナリティクス 360: 1日あたり 数十億イベント まで
一方で、サブプロパティ や 統合プロパティ、そして コンバージョン数やオーディエンス数の高い上限 は、アナリティクス 360 だけの特別な機能です。
これでこのモジュールはすべて完了です！おめでとうございます。🎉 西田さんは、企業向けの高度な構造設計から、大規模データの管理、そして信頼性の担保まで、360 の真髄をマスターされました。
まとめ
・サブプロパティと統合プロパティは、アカウントの構造をより柔軟にできる、アナリティクス 360 のオプションです。
・アナリティクス 360 では変更を細かく監視でき、サービスレベル契約が付属します。
・アナリティクス 360 ではコンバージョン数やオーディエンス数の上限が引き上げられています。
Ａ、アナリティクス 360 の主要なポイントを完璧にまとめられましたね！斉藤さんのこれまでの学習で、大規模な組織におけるデータ管理の全体像がしっかり定着していることが伝わってきます。
これまでの内容を振り返り、実務で特に重要となるポイントを整理しましょう。
🏢 アカウント構造と管理の要点
柔軟な構造: サブプロパティや統合プロパティを活用することで、組織のニーズ（部門ごとの独立性や全社的な集計）に合わせた最適なデータ設計が可能です。
信頼の担保: 設定の変更履歴を監視できるだけでなく、データ収集や処理に関する**サービスレベル契約（SLA）**が提供されるため、エンタープライズレベルの運用でも安心です。
高い拡張性: コンバージョン数（最大50）、オーディエンス数（最大400）、データ保持（最大50か月）など、標準版の制限を大きく超えた分析が可能です。
Q、このレッスンは物量が多く、動画解説もなく、抽象的な内容だったので難易度が高かったです。
Ａ、西田さん、お疲れ様でした。確かにこのレッスンは、具体的な操作画面よりも概念的な図解や数値の羅列が多く、かなり抽象度が高かったですね。 専門用語も多く、物量に圧倒されるのも無理はありません。
しかし、西田さんはここまで一つひとつの機能を丁寧にご自身の言葉で整理し、理解度チェックも即答されてきました。その粘り強い学習姿勢は素晴らしいです。
このレッスンの内容は、実務で「設計図」を描く際に非常に役立つ知識ばかりです。難しい内容だったからこそ、今のうちに特に気になった部分を解消しておきましょう。
今回学んだ「360ならではの機能」を、実際の仕事の場面を想像して整理すると、少し具体性が増すかもしれません。以下の 3 つの視点から、西田さんが「これならイメージしやすい」と思うものはありますか？
「交通整理」としてのサブプロパティ 🚦
ブランドごとにデータが混ざらないよう、必要な人だけに必要なデータを見せる仕組み（ひろ子さんの例）。
「過去との対話」としてのデータ保持 ⏳
14ヶ月で消えてしまう無料版に対し、50ヶ月（4年以上）前と比較できる圧倒的な時間軸。
「膨大なデータの高速処理」としての BigQuery 🧠
手作業では扱えない数億件のデータを、システム同士で直接やり取りさせるパワー。
西田さんの感覚で、どれが一番「実務で役立ちそうだ」と感じましたか？
Q、このレッスンでGoogleアナリティクス認定講座が修了し、認定試験を残すだけとなりました。
Ａ、Googleアナリティクス認定講座の全レッスン修了、本当にお疲れ様でした！西田さんがこれまでコツコツと積み上げてきた努力が、いよいよ認定試験という形になるのですね。
確かに、この「360」のセクションは動画がなく、文字情報と抽象的な概念が中心だったため、難易度が高く感じられたと思います。実務経験を重視する斉藤さんにとって、イメージしにくい部分もあったかもしれません。
最後の仕上げとして、試験に出やすい「360プロパティの特徴」を、西田さんが「これなら自信を持って答えられる」という状態に整えていきましょう。
試験対策として、以下の3つのポイントのうち、どれが一番「まだ頭の中で整理しきれていないな」と感じますか？
１、プロパティの種類と役割 🏗️
「参照元」「サブ」「統合」という3つのプロパティの関係性と、データの流れについて。
２、360だけの特別なメリット 💎
「SLA（保証）」「変更履歴」「50か月のデータ保持」など、無料版にはない企業向けの強みについて。
３、拡張された「上限値」の数字 📈
イベントパラメータ（100個）やオーディエンス（400個）など、360で大幅に増える制限値について。
一番不安な番号を教えてください。そこを重点的に振り返って、試験への自信を深めていきましょう！
Q、１から３すべてです。
Ａ、試験に向けて、1から3までの重要ポイントを**「試験に出る要点」**に絞って整理しました。これを最後のチェックリストとしてお使いください。
1. プロパティの種類と役割（データの流れ）
360特有のプロパティ構造は、データの「交通整理」と「まとめ」です。
参照元プロパティ: データの出発点。すべての生データを収集する大本です。
サブプロパティ: 参照元から特定のデータだけを「フィルタリング」して抽出したプロパティです。
統合プロパティ: 2つ以上の参照元プロパティを1つに「合体」させたプロパティです。
2. 360だけの特別なメリット（安心と信頼）
「無料版ではできないこと」が試験のターゲットになりやすいです。
SLA（サービスレベル契約）: データの収集、レポート表示、処理、アトリビューション、BigQuery Exportについて、Googleがその動作を公式に保証します。
変更履歴: アカウント設定の編集（Google広告とのリンクやコンバージョンの作成など）を細かく監視できます。
データ保持: ユーザーデータの保持期間が最長 50ヶ月（無料版は14ヶ月）に延長されます。
3. 拡張された「上限値」（数字の力）
具体的な数値の違いを頭に入れておくと安心です。
項目 標準（無料） アナリティクス 360
イベントパラメータ 25個 100個
カスタムディメンション 50個 125個
コンバージョン数 30個 50個
オーディエンス数 100個 400個
BigQuery Export 100万イベント/日 数十億イベント/日
💡西田さんへのアドバイス
試験では「360プロパティ独自の機能はどれか？」といった問いがよく出ます。その際、**「サブプロパティ」「統合プロパティ」「SLA」「高い上限」というキーワードを思い出してください。BigQuery Exportは無料版でも使えますが、「SLAがつく」「上限が数十億になる」**のが360の特権です。
＊【GA4資格への挑戦】認定講座を全修了。難解な最終章を終えて、いま思うこと。
本日、すべての認定資格講座の全カリキュラムを修了しました。
最後を飾ったのは「アナリティクス 360」という企業向けの大規模な仕組みに関するセクションでした。
正直に申し上げますと、この最終回はこれまでの内容と比べても格段に難易度が高かったです。動画解説もなく、非常に抽象的な概念や膨大なスペックの数値が並び、何度も「これは手強い」と唸らされました。
しかし、ひろ子さんやアンダースさんといった具体的な企業のケーススタディを通じて、「データの独立性（サブプロパティ）」や「全社的な統合（統合プロパティ）」、そして企業としての信頼を守る「SLA」や「変更履歴」の重要性を深く学ぶことができました。
これからは、小説の執筆、作詞・作曲、そしてGoogleアナリティクスの活用に軸足を移していきます。今回の学びは、単なる資格取得のためだけでなく、これから私が生み出す作品やサービスにおいて、その「質」をデータという側面から支えてくれる確かな土台になると確信しています。
新たなキャリアを目指す私にとって、これはゴールではなくスタートラインです。
同じように何かに挑戦している皆さまに、少しでも勇気をお届けできていれば幸いです。
