変化が求められるデータ共有のあり方

Adjustの管理画面で最も使用されている機能の1つは、インストール、セッション、イベントのローデータをモジュールでネットワークパートナーに転送する「パートナー設定」です。

ネットワークパートナーの多くは、ネットワーク経由で「アトリビュートした（成果が紐付いた）」トラフィックだけではなく、オーガニック経由のデータや他のネットワークにアトリビュートされた情報なども提供するよう要求します。Adjustがアトリビューション情報を自ら共有することはありませんが、お客様がAdjust管理画面の転送機能を使用すれば、お客様のネットワークパートナーに対してユーザーに関する多くの情報を提供することになります。

それでは、媒体社との情報共有を最小限に留めるために、どんな対策を講じることができるでしょうか。今回は、現状のデータ共有の仕組みを解説するとともに、なぜ改善が求められているかを解説します。

ユーザーデータを不必要に共有

ネットワークは、なぜ自社が発生させたトラフィックだけではなく、全てのインストール情報を要求するのでしょうか。皆様のネットワークパートナーは、その理由に「特定ターゲットの除外 (Exclusion Targetting)」を挙げるかもしれません。

しかし、できるだけ多くのデータを要求するネットワークが、なぜ特定のターゲットを除外しようと考えるのでしょうか。

その理由は簡単です。すでにアプリを使用している人（特定のターゲット）に広告を表示しないようにすれば、ユーザー獲得キャンペーンの効率を劇的に高めることができるからです。アプリの使用率が高い既存ユーザーは、アプリに関連した広告を頻繁にクリックする傾向があります。ネットワークパートナーはインストール率よりもCTRの最適化に力を入れるのが一般的なため、アプリへのエンゲージメントを既に行なったユーザー層にも不必要に広告を表示して、多額の広告費を費やしてしまいます。

また、ネットワークパートナーは、これらのユーザーをターゲットから除外するだけで、キャンペーンの効率化を図ることができます。必要なデータは、リアルタイムコールバックをネットワークパートナーのバックエンドに送信して共有するのが一般的です。

それらの一連のイベント情報から、パートナーは既存ユーザーのデバイスリストを作成します。

このように仕組みは簡単です。

しかし、インストール情報をリアルタイムに転送するには、リアルタイムコールバックが有効化されていることが必要です。この機能は有効化された時点で機能するため、その前に発生したインストール情報は転送されません。問題なのは、アプリのアクティブユーザーのほとんどは、コールバックが有効化される前にインストールを完了していることです。

既存ユーザーの90%が不明な場合、ターゲットの除外はどの程度役に立つのでしょうか？

ネットワークパートナーは「簡単に解決できる方法がある」と言うでしょう。セッションデータを送信すれば、現在アプリを使用する全てのユーザー情報が見れるため、除外リストをカバーする範囲が大幅に改善される、というのが彼らの主張です。

しかしこれを行うと、過去にアプリをインストールしたユーザー情報を必要以上に共有し、機密情報をネットワーク側に提供してしまうことになります。

どのデバイスが最もアプリを起動しているかを確認することで、最もエンゲージメントの高いユーザーリストを簡単に作成できます。過去30日間にアプリを使用したユーザーリストよりもはるかに価値があります。

したがって、今日選ばれているこれらのソリューションには受け入れがたい欠点があると言えます。これに代わる方法はないのでしょうか？

理想的な世界では

現状の問題を解決する方法をお話する前に、まずは理想的な解決策について考えてみましょう。

Adjustでは、お客様がオーディエンス情報をネットワークパートナーと共有する際はなるべく最小限に留め、セグメントの変更をリアルタイムに更新していただけるよう取り組んでいます。お客様のパートナーは常に最新のオーディエンスが把握できる一方で、ユーザーリストを他の目的には使用できなくなります。

デバイス情報は必要なものだけ抽出され、特定のデバイスIDのみがYES／NOの判断にしたがって共有されるのが理想的です。例えば、特定のユーザー層を除外するなら、アプリがインストール済みであること以外の情報を共有するのは控えたいものです。

現実の世界では

この解決策をさまざまな側面から見ると、どこが現実的にうまくいっていないかがわかります。リストを共有する良い方法が他にあるのでしょうか？

この問いに答えを出すには、まず（例えば）IDFAのような広告IDが広告エコシステムを通してどのように送信されているかを理解する必要があります。デバイスが広告インプレッションをリクエストする度に、ネットワークはIDFAを受信して、どの広告をデバイスに表示するかを決定します。その際に、ネットワークがIDFAに付随する国やOS、デバイスタイプなどの基本情報を保存するのを阻止する機能は何もありません。悪意がないとしても、ネットワークはIDFAを保存し、どの広告がどのくらいの頻度でデバイスに配信されたかを記録する必要があります。

ここで、特別に暗号化されたリストをネットワークと共有する、あるいは、特定のIDFAを与えられた時に「YES／NO」の判断のみを返すアドサーバーに、DMPのようなサーバーを導入するとどうでしょう。こうすれば、完全なリストを読まれることはありません。

しかし実際には、このブラックボックスに対してネットワークが既知のIDFAのリストを渡し、完全なリストまたは少なくとも完全に近いものを受信するには数分とかかかりません。

ハッシュ化または暗号化されたデバイスID、あるいはDMPへの連携を介してリスト共有を行う一般的なアプローチには盲点があり、結局はほぼ全てのネットワークがアクティブなIDFAにアクセスできてしまうのです。

とはいえ、暗号化技術は大きな進歩を遂げており、将来が期待されます。理想を現実にするための一番のハードルは、オペレーティングシステムです。アプリ開発者が意図する目的以外に使用できないように、特別に暗号化されたデバイスIDの生成をサポートする必要があります。

今までは、ユーザーリストをネットワークパートナーに提供せざるを得ませんでした。

しかしながら、デバイスIDのローデータ転送は、現状に比べて大きな改善策だと言えます。不完全で不正確なユーザーリストを共有したり、ユーザーベース全体のセッションデータを公開したりするのではなく、キャンペーンのターゲットにマッチしないデータを除外した上でリストを共有することができるからです。

例えば、日本のiPhoneをターゲットにしたキャンペーンを実施する場合、その条件に一致するデバイス情報だけを共有すれば良いのです。他の方法と比較して、これは間違いなく改善策だと言えるでしょう。

では、デバイスIDリストの共有がそれほど有効ならば、何を実施する必要があるのでしょうか？

理想に近づくために

まず、特定の条件に一致するデバイスリストを生成できなければなりません。この作業はマニュアルで入力することなく、オーディエンスを自動的に最新の状態に維持するのが理想的です。

次に、選択したネットワークパートナーとリストを共有し、必要に応じて更新できなければなりません。

一般的に、ネットワークパートナーとオーディエンスを共有して定期的に更新情報を受信するための方法は2つあります。一つは、パートナーが提供するPull APIを介して行う方法、二つ目は、Pull APIとしてURLで共有されるリストをネットワークが利用する方法です。

Adjustのオーディエンスビルダーは、まさにこのような機能を提供しています。お客様のパートナーとあらゆる条件に基づくオーディエンスをリアルタイムに作成して共有します。

過多なデータ共有を控えたいと考えるマーケター様が増える中で、Adjustはオーディエンスビルダー機能を大幅に拡張することを決定しました。

Adjustは、ネットワークパートナーから利用可能なプッシュAPIを全て追加し、現在Pull APIに依存してオーディエンスを取得しているパートナーと連携を進める予定です。

これを実施するため、ネットワークパートナーはシステムをアップグレードする必要がありますが、マーケターがより優れたデータ共有のあり方を求めることで、この取り組みを推し進めていけることを確信しています。

業界の現状を一緒に改善していきましょう。