iOS 14による運用型広告の広告配信やトラッキングに対する影響まとめ

iOS 14による運用型広告の広告配信やトラッキングに対する影響まとめ

米アップル社は2020年9月16日(日本時間では9月17日)にiPhoneやiPad、iPod touch向けの最新OSであるiOS 14をリリースしました。

iOS 14ではITP(Intelligent Tracking Prevention)機能、端末の広告識別子であるIDFA(Identifier For Advertising)の利用にユーザーの許可を必要とする機能といったプライバシー保護機能の強化が図られており、より個人のプライバシーが守れるようになった一方で、広告の効果測定やターゲティングに利用できるオーディエンスデータ(行動履歴や興味関心など)の取得がさらに厳しくなりました。

参考:Build trust through better privacy – WWDC 2020 – Videos – Apple Developer

今回発表や実装がされたiOS 14のアップデート内容のうち2点が広告の配信や計測に影響を与えることになります。

1つはSafari以外のブラウザアプリや、アプリ内ブラウザ機能の多くにもITPが適用される事になったという点。もう1つはIDFAの利用にユーザーの許可を必要とする機能の実装(2021年初頭に適用予定)、つまりIDFAのオプトイン化です。

本記事では、この2つのアップデートが運用型広告プラットフォームへどのような影響を与えるのかについて解説いたします。

※注1:記事執筆に当たっては、2020年9月25日現在に確認できた様々な1次情報を元にしておりますが、筆者の解釈などに誤りがないとは言えないため、誤った点がありましたらぜひご指摘ください

※注2:IDFAの利用にユーザーの許可を必要とする機能の実装による影響については、今後変更になる可能性もあります。本記事では予定通り各機能が変更なくリリースされた場合の影響について述べます

1. iOS 14、iPadOS 14下で実行されるすべてのブラウザでITPが有効化される

iOS 14やiPadOS 14下で動作するブラウザのすべてでITPがデフォルトで有効になります。これはSafariだけではなく、iOS版のGoogle ChromeやMozilla Firefox、Operaなども対象となったことを意味します。

また、これらのブラウザアプリだけではなく、アプリ内でブラウジング機能を有している場合もITPがデフォルトでオンとなります。厳密に言うと、アプリがWKWebViewクラスを利用しているiOSアプリにおいては…ということになるのですが、そこまで考えるとややこしくなってしまうので、iOS 14で動作するアプリのうち、ブラウジング機能を有するアプリと覚えとくと良いかなと思います。ざっくりではありますが。

これによって、すべてのブラウザでJavascriptを用いて発行されたCookieの保持期間が最大7日に設定されることになります。

Google 広告やYahoo!広告などが発行する計測タグ(グローバルサイトタグやサイトジェネラルタグ、Pixelなど)を利用して、ブラウザに1stパーティCookieをセットする仕組みでは、広告をクリックした後にITPによってクロストラッキング機能を有するドメインに分類されます。さらに自動タグなどによってクリックIDなどがランディングページのURLにリンクデコレーション(注1)として付与されていると、Cookieの保持期間は最大24時間にさらに短縮されることになります。

※注1:リンクデコレーションとはURLの末尾にて「?id=abc123&q=shoes」のように「?」で始まるクエリパラメータを付加(デコレーション)することを指します

コンバージョン計測やオーディエンスリストの保持期間が最大で24時間になってしまうというのは、2019年に機能強化されたITP2.2からの仕様です。iOS 14ではSafariだけではなく、すべてのブラウザでこの機能が有効になりました。

余談ですが、有効期限内にWebサイトへの再訪があった場合などは、有効期限が更新されるという点も覚えておきましょう。再訪によってさらに24時間は有効になるので、すべてのデータが24時間で消去されるわけではないというのがポイントです。

例えば再訪が多いWebサイトであれば、再訪のたびに有効期限が更新されるので、24時間~7日を超えても計測に必要なデータをCookieに保持しているケースも見受けられます。

影響を受ける主な広告プラットフォームと影響範囲

Google 広告、Yahoo!広告、Facebook広告、Twitter広告、LINE広告など、広告クリック情報をJavaScriptで生成した1stパーティCookieに保持して計測する広告プラットフォームのすべてで影響を受けます。コンバージョン計測、オーディエンスリストでの保持期間が最大24時間に短縮されることに。

ITPはデバイスレベルで機能するため、必ずしも24時間に短縮されないケースも見受けられるものの、基本的には最大24時間までしか情報は保持されないと考えておくのが良いでしょう。

よって、すぐに影響が出るのはリターゲティング広告の配信割合が高い広告アカウントと、休眠ユーザーの再想起が重要なビジネス(検討期間が長いBtoB商材等)になると言えます。

しかしながら、すでにITP2.2で実装されている機能に対して、適用範囲が広がったというのが今回の更新のため、iOSでChromeやFirefoxといったSafari以外のブラウザアプリを使っているユーザーの割合はそこまで高くないような気がするので、影響範囲は限定的かもしれません。

ブラウザアプリ以外のアプリに関しても考えてみます。

アプリ内広告をクリックしてそのまま同じアプリ内でウェブサイトを表示するケースでは、アプリ内ブラウザでITPが有効になるケースもあるので、アプリ面からのコンバージョン計測に影響が出そうです。

しかしながら、アプリ内ブラウザでページを開いて24時間以上放置することもほぼありませんし、iOS 11以降ではアプリ内ブラウザで保持されたCookieがSafariや他のブラウザアプリと共有されることもありませんので、アプリ内の広告クリックに対してITPが適用されたとしても、その影響は非常に軽微なものと考えられます。

したがって、ブラウザアプリ以外のアプリにおけるITPの影響というのはそこまで大きくないのかなと考えられます。

2. IDFAの利用にユーザーの許可を必要とする機能の実装による影響

IDFAの利用にユーザーの許可を必要とする機能が実装された場合、デフォルトではIDFAの取得は不可となります。そのため、IDFAの取得を行うためには、アプリ上でAppTrackingTransparencyというフレームワークを使う(アプリ開発時に実装する必要があります)ことで、ユーザーにトラッキングに対する承諾を得る必要があります。

この画面にて許可を選択することで、アプリ内での行動(イベント)の取得やエンゲージメントを計測することができるようになります。アプリ内で収集されたそれらの情報は、個人情報を含まない匿名化されIDFAに紐づきます。

IDFAが収集できることによって、広告によるアプリインストールキャンペーンの計測やリエンゲージメントキャンペーンによる休眠ユーザーの掘り起こしを行うことができるようになるのです。

また、IDFAにはユーザー属性(年齢、性別、興味関心)の情報も含まれるため、これらを収集して類推された類似ユーザーのターゲティングにも活用されます。

つまりIDFAが収集できなくなると、アプリインストールキャンペーンの計測や、リエンゲージメントキャンペーンの実施が難しくなるほか、収集したIDFAからの類似ユーザーターゲティングの精度も下がることになり、目に見える広告効果は大幅に下がることになります。

2-1. アプリインストールキャンペーンではコンバージョン計測でデータの欠損が発生する

IDFAを利用したアプリインストール広告のコンバージョン計測では、①広告をクリックしたときに収集されるIDFAと④アプリを起動したときに収集されるIDFAを突合させ、一致すればコンバージョンとしてカウントする仕組みが一般的です。

そのため、IDFAの取得が許可制になることで、広告をクリックしたときアプリ(ブラウザアプリを含むアプリ全般)とインストールしたアプリの両方でIDFAの取得が許可されていないと、前述の①と④の突合したときに不一致となってしまい、コンバージョンとしてカウントされなくなってしまいます。

Apple社としてはこういった計測の欠測などを防ぐために、IDFAの代わりとなるSKAdNetworkという機能を提供しています。

参考:SKAdNetwork | Apple Developer Documentation

このSKAdNetwork機能により、アプリのインストールについては継続して計測ができるようですが、広告シグネチャを付与するプラットフォーム(Ad Network)、シグネチャ付きの広告(広告枠)を表示させるアプリ、広告で宣伝されるアプリ、第三者のアプリ計測プロバイダ(利用する場合)のすべてでSKAdNetworkに対応している必要があります。

また、SKAdNetworkでも収益額といったようなデータの取得はできるとされていますが、IDFAを利用した場合よりも取得できるデータの粒度が荒く、詳細な広告キャンペーンデータとの紐付けができないなど、これまでほどのデータは取得ができなさそうです。

2-2. リエンゲージメント広告が実施できなくなる

リエンゲージメント広告は、例えばアプリのインストールがされているもののしばらく利用していない端末に向けて、アプリの利用再開を促すための広告で、その端末にインストールされている別のアプリの広告枠に広告を配信するというものです。

例として、アプリAをしばらく利用していないユーザーに対して、そのユーザーが同じ端末にインストールしている別のアプリBに広告を配信することで、アプリAの利用再開を促すとします。

このとき、アプリAで取得されたIDFAとアプリBで取得されたIDFAが一致した場合、休眠ユーザーに広告が配信されるのですが、どちらかのIDFAが取得できないとマッチングが取れないため、広告の配信ができなくなってしまいますね。

2-3. アプリの広告面に対するターゲティング精度が低くなる【2020年10月14日追記】

アプリ内に表示される広告は、広告のリクエストを行う際にIDFAを載せることがあります。

ターゲティング広告では、広告リクエストとともに送られたIDFAを利用して配信する広告を決定するケースもあるため、アプリからこのIDFAが取得できなくなるとターゲティングの母数が少なくなるということになります。

よって、ターゲティングの母数減少と連動する形でインプレッション数が減少したり、属性を類推して広告配信を行うケースではターゲティングの精度が低下し、広告費用対効果を合わせようとして結果的にインプレッション数が減少するなどの影響が考えられます。

影響を受けると考えられる主な広告プラットフォームとそのメニュー

IDFAの利用にユーザーの許可を必要とする機能が予定通り実装された場合、コンバージョン数の欠測やターゲティングなどの精度が下がると考えられますが、実際どのような配信が対象となりうるのでしょうか。

各プラットフォームのヘルプなどから、IDFAの利用が可能であると判明しているプラットフォームと広告メニューを抜粋しております。

Google 広告

アプリキャンペーン

iOSアプリのコンバージョントラッキングには、Firebaseか第三者のアプリ計測プロバイダが必要になりますが、どちらも基本的にはIDFAの利用をした計測を行っているため、コンバージョンやイベントデータに欠損が発生すると考えられます。

現時点(2020年10月12日)では、広告表示先となるアプリで利用されるAdMob(Google Mobile Ads SDK)や、Firebaseなど広告枠や計測の部分ではSKAdNetworkの対応が進んでいるようですが、Google 広告としての対応についての発表はありません。

参考:Prepare for iOS 14+ | Google Developers

参考:Firebase iOSリリースノート

カスタマーマッチでモバイル端末 ID(IDFA)を利用したリスト

広告配信先となる端末のIDFAが取得できなくなるため、インプレッション数の減少が予想されます。

アプリ面への広告配信【2020年10月14日追記】

アプリに広告を表示させるために利用されるAdMobやGoogle アド マネージャーでは、広告リクエストにIDFAを載せているため、アプリの広告面へ対するターゲティング精度が低くなり、インプレッション数の減少が発生する可能性があります。

参考:リリースノート  |  Google AdMob  |  Firebase ※Google Mobile Ads SDK ではver.6.5.0より

Yahoo!広告

アプリダウンロード用広告とアプリ訴求キャンペーン

iOSアプリのコンバージョントラッキングには、第三者のアプリ計測プロバイダが必要になりますが、基本的にはIDFAの利用をした計測を行っているため、コンバージョンのデータに欠損が発生します。

現時点(2020年10月12日)では、SKAdNetworkへの対応など具体的な予定に関する公式発表はまだありません。

アプリ面への広告配信【2020年10月14日追記】

アプリに掲載される広告の表示にIDFAが利用されているケースがあるため、アプリの広告面へ対するターゲティング精度が低くなり、インプレッション数の減少が発生する可能性があります。

参考:Yahoo! JAPANが配信する広告などへのパーソナルデータの利用 ※スマートフォン端末の広告設定について

Facebook広告

モバイルアプリインストール広告・モバイルアプリエンゲージメント広告

iOSアプリのコンバージョントラッキングには、Facebook SDKか第三者のアプリ計測プロバイダが必要になりますが、どちらも基本的にはIDFAの利用をした計測を行っているため、コンバージョンやイベントデータに欠損が発生します。

Facebook社ではAppleのポリシーの詳細が確定するのを続き待ち受けている状況です。iOS 14デバイス用のアプリにおいてもIDFAの収集は継続する一方で、SKAdNetworkへの対応も予定。そのためFacebook SDKの新バージョンの利用が推奨されます。

参考:Preparing Our Partners for iOS 14

カスタムオーディエンスでIDFAを利用したオーディエンス

広告配信先となる端末のIDFAが取得できなくなるため、インプレッション数の減少が予想されます。

Audience Networkへの配信【2020年10月14日追記】

アプリに掲載される広告の表示にIDFAが利用されているケースがあるため、アプリの広告面へ対するターゲティング精度が低くなり、インプレッション数の減少が発生する可能性があります。

参考:iOS 14に向けたAudience Networkの対応 | Facebook Audience Network

Twitter広告

アプリのインストール数キャンペーン・アプリのリエンゲージメント数キャンペーン

モバイルアプリのコンバージョントラッキングを行うには、第三者のアプリ計測プロバイダが必要。Twitter社は、2020年9月28日時点でSKAdNetworkの対応を予定していると発表しているため、アプリの開発者に対してSKAdNetworkへの対応を呼びかけている。

参考:iOS14アップデートに伴う対応事項について

カスタムオーディエンスでモバイル広告ID(IDFA)を利用したオーディエンス

広告配信先となる端末のIDFAが取得できなくなるため、インプレッション数の減少が予想されます。

LINE広告

アプリのインストール・アプリのエンゲージメント

アプリのインストールやオープン等イベントの効果計測をするためには、LINE広告が連携している効果計測SDK(第三者のアプリ計測プロバイダが提供)の導入が必要になり、これらの効果計測SDKでIDFAを利用している場合は影響を受けます。

2020年9月25日現在、SKAdNetworkへの対応など具体的な予定に関する公式発表はまだありません。

IDFA利用したオーディエンス

広告配信先となる端末のIDFAが取得できなくなるため、インプレッション数の減少が予想されます。


Googleであればfirebase SDKやMobile Ads SDK、FacebookであればFacebook SDKやAudience Network SDKが提供されていますが、いずれも基本的にはIDFAを利用するため、iOS 14の影響は受けてしまいます。

IDFAのオプトイン化はプラットフォーマーからも懸念の声が

IDFAの利用に際してユーザーの許可を必要とする機能が実装された場合、ユーザーの多くが”許可しない”を選択するであろうという予測から、iOS 14におけるオーディエンスデータの収集がほぼできなくなるという懸念があります。これに対してFacebook社が異例の声明を発表したことは記憶に新しいところです。

参考:iOS 14に向けたAudience Networkの対応 | Facebook Audience Network

Facebook社を始め多くの広告主から怒りを買った影響なのかは定かではありませんが、この機能の適用は2021年初頭まで延期となりました。しかしながら、あくまでもアディショナルタイムに突入しただけであって、現時点で適用内容に変更はありません。

これは完全に筆者の個人的な推測ですが、Apple社として完全にIDFAを取得できないような状況を作ってしまうと、広告のプラットフォーマーや広告主、アプリのデベロッパーすべてを敵に回す形になることになるでしょう。IDFA取得の許可をすべてユーザーに委ねることによって、Apple社としては逃げ道は確保しつつ、間接的にIDFAの取得が困難になるような状況を作り出し、実質的にIDFAがほとんど機能しないような状況に追い込みたいのだと思います。生かさず殺さずといった言葉が適切かもしれません。

3. 【番外編】CNAMEクローキングも制限の対象になる予定

前述の1と2はiOS 14のリリースに伴う機能強化ですが、これ以外にもCNAMEクローキング(CNAMEを使った計測)に関して制限が掛かる可能性が出てきました。

参考:215201 – Experimental: Cap the expiry of persistent cookies set in 3rd-party CNAME cloaked HTTP responses

CNAMEクローキングというのは、DNSレコードのうちのCNAMEレコードを用いて、第三者ドメインへのデータ送信を自社ドメインへのデータ送信と見せかける手法です。

この方法により、JavaScriptではなくサーバー側で発行した1stパーティーCookieをセットすることができるので、ITPの制限を受けることなく計測を行うことができていました。

しかしながら、この方法で付与されたCookieについても制限する必要があるとされ、今後は有効期限が設定されるようになる見通しです。

このCNAMEクローキングに対する制限は、日本時間2020年10月9日にリリースされた開発者向けの Safari Technology Preview 114 に実装がされており、大きなバグなどが発見されなければ次期バージョンのSafariにて正式実装される見込みです。

与えられたルールの中で最大限のパフォーマンスを出すためには?だけを考えよう

広告プラットフォームから提供されるコンバージョン計測の仕組みによって、JavaScriptで生成されたCookieを利用している限りは、24時間という有効期限の壁を超えることはありません。再訪による有効期限の延長はあるにせよ。

いまのところ、広告の計測に必要となるデータをCookie以外のストレージに保存することで、データの保持期間を7日まで延長することは可能です。ただし、プラットフォーム側でその対応が必要になりますし、今後Cookie以外のストレージが7日よりも短縮される可能性が無いとは言えないという課題が立ちはだかります。

以前よりアナグラムのブログでもお伝えしていますが、プライバシー保護の強化はデバイスを提供する企業によるルールチェンジのため、このルールチェンジによって発生する取得データの断片化に対しては、広告プラットフォーム側での対応を待つほかありません。

僕らは与えられたルールの中でどう成果を出すか?という考えにシフトする必要がありますし、シフトしなければなりません。これはITPが登場した当初から変わらない考えだと思います。

計測はJavaScriptで生成されたストレージに依存しない時代へ

前項でも触れたとおり、デバイス側で広告のクリック情報をJavaScriptで生成したCookieやそれ以外のストレージで保持しようとしても、最終的に制限がかけられてしまうということもあり、一部のプラットフォームではJavaScriptで生成されたストレージに依存しない計測方法の提供を始めています。

Google はGoogle タグマネージャにおいて、サーバーサイドタグ機能を提供し始めました。

参考:【コラム】GTMの新機能 サーバーサイドタグは新時代の幕開けか? – コラムバックナンバー | アナリティクス アソシエーション

参考:GTMにサーバーサイドで動作するサーバー用コンテナが登場

詳細を説明すると長くなってしまうので割愛しますが、これまでJavaScriptを使って発行していたCookieをサーバー側で発行することが出来るようになるので、現時点ではITPの制限を受けないというメリットがあります。

Google タグマネージャのサーバーサイドタグ機能はベータ版のため、現時点で対応しているプロダクトはGoogle アナリティクスのみですし、Google Cloud Platformを利用するために費用がかかるといった面もありますが、今後のアップデートに期待が持てる機能だなと思います。

また、FacebookではコンバージョンAPI(CAPI)を利用して計測の補助を行う仕組みを提供しています。

参考:コンバージョンAPIについて | Facebook Businessヘルプセンター

これは広告主の所有するサーバーからAPIを通じてイベントを送る仕組みとなっているので、ITPといったブラウザ側の制限を受けることなく効果測定が行える(注2)というものです。

【2020年10月12日追記】
※注2:コンバージョンAPIで計測の補完が可能になっているとはいえ、Facebook広告も現時点ではピクセルによるCookie計測がベースになっているため、今後は制限を受ける可能性はゼロではありません

APIによって送信されたイベントはFacebook Pixelとリンクされているので、Facebook広告のパフォーマンス改善にも役に立つとされています。

ここで紹介したサーバーサイド計測を実現するには、高い実装ハードルをクリアする必要がありますが、一方でセキュリティを高められたり、ページの読み込みや表示速度の高速化が見込めるといったメリットもあります。

近い将来に訪れるポストCookieの世界では、恐らくAPI活用を含むサーバーサイド計測が主流になるのではないかと考えられますので、今すぐは実装できないとしても、いつでも対応できるように情報だけはキャッチアップしておいたほうが良いでしょう。

Cookieとの決別はApple社にしかできない偉業かもしれない

Cookieは10年近く前からプライバシー保護の観点で問題視され続けてきたものの、それに代わるものが登場することなく時間だけが経過してきました。ハードウェアやソフトウェアは目覚ましい進化を遂げ続けているにもかかわらず……です。

そこで一石を投じたのがApple社です。

ITPの登場からOSレベルでのプライバシー保護機能の強化の片鱗を見るに、Apple社があえて広告業界から嫌われ者になることで、これまでもなかなか脱却できなかったCookie計測に依存する世界から、Cookie計測に依存しないセキュアな計測の世界を実現という現状の外側の目標に対して、業界を牽引する役割を果たしているのではないか?とさえ思えるようになってきました。

恐らくApple社がこれらのような行動を起こさなければ、あと数年~十数年はまだまだCookieに依存する世界が続いていたかもしれません。

もちろん、業界としてはCookieに代わるプライバシー保護強化と、計測できる仕組みの整備との両輪で動けるのが理想ではあるのかなと思いますが、これまでそうしようとしても動かなかったからこそ、今のような状況になったのかなとも思います。

そう考えると、「Apple社のせいで……」ではなく、「Apple社のおかげで……」と思える一面も出てきますね。

今後もプライバシー保護の強化と計測環境の変化については、引き続きアンテナを張って注視していきます。

この記事のURLをコピーする
Hiroki Tanaka

Hiroki Tanaka

アナグラム株式会社 シニア テクニカルアカウントマネージャー。元公共放送の放送エンジニアからのキャリアチェンジで、前職の広告代理店にリスティング広告の運用コンサルタントとしてこの世界に飛び込む。その後、2012年1月にアナグラム第1号社員として入社。広告運用、クルーのブログの編集と自社Webサイトの管理、Googleアナリティクス・タグマネージャー・データフィードなどに関する技術支援、セミナー登壇、社内整備など経営以外の領域をだいたいカバー。お酒が飲めないのにワイナリーの収穫祭に参加する人。書籍「いちばんやさしい[新版]リスティング広告の教本」の著者。

最近書いた記事