iOS14のIDFA関連記事をまとめました

### [iOS 14における広告トラッキングの変更の適用延期について | Adjust](https://www.adjust.com/ja/blog/what-you-need-to-know-about-the-delay-to-ios-14-ad-tracking-changes/)

#### 概要

- App Tracking Transparencyフレームワーク用のAppleポップアップを表示しユーザーから許諾を得なくても、以前と同様にIDFA(Identity for advertisers, 広告識別子)を取得できる。
- ユーザはアプリベースで個別にトラッキングを拒否できる。ユーザーが全てのアプリのトラッキングを拒否した場合、IDFAはリセットされる。
- アプリのrequestTrackingAuthorizationコードにより、ユーザーはアプリ毎にオプトアウトができる。
- requestTrackingAuthorizationのメソッドが呼び出され、ユーザーが同意のリクエストを拒否した場合、IDFAは取得できない。
- 上記の変更点は2021年初旬まで有効となる。

#### IDFAへのアクセス

- iOS 14ベータ版のバージョン7では、ユーザーのIDFAはデフォルトで取得可能となっており、ユーザーがトラッキングをオプトアウトする場合にのみIDFAを取得できなくなります。Appleによると、同機能はユーザーのプライバシーに対する仕様変更が完全に適用される来年初旬まで保留となります。
- 「Allow Apps to Request To Track （Appからのトラッキング要求を許可）」がOFFにされ、再びONにされた場合にのみIDFAがリセットされます。あるいは、デバイスの全てのアプリでオプトアウトされた場合も同様です。

#### Adjustが推奨すること

- **まず理解しておきたいのは、アプリパブリッシャーは自社のアプリにとって最適なユーザー同意フローをテストし調査してから、初めてATTフレームワークをProductionモードで実装するべきだということです。これは、現在の仕様ではATTがユーザーを早すぎるタイミングでオプトアウトする選択肢に誘導してしまう可能性があるからです。**
- **今回延期が発表されたことにより、アプリ開発者はiOS 14のユーザープライバシー変更への準備を余裕を持って行うことができるようになりました。この期間を有意義に使い、同意フローとUXデザインの最適化を行いましょう。Apple社は、来年初旬にアプリレベルでの同意が導入されることを明らかにしました。アプリマーケターはこれに備えて同意フローを改善し、同意率が高まるような仕組みを取り入れることが重要となります。ユーザーがオプトアウトするとIDFAが取得できなくなるため、全てのユーザーに向けて同意ポップアップを配備する前に、フローを徹底的にテストする必要があります。効果的な同意フローの設計については、ブログ記事「[iOS 14のユーザー同意を確保するためのオプトインの設計方法](https://www.adjust.com/ja/blog/getting-the-opt-in)」を参考にして下さい。**
- **来年の初めまでにできる限り多くのテストを社内で実施し、Appleがガイドラインを施行する少し前になったらATTを実装するのが賢明だと言えます。ATTが実装されたその瞬間から、ユーザーはアプリ毎にIDFAの共有をオプトアウトできるようになります。このような取り組みにより、アプリ開発者はユーザーがオプトアウトするリスクを負うことなく、同意フローを十分にテストできます。**

#### SKAdNetwork

- SKAdNetworkはiOS 14ベータ版のバージョン7では大きく変更されておらず、これまでと同様のデータを提供しています。しかし、9月3日のApple社による延期発表により、業界各社はSKAdNetworkをテストし、アナリティクスおよび最適化のためのconversion value（コンバージョン値）のロジックを開発する時間ができました。
- 業界各社がSKAdNetworkの機能性をテストするためのサポートとして、Appleはタイマーを5分間に短縮した新たなSKAdNetworkプロファイルをリリースしました。このプロファイルは、ローカルのテストデバイスで実装され、テスト目的のみに使用されるのを意図して設計されています。

#### Adjustが推奨すること

- **現時点ではIDFAの取得は可能ですが、SKAdNetworkのテストを開始し、アプリ開発者や業界全体がどのようなインサイトを得られるかを調査しましょう。このテストを通してSKAdNetworkの制約を理解し、対応策を検討することができます。特にconversion valueに関しては、アプリ開発者がSKAdNetworkを活用するには、どのロジックを適用させ、どのイベントが各値と紐付くのかを理解することが重要です。**

---

### [iOS14のユーザー同意を確保するためのオプトインの設計方法 | Adjust](https://www.adjust.com/ja/blog/getting-the-opt-in/)

- iOS14が業界に与える影響については、こちらのブログ記事で解説していますので是非ご覧ください。 **iOS14では、アプリ開発者がAppleの許諾ポップアップをアプリ内で表示させるチャンスは1度しかありません。** つまり、より多くのユーザーから同意を得るためには、アプリを最適化することが不可欠です。しかし、ユーザーがAppleのポップアップ表示に対して同意しなかった場合でも、後日ユーザーをアプリからiOSのアプリ設定にディープリンクできるということを知っておくことも重要です。
- ユーザーの同意率を最大限に高めるために、Adjustは優れたオプトインのプロンプトについて研究してきました。今後数回にわたって、ユーザーを同意に誘導するオプトインフローの構築に関するアドバイスをブログでお届けしていきます。初回である今回は、UX戦略を定義し、説得力のあるアプリ内メッセージ（Adjustでは「プリ パーミッション プロンプト（pre-permission prompt）」と呼ぶ）を設計する方法について取り上げます。

---

### [isAdvertisingTrackingEnabled | Apple Developer Documentation](https://developer.apple.com/documentation/adsupport/asidentifiermanager/1614148-isadvertisingtrackingenabled)

- **このプロパティは非推奨であり、常にNoを返します。機能は、[App Tracking Transparency](https://developer.apple.com/documentation/apptrackingtransparency)フレームワークに置き換えられました。**

#### Forumより

- [for ios14 isAdvertisingTrackingEna… | Apple Developer Forums](https://developer.apple.com/forums/thread/660446)
    - iOS 14の場合、isAdvertisingTrackingEnabledは常にfalseを返します。
    - ポップアップは2021年第1四半期までのオプションであり、Appleが施行を遅らせたため、isAdvertisingTrackingEnabledの機能をロールバックする必要があります。(という問い合わせ。Appleの回答待ち)
    - 他のアイディアはありますか?

---

### IDFAの実装例

- [iOS14でエンジニアがすべきIDFA対応 - Qiita](https://qiita.com/koooootake/items/e467be2c4f63ff605841)
- [iOS14でのIDFA取得 - Qiita](https://qiita.com/yofuru/items/213b88b85553631204e4)
    - 現在から2021年初旬までの期間の間、選択可能な暫定対応例が文末に載っている。これを参考にするのが良さそうに思う。
        - ここで言う文末 とは **iOS14(2021年はじめまで)の紳士的なIDFA取得方法** というソースコードのこと
    - 2021年初旬以降は、requestTrackingAuthorizationWithCompletionHandlerでダイアログを表示する必要がある。
    - ダイアログ表示の実装をしたアプリを急いでリリースしてしまうと、一度切りしか表示が出来ない仕様のため、下の施策が行えなくなってしまう。
    - ユーザー同意率を高める施策を行う場合は、 [iOS14のユーザー同意を確保するためのオプトインの設計方法 | Adjust](https://www.adjust.com/ja/blog/getting-the-opt-in/) や、今後掲載されるであろうAdjustのブログ記事を参考にするといいと思われる。

---

### **ATTrackingManager.AuthorizationStatus.restricted ではなく .denied が返却されるバグ?**

[ATTrackingManager.AuthorizationStatus.restricted | Apple Developer Documentation](https://developer.apple.com/documentation/apptrackingtransparency/attrackingmanager/authorizationstatus/restricted) には

> Allow Apps To Request To Track setting is disabled and cannot be changed

("Allow Apps To Request To Track setting" は日本語で、 "Appからのトラッキング要求を許可" に当たる)

とあるが、アプリ未インストールな状態で "Appからのトラッキング要求を許可" をオフしても restricted ではなく denied が返却されるケースがあった。 
(iPhone 7 Plus, MNRD2J/A, 14.0 18A373, DEV2l089)

※ Xcode 12 (12A7209) の **iPhone Simulator では restricted が返却される**

**事業・実装上の影響はありそうか?**

- restricted が denied で返却されたとしても、「アプリ個別にトラッキングを許可していない」か、「デバイス一括で許可していないか」の違いしかないので、影響はないと思われる。
- なのでプロダクト側の判断に任せるで十分に思う。