プライバシーを保護した広告アトリビューションについて

♪ ♪ こんにちは Kateです Safari and WebKitチームで エンジニアをしています 本日お話するのは プライバシーを保護した 広告アトリビューションについてです このセッションをご覧の方は 広告アトリビューションに 詳しい方も多いと思いますが 皆さまの認識に 差が出ないように まずは背景情報として Cookie 広告 トラッキング についてお話します

それからPrivate Click Measurementという 複数サイトでの 広告キャンペーンの効果を プライベートに測定できる ツールをご紹介します 次に PCMをさらに拡張して App内で始まり Webでコンバージョンする キャンペーンを測定する 方法をご紹介します

最後に SKAdNetworkによる App-to-App Storeの プライバシー保護の 広告アトリビューションの 改善について話します

ではまずCookieの歴史と Web広告での役割について お話しします Cookieは企業にとって 有用です 広告アトリビューションを サポートするためです 広告アトリビューションは 広告に関係する クリックなどの行動と 購入など望ましい結果と 関連づけるプロセスです この望ましい結果は "コンバージョン"とも 呼ばれます 言葉で説明すると 少し抽象的なので 例を見てみましょう 私はロングボードが 好きなのですが 例えば私がロングボードの 広告を検索サイトの searchforlongboard.bizで クリックしたとします searchforlongboard.bizは Cookieという情報を ブラウザに保存します Cookieはユーザーが 以前にサイトを訪問した際の データを記憶できるように する文字列です 例えばカートに入れた 商品などの情報です

もしsearchforlongboard.biz に表示されたリンクを 私がクリックして別サイトの longboardshop.bizに アクセスし ロングボードをカートに 入れた場合 searchforlongboard.bizは 先ほど保存された Cookieを参照して 私の最初の広告のタップと この購入を関連づけます これが広告 アトリビューションの例です Cookieのデータにより searchforlongboard.bizは この広告キャンペーンの 効果を測定できます これは企業にとって 非常に役立ちます 最初に広告をタップして いない場合はどうでしょう searchforlongboard.bizは その場合でも 私に関するCookieの データを取得します 私が行ったクリック 訪問したサイト ページに留まった時間 その他の閲覧履歴や 行動履歴などの 詳しい情報です searchforlongboard.biz のような企業は この情報を利用して ユーザーを追跡し 広告主向けに詳しい プロフィールを作成できます ユーザーの同意なしにです これをクロスサイト トラッキングと呼びます 多くのユーザーは ネット上で 自分の興味や行動の情報や 個人情報が 保存やトラッキングされるとは 思っていません そのためトラッキングにより 信頼が崩れ ユーザーと企業の間に 溝が生まれることもあります 現在では多くのユーザーが コンテンツブロッカーなどの 仕組みを利用して 利用したサイトに関する トラッキングを制限しています ユーザーから見ると コンテンツブロッカーは トラッキングを防止する上では 非常に優れています しかし互換性の問題も よく生じます さらに すべての広告が ブロックされるので 広告アトリビューションは 一切不可能になります 広告とトラッキングに関して ユーザーと企業の間に 溝があると Webの利用体験が 大きく損なわれます そこでAppleは ユーザーの プライバシーの保護と Webの互換性の維持を 両立する方法を模索し

2017年にIntelligent Tracking Prevention(ITP)を 構築しました トラッカーを特定し Web上でのプロフィールが 作成されないように ユーザーを保護しますが 広告はブロックされません ITPを使用して 先ほどの検索サイトで 同じ広告をタップすると ファーストパーティー Cookieが保存されます そして私は longboardshop.bizに 移動してカートに ロングボードを入れます でも今回は Cookieと その他のWebサイト情報が searchforlongboard.bizに 送信されないように ITPが防いでくれました 広告をタップしたことは 分かるかもしれませんが 外部のサイトでの行動は トラッキングできません ITPはブラウザでの クロスサイトトラッキング の軽減に特化していますが トラッキングはWebに限られた ものではありません Identifier For Advertisers (IDFA)はiOS Appでの ユーザープロフィールの作成 に長く使用されてきました

2020年 Appleは SKAdNetworkを StoreKitフレームワークの 一部としてリリースしました Appのインストールを促す 広告に関するデータを 収集して報告します そしてアドネットワークに 広告アトリビューションの Privacy-Preserving技術を 提供します SKAdNetworkは昨年 強化されましたが それについては 後ほどお話します トラッキングはユーザーが 自分のどの情報が 共有されているかを 特定 理解 同意できない限り プライバシーの侵害 となります こう考えるのは 私たちだけではありません CCPAやGDPRなどの規制は Webサイトのユーザーに データの利用方法について 知らせることを 義務づけています BraveやFirefoxなどの ブラウザも組み込み型の トラッキング保護機能を 提供しています トラッキングに頼った ビジネスモデルは 持続可能ではないことが 明らかになってきています 私たちは 変化するエコシステムでの 成功を支援する上で プライベートな広告の 測定方法を提供する 重要性を理解しています では 残りの時間は プライバシーを守りつつ 広告を測定できるよう 実装されたいくつかの 新しいソリューションに 焦点を当てます 一つ目はWeb-to-Webの 広告アトリビューションです つまり最初のクリックと 最後のコンバージョンが どちらもブラウザ上で 発生する場合です

今年 Appleは新たに Private Click Measurement つまりPCMをリリースし プライバシー保護の 広告アトリビューションを Webに適用しました

PCMはW3Cの Privacy Community Groupで 標準化が提唱されています 完全に標準化されるには 他のブラウザにも導入される 必要があります 現在 PCMの標準化に向けて 他のブラウザと調整を 行っています

PCMは完全に デバイス上で行われる 広告アトリビューション レポートの仕組みです レポートで提供される エントロピーを制限するため サイト側はユーザーを 特定できません また PCMを使うと サイトをまたぐユーザーの トラッキングは行われません つまりApp Tracking Transparencyの要件は PCMの使用時には 適用されません

現在 Web-to-Webと App-to-WebのPCMは Safariで完全に サポートされています そのため ここから先で 私が"ブラウザ"という時には すべてSafariを指します 他のブラウザへのサポートも 追加する方向で 現在調整を進めています WebKitエンジンを 使用するブラウザも それ以外のブラウザも 対象です ここでもう一度 ロングボードの例を使って PCMの仕組みをご説明します ここでも searchforlongboard.bizで ロングボードの 広告をタップします PCMを使用する場合 このリンクでは さらに２つの情報が 指定されます １つ目はSource IDです ８ビットのエントロピーで 広告キャンペーンの 指定に使用できます ２つ目は広告の誘導先となる アトリビューション 宛先サイトです これらはデバイス上で ブラウザに保存されます longboardshop.bizへと 広告リンクが誘導します Add to Cartをタップすると longboardshop.bizは コンバージョンイベントの 情報を追加の値を使って 指定できます この追加の値は トリガーデータと呼ばれます トリガーデータは４ビットで Add to Cartや 購入などの行動を 指定できます これもデバイス上で ブラウザに保存されます

ではレポートは どうでしょう？ ブラウザのみが クリックした側と コンバージョンが発生した側 の情報を持っています そのため コンバージョンが 保存されたクリックに 合致するとブラウザは その情報から レポートを作成し 広告主に情報提供しつつ サイトをまたぐ ユーザーの特定は 防止できます

そしてブラウザは レポートの送信を 送信元と宛先の両サイトに 対して設定します 24～48時間後に 不規則に設定されます この不規則な遅れにより 時間に関する データが一切 提供されないので 広告クリックと コンバージョンを関連づけて 個人が特定されることも ありません iOS 15とmacOS 12では このレポートにIPアドレス 保護が付いています フィンガープリンティングの 防止には必須です IPアドレス保護については WWDCセッションの 「Appleがフォーカスする プライバシーの柱」をご覧ください

では 広告キャンペーンで 実際にPCMデータを 指定する方法を見ていきます 広告が表示される 送信元サイトでは リンク属性を使用して PCMデータを指定できます このロングボードの キャンペーンでは 識別子は55 コンバージョン先は longboardshop.bizです

宛先サイトでは アトリビューションイベント をトリガーできます 方法は 送信元サイトへの HTTP GETリクエストを作成し コンバージョンイベントの データを指定します 送信元サイトは このリクエストを受け取り このwell-knownロケーション にリダイレクトします ロングボードのカート追加の トリガーデータ値は15です 後にこのコンバージョンを もっと重要な 購入などに 上書きしたい場合は 6-bit priorityを 指定できます

このデザインは従来の ピクセルに対応しているので 導入がしやすくなっています

最後はレポートです レポートはJSON形式で このwell-knownロケーション に送信されます レポ－トでは 広告のクリックと コンバージョンを関連づける データは提供しますが ご覧のように ユーザーを特定できる 情報はありません この場合 わかるのは 誰かがどこかで ロングボードを longboardshop.bizで カートに追加したことです この情報により 広告キャンペーンの測定を 特定のユーザーを トラッキングすることなく行えます 以上がPCMを実装して Web-to-Webの 広告キャンペーンを 測定するための 基本です では PCMをさらに拡張して Appで使用する方法を ご紹介します これまで 多くの方から App内広告の Webでのコンバージョンを 測定することが重要だと 意見を頂き その対応が 必要だと気づきました そこでPCMのApp-to-Web アトリビューションも ご紹介いたします では例を使ってその仕組みを 見てみましょう まずSocial Appを開きます ロングボード仲間と つながれるAppです ロングボードの広告を タップします Source IDと 宛先サイトが デバイス上に保存されます そして誘導先はSafariの longboardshop.bizです コンバージョン側は Web-to-Webの場合と同じです Add to Cartをタップすると longboardshop.bizは コンバージョンを トリガーできます トリガーデータは ブラウザに保存されます

ブラウザはその情報を レポートに組み込み Appのレポートサイトと 宛先サイトに24～48時間 遅れで送信します

PCMのApp-to-Web アトリビューションでは アトリビューションレポート の宛先サイトを Appのinfo.plistに 追加し こちらのキーも合わせて 追加します このステップは必ず必要です というのも 登録可能なドメインを レポートの宛先URLから 取得して well-knownパスを作成し レポートを送信するからです

このwell-knownパスは Web-to-Webの時と同じです PCMのApp-to-Webでは Appのコードへの変更も いくつか必要になります キャンペーンを効果的に 測定するには 広告のタップが発生したかを 知る必要があります そのため新しいデータ構造を 追加しました UIEventAttributionViewです App内で広告を 表示すると UIEventAttributionViewが 新しく作成されるので それを広告の上に 置きます UIEventAttributionViewは ユーザーの動作を 検証してから アトリビューションの レポートを行うので データの精度が確保されます 広告がタップされると 新しいデータ構造の UIEventAttributionの 作成が必要となります App内で外部サイトの URLが開かれると このデータ構造が 送信されます ここには４つの要素が 入力されます sourceIdentifier これは広告キャンペーンを 識別します この例の場合 ロングボードの広告です 次にdestinationURL 広告のコンバージョン先です sourceDescription タップされたコンテンツの 説明です そしてpurchaser コンテンツの購入者の 説明です UISceneベースのライフ サイクル管理を使う場合 OpenExternalURLOptions オブジェクトを作成します そしてイベント アトリビューションを 対応するプロパティに割当て open関数を呼び出します UIApplicationベースの ライフサイクル管理を 使う場合は App-to-Webキャンペーンの サポートの追加方法は 少し異なります eventAttribution オブジェクトを含む 辞書の作成が 必要となります これでopen関数を 呼び出せます 作成した辞書をoptions パラメータの値とします 以上がApp-to-Web アトリビューションの 実装についてでした

SKAdNetworkの改良に 進む前に 少しだけPCMの不正防止 についてお話します PCMのレポートには個人を 特定する情報は入らないので コンバージョンレポートの 信頼性を サーバー側が確認する方法は 備わっていません そのためPCMは 暗号署名を使って 不正を防止しています 署名について 封筒の例で 説明します 仕組みはこうです searchforlongboard.bizで 広告のタップが行われると ブラウザがこのサイトの 公開鍵を取得します それからメッセージを作成し searchforlongboardが 後に検証します ただsearchforlongboard.biz がクリックと コンバージョンを 関連づけないように このメッセージを隠します メッセージを封筒の中に 入れるのと同じです ブラウザはその隠された メッセージを searchforlongboard.bizに 送信します そしてRSAブラインド署名 スキームを使って 隠されたメッセージに 署名が行われ 返送されます そしてカーボン紙のように 封筒上の署名は メッセージにも適用されます そのためブラウザが封筒から メッセージを抜き取ると そこには searchforlongboardの 署名が付いています アトリビューションが 発生すると ブラウザは searchforlongboardの 署名付きアトリビューション レポートを送信します これで送信元と 宛先のサイト はクリックが 行われた時に信頼性があると 見なされたことを searchforlongboardの 公開鍵で検証できます 元のメッセージを見ていない searchforlongboard.bizは 広告のクリックとの 関連付けはできません 不正防止については 以上です テストについても お話したいと思います 皆さんにとって テストとデバッグを 迅速かつ簡単に 行えることは 重要だからです WebKitには 実験用機能があります Private Click Measurement Debug Modeです macOSのSafariの Developメニュー下の Experimental Features にあります

iOSでは Debug Modeを オンにします WebKitのExperimental Featuresメニューにあります

デバッグモードでは強化した Web Inspectorログにより レポートが10秒毎に 送信され 24～48時間の遅れは ありません

PCMの活用した 広告キャンペーンの支援に ついては以上です

次に App-to-App Storeの 広告キャンペーンを 改善する方法を ご紹介します 最近アップデートされた SKAdNetworkを使います まず簡単にこれまでの SKAdNetworkの 概要を話します SKAdNetworkの基礎は 2020年のWWDCで 説明されています ですから仕組みに関する 詳しい情報については プレゼンテーションを ご確認ください 基本的にSKAdNetworkには ３つの要素があります Ad Network Publisher App Advertised App です 仮に 私がSocial App上で SocialAdNetから Longboard Appの広告を 提供された場合 SKAdNetworkの用語では SocialAdNetがAd Network Social AppがPublisher App Longboard Appが Advertised Appです Longboard Appの 広告をタップすると レポートが生成され Ad Network IDとPublisher App IDとCampaign ID タイムスタンプ 不正防止用の追加情報が レポートに入ります この情報はデバイス上で App Store内に保存されます 例えばLongboard Appの 広告により App Storeに誘導され そこでLongboard Appを インストールし起動すると Longboard AppはStoreKitが 提供するAPIを呼出します RegisterApp- ForAdNetworkAttribution または updateConversionValueです どちらもSKAdNetwork レポートをトリガーします どちらをいつ使うかは 資料を参照して ご確認ください StoreKitは有用な情報を レポートに組み込み AdNetworkに送信します 以上がSKAdNetworkの 背景情報です 次にこの１年間で行った 改良についてお話します SKAdNetworkを リリースして以来 皆さまのご意見に 耳を傾けながら 変更を行ってきました 変更の度に 機能を追加して ニーズに応えました セキュリティの強化 広告の測定方法や アトリビューションレポート の増加などです このセクションでは Signing Keyの改良 ビュースルー アトリビューションへの対応 複数のポストバック IPアドレス保護 開発者へのポストバック について話します また 各機能を 活用するために 最低限必要な iOSバージョンも紹介します まず バージョン2.1では より強固で安全な 256ビット公開鍵が 導入されました これを利用するには お使いのAppleの公開鍵を 更新してポストバックを 検証する必要があります

Appleの署名を確認する 具体的な手順は このセッションに付属する SKAdNetworkの資料の リンクからご確認ください

次に バージョン2.2では ビュースルーに対応しました 新しいSKAdImpression インスタンスを作成し 署名を生成して 新しい２つのAPIである startImpressionを カスタム広告を 表示する際に endImpressionを 広告の表示を終了する際に 呼び出します また StoreKitには 新たに フェデリティタイプという パラメータが導入されました StoreKitが表示する クリックスルー広告は フェデリティタイプ１ カスタムのビュースルー広告 はフェデリティタイプ０です これによりビュースルーの インプレッションは クリックスルー広告よりも 優先度が下がります ビュースルーのポストバック もフェデリティがより高い 競合するインプレッションが ない場合にのみ レポートされます iOS 14.6では複数の ポストバックと IPアドレス保護が 導入されました 現在 SKAdNetworkは ウィナーつまり１位の ネットワークと後続の５つに 対するレポート送信に 対応しています ウィナーのネットワークは コンバージョンの直前に 発生したインプレッション となります

レポートが生成されると ウィナーは 送信元Appや コンバージョン値など 匿名性が コントロールされた値を 受け取る可能性があります 後続のネットワークは この情報を受け取りません SKAdNetworkの新機能として 開発者へのポストバックも あります ウィナーのポストバックが 広告対象のAppに レポートされる仕組みです

この機能を活用するには info.plistでAppが 開発者のレポートサイトを 指定する必要があります PCMのApp-to-Webレポートに 必要なキーと同じ NSAdvertisingAttribution- ReportEndpointを 使用します

PCMと同じく plistで指定されたURLの 登録可能なドメインを使って well-knownロケーションを 作成し そこでポストバックが 送信されます

それでは新しい SKAdNetworkのテストと デバッグを成功させるための ベストプラクティスを いくつかご紹介します まず 各インプレッションの ノンスは 一意である必要があります これは不正防止や レポートの整合性を 維持する上で重要です 次に 署名の作成の際には 引数の順序が 重要です ですので このステップで 問題が発生した場合は 資料を参照して 引数の順序が 正しいか 確認してください ポストバックのテストでは 常にSourceAppIDが０の Development-signedの 送信元Appを使用します そして最後に テストプロフィールを使うと ポストバックの送信時間が 短縮されます テストプロフィールは このセッションに 付属するリンクから ダウンロードできます SKAdNetworkの 改良については以上です そして 今年の広告 アトリビューションに 関するセッションの内容も これで以上です

ご覧頂いたように この１年間で プライベートな広告 アトリビューションに関する 多くの機能の導入や 改良が行われました 本日の内容を 振り返ってみましょう

まず PCMをご紹介しました プライベートにWebで広告を 測定できる広告 アトリビューション機構です PCMは完全に Web上で測定される 広告キャンペーンのほか Appではじまり Webでコンバージョンする キャンペーンにも対応します

またこの１年で行われた SKAdNetworkへの アップデートもすべて 紹介しました このアップデートにより Appのインストールの測定が さらにプライベートかつ 安全で便利になりました

最後に 強調したいのは こうした技術の設計や 改良の多くは 開発者の皆さまからの ご意見を基に 行われました ありがとうございます そして今後とも よろしくお願いいたします PCMの標準化提唱に関する ご意見も歓迎します 内容は W3CのPrivacy Community Groupの GitHubページで ご確認いただけます

もし皆さまの中で プライバシーと広告は 両立しないと 考えていた方がいれば このセッションが その考えが変わる きっかけとなれば幸いです では 残りのWWDCも お楽しみください [アップビートな音楽]