【徹底解説】 Apple Search AdsとMMPのデータ乖離。PART 2 ー 今何が起きているのか?
見出し画像

【徹底解説】 Apple Search AdsとMMPのデータ乖離。PART 2 ー 今何が起きているのか?

📌 今回の記事は、UNICORNが独自に調査した内容であり、
Apple社やMMP提供会社の公式的な見解は含まれておりません。

先日 『 【徹底解説】 Apple Search AdsとMMPのデータ乖離。今までとこれから 』という記事にて、Apple Search AdsとMMP間のデータ乖離についての現状を伝えさせて頂きました。
こちらでは“今まで起きたデータ乖離の原因と、新たに発表された計測仕様によって期待される改善点“についてを記載したのですが、今回は“その後”について詳しくお伝えさせていただきます。

前回の記事はたくさんの方々にお読みいただき、個別の質問なども多くいただきました。少しでも役に立ったかもしれないと嬉しい気持ちになったと同時に「データ乖離」、「Apple Search Ads」 における皆さんの関心度の高さも改めて感じることとなりました。


データ乖離がまだ起きている?


そんな記事を書いてから、約1ヶ月が経過しました。当初は1ヶ月後であれば、Apple Search Adsの新たな計測仕様(AdServices Framework)によりデータ乖離が概ねが解消されているだろうという期待とともに、改善されたデータを皆さんに共有する計画を立てていたのです。しかしながら、蓋を開けてみるとAdServices Frameworkをアプリ側で導入したのにも関わらず、データ乖離は引き続き発生しておりました。

その一方、データ乖離の内容自体は大きく変わりました。

今まで発生していたInstallの数値に対するデータ乖離は 『 Apple Search Ads > MMP 』 と、MMPの数値がApple Search Adsの数値より小さい現象でした。先日の記事でも説明した通り、MMP側ではIDFAの無いユーザー(Limited Ad Tracking をONしたユーザー、LAT ON)の流入経路が確認できないことが起因した結果です。

しかし、AdServices Frameworkが導入された後からは 『 Apple Search Ads < MMP 』と、今までとは真逆であるMMPの数値が、Apple Search Adsの数値より大きい現象が新たに確認されました。

画像1

今回の記事では、この新たなデータ乖離の詳細について、現状を共有させて頂きます。

📌 なお、本記事は『 【徹底解説】 Apple Search AdsとMMPのデータ乖離。今までとこれから 』 の続編に当たるものであり、Apple Search Adsの新たな成果判定仕様に対する説明などは省かれております。まだ前回の記事を読まれてない方はお読みなった上で本記事を読んで頂く事をお勧めします。https://story.unicorn.inc/n/n2c8c2d322ecf


何故、この現象が起きているのか?

『Apple Search Adsの数値より、MMPの数値が大きい?』

この現象がすでに現れた方、もしくはこの話を初めて聞いた方。どちらにせよ、この疑問に対し、いくつかの可能性を頭に思い浮かべたことでしょう。自分の場合は、' 重複カットがされてないか?'という答えでした。

結論的に、その' 重複カットがされていない ' という現象自体が、新たなデータ乖離の中身としては正しいものでした。しかし、この現象を巻き起こしている背景は、かなりややこしいものだったのです。以下でより理解を深めるために、その背景とパターンについてまとめさせて頂きます。

『リセマラ』 & 『 変わるIDFV 』

アプリゲームに関わる方なら誰もが知っている 『リセマラ』 と、 『 IDFVが変わる現象 』 が新たなデータ乖離の主犯人です。

📌 IDFV(Identifier For Vendor)は、アプリデベロッパー(ベンダー)向けのデバイス識別用IDとして、特定アプリデベロッパーがApp Store上に公開している全てのアプリにおいて、同じデバイスであれば同じデバイス識別用IDを持つ事が特徴です。iOS13以下のLAT ONユーザーや、iOS14以上のATT不許可ユーザーにおいてIDFAの取得ができないものの、IDFVは必ず取得できるIDです。

" IDFVって変わるの ? "

と驚く方もいらっしゃると思いますが、IDFV(Identifier For Vendor)は特定の環境下で変わるケースがあります。

下記は、Apple社の文書に記載されている内容ですが、

画像2

1. ユーザーがデバイスからそのベンダーのアプリをすべて削除し、その後、1つまたは複数のアプリを再インストールした場合。
2. Xcodeを使用してテストビルドをインストールした場合。
3. アドホック配布(App Storeを通さず)でデバイスにアプリをインストールした場合。

において、IDFVが変わると説明されています。
上の3つのケース以外にも、アプリデベロッパーの登録名義が変わった場合でもIDFVが変わるケースもあるようです。

テストビルドやApp Storeを通さないアプリの配布は、アプリをプロモーションする時期では起きない現象であり、アプリデベロッパーの登録名義変更も滅多に起こる現象ではありません。そのため、主な原因は、上記の1番のケースに絞られるでしょう。

Tokenの使われ方

尚、『 リセマラ 』 と 『 変わるIDFV 』 に加え、Tokenの使われ方が新たなデータ乖離の化学反応を起こします。

📌 Tokenとは、新たなApple Search Adsの計測(AdServices Framework)で導入された仕組みであり、既存の計測(iAd Framework)がIDFAを基準に計測したことに対し、ユーザーを特定できない任意の文字+数字列で発行されたものです。MMP又はデベロッパーは、デバイスのAdServices Frameworkから発行されたTokenの情報を元にAppleへApple Search Adsの計測記録を問い合わせします。

このTokenにはいくつかの特徴がありますが、データ乖離においては、下記の2つが関係しています。

・TokenはユーザーのApple Search Ads(以下、ASA)における計測記録を調べる用途のみに使われており、Token自体をIDFAやIDFVなど、他のIDと紐付けての使用はされていない。(2021年6月12日現在)
Tokenの有効期限は最初のInstallから24時間。24時間が過ぎたTokenをApple側に対し成果の問い合わせを行った場合は、エラーが返ってくるため、ASAの計測記録は取得できない。

これらを踏まえて整理すると、MMP側での計測フローはおおよそ以下のようになります。

⚫️ ユーザーがASA経由でInstallし、ATTを不許可した。
⚫️ Tokenを用いて、ASA経由でInstallしたという確認が取れた。
⚫️ MMP側ではこのユーザーの全てのアクション及び、流入経路をIDFVを基準に記録される。[ASAのInstall合計 = 1 ]
⚫️ しかし、Token自体は、IDFVに記録&結合しない。あくまで、ASAに確認する用途のみに使う。
⚫️ その後、ユーザーがリセマラ目的で、アプリを削除し再Installした。
⚫️ このユーザーのデバイスにアプリデベロッパーのアプリはこの1つのみであったので、IDFVが変わってしまった。
⚫️ 新しいIDFVなので、新しいユーザーとして認識。
⚫️ Tokenを用いて、ASA経由でInstallしたという確認が取れた。[ASAのInstall合計 = 2 ]
⚫️ その後、ユーザーがリセマラ目的で、アプリを削除し再Installした。
⚫️ ... (繰り返し)

画像3

つまり、リセマラでIDFVが変わる現象が起きている中、TokenはASAの記録を問い合わせる用途のみで使用され、また、ユーザーの重複判定の用途としては使われていないため、データ乖離が生じています。

ここまでの説明で、現在起きているデータ乖離の状況や背景について、ある程度ご理解頂けたかと思います。

なお、上の説明はできるだけシンプルに集約した内容です。そのため、実際にはいくつかのパターンが存在します。実際に起きている現象を把握しやすくするため、記事の下に付録として新しい計測仕様の主要パターンについてまとめさせて頂きます。ぜひご覧くださいませ。


Good News ー 課金計測の改善

リセマラによるデータ乖離が生じ、新規Install数やCPI計算にノイズが発生しているのは現時点で事実です。

しかしながらIDFAが取得されないデバイスでも、Apple Search Adsの広告インパクトを測れるようになるという、新しい計測仕様の期待値がしっかり現れた部分も見つかりました。それは課金(収益)計測です

まず、課金における旧・新計測仕様の違いについて改めて整理しましょう。

旧(iAd Framework)計測仕様の場合、IDFAをベースにするため、IDFAが取れないデバイスにおいてはOrganicとして判定をし、そのデバイスから上がった収益もOrganicに計上されました。一方、新(AdServices Framework)計測仕様の場合は、IDFAではなくTokenをベースにASAからのアトリビューションを判定するため、収益もApple Search Adsに正しく計上されます

画像4

そして、新しいASAの計測仕様において、新規InstallデータはリセマラとIDFVの変更による重複の影響を受けますが、課金データはその影響を受けません。その理由は、特定ユーザーのIDFVが変わっても、そのユーザーがApple Search Adsを経由してInstallしたという事実は、Tokenのおかげで確認ができるようになったためです。その為に、そのユーザーが課金をした場合には、しっかりとApple Search Adsに収益が計上されます。

画像5

なお、下記は実際にApple Search Adsに出稿中のアプリデータを元に、旧・新計測の仕様による比較をしたものです。AdServices Frameworkを導入したアプリバージョンをリリースした日の前後の同日数(30日)の中で、データがどのように変わったかを比較してみました。この期間中にアプリ内の特別なイベントはありませんでした。

📌 比較時のノイズを避ける為に、新規インストールの数はApple Search Adsの管理画面の新規DLの数値を使い、課金のデータはMMPのコホート収益が比較に使われております。

📌 旧計測期間中の各指標別データを「1.00」に変換し基準値として設定した上で、新計測期間中の各指標別データがどれほど変わったかを比較計算しています。

一つ目のアプリでは、新規DLの数値は旧計測期間中が49%ほど多かったものの、課金 / DL (DL当たり課金)は新計測になってから6.55倍多く計測され、課金合計も3.37倍多く計測されました。30日間のROASについても、旧計測と新計測の間に大きな差が見えました。

画像6

二つ目のアプリでは、旧計測と新計測期間中の新規DLの数値はほぼ同じでした。一方、課金 / DL (DL当たり課金)は新計測になってから4.12倍多く計測され、課金合計も4.16倍多く計測されました。30日間のROASについても、新計測の期間中が旧計測の期間中より4倍以上高い結果が見られました。

画像7

最後は三つ目のアプリです。こちらでは、新規DLの数値は新測期間中が51%ほど少なかったものの、課金 / DL (DL当たり課金)は新計測になってから2.68倍多く計測され、課金合計も1.31倍多く計測されました。30日間のROASについても、旧計測と新計測の間に大きな差が見えました。

画像8

三つのアプリで共通的に、「旧計測が適用された期間より新規DL数は多くなって無いのにも関わらず、課金額が多くなった」 という現象が見られています。

要するに、Apple Search Adsという同じ広告チャンネルにおいて、“アプリ内に特別なイベントが無かった期間中”という条件の中からこの現象を解釈する場合、偶然といきなり質の高いユーザーが取れるようになったと解釈するよりは、「今まででは計測できていなかった部分が計測できるようになった」 と解釈することが正しいでしょう。

以上、Apple Search Adsの新しい計測仕様における影響について、現時点で起きている現象と背景についてまとめさせて頂きました。MMP各社それぞれ計測の方法は微妙に異なることもあるかと思いますが、大元の要因となる部分は相違はないと考えています。

リセマラ及びIDFVが変わるケースによって、新規Installにおけるデータ乖離が起きており、広告の評価分析においてノイズを起こしているのは事実です。

一方、課金計測においては影響がなく、Apple Search Adsの新しい計測仕様によって、今まではOrganicとしか計測ができなかったユーザーのデータもしっかりApple Search Adsで計測できるようになった。それは、かなりポジティブな部分であることは間違いありません。

足元でInstall数やCPI計算などについて不便な状況は発生していますが、Apple Search Adsの管理画面数値とMMPの収益を合わせて確認することで、今までより正しいROASの評価ができるようになったことに意味を付与し、キャンペーンを進めて行くことが得策だと思います。

またこちらの現象については、Apple Search Adsと各MMP社の間では認識されている部分だと思いますので、近い将来に何らかの改善策が出ることも期待しております。

最後は、Apple Search Adsの新しい計測仕様により、データ乖離が発生するケースと発生しないケースなどを整理し、付録資料として皆さんと共有しながら終わりにしたいと思います。最後までご覧頂きありがとうございました。

付録 ー ASAの新しい計測仕様の主要ケース

新計測仕様においてデータ乖離が発生するいくつかの主要ケースを整理し、本現象における解像度を一段階上げることができればと思います。なお、こちらで扱っているケースは全て、「ATTを不許可する」 パターンのみを記載致します。

Case #1. データ乖離無し| 通常のシナリオ
まずは、新しい計測仕様下で、どのようにApple Search Ads経由のInstallであることや課金を計測するかを通常のケースから見てみましょう。状況をシンプルにするため、ユーザーはASAの広告のみを接した事にします。

画像9

1. ユーザーがASA経由でアプリをInstall & ATTを不許可。
2. アプリ内のAdServices FrameworkからTokenを取得。
3. ATT不許可に基づき、MMPのSDKがデバイス情報とTokenをMMPのServerに送信。
 ・IDFA = 000
 ・IDFV = ABC
 ・Token
4. MMPのServerからTokenを用いて、ASAのServerにASAの計測記録を問い合わせる。
5. ASAのServerがTokenの有効性を確認した上で、ASAの計測記録をMMPのServerへ返す。
6. このユーザーがASAから来たことが分かり、次のように記録する。
 ・IDFA = 000 | IDFV = ABC | from Apple Search Ads 
 ※ Token自体をIDFVと紐付かない
7. MMPのASAレポートにInstallが 「 1 」 と計上される。
8. その後、ユーザーが ¥1,000を課金する。
9. MMPのSDKから課金の情報がServerに送られ、次のように記録する。
 ・IDFA = 000 | IDFV = ABC | from Apple Search Ads | 課金 = ¥1,000
10. MMPのASAレポートに課金が 「 ¥1,000 」 と計上される。

Case #2. データ乖離無し|24時間以内のリセマラ & IDFVの変更無し
Case #1にリセマラが加わったケースです。1~7順までは、Case #1と変わりはないですが、読みやすいように全て流れを記載致します。

画像10

1. ユーザーがASA経由でアプリをInstall & ATTを不許可。
2. アプリ内のAdServices FrameworkからTokenを取得。
3. ATT不許可に基づき、MMPのSDKがデバイス情報とTokenをMMPのServerに送信。
 ・IDFA = 000
 ・IDFV = ABC
 ・Token
4. MMPのServerからTokenを用いて、ASAのServerにASAの計測記録を問い合わせる。
5. ASAのServerがTokenの有効性を確認した上で、ASAの計測記録をMMPのServerへ返す。
6. このユーザーがASAから来たことが分かり、次のように記録する。
 ・IDFA = 000 | IDFV = ABC | from Apple Search Ads 
 ※ Token自体はIDFVと紐付かない。
7. MMPのASAレポートにInstallが 「 1 」 と計上される。
8. アプリを最初Installした10分後に、ユーザーがアプリを削除し、リセマラで再Install & ATTを不許可。
9. (2と同じ)アプリ内のAdServices FrameworkからTokenを取得。
10. (3と同じ)ATT不許可に基づき、MMPのSDKがデバイス情報とTokenをMMPのServerに送信。
 ・IDFA = 000
 ・IDFV = ABC (IDFVの変更無し)
 ・Token
11. MMPのServerからTokenを用いて、ASAのServerにASAの計測記録を問い合わせる。
12. ASAのServerがTokenの有効性を確認した上で、ASAの計測記録をMMPのServerへ返す。
13. IDFAは無いが、このユーザーのIDFV = ABCで、ASAから来ているという履歴があるため、新規Installにはならない。
14. その後、ユーザーが課金をしても IDFV = ABC というユーザー情報の中で記録され、課金額もASAに計上される。

Case #3. データ乖離有り|24時間以内のリセマラ & IDFVの変更有り
データ乖離が発生するケースです。ユーザーの動きはCase #2と全く同じですが、IDFVが変わるケースをCase #3としてまとめます。1~9順までは、Case #2と変わりはないですが、読みやすいように全て流れを記載致します。

画像11

1. ユーザーがASA経由でアプリをInstall & ATTを不許可。
2. アプリ内のAdServices FrameworkからTokenを取得。
3. ATT不許可に基づき、MMPのSDKがデバイス情報とTokenをMMPのServerに送信。
 ・IDFA = 000
 ・IDFV = ABC
 ・Token
4. MMPのServerからTokenを用いて、ASAのServerにASAの計測記録を問い合わせる。
5. ASAのServerがTokenの有効性を確認した上で、ASAの計測記録をMMPのServerへ返す。
6. このユーザーがASAから来たことが分かり、次のように記録する。
 ・IDFA = 000 | IDFV = ABC | from Apple Search Ads 
 ※ Token自体はIDFVと紐付かない。
7. MMPのASAレポートにInstallが 「 1 」 と計上される。
8. アプリを最初Installした10分後に、ユーザーがアプリを削除し、リセマラで再Install & ATTを不許可。
9. (2と同じ)アプリ内のAdServices FrameworkからTokenを取得。
10. (3と同じ)ATT不許可に基づき、MMPのSDKがデバイス情報とTokenをMMPのServerに送信。
 ・IDFA = 000
 ・IDFV = XYZ(IDFVがABCからXYZに変更されている!
 ・Token
11. (4と同じ)MMPのServerからTokenを用いて、ASAのServerにASAの計測記録を問い合わせる。
12. (5と同じ)ASAのServerがTokenの有効性を確認した上で、ASAの計測記録をMMPのServerへ返す。
13. 実際は同じデバイスだが、IDFVが変わり、IDFV = XYZのユーザー記録もないため、ASAからの新規ユーザーと記録する。
 ・IDFA = 000 | IDFV = ABC | from Apple Search Ads 
 ・IDFA = 000 | IDFV = XYZ | from Apple Search Ads
14. MMPのASAレポートにInstall 「 1 」が追加され、合計 「 2 」 と計上される。
15. その後、ユーザーが課金をした場合は、 IDFV = XYZ というユーザー情報の中で記録され、課金額もASAに計上される。

Case #4. データ乖離有り | 24時間以降のリセマラ & IDFVの変更有り
最後のケースは、今までのリセマラとは異なり、最初のInstallから24時間が過ぎた時点でリセマラを行うケースです。こちらでもデータ乖離が発生しますが、課金などが、Organicに計上されるケースです。

画像12

1. ユーザーがASA経由でアプリをInstall & ATTを不許可。
2. アプリ内のAdServices FrameworkからTokenを取得。
3. ATT不許可に基づき、MMPのSDKがデバイス情報とTokenをMMPのServerに送信。
 ・IDFA = 000
 ・IDFV = ABC
 ・Token
4. MMPのServerからTokenを用いて、ASAのServerにASAの計測記録を問い合わせる。
5. ASAのServerがTokenの有効性を確認した上で、ASAの計測記録をMMPのServerへ返す。
6. このユーザーがASAから来たことが分かり、次のように記録する。
 ・IDFA = 000 | IDFV = ABC | from Apple Search Ads 
 ※ Token自体はIDFVと紐付かない。
7. MMPのASAレポートにInstallが 「 1 」 と計上される。
8. アプリを最初Installした24時間後に、ユーザーがアプリを削除し、リセマラで再Install & ATTを不許可。
9. (2と同じ)アプリ内のAdServices FrameworkからTokenを取得。
10. (3と同じ)ATT不許可に基づき、MMPのSDKがデバイス情報とTokenをMMPのServerに送信。
 ・IDFA = 000
 ・IDFV = XYZ(IDFVがABCからXYZに変更された!)
 ・Token
11. (4と同じ)MMPのServerからTokenを用いて、ASAのServerにASAの計測記録を問い合わせる。
12. ASAのServerがTokenの有効性を確認した結果、有効期限が過ぎているため、エラー(404)を返す。(ASAの計測記録を取得できない。)
13. 実際は同じデバイスだが、IDFVが変わり、IDFV = XYZのユーザー記録もない、かつASAからの計測記録も無い為、Organicの新規ユーザーと記録する。
 ・IDFA = 000 | IDFV = ABC | from Apple Search Ads 
 ・IDFA = 000 | IDFV = XYZ | from Organic
14. MMPのOrganicレポートにInstall 「 1 」が追加される。
 ・ASA Install合計 = 1
 ・Organic Install合計 = 1
15. その後、ユーザーが課金をした場合は、 IDFV = XYZ というユーザー情報の中で記録され、課金額はOrganicに計上される。
 ・ASA Install合計 = 1 | ASA 収益合計 = ¥0
 ・Organic Install合計 = 1 | Organic 収益合計 = ¥1,000


一緒に読むと良い記事


“すべては人の可能性のために。” UNICORNはこれからのデジタルマーケティングを形作っていくプラットフォームを運営している会社です。 ここでは私たちが信じている事業やチーム、そして業界の未来について私たち自身の言葉で綴っていきます。