Cookie規制とBigQueryのランデヴーなご関係

Google Cloud Champion Innovators Advent Calendar 2024 の 4 日目の記事です。

こんにちは。BigQueryに仕事を支えられているふっくです。
この一年でブランディングを目指しましたが自分で名乗るのをためらっていたらニックネームが全然浸透しなかったのでどこかで見かけたら呼んでやってください。

この記事では、自社techblogで人気の高かったBigQueryに関する記事をピックアップして概要を紹介します。詳細手順などはぜひリンク先記事でご覧ください。

弊社ではデジタルマーケティング活動の為のGoogleCloud利活用が活発である為、データを分析、施策利用にあたりCookie規制への対応と安全な環境についてが継続的な課題となっています。
今回ピックアップする3点は、
1.何が起きているのか
2.なぜBigQueryがセキュアな助けにつながるのか
3.どんな分析をCookieを利用したデータでしているのか
の順に並んでいます。ご参考になれば幸いです。

Cookie規制について

1. データ計測と Cookie の関係
   Cookieは、サイトを訪問した時にブラウザに保存されユーザーごとに割り振られた識別IDやサイトの訪問日時、ログイン時のパスワード、行動履歴といった情報などが保存されます。Cookie には主にサイトのドメインから発行される「1st Party Cookie」と、その他のドメインから発行される「3rd Party Cookie」があります。多くのクライアントサイトに設置した解析タグによって「3rd Party Cookie」でのデータ収集が行われてきました。昨今、このユーザーが知らぬまま収集された3rd Party Cookie が様々な所で活用されたり、悪用される可能性などがあったりと生活者への影響が懸念され、昨今ではこれら Cookie に関する規制が厳しくなっています。

2. プライバシー保護の動向とCookie規制の強化
   プライバシーを保護するための規制として主要なものをいくつかご紹介していきます。*2024年12月時点の情報です。これらは今後の法改正で変更される可能性がある点にご注意ください

・GDPR（欧州）
EU（欧州）では、インターネット上のプライバシー保護に関する法律として「欧州一般データ保護規制」（GDPR）があります。GDPRは個人データ保護に関する包括的な法規制で、EU内のすべての個人データ処理に適用されます。

・eプライバシー指令
電子通信データのプライバシー保護に特化しています。これらの規制により、EU圏内のサイトでは Cookie 取得時のユーザーからの同意（オプトイン）が必須となりました。
ユーザーがサイトを利用する前に3rd Party Cookie の利用を明示的に同意しない限り、3rd Party Cookie を利用してはならないというものです。

欧州のユーザーが利用するサイトは、これらの法律に対応する必要があるため、サイト上で同意を得る仕組みの導入が必要となります。

・CCPA（米国）
米国カリフォルニア州では2020年1月に「カリフォルニア消費者プライバシー法」（CCPA）が定められました。
カリフォルニア州で施行されている法律で、CCPAにおいては Cookie が個人情報とみなされており、ユーザーが Cookie データを第三者に販売されるのを止めたいときに利用停止できる仕組みと、3rd Party Cookie を利用する場合には、ユーザーが利用停止を選択できる仕組みの導入を義務化しています。

3. これらの規制への各ブラウザの対応

・Google Chrome
Google Chromeではプライバシー保護を強化する方針が掲げられています。その一環であった、2025年後半に予定されていたサードパーティ Cookie の完全廃止については、2024年7月に撤回されましたが、サードパーティ Cookie の完全廃止に向けて開発されたプライバシーサンドボックスは引き続き提供されています。
https://privacysandbox.com/intl/en_us/news/privacy-sandbox-update/

・Safari
Appleの標準ブラウザであるSafariでは、 「ITP」（Intelligent Tracking Prevention）というトラッキング防止機能が実装されています。
バージョンアップを重ねるたびに3rd Party Cookie の取得を厳しくしており、2017年（ITP1.0）には30日で削除する仕様でしたが、2020年3月以降はデフォルトで完全にブロックするようになっています。

・Microsoft Edge
Microsoft Edgeは「追跡防止」（Tracking Prevention）機能を提供しており、「Basic」、「Balanced」、「Strict」の3つのレベルでトラッキング Cookie の制御を行います。
デフォルトでは「Balanced」に設定されており、既知のトラッカーをブロックすることでユーザーのプライバシーを保護します。https://learn.microsoft.com/ja-jp/microsoft-edge/web-platform/tracking-prevention

・Firefox
Firefoxはプライバシー保護機能である「包括的 Cookie 保護」（Total Cookie Protection）をデフォルトで有効にしています。
各ウェブサイトのトラッキング Cookie を独自の「Cookie Jar」に分離することで、サイト間の追跡を防止する仕組みとなっています。https://support.mozilla.org/ja/kb/introducing-total-cookie-protection-standard-mode

また、ブラウジング中のプライバシーを自動的に保護する機能である「強化型トラッキング防止」が選択可能になっています。https://support.mozilla.org/ja/kb/enhanced-tracking-protection-firefox-desktop

4. Cookie 規制による影響
   Cookie の取得が規制されると何が困るのでしょうか。
   従来の3rd Party Cookie によるアドテクノロジーは、収集したコンバージョンデータを元にリターゲティングや、広告効果の最適化などに活用してきました。
   3rd Party Cookie の規制により、広告主は広告のインプレッションやコンバージョンの情報を3rd Party Cookie 以外に頼らざるを得なくなり、広告のアトリビューションも影響を受けるため、どの広告キャンペーンが実際のコンバージョンに寄与したのかを把握することが困難となります。

現在ここに代わるデータの在り方として、1st Party Dataとのデータの接合の上での分析が求められますが容易照合性の観点などから実施までのハードルがあり、開発や分析に臨む前に法的な整理事項までデータサイエンスには求められているのが現状です。

具体的な対応策の例などは元記事で詳細を紹介しています。
元記事：データ収集におけるCookie規制と Googleアナリティクス・プライバシーサンドボックスについて

BigQueryデータクリーンルームを活用してセキュアにデータを共有する

データ分析とデータクリーンルーム
上述のようなデータによる個人の特定への懸念から、取得することに問題があるのでなく、収集されたデータの保有場所が正しく管理され個が特定されない状態で集計できればよいのではないか、との観点から考え出されたのが「データクリーンルーム」というデータの持たせ方です。

一般的には、データクリーンルームとは、プライバシーが保護された状態でデータを統合・分析できる環境のことを意味します。

BigQueryのデータクリーンルームは、高度なセキュリティとプライバシー保護を実現しながらデータを共有できる環境を提供するとされ、データの提供元となるデータコントリビューターは基本的にデータを移動またはコピーすることなく、機密性の高いデータを共有することができます。また、集計できるサンプル数にしきい値を設定したり、実行可能なクエリのタイプを制限する分析ルールを設定したりすることも可能です。(公式ブログ)

この操作はBigQuery Analytics Hubを利用します。
UI操作上でデータクリーンルームの定義や作成を行うことで環境が簡単に作ることができ、そこに対してビューやテーブルを作成して追加・変更の処理を行うことができます。また、ビューに対してはプライバシーポリシーを適用することもできます。

元記事では具体的なUI操作やクエリのサンプルを説明しています。
元記事：BigQueryデータクリーンルームを活用してセキュアにデータを共有する

GA4 と Google Search Consoleデータをつなげた分析

数々の規制の憂き目に合っている我々デジタルマーケティングの分析屋ですが、環境さえ整えらればやはりBigQueryを媒介にして様々なデータソースを接合することに施行の喜びがあり、積極的に対応策や開発によって解決の余地を与えてくれるGoogleプロダクト郡は人気があります。

以下は、Google検索(SEO)のデータとGoogleアナリティクス4のデータをBigQueryによって統合して分析したユースケースです。

GA4 と GSC のデータをつなげてわかること
GA4のデータは自社サイト内のパフォーマンス、ユーザー行動を収集しています。
GSCのデータは、自社サイトがGoogleの検索結果として表示されたページ、検索キーワードを収集しています。
上述の通り、数々の規制によりプロダクト内に個情報を持たせられない(持たせたくない)ので、大前提として、GA4とGSCのデータは同じユーザーを識別できるデータを持っていません（2024年1月時点）。そのため、特定の検索キーワードでユーザーがサイトに来訪しコンバージョンしたか、という分析まではできません。
製品単体ではわからないことも、BigQueryにGA4、GSCのデータを連携することで、ランディングページと検索キーワードを組み合わせた分析が可能になり、おおむね以下のことが分析できるようになります。

• 自社サイト内で検索エンジン経由での流入が多い/少ないページと検索エンジン経由のコンバージョンやCVRはどうか
• 検索エンジン経由での流入が多い/少ないページが、よく検索されているキーワードはなにか
• 上記分析結果を踏まえると、以下のような施策の検討ができます。
• 検索エンジン経由の流入が少ない　かつ　CVRが高いページ
• リスティング広告を活用することで流入を増やし、コンバージョンを増やすことができる
• リスティング広告に入稿するキーワードは、そのページで実際に流入しているキーワードを参考にする
• 検索エンジン経由の流入が多い　かつ　CVRが低いページ
• CVRを改善した際のインパクトが大きい
• 流入時のキーワードを確認し、キーワードに合わせたコンテンツ改修をすることでCVRを改善できる

<サンプル>

with ga4 as ( 
  select 
    landing_page_location 
    , count(distinct ssid) as visit_all 
    , count(distinct case when landing_medium = 'organic' then ssid else null end) as visit_seo 
    , count(distinct case when landing_medium = 'cpc' then ssid else null end) as visit_cpc 
    , count(distinct case when event_name = 'セミナー申し込み完了' then ssid else null end) as cv_all 
    , count(distinct case when event_name = 'セミナー申し込み完了' and landing_medium = 'organic' then ssid else null end) as cv_seo 
    , count(distinct case when event_name = 'セミナー申し込み完了' and landing_medium = 'cpc' then ssid else null end) as cv_cpc 
  from 
  ( 
    select 
      user_pseudo_id 
      , first_value(page_location ignore nulls) over(partition by user_pseudo_id, ga_session_id order by event_timestamp asc) as landing_page_location 
      , first_value(source ignore nulls) over(partition by user_pseudo_id, ga_session_id order by event_timestamp asc) as landing_source 
      , first_value(medium ignore nulls) over(partition by user_pseudo_id, ga_session_id order by event_timestamp asc) as landing_medium 
      , event_name 
      , event_timestamp 
      , concat(user_pseudo_id, '-', ga_session_id) as ssid 
    from 
      ( 
        select 
          event_date 
          , user_pseudo_id 
          , regexp_extract(lower(util.get_value(event_params, 'page_location')), r'^([^\?]+)') as page_location 
          , util.get_value(event_params, 'ga_session_id') as ga_session_id 
          , collected_traffic_source.manual_source as source 
          , collected_traffic_source.manual_medium as medium 
          , event_name 
          , event_timestamp 
        from 
          `project名.analytics_251045496.events_*` 
        where 
          _table_suffix between '20231201' and '20231207' 
      ) 
  ) 
  group by 
    1 
) 
  
, gsc as ( 
  select 
    regexp_extract(lower(url), r'^([^\?]+)') as landing_page_location 
    , ifnull(query, '(anonimized)') as query 
    , sum(impressions) as imp 
    , sum(clicks) as click 
    , ((sum(sum_position) / sum(impressions)) + 1.0) as avg_position 
  from 
    `project名.searchconsole.searchdata_url_impression` 
  where 
    data_date between '2023-12-01' and '2023-12-07' 
    and search_type = 'WEB' 
  group by 
    1, 2 
) 
  
  
select 
  ga4.landing_page_location 
  , gsc.query 
  , gsc.imp 
  , gsc.click 
  , sum(gsc.click) over(partition by gsc.landing_page_location) as click_by_page
  , gsc.avg_position 
  , ga4.visit_all 
  , ga4.visit_seo 
  , ga4.visit_cpc 
  , ga4.cv_all 
  , ga4.cv_seo
  , ga4.cv_cpc 
from 
  ga4 
  left join 
  gsc 
  using(landing_page_location) 
order by 
  landing_page_location 
  , click desc 

元の記事では、上記のアウトプットにあたっての指標の説明やクエリについての補足説明や制限事項などを詳細説明しています。

元記事：GA4 と Google Search Consoleデータをつなげた分析

以上のように、分析としての機能だけでなくセキュアな環境までも提供するBigQueryが多くの現場で活用されています。Geminiの登場でクエリのサンプルをご紹介することも今後は減っていくかもしれません。なお、一層「なぜ」この環境、この出力結果が必要なのかの根本を把握しておくことが大切になってくることを念頭にこれまでも来年もBigQueryとともに走り抜けていきましょう！

了