WWDC2020で発表されたIDFAのオプトイン化について

2020年6月22〜26日で行われたWWDC(Apple Worldwide Developers Conference)にて、IDFA(Identifer For Advertising)をアプリが使用する際に、ユーザに許可を求める仕様（オプトイン）になることがしれっと発表されました。一部の業界内では激震が走っていて混沌とした状態です。わからないなりに少し整理してみようと思います。

まず、対象範囲ですが、
・iOS 14.0以降
・macOS 11.0以降
・Mac Catalyst 14.0以降
・tvOS 14.0以降
　※参考：https://developer.apple.com/documentation/apptrackingtransparency
となるようです。

下記のページにセッション動画ががあります。

Build trust through better privacy：https://developer.apple.com/videos/play/wwdc2020/10676/
　※IDFA関連の話は、26:59〜

ポイントとしては、

という内容になります。

１．は記載の通りですが、アプリがIDFAへアクセスする際には、下記画像のようなユーザーへ許可を求めるようになるのがデフォルト設定になります。
その際、ユーザー追跡する理由も明記する必要があります。

この許可は、仮に1度「Allow Tracking」を選択したら他のアプリでは必要無くなるかと言えばそうではなく、アプリ毎に許可が必要になるようです。

また、下記のように、アプリからのトラッキング設定を常に許す設定が存在し、これをONにすることで、毎回、アプリからIDFAの許可のリクエストをなくす事ができます。

※iOS14をまだ試せていないので難ですが、これは今までの[設定]->[プライバシー]->[広告]の画面がこれに変わるのでしょうか？もし、そうであれば、「いろんなアプリで毎回、許可求められるのがウザいから、も許可するでいいや」というユーザーがそこそこいるのでは？という妄想に思いを馳せています…

２．の変更について、簡単にいうとインストールイベントのポストバックをiOSが担うようにできるということのようです。

不要な情報をアドネットワークに流すこと無く、アドネットワークには必要最低限の情報のみを送信できるということなのでしょう。

セッション動画のスライドでは、「とにかくSKAdNetworkを使え」的なメッセージ。。

SKAdNetworkについては、下記のページも記載されています。
https://developer.apple.com/documentation/storekit/skadnetwork

上記のページに記載されているように、広告主アプリ(App B)が初回起動時に
registerAppForAdNetworkAttribution()
updateConversionValue(_:)
のメソッドを呼び出すとタイマーが起動し、そのタイマーの期限後にアドネットワーク(おそらく任意のエンドポイント)へポストバックが行われるようです。

この”タイマー”についてですが、updateConversionValue(_:)のドキュメントと見ると、24時間のようです。また、

The device sends the install notification to the ad network’s postback URL within 0-24 hours after the timer expires.

https://developer.apple.com/documentation/storekit/skadnetwork/3566697-updateconversionvalue

とあるので、24時間タイマーが切れてから、さらに0〜24時間以内にポストバックが行われるということでしょうか。

※この時差に関しては、「もう少し早くできないのだろうか？」という疑問はあります。。

また、ポストバックで実際どのようなパラメータを受け取れるのかは、下記のページに記載があります。

Verifying an Install Validation Postback
https://developer.apple.com/documentation/storekit/skadnetwork/verifying_an_install_validation_postback

iOS14以降では、バージョン2.0のポストバックパラメータになるようです。

・version

・ad-network-id

・campaign-id

・app-id

・transaction-id

・redownload Note: use the strings “true” or “false” to represent the Boolean value of the redownload parameter.

・source-app-id

と、ここまで今回のIDFAのオプトイン化とSKAdNetworkの変更点について整理してきましたが、ここからはIDFAのオプトイン化とはどういうことなのかを掘り下げていきたいと思います。

IDFAのオプトイン化へ進むことで、IDFAのアクセス許可を許すことにユーザーは明確なメリットを感じられないため、おそらく、ほとんどのユーザーが許可しない設定にすると思われます。IDFAを元にしたユーザーの捕捉の代替として、フィンガープリントという選択が出てきますが、今までは補完的な役割で使われていました。それは100%の精度を担保するのには向かないという特性やフィンガープリントの判定に対してアドフラウド(不正行為)が行われやすいという特性もあったと思います。精度やアドフラウドのリスクを考慮すると、メインでの使用は厳しいのではないでしょうか。
結果的に、リターゲティングやリエンゲージメントで、かなりのダメージを与えることになりそうです。

また、今回、Appleは、AppTrackingTransparencyフレームワークとSKAdNetworkの使用をセットで推奨してきました(参照：https://developer.apple.com/app-store/user-privacy-and-data-use/)。SKAdNetwork経由でのポストバックを握ろうとしている動きは、効果測定ツール/MMP(Mobile Measurement Partners)など、広告主にSDKを配布しているレイヤーにとっては、嫌な動きになりそうです。

一方、広告主やアプリデベロッパーに対しては、リターゲティングやリエンゲージメントという選択肢が無くなるというのはありますが、それを除くと影響は比較的小さいと思います(リタゲ、リエンゲージがでかいんだよ〜という声は聞こえてきそう…)。
SKAdNetworkの仕様や、IDFV(ID for Vendors)の存在も考えると、広告主やアプリデベロッパーが抱える自分たちのユーザーに対しての広告効果測定や分析に関しては、Appleは許容する方向であると思われます。
広告主/アプリデベロッパーが効果測定ツールを使用する流れは、しばらくは続いていくと思いますが、効果測定ツール/MMPの役割の一部をAppleが担うような変化は、今後ありうるかもしれません。

ちなみに効果測定ツールのadjustが、今回のIDFAのオプトイン化とSKAdNetworkの変更において、下記のブログで考えを示していて、参考になりました。

今回の変更にあたり、複数の業界リーダーと話し合った結果、今後考えられる４つのシナリオが示されています。

Option 1: iOS Referrer similar to Google PlayStore Referrer
Option 2: Fingerprinting
Option 3: Mandatory or incentivized opt-in
Option 4: More granular tracking permissions with attribution as an exception

https://www.adjust.com/blog/mobile-measurement-in-ios-14-four-possible-scenarios/

ざっくりニュアンスをまとめると下記な感じでしょうか。。(わかりやすくするため若干創造的ニュアンス入っています)

• Option 1: Google PlayStoreリファラーに類似した仕組みをiOSでも導入する方向が良いと思う。
• Option 2: このままだとフィンガープリントへの依存度はあがっていく。が、理想形とは思っていない(だから、妥当な代替案を用意すべきだ…)。
• Option 3: ユーザーに対して何らかのインセンティブ与えるなどIDFAアクセス許可へ導くアプローチを作るとかあり得る。ただしAppleの反応はわからない(おそらくネガティブな反応をしてくるだろう…)。
• Option 4: 実はユーザーの許可無しでIDFAへアクセスできる特例をAppleは用意していて、Appleが考えるプライバシーとオプトインに準拠すればIDFAを元にしたアトリビューションを行えるかもしれない(希望的観測…？)。

個人的な総括ですが、広告業界としては、「Appleが考えるプライバシーに準拠するのはOKです。ただ、準拠する仕組みにするにしても広告エコシステムに多大なダメージを与えない仕組みにできるはずなので、それを共に考えて行きましょう。」というスタイルであると思います。

一方、Appleは、「ユーザーのプライバシー保護は重要だと思っている。ただ、不特定多数のアプリおよびweb全体にまたがったユーザーの紐付けを行うことでの追跡型広告を制限しようとしているだけなので、広告主/デベロッパーが自身のアプリの広告効果測定やユーザーの分析をできないようにするつもりは無い」というスタイルだとは思います。ユーザーのプライバシーが大事としながらも、正直なところApple自身の優位性をキープするための動きという側面もあるんじゃないですかね。。その辺の大人の事情も加味しつつ、ユーザーのプライバシーを守り、かつ、広告エコシステムもきちんと回る仕組み…そんなシュタインズゲートは存在するのでしょうか…模索が続いていくイメージです。

どういう落とし所になるのか、引き続き、今後の動向については注意深く見守っていく（ときおり訪れるヒヤヒヤ感を楽しむ？）感じになりそうです^^;

---

フクロウラボではエンジニアを募集中です！！

エンジニア／昨対比200％で急成長中！広告主、メディア向けの管理画面を改修