アトリビューションシナリオ

Airbridgeが特定の状況で広告のパフォーマンスを測定する方法をご紹介します。先に進む前に、Airbridgeのアトリビューションモデルに関するこの記事をご参照いただき、次のコンセプトを理解しておいてください。

ウェブアトリビューションのルール

Airbridgeのウェブアトリビューションのルールは、モバイルアプリのルールと以下の点で異なります。

  • ウェブイベントのためのルックバックウィンドウは設定できません。

  • ウェブイベントのアトリビューションウィンドウはデフォルトで3日間(72時間)に設定されています。変更をご希望の場合は、この記事を参照ください。

  • トラッキングリンク経由で収集されたタッチポイントは、Airbridge Web SDKのUTMパラメータパーシング(Parsing)機能により収集されたタッチポイントよりも優先されます。

モバイルアプリのアトリビューション

モバイルアプリのアトリビューションのプロセスを、以下のシナリオでご説明します。不正なタッチポイントは排除されており、すべてのコンバージョンがアプリ内で発生したことを前提としています。

ルックバックウィンドウの仕組み

ユーザーがアプリをインストールする前に3つの異なる広告チャネルとインタラクションしたとします。ここでの目的は、アプリインストールの功績をどの広告チャネルに割り当てるかを決定することにあります。

ユーザージャーニーを再構成した後、Airbridgeは以下のように進めます。

アトリビューションウィンドウの仕組み

ユーザーがアプリのインストールを含め、合計5回のインタラクションをしたとします。アプリインストールに導いたタッチポイントはすでに決定されています。ここでの目的は、インストール後のアプリ内イベントのアトリビューションを行う方法を決定することにあります。

ユーザージャーニーを再構成した後、Airbridgeは以下のように進めます。

重複するアトリビューションウィンドウの仕組み

ユーザーがアプリのインストール(Install)とDeeplink Openを含め、合計5回のインタラクションをしたとします。これら2つのイベントを導いたタッチポイントはすでに決定されています。ここでの目的は、インストール後のアプリ内イベントのアトリビューションを行う方法を決定することにあります。

ユーザージャーニーを再構成した後、Airbridgeは以下のように進めます。

ウェブアトリビューション

ウェブアトリビューションプロセスを、以下のシナリオでご説明します。不正なタッチポイントは排除されており、すべてのコンバージョンがアプリ内で発生したことを前提としています。

ウェブアトリビューションのルール

Airbridgeのウェブアトリビューションのルールは、モバイルアプリのルールと以下の点で異なります。

  • ウェブイベントのためのルックバックウィンドウは設定できません。

  • ウェブイベントのアトリビューションウィンドウはデフォルトで3日間(72時間)に設定されています。変更をご希望の場合は、この記事を参照ください。

  • トラッキングリンク経由で収集されたタッチポイントは、Airbridge Web SDKのUTMパラメータパーシング(Parsing)機能により収集されたタッチポイントよりも優先されます。

ウェブイベントのアトリビューションを行う方法

Airbridgeがウェブイベントに導いたタッチポイントを特定するためには、Airbridge Web SDKをウェブサイトに統合し、ユーザーがトラッキングリンクが埋め込まれた広告をクリックしてウェブサイトを訪れる必要があります。

ユーザーがウェブサイト訪問を含め、ウェブサイトと4回インタラクションしたとします。ここでの目的は、訪問後のウェブイベントのアトリビューションを行う方法を決定することです。

ユーザージャーニーを再構成した後、Airbridgeは以下のように進めます。

重複するウェブアトリビューションウィンドウの仕組み

ユーザーがウェブサイトを2回訪問することを含め、ウェブサイトと5回インタラクションしたとします。ここでの目的は、他の3つのウェブイベントにどのようにアトリビューションを行うかを決定することです。

ユーザージャーニーを再構成した後、Airbridgeは以下のように進めます。

このページは役に立ちましたか?

ご質問やご提案はありますか?