アプリ配信の成長: アトリビューションモデルとフレームワークの紹介

広告業界には、百貨店業界の父ジョン・ワナメーカーの有名な言葉が昔からある。「広告費の半分が無駄になっているのはわかっているが、どの半分が無駄になっているのかはわからない。」なぜ「半分が無駄なのか分からない」というのでしょうか。その理由は単純に、広告トラフィックがもたらすコンバージョン効果を測定することが不可能だからです。「トラフィック」と「コンバージョン」は、常にアプリ配信の成長を取り巻く2つのキーワードでした。配信プロセス中、広告主は「お金はどこに行ったのか？どのチャネルがより効果的か？どのチャネルのROIが低いのか？次の段階で広告予算をより合理的に割り当てるにはどうすればよいのか？」などの一連の質問を理解していないことがよくあります。

すべての広告主は、限られた予算内で最大限の広告収益を獲得し、予算を賢く使いたいと考えています。実際、これらの問題は広告のアトリビューションモデルとロジックに密接に関連しています。

したがって、アトリビューションモデルとロジックを理解することは、すべての広告主/製品/オペレーターにとって不可欠なスキルの 1 つです。

背景

現象の発生の背後には何千もの影響要因がある可能性があるため、帰属は非常に複雑な問題です。私たちがすべきことは、アトリビューションを通じて最も重要な要因を見つけ、それらの主要な要因を徐々に改善していくことです。

帰属の重要なポイント: 大胆な推測を行い、慎重に検証します。大胆な推測とは、すべての可能性と主要なパスをリストすることです。慎重な検証とは、結果に基づいてリンク全体のあらゆる可能性を検証し、最も可能性が高いもの、または最も説得力のあるものを見つけることです。

次のようなシナリオを想定してみましょう。OTT の Tencent Video で TV シリーズを視聴していて、製品 A のプレロール広告が表示されたとします。その後、PC の Baidu で製品 A に関する情報を検索し、有料広告をクリックして製品 A の詳細ページにアクセスし、製品について調べました。

翌朝、商品 A が特に自分に合っていると感じたので、モバイルブラウザで検索しました。有料広告をクリックすると、アプリストアにリダイレクトされ、ショッピングアプリをダウンロードしてインストールすることができました。

アプリをダウンロードしてインストールした後、購入するためにアプリを開くのを忘れました。夜、携帯電話でテレビシリーズを観ていたところ、iQiyi アプリでこの製品の広告を見ました。広告をクリックして、アクティベーションと登録のために次のアプリを起動しました。

その後、ショッピングアプリで商品を検索したところ、アプリ内で商品の検索入札広告が表示されました。広告をクリックして商品の詳細ページに移動し、注文しました。商品Aの注文詳細に一致する商品Bが見つかり、一緒に購入しました。

さて、私のショッピングの道のりを整理してみましょう。OTT 広告 -> PC での有料検索広告 -> モバイルでの有料検索広告 -> アプリマーケット -> ショッピングアプリのダウンロード -> モバイル OTV 広告 -> ショッピングアプリの起動 -> ショッピングアプリの有効化 -> ショッピングアプリでの有料検索広告 -> 製品 A を注文 -> 同時に製品 B を購入。

ショッピングのプロセス全体は非常に長いため、この場合、最後の 2 つの注文はどの広告キャンペーンによるものかが問題になります。

同時に、ダウンロードのアクティベーション（新規ユーザー）はどのチャネルに帰属するべきでしょうか?以下はすべて帰属に関するものです。

アトリビューションとは、「原因」と「結果」に関するものです。まずは、上記のショッピングジャーニーのケースにおける関連する原因と結果を分析してみましょう。

原因: 通常、広告が掲載されたときにユーザーが製品について知るタッチポイントを指します。これらのタッチポイントには、露出、クリック、またはユーザーにリーチできるその他の方法が含まれます。主に以下の質問に答えてください。

いつ: 何時ですか?
誰: 誰?
場所: どのチャネルで、どのデバイスで?
何: 何をしましたか?

結果：通常、ショッピングアプリをダウンロードして起動し、広告内の商品 A を購入し、同時に商品 B を購入するなど、広告主が広告を通じてコンバージョン効果をもたらすことを期待するイベントを指します。

「原因」と「結果」の両方がわかったので、関連する帰属方法論を正式に導入し始めます。

ユーザーID

このショッピングジャーニー中に、ユーザーは OTT、PC、モバイルの 3 つの端末にアクセスしました。これら 3 つの端では同じ実ユーザー (生体認証識別子) ですが、プログラマティック広告では、異なる機能を通じて同じユーザーを識別する必要があります。

オーバー

OTT（Over The Top）広告とは、オープンインターネットをベースとした動画サービスを指し、端末としてはテレビやセットトップボックスなどが挙げられます。現在、OTT デバイスの OS は主に Android であり、その時点では Apple TV も除外されていません。 Android プラットフォームでは、OTT のデバイス識別子は主に MAC であり、TVOS (Apple) では、デバイス識別子は主に IDFA です。

パソコン

PC広告の場合、デバイス関連の情報を取得できないため、ユーザーのIDは主にIP+UAになります。クッキーを通じてユーザーを識別する方法もありますが、これにはクッキーマッピングが必要です。

アンドロイド

モバイル広告の場合、Android で一般的に使用されるデバイス識別子は IMEI、OAID、MAC、AndroidId であり、アトリビューションの優先順位は IMEI>OAID>MAC>AndroidID です。 Android Q バージョン以降、Android システムは IMEI の取得をサポートしなくなったため、現在の Android デバイス番号は主に OAID に基づいています。ここで注意すべき点は、メーカーによって OAID 形式が異なるため、使用する際に注意する必要があるということです。

iOS

モバイル広告の場合、iOS 側でよく使用されるデバイス識別子は主に IDFA、IDFV、CAID であり、アトリビューションの優先順位は IDFA > CAID > IDFV となります。 IOS14以降では、ユーザーのプライバシーをさらに保護するために、IDFAの取得にはユーザーによる明示的な承認が必要となり、IDFAの取得率が低下します。大手主流メディアも対応計画を発表しているが、基本的にはCAIDである。しかし、CAID SDKを統合したアプリは、Appleに審査のために提出された際に拒否される。

帰属ロジック

ユーザー識別について説明したので、次は帰属ロジックについて説明します。帰属論理は、「結果」を特定の「原因」に帰属させる上で決定的な役割を果たします。業界で一般的に使用されているアトリビューションロジックには、主に次のものがあります。

最初のインタラクションモデル

最初のインタラクションモデルは、最初のインタラクションがユーザーに与える影響を重視します。その後の行動に関係なく、コンバージョンの結果は、接続を確立した最初のインタラクションチャネルに起因します。

ただし、このモデルは、ユーザーの行動サイクルが長すぎるため、予測が不正確になるなどの問題が発生する場合があります。そのため、このモデルは、ブランド構築や製品プロモーションの初期段階で新しいブランドの認知度を高めるのに適しています。

上記のショッピングジャーニーでは、最初のインタラクションモデルロジックを通じて、注文をアクティブ化するコンバージョンが「モバイル有料検索広告」に帰属します。実際、ユーザーの本当の最初のインタラクションはOTT側で発生しますが、OTT側とモバイル側のユーザーを結びつけることは困難です。もし結びつけることができれば、このコンバージョンは「OTT広告」に起因するものになります。

最終モデル

最後のインタラクションモデルは、最後のインタラクションがユーザーに与える影響を重視します。以前の行動に関係なく、コンバージョン結果は接続を確立した最後のインタラクションチャネルに起因します。

しかし、このモデルの重大な問題は、誤スワイプと盗難です。インタラクティブな動作を継続的にシミュレートすることで、他のチャネルからのトラフィックを独自のコンバージョンに統合できます。上記のショッピングジャーニーでは、最終的なインタラクションモデルロジックを通じて、アクティブ化された注文の変換が「モバイル OTV 広告」に帰属します。

そのため、このモデルは、コンバージョンパスが少なくサイクルが短い、つまり広告の目的がユーザーを購入に導くことであり、最終ステップが最も重要であることが多いビジネスに適しています。

平均モデル

平均分布モデルでは、ユーザーのジャーニー全体にわたるすべてのインタラクティブな動作を記録して分析する必要があることを強調しており、最終的なコンバージョン結果は各リンクに均等に帰属させる必要があります。これは、広告主がジャーニー全体を通じてユーザーとのつながりを維持し、ブランド認知度を維持したいと考えている企業に適しています。この場合、各チャネルは顧客の検討プロセスにおいて同等の役割を果たします。しかし、このアトリビューションモデルの問題は、さまざまなチャネルの有効性を区別できないことです。

時間減衰モデル

時間減衰モデルでは、ユーザーの最終的なコンバージョンはジャーニー全体を通じてすべての行動によって影響を受けることを認識していますが、行動がコンバージョンの瞬間に近いほど影響が大きくなることを強調しています。このアトリビューションモデルは、平均分布モデルのアップグレードバージョンです。このモデルは、ユーザーの意思決定サイクルが短く、販売サイクルが短い状況に適しています。たとえば、短期のプロモーションを実施していて、広告を 2 日間だけ掲載する場合は、この 2 日間の広告に高いウェイトを与える必要があります。

カスタマイズモデル

カスタムモデルでは、最終的なコンバージョン効果をカスタマイズし、コンバージョンチェーン内の各チャネルに帰属させることができることを強調しています。これを使用する場合、異なるチャネルの比率を設定する必要があります。この変換モデルの問題点は、異なるチャネルの比率をどのように設定するかです。モデル全体をサポートする強力なデータ分析機能が必要であり、グレー産業の開始を防ぐために公平かつ公正な視点に立つ必要があります。

まとめ

各アトリビューションモデルにはそれぞれ長所と短所がありますが、使用する際に、選択したモデルがビジネスシナリオに沿っており、すべてのチャネルに対して公平である限り、問題ありません。結局のところ、コンバージョンプロセスに参加したどのチャネルも、ユーザーに一定の影響を与える可能性があります。

アトリビューションウィンドウ期間

アトリビューションモデルに加えて、アトリビューションウィンドウ期間も、最終的なコンバージョンにつながる広告配信に影響します。いわゆるアトリビューションウィンドウサイクルとは、ユーザーがコンバージョンしたときに「原因」の時間をどのくらい遡るかを指します。この「時間」がアトリビューションウィンドウです。あらゆる変換結果を特定の期間までさかのぼって追跡する必要があることは、理解するのが難しくありません。期間の設定が異なると、関与する可能性のある「原因」も異なります。

では、このウィンドウ期間はどのくらいに設定すればよいのでしょうか?一般的に言えば、アトリビューションウィンドウの適切な期間は、プロモーションキャンペーンの目標に応じて決定する必要があります。プロモーションキャンペーンによって、アトリビューション期間は異なります。同じプロモーションキャンペーンであっても、PC やアプリなど異なるプラットフォームでプロモーションする場合は、アトリビューションウィンドウの期間が異なります。各企業の平均的なコンバージョンプロセスに基づいて、さまざまなウィンドウサイクルを策定できます。

帰属方法

ユーザー、モデル、ウィンドウサイクルについて説明したので、次に、これらの「原因」イベントをコンバージョン結果に関連付ける方法について説明します。一般的な帰属には次のものが含まれます。

固有のデバイス番号の割り当て

アプリ内配信では、デバイス番号が一意であり、さまざまなシナリオに関連付けることができる場合に、デバイス番号の属性が主に使用されます。ユーザーが広告を表示したりクリックしたりするなど、デバイスを操作すると、広告プラットフォームはデバイスのデバイス ID を取得し、監視リンクを通じて広告主にデバイス ID を送り返します。広告主側でユーザーがコンバージョンを完了すると、広告主のデータ分析プラットフォームは、デバイス数に基づいて配信チャネルでのユーザーの広告行動をマッチングし、異なるチャネルの配信効果を測定および帰属させることができます。

IP+UA 帰属

IP+UA 属性は、固有のデバイス識別子を持たないため、あいまい属性です。デバイス番号を取得できない場合に、属性を補足するために使用されます。そのアトリビューションの原理はデバイス番号アトリビューションに似ており、ユーザーが広告を操作すると、ユーザーの IP と UA (ユーザーエージェント、ユーザーのオペレーティングシステム、携帯電話のモデル、ブラウザ情報などを含む) が収集され、コンバージョン時のユーザーの IP と UA と照合されてコンバージョンアトリビューションが実現されます。

チャンネルパッケージの帰属

チャネルパッケージの帰属の主な適用シナリオは Android 側で、事前定義された「チャネル番号」が APK インストールパッケージに書き込まれます。

広告配信時、ダウンロードリンクは「チャンネル番号」付きのアプリパッケージリンクとなります。ユーザーがアプリをダウンロードして起動すると、インストールパッケージからチャンネル番号を読み取って帰属させることができます。

この帰属方法はシンプルで、デバイス番号の取得に限定されません。ただし、この方法にはインストールパッケージのカバレッジの問題があります。Android フォンには通常、システムレベルのアプリストアがあります。指定された「チャネル番号」を持つインストールパッケージは、アプリストアによって簡単に傍受され、ユーザーにアプリストアからダウンロードを強制します。その結果、最終的なコンバージョン効果は、アプリマーケットのインストールパッケージに帰属します。

こういった事態を防ぐために、次回以降の記事で紹介するアンチカバレッジの問題をここで紹介しますので、まずはそちらに注目してみましょう。

スキームの帰属

スキームアトリビューションとは、メディアアプリ内の広告をクリックし、スキームリンクを通じて広告主のターゲットアプリを起動することを指します。このとき、スキームリンクには関連するパフォーマンスパラメータが含まれます。

ユーザーがコンバージョンを実行すると、スキームのパフォーマンスパラメータが照合され、コンバージョンの帰属が達成されます。このアトリビューション方法の使用シナリオは、ユーザーが広告主の宣伝対象アプリをインストールしていることを前提としているため、アクティビティを誘引することです。

アプリ内配信の場合、PC と H5 はランディングページのアトリビューションも導出できます。つまり、関連するパフォーマンスパラメータを広告のランディングページリンクに挿入します。これにより、ユーザーがコンバージョンすると、広告主はアトリビューション用のランディングページのパフォーマンスパラメータも取得できます。

クリップボードの属性

クリップボードアトリビューションとは、ユーザーが H5 環境で広告を操作すると、その操作行動の一意の識別子がクリップボードに書き込まれることを意味します。その後ユーザーがコンバージョンすると、クリップボードの内容を読み取ってアトリビューションが実行されます。

この帰属方法の問題は、ユーザーのプライバシーです。結局のところ、工業情報化部はユーザーのプライバシーに関わる操作を厳しく調査してきました。

まとめ

さまざまな帰属方法がありますが、主なポイントは、一意の識別子を通じて「原因」と「結果」をどのように関連付けるかです。

この一意の識別子は、デバイス関連の情報、チャネルパッケージ情報、または特定の広告配信の一意の識別子にすることができます。ユーザーの広告インタラクションとコンバージョンが発生したときに一意の識別子をすばやく収集できる限り、収集された一意の識別子はローカルまたは基盤となるデータウェアハウスに保存できます。

アトリビューションフレームワークの設計

全体的な方法論を紹介した後、アトリビューションフレームワークの全体的な設計について説明し、完全なアトリビューションを実現するためにどのモジュールを設計する必要があるかを確認します。

上の図は基本的に、広告インタラクションからコンバージョンアトリビューションまでの完全なプロセスを示しており、ポイント 1 ～ 6 がマークされています。これらの 6 つのポイントに対応するモジュールを分解してみましょう。

監視モジュール

監視システムは、上図の 1 に相当します。このモジュールは、主にリンクを通じてユーザーのインタラクション動作を収集します。リンクによって収集されるパラメータは、さまざまな広告プラットフォームでサポートされているマクロ置換パラメータによって異なります。一般的なパラメータは、デバイス番号、タイムスタンプ、IP + UA、および広告配信に関連するいくつかのパラメータです。

監視リンクがデータを受信すると、そのデータは基盤となるデータウェアハウスに保存されます。その後、コンバージョン動作が発生すると、対応するインタラクティブ動作データがデータウェアハウス内で照合されます。

スキームリンク

Scheme リンクは、上図の 2 に相当します。このモジュールの主な機能は、指定されたページにアプリを起動し、起動パフォーマンスパラメータを記録することです。

ターゲットアプリが起動されると、起動パフォーマンスパラメータがローカルに保存されます。ユーザーが変換すると、ローカルパラメータが読み取られ、下流の変換アトリビューションサービスに送信され、それに基づいて Scheme アトリビューションが実行されます。

ここで注意すべき点は、パフォーマンスパラメータをローカルに保存する場合、パラメータの検証が必要であり、不正なパラメータは破棄する必要があることです。同時に、最初のインタラクションモデルなど、一度だけ保存する必要があるアトリビューションロジックを組み合わせる必要があります。

Android パッケージングモジュール

Android パッケージングモジュールは、上図の 3 に該当します。このモジュールの機能は、Android チャネルパッケージをパッケージ化して管理し、チャネルパッケージの APK ファイルを出力することです。

JS-SDKモジュール

JS-SDKは上図の5と6に該当します。このモジュールの主な機能は、H5ページを開いたときにJS-SDKを通じてコンテンツを記録し、関連するコンテンツをクリップボードとCookieに書き込むことです。

記録されるコンテンツには、IP、UA、URL リンク、固有の広告 ID などが含まれますが、これらに限定されません。ユーザーがアプリを開くと、アプリがアクティブ化されているか起動されているかに関係なく、対応するクリップボードの内容を読み取ることができます。対応するコンテンツに応じて異なるコンテンツを表示します。

アクティビティ構成モジュール

ユーザーがアプリを開いたときにユーザーに表示されるページを構成します。監視リンクとクリップボードの内容を関連付けることで、シーンの復元やインタラクティブなカスタマイズを実現できます。

このモジュールは比較的重要です。ユーザーがアプリに最初にアクセスするページは、ユーザーのコンバージョンに直接関係します。このセクションでは、ユーザーが最も興味を持っているコンテンツを表示するためのいくつかの関連戦略を設定できます。

たとえば、ユーザーが目にする広告商品を表示して、見た通りの商品を入手したり、新規ユーザー向けの特別ゾーンコンテンツを表示して初回注文の可能性を高めたりします。

アトリビューションモジュール

アトリビューションモジュールは、フレームワーク全体の中で最も重要なモジュールです。主に、アトリビューション戦略の管理とアトリビューション結果の表示を担当します。

さまざまなシナリオに合わせてさまざまなアトリビューション戦略を構成でき、アトリビューションの結果はデータレポートを通じて表示できます。