こんにちは、喜田です。
私は昨年Snowflakeのデータクリーンルームに関する案件経験を発信して、SnowflakeのDataSuperheroes 2024に選出いただいたわけですが、そのデータクリーンルームが大幅進化を遂げて正式機能としてリリースになりました!🥳🎉🎊(2024年5月時点)
3月末に一部リージョンでGAされ、その時点では「データクリーンルーム」の利用にあたって専用の規約に合意したユーザーのみが使用可能でしたが、5月1日付けでSnowflake標準のサービスとして利用可能になっています。併せて利用可能なリージョンが拡充されています。(日本はまだですが・・・泣)
大幅進化の中身 – Native Clean Room –
これまでのデータクリーンルーム機能
Snowflakeでは、現在利用中の自社データをそのままの形でパーティ(企業・組織)をまたいで共有するデータシェアリングがあり、そこに様々な制限をかけることで「データクリーンルームとして求められる実装」を可能としていました。
少々前置きが長くなりますが、これまでの機能は廃止されるわけではないので、一つのパターンとしておさらいしておきます。
こちらの図で示しているのは、データシェアリングの技術はいずれも同じで、そのうちの1つのパターンとして行レベルのデータを見せずに集計値のみを見せる形を実現するのがデータクリーンルームの実装でした。テーブルや列に対して設定できる制限の種類には以下のようなものがあります。
- ダイナミックマスキングポリシー
- 行アクセスポリシー
- クエリ制約(Preview)
- 射影ポリシー
- 集約ポリシー
この中で、「行アクセスポリシー」ではGROUP BYやJOIN、集計関数の利用を強制する(そのようなSQLを事前に許可する)ことでデータから得られる分析結果のみが相手に渡るようにしていました。
/*
このSQLを丸ごとデータ提供元で許可する「行アクセスポリシー型のクリーンルーム」
1文字でも違えば未許可のSQLと判断され、結果が0件になる
*/
SELECT keyword,age,count(keyword),
FROM my_db.demo.customer AS local -- 自パーティーの表
JOIN from_dcr_provider.trends.user_trends AS remote -- クリーンルーム越しの表
ON local.user_id = remote.user_id
GROUP BY keyword,age;
「クエリ制約型」は比較的新しい機能で、テーブルや列に対するルールとして、この列はGROUP BY要素としてしか使わせない、GROUP BYの結果n行以下の結果は表示しない、といったことを宣言できます。その条件を満たせばクエリは自由に書けます。例えばWHERE条件一つの違いで都度発生する事前SQL許可が不要になり、より利便性の高い形でした。
/*
上記のSQLをGROUP BY列などルールに沿っていれば自由に実行できる
「クエリ制約型のクリーンルーム」
*/
SELECT keyword,age,count(keyword),
FROM my_db.demo.customer AS local -- 自パーティーの表
JOIN from_dcr_provider.trends.user_trends AS remote -- クリーンルーム越しの表
ON local.user_id = remote.user_id
WHERE billing_range BETWEEN 10000 and 50000 -- 自社データを使った絞り込み(可変)
GROUP BY keyword,age;
このSQLサンプルは「ユーザの年齢層」と「興味関心の高いキーワード」の組み合わせで該当者が何人いるかを集計しているものです。
自社サービスのユーザを年代別で分けた(縦軸)ときに、大手メディア企業とのコラボレーションによって入手した記事の閲覧実績と照らし合わせることで、30代は多趣味、10代はゲームに偏っているといった興味関心を把握(横軸)することができるという例です。
縦軸・横軸はSnowsightのヒートマップ機能で設定しており、関心度合いの高いところが濃く表示されているので一目瞭然ですね!
2本目サンプルSQLでは課金額(billing_range)をWHERE条件に記載しており、描画対象の母集団が課金額大きい人となり、よりビジネス影響の大きい人に注力して興味関心を捉えることができそうです。
と、ここまでがSnowflakeで従来利用可能だったデータクリーンルームの実装です。
このような従来から利用可能な機能は、データシェアリングによる企業間コラボ/企業内グループ内コラボなどを考えるときに当たり前の選択肢の一つとして、今後も有益なものと思います。
新しいSnowflakeのデータクリーンルーム
ズバリ、Snowflake標準の「データクリーンルーム機能」が登場したというのが今回の大幅アップデートの中身です。
- ウェブUIを備えてユーザーフレンドリーな分析が即始められる
- 構築が複雑だったデータクリーンルームを数クリックですぐ作れる
- 業種別テンプレートと、それに沿ったデータを選択するのみ
相手に合わせてシナリオ(SQL)を考え、制限と許可の範囲を考え・・・が不要
- 考慮漏れなどによるセキュリティ/プライバシー設定の誤りを防ぐ
- 差分プライバシーなどの更なるプライバシー保護に対応
- ショートスパンで繰り返しクエリすることで個人を特定することを防止
- Snowflake同士だけでない新たなコラボレーションの可能性
- 新たなアカウント種別「マネージドアカウント」
- S3やGCSのファイルとの突合
- Ad Tech、プライバシーTech関連とのエコシステムの構築
- 広告プラットフォーマーのウォールドガーデンとの接続
- ID関連サービスを使った結合キーのマッチ率向上
新しいWeb UI
超簡単に言うと、みんな大好きSnowsightに次ぐ、DCR専用のWebクライアント(Webサービス)がリリースされています。
このWebサービスに初回アクセスする際は、お使いのSnowflakeアカウントやユーザーとは全く別モノの「Webサービスのユーザー」をまず作成します。メアド認証などを経てログインした後に、今度は自身が管理するSnowflakeアカウントとの紐付け作業を行います。(ACCOUNTADMIN必須です。)
案内に沿って作業を進めると、WebサービスとSnowflakeアカウントの紐付けが完了し、アカウント内には以下が自動的に行われます。
- DCR管理用ユーザーが作成される
- マーケットプレイスで提供されるDCRアプリケーションがインストールされる
- DCR構築に必要な内部オブジェクト一式が作成される
このとき、各種内部オブジェクトに「samooha_by_snowflake」と言った名前がつきます。これは2023年冬に当時としてはデータクリーンルームの最先端を実現していたサービスSamoohaをSnowflakeが買収したためです。予備知識なしに単語を見ると「samoohaって何?」となりそうですが、データクリーンルームに関する機能ブランドのネーミングのようなつもりで受け取りましょう。
WebUIが備える機能
データクリーンルーム用のWebUIにログインすると、以下のような画面が用意されています。
左袖のメニューから大まかに機能を把握できます。
Analytics & Queries | 分析テンプレート一覧 参加済みのクリーンルームで提供されている分析シナリオの一覧です。 |
Clean Rooms | クリーンルームの作成や管理 「クリーンルーム」オブジェクトを作成して、分析シナリオを登録します。プロバイダーが提供するテーブル群、クエリ制限、公開相手を定義します。 公開相手に選ばれたコンシューマ側には「クリーンルームへの招待」という形で表示され、招待されたクリーンルームへの参加もこのメニューから行います。 |
Collaborators | クリーンルームを共有するパーティの登録 データプロバイダーがコラボレーション相手を登録する画面です。 ここで登録した相手のうち、各クリーンルームの中でさらに指定された相手のみがクリーンルームに参加できます。 Managed Accountsはプロバイダーが用意する非Snowflakeユーザー向けのDCR限定用途で利用可能なアカウントです。 |
Connectors | エコシステムとの接続 ウォールドガーデンDCRやIDソリューションとの統合を定義 |
Snowflake Admin | 自パーティのSnowflakeアカウントとの紐づけを管理 |
User Management | WebAppのユーザー管理 |
利用の中心となるのはClean Roomsですね。
シナリオに沿って、すぐ始めるパーティ間分析!
パーティ間で分析を行うにあたり、「シナリオ」を定義して、それに沿ったデータを両社が投入する必要があります。
シナリオの根本は、「こんな分析したいね、こんな結果が欲しいね」という両社の合意です。
そのためには、プロバイダーはこんなデータを提供します。コンシューマーはこんなデータを突合したときに(こんなSQLを叩けば)こんな知見が得られます。をしっかり考えておく必要があります。
これ、実は相当難しいです。
双方が相手のデータを知ったうえで、ウチのこのデータと突き合せればこんな知見が得られそう!を考えるわけです。NDAを締結前提だとしても、そこまですべてをさらけ出すことはなかなかしないし、その検討に至るまでに費用対効果の試算があって案件化するかどうか・・・コラボビジネスの実現までのハードルが非常に高いと言えます。
Snowflakeが提供するシナリオテンプレート
こちらがデフォルトで提供されているシナリオの設定画面です。
Audience Overlap、Reach & Frequency、Last Touch Attribution といった広告にありがちなキーワードが並びます。シナリオを選ぶと、そのシナリオで入力必須のデータや、具体的にどのような制限をかけるかといった詳細を入力することができます。
例えばリテールメディアのような例を考えます。広告ビジネスが主ではなかった企業が、自社ECサイトというリソースを広告主に貸し出して、広告主にメリットのあるプロモーションを行うわけです。
一定期間のプロモーションを行い、さて広告主にとって売り上げ影響はあったでしょうか?
世のトレンド等を排除して、このECサイトの広告から商品を買ってくれた効果を正確に測るにはデータを見るほかありません。「広告掲載枠を貸し出す」というビジネスですが、そのためにはアクセスログデータの授受するための契約、データ授受のためのインフラ構築、広告効果を可視化するUI実装といった様々なシステム的な準備が必要になり、これは従来、非テック企業が新たなデータビジネスに舵を切るのに大きなハードルになっていました。
Snowflakeのクリーンルームで提供される標準シナリオでは、ECサイトがプロバイダー、広告主がコンシューマーになって、両社のウェブのアクセスログを突き合わせることができます。Audience Overlapではメールアドレスなどの個人を特定するキーを用いて顧客の興味関心を理解すること、Reach & FrequencyやLast Touchでは時系列データの投入が必須になっており、同じタイムライン上で「広告を見たあとに購買につながった」といったことが判断できそうです。(実はこのあたりの詳細なガイドがないので、設定画面からの今時点の推測です。)
機械学習を拡張する新たなユースケース
(こちらも詳細がガイドされていないので徐々に調査を進めている、という段階ですが、)クリーンルームで示される示唆は「プライバシー保護」「集計値を返す」といったことが言われますが必ずしも集計値に限る必要はありません。
クリーンルームはあくまで安全なデータの受け渡し場所であって、そこに投入したデータをインプットとして「何らかのロジックを使って入力に対してアウトプットをくれる関数」と見ても良いのです。
Audience Lookalike Modeling、Inventory Forecastingといったシナリオでは、機械学習モデルに学習させるデータをプロバイダーが提供するようになっており、学習済みモデルを使ってコンシューマーのインプットに対して属性付けしたり、将来予測するような使い方ができそうです。
終わりに
語りたいことはいろいろあるのですが、巨大なイチ製品ともいうべき機能群を成す様々なサブ機能が一挙に登場したため、どこから手を付けようか・・・ということで、まずは目新しいUIが登場したこと、UIに沿って用意されたシナリオテンプレートを使ってすぐ始められる!という部分をご紹介しました。
これからも続々来るであろうデータクリーンルーム、データビジネスについてのアップデートを追いかけつつ、様々な企業様と会話しながらデータビジネスの新たな可能性を一緒に模索していければと思っています。
この記事へのコメントはありません。