アトリビューション 101 (モバイルアプリ編)
本日は広告を実施する上で、広告の成果を測定するには必ず必要な、"アトリビューション" について、モバイルアプリマーケティングが初めての方達の為に、アトリビューション（トラッキング）とは何かと、その中にある重要なポイントについて記載します。
（前からアトリビューションの基本概念について記載すると言いつつ、実際の開始まで時間がかかりましたね^^;）
こちらは、"APP" に限定したアトリビューションの話となります。"WEB"のアトリビューションとは本質的には同じものですが、手法などについて異なる部分があるので、"APP"に特化した話をします。
尚、アトリビューションは提供する会社によって、用語の呼び方や機能について多少の違いが存在しますので、こちらはご了承ください。
"この人の話って信憑性ある？？" という方も当然いると思いますので、自分とアトリビューションに関する背景を簡単に説明します。
■ 2013 ~ モバイル広告代理店 Adwaysがプロデュースした、Party TrackというアトリビューションのAPAC事業に関わる
■ 2017 ~ 2020 モバイル広告の分析＋アトリビューションを提供する、
San FransiscoベースのSingularという会社で、APACのHead of Customer Success兼Director of Solutions Consultingとして、様々な企業のマーケターへのトレーニングや課題に取り組む。
先月（2020.5）からUNICORNという会社で新しいチャレンジをしております。ちなみに、今UNICORNを作ったチームは過去Party Trackやその他、Twitterのキャンペーン最適化ソリューションを作ったメンバーでもあります。
では、本題へ。
目次
■ アトリビューション（Attribution）とは？
■ アトリビューション提供会社
■ アトリビューションモデル（Attribution Model）
■ アトリビューションの判定方法（Method）
■ アトリビューション判定の優先順位 (Waterfall)
■ アトリビューションウィンドウ（Window）
■ アトリビューション判定のCase Study
■ ポストバック（Postback）
■ リエンゲージメント（Re-engagement）
■ コホート（Cohort）
■ リテンション（Retention、継続）
■ ディープリンク（Deeplink）
■ ディファードディープリンク（Deferred Deeplink）
アトリビューション（Attribution）とは？
"このユーザーは誰が連れて来たの？"の判定。
・インストールなどの成果、又はゴールを牽引した広告と結び付ける事。
・トラッキング、又は日本ではSDKとも言われている。（が、SDKは正しい表現では無い）
アトリビューション提供会社（アルファベット順）
・Adjust
・AppsFlyer
・Branch
・Kochava
・Singular
アトリビューションモデル（Attribution Model）
"判定のルール、原則"みないなのもです。
・ラストタッチモデル（Last Touch Model) - 主流であり、成果の直前にあった広告クリックや広告ビュー（合わせて、Touch points, タッチポイントと言う）からアトリビューションされたと判定するモデル。
・マルチタッチモデル（Multi Touch Model) - 成果まであった複数のタッチポイントを想定の判断基準に基づき、それぞれの貢献率を付与するモデル。主にウェブのアトリビューションで適用。
アトリビューションの判定方法（Method）
"何をみて判定をするのか？"的なもので判定際に参照する識別子です。
・リファラー（Referrer) - Androidのみ（App, Web両方可能）
- ユーザーが広告をクリックしGoogle Play Storeに飛ぶ際に、アトリビューション提供社がGoogle PlayにユニークなReferrer IDを渡す。その後、ユーザーアプリをインストールしたら、アプリに実装されているSDKがGoogle Play渡されたReferral IDをアトリビューションサーバーに送り、アトリビューション判定を行う。
・デバイス ID（Device ID Matching) - Android, iOS（Appのみ）
- 正確にはデバイスIDではなく、広告ID(Advertising ID)。
- Google Play = GAID = Google Advertising ID
- App Store = IDFA = Identifier for Advertiser
- アプリのみ可能。つまり、ウェブ媒体では取得不可。リセット可能。
・フィンガープリンティング (Fingerprinting) - Android, iOS（App, Web）
- モバイルのウェブブラウザで広告IDが取得不可の場合使用。
- IPアドレス、端末製造社・モデル、ブラウザ、言語、画面サイズなどベースにユニークなIDを生成。
- 一般的に24時間以内にインストールされないとアトリビューション判定から除外
・Self-Attributing Networks（SANs, Facebook, Twitter, Googleなど）
- アトリビューション側の判定ではなく、自社基準でアトリビューションを判定する広告ネットワークを、セルフSelf Attributing Networks (SANs) と言い、Facebook, Google Ads, Twitter, Apple Search Ads, Snapchat, Line Ads Platformなどがいる。
- Tracking Link経由ではなく、アトリビューションとSANsの間の通信にてアトリビューションを判定。
- 測定が可能なアトリビューション提供者は決まっている。
- Adjust, Appsflyer, Branch, Kochava, Singular (ABC順)。
- MMP（Mobile Measurement Partner）と呼ばれている。
アトリビューション判定の優先順位
基本的に決定的要素（Deterministic）か、確率的要素（Probabilistic）かと、
広告の反応が直接（Direct Engage）か、間接（Indirect Engage）かによって優先順位が変わります。
決定的要素には、GoogleのReferrer, 広告 IDがあり、
確定的要素には、フィンガープリンティングがあります。
直接反応はClickで、間接反応はViewですね。それを元に上から下の順に優先判定されます。
1. リファラー ID with Click or 広告 ID with Click
2. フィンガープリンティング with Click
3. 広告 ID with Impression
4. フィンガープリンティング with Impression
5. オーガニック（タッチポイントが何も無い）
アトリビューションウィンドウ（Window）
ClickやViewからInstall (Re-engagement)が発生したまでの許容期間を意味する。許容期間内でInstallが発生した場合は、アトリビューションとして認める。期間外であれば認めない仕様。
- Click with（Click-through）リファラーID & 広告ID = 1~30日
- Click with（Click-through）フィンガープリンティング = 1~24時間
- View with（View-through）リファラーID & 広告ID = 1~24時間
- View with（View-through）フィンガープリンティング = 1~8時間
アトリビューション判定のCase Study
条件：Click-through 7日、View-through 24時間、ラストタッチモデル
1) [iOS] Network#A App面 Click(9日前) → Network#B Web面 Click(3時間前) → Install
Winnerは？
ラストタッチでNetwork#Bの勝利。が、アトリビューション優先判定で、Network#BはWeb面で、広告IDが取れないのでFingerprintingとなり、広告IDを持つNetwork#Aに負けます。
ただ、Network#Aはアトリビューションウィンドウ(7日)を超えたので、失格し、最終的にNetwork#Bにアトリビューションされるケースです。
次は、同じ条件でAndroidのケースを見てみます。
2) [Android] Network#A App Click(6日前) → Network#B Web面 Click(3時間前) → Install
Winnerは?
ラストタッチは同じくNetwork#Bの勝利。一方、判定の優先度的には、今回もNetwork#BはWeb面なのに負けてません。なぜでしょう？それは、Androidの場合、WebでもAppでもReferrerが取れる為です。
ここで注意点は、アトリビューション提供者によっては、Referrer ID > 広告IDのケースも、その反対である、Referrer ID < 広告IDのケースもあります。
アトリビューションウィンドウも両方とも期間内と合格なので、結果的には同じ条件なので、ラストタッチであるNetwork#Bがアトリビューションされうケースです。
では、最後のケース。同じく、条件は同じです。
3)[Android] Network#A App Click(6日前)→ Network#B App View(2時間前) → Install
Winner?
ラストタッチでNetwork#Bが勝利。しかし、直接反応(Click)ではなく、間接反応(View)なので、結果、Network#Aに負けるというケースです。
ここで、実はNetwork#Aがアトリビューション判定を騙し、ClickしてないのにViewとしてアトリビューション側に通信せず、Clickと誤魔化して通信したとしたらどう思いますか？本来であれば、ViewとViewの競争で、かつNetwork#Aはアトリビューションウィンドウの外で失格判定されるはずが、Clickと誤魔化して結果、勝利するという話にならない現象が今日本のアプリ広告業界には起きているので、しっかりと実行するネットワーク、媒体のViewとClickの基準を把握した上で、同じ基準で評価するのが非常に重要となります。この話の詳細は下記の記事に詳しく纏めておりますので、一度ご覧ください。
ポストバック（Postback）
アトリビューション提供者側で広告ネットワークにネットワークが指定したURL及び情報規格にて自動的に、リアルタイムで送信する通信を言います。
この決め事を設定する作業を”連携（Integration）”と言います。
ポストバックの種類には、
- アトリビューション（Install & Re-engagement）
- イベント（In-App Event）: Install後の特定イベントに対する最適化に使われる。
- 収益（Revenue）: イベントと同様。+αで決済された商品、数量、金額、通貨単位を含む。
最近では、Fraud Postbackもあり、アトリビューション側でFraudと判定した場合、その理由をPostbackする事もあります。
尚、ポストバックは昔、アトリビューションに貢献した広告ネットワークに該当する広告トラフィックだけポストバックする事が一般的でした。
つまり、Network#AからユーザーXとユーザーYを送ったものの、実際アトリビューションされたのはユーザーXの場合、ポストバックはユーザーXの分だけが発生するとの事です。
一方、直近では、Network#Aが送った広告トラフィックだけではなく、Organic(広告経由のユーザーではない)を含む他ネットワークからのインストールやイベントまでポストバックする事が重要視されます。特に、機械学習を用いてリアルタイムビッディングを行う広告プラットフォームだと尚更重要です。その理由は、データを基盤に機械が学習を行う事に際して、精度の高い予測を元に最適化を行う為にはより多くのデータが必要となるのですが、これを該当するネットワークのデータだけを機械にフィードさせるよりは、該当アプリの全てのデータを機械にフィードする事で、より早く、より精度の高いモデリングができる為です。より早く、より精度の高いというのは、結果的に、より効率よく、より効果的にキャンペーンが最適化される事を意味します。
まだ、"何で御社から上がったインストールやイベントでも無いのに、ポストバックを上げないと行けないですか？"と疑うマーケターさんもいますが、学習できるサンプル（データ）が多い程、キャンペーンが設定した目標に対して安定化するので、絶対プラスになる設定です。
リエンゲージメント（Re-engagement）
上に登場したリエンゲージメントとは、既にアプリを利用したユーザーであるが一定期間アプリを利用して無いユーザーを対象に行うキャンペーン（リターゲティング）から流入したユーザーがアプリに再度流入し、アプリを起動した行為を言います。
コホート（Cohort）
定義
- 定められた期間内にある特定のイベントを発生させたユーザー群
- 基本的には同じ日にInstall又はRe-engagementしたユーザーグループ
活用
アトリビューション（Install又はRe-engagement)された日から’x’期間までの行動合計を分析する際に使用。
例）
- Network#Aの30日間（D30)の累計決済額 = xxx,xxx,xxx JPY =D1+D2+...+D30
- Network#Aの14日間（D14)のStage5突破数 = z,zzz = D1+D2+...+D14
- Network#Aの7日間（D7)のリテンション（残存率） = yy%
Re-engagementされた場合には、Re-engagementを牽引したADNWにコホートが蓄積されます。こちらは、内容が多少ややこしいので例を元に説明します。
例）
Network #A経由でUser Xが新規インストールし、二日後には課金もしました。
2020-05-01, User X, Event = Install, Network = ABC
2020-05-03, User X, Event = Purchase (500JPY)
アトリビューション側の管理画面上では、下記のように表示されます。
その後、User Xはしばらくアプリに接続しませんでした。が、ある日、一度離れたユーザーを復帰させるキャンペーンをNetwork DEF経由で実施し、User Xがその広告に反応して、アプリに復帰しました。その二日後に課金もしました。
2020-05-21, User X, Event = Re-engagement, Network = DEF
2020-05-24, User X, Event = Purchase (3,000JPY)
その場合、このUser Xの課金データを含む行動データは復帰した時点を基準に、最初Installを起こしたNetwork ABCではなく、Re-engagementを起こしたNetwork DEFに蓄積される事を意味します。
リテンション（Retention、継続）
ユーザーのサービス継続に関する指標で、Install又はRe-egagenemt後、n日にアプリを利用したユーザー数を表します。
例として、2020-05-31にInstallした数は100で、その内、7日後アプリを利用したユーザーの数が10だと、7日目(D7)のリテンション率は、
10/100 = 0.1 = 10%です。
尚、このn日の日の基準を会社によってカレンダー日を基準にする場合と、24時間を基準にする場合があります。
ディープリンク（Deeplink）
ユーザーをサービス内の特定のページに移管させる事です。
条件は、ユーザーがアプリが既にインストールされている必要があります。
ショッピングアプリなどで多く利用されます。
アトリビューション側が広告の測定に利用するTracking URLに、新規ユーザーの場合にはアプリをダウンロードできるアプリストアに、既存ユーザーの場合には、アプリ内の特定ページに遷移する様に設定できます。
ディファードディープリンク（Deferred Deeplink）
アプリを持って無いユーザーがアプリをインストールをした後に、サービス内の特定ページに移管させる事です。例をあげると、アプリでスニカーを販売するサービスがあり、とあるスニカーをクリエイティブとして制作し、広告を回して、ユーザーがこの広告をクリックしました。このユーザーはアプリを持って無い為、アプリストアに遷移されアプリをダウンロードします。
ここから、違います。
<ディファードディープリンクを設定して無い場合>
ダウンロード完了後にアプリを起動すると、アプリのデフォルトのホームページが表示されます。
<ディファードディープリンクを設定して無い場合>
ダウンロード完了後にアプリを起動すると、広告に出たスニカーの詳細ページに自動的に遷移されます。
以上です。書いてみたら、かなりのボリュームですね^^;
一度みるだけだと、全部理解するのは難しいと思いますので、ブックマークとかで登録頂いて、定期的に見て頂いた方が言いかもです。
新卒の方達やこれからモバイルアプリマーケティングに携わる方達に有益な情報になったら幸いです。長い文書、最後までご覧頂き、ありがとうございました！
次回には、最近注目を浴びている、Apple Search Adsについて、記載してみようと考えてます！