ファーストタッチ、ラストタッチ、マルチタッチアトリビューションモデルの比較

ファーストタッチ、ラストタッチ、マルチタッチアトリビューションモデルの違いとは？ これらのモデルは、モバイルマーケターがユーザー獲得経路におけるコンバージョン貢献度をどのように分配するかを決定するものです。モバイルの獲得チャネルが検索広告、SNS広告、インフルエンサー、リターゲティングへと拡大する中、モバイルアプリのアトリビューションモデルは、ユーザー体験全体を通じた各チャネルの貢献度を評価するための測定基盤となります。

アトリビューションモデルとは、コンバージョンに至るまでのマーケティング接点に対し、コンバージョンや収益の価値をどのように割り当てるかを定義する定量的なルールや数学的フレームワークです。断片的あるいは単一のポイントに貢献度を割り当てることで、マーケターは各メディアチャネルの真の獲得効率を評価できるようになります。

AppsFlyer、Adjust、Branch、およびOpeninstallなどのモバイル計測プラットフォーム（MMP）は、アトリビューションモデルを適用し、キャンペーンの接点、インストール、インストール後のイベント、および広告チャネル間の収益シグナルを照合します。

以下に移動: クイック比較表 | モデルと計測期間の違い | アトリビューションとインクリメンタリティ | よくある質問

結論：クイック回答

モバイルマーケティングにおいて、アトリビューションモデル自体はトラッキングの仕組みではありません。それはアトリビューション処理中に適用される、どの接点にコンバージョンの功績を与えるかを決めるルールです。ファーストタッチは「発見」、ラストタッチは「最終コンバージョンの影響」、マルチタッチは「複数の相互作用による複合的な貢献」を評価します。

• ラストタッチアトリビューションの選択基準: 購入サイクルが短い（24時間以内）製品で、ユーザーが一度の広告接触ですぐにコンバージョンする場合。
• マルチタッチアトリビューションの選択基準: アプリが検索、SNS広告、インフルエンサーなどのマルチチャネルをまたぐジャーニーを伴う場合や、検討期間が数週間に及ぶサブスクリプション型サービスの場合。
• データドリブンアトリビューションの選択基準: 十分なコンバージョン数があり、統計的に意味のある過去の接点データが蓄積されており、貢献度モデルを学習させる体制が整っている場合。

クイック比較表

以下の表は、シングルタッチおよびマルチタッチアトリビューションモデルにおけるコンバージョン貢献度の分配をまとめたものです：

モデル	適した用途	主な利点	主な制限
ファーストタッチ	ブランド発見キャンペーン	初期獲得のきっかけを測定できる	後続のコンバージョン要因を無視する
ラストタッチ	短サイクル型のアプリ	導入と照合が容易	最終的な広告接触を過大評価する
マルチタッチ	検討期間の長いジャーニー	チャネル間で貢献度を分割配分できる	ログレベルのデータ連携が必要

アトリビューションモデル選定チェックリスト

• ラストタッチモデルを選択すべきケース:
  • ✓ キャンペーンが単一チャネルのCPIモデルで運用されている場合。
  • ✓ 初回広告接触から24時間以内にコンバージョンが完了する場合。
  • ✓ ユーザーのジャーニーにおいて、途中のナーチャリング接点がほとんどない場合。
• マルチタッチモデルを選択すべきケース:
  • ✓ マーケティング予算が複数の有料ネットワーク、検索、SNSチャネルに分散されている場合。
  • ✓ 製品検討に数週間かかる場合（サブスクリプションアプリ、フィンテック、B2B SaaSなど）。
  • ✓ SANネットワーク（Meta広告やGoogle広告など）でコンバージョンの重複報告が発生している場合。
• データドリブンモデルを選択すべきケース:
  • ✓ 月間数万件以上のコンバージョンが発生しているキャンペーン規模がある場合。
  • ✓ イベントレベルの接点ログを出力可能なデータインフラがある場合。

一般的なモバイルアトリビューションモデルの種類

モバイルアトリビューションの枠組みは、貢献度の配分ルールに応じて3つのパラダイムに分類されます：

• シングルタッチアトリビューション: コンバージョン貢献度の100%を単一の接点に割り当てます。ファーストタッチ（最初の発見接点を評価）とラストタッチ（計測期間内の最終接点を評価）が含まれます。

• ルールベース・マルチタッチアトリビューション: すべての記録された接点に対して、固定のアルゴリズムに基づいた割合で配分します。線形（均等配分）、タイムディケイ（最近の接点を重視）、ポジションベース（U型配分）が含まれます。

• アルゴリズムアトリビューション: 機械学習を用いて、各接点の貢献度を動的に算出します。

  モバイルアトリビューションモデル
  │
  ├── シングルタッチアトリビューション
  │ ├── ファーストタッチアトリビューション
  │ └── ラストタッチアトリビューション
  │
  ├── ルールベース・マルチタッチアトリビューション
  │ ├── 線形（リニア）アトリビューション
  │ ├── タイムディケイアトリビューション
  │ └── ポジションベースアトリビューション（U型）
  │
  └── アルゴリズムアトリビューション
  └── データドリブン機械学習モデル

モバイルアトリビューションの業界背景

業界のベンチマークによると、モバイル広告エコシステムの複雑化に伴い、モバイルアトリビューションは単純なインストール計測から、イベントや収益に基づくアトリビューションへと進化してきました。

初期のインストール単価（CPI）キャンペーンは、検討経路が短く、パフォーマンス広告や有料獲得チャネルが主流であったため、主にラストタッチアトリビューションに依存していました。しかし、サブスクリプションアプリやゲームの収益化ループ、チャネル横断的な獲得が拡大するにつれ、マーケターは assisted conversions（間接コンバージョン）を分析し、ファネル上部のメディア投資を評価するために、マルチタッチやデータドリブンアトリビューションモデルを積極的に導入するようになりました。

現代のアトリビューションアーキテクチャは、クリックログ、インプレッションデータ、アプリストアのインストールシグナル、インストール後のコンバージョンイベント、収益コールバックを一元管理し、初回ダウンロードを超えた獲得品質を評価しています。

モデル	適した用途	主な利点	主な制限
ファーストタッチ	ブランド発見キャンペーン	初期獲得のきっかけを測定できる	後続のコンバージョン要因を無視する
ラストタッチ	短サイクル型のアプリ	導入と照合が容易	最終的な広告接触を過大評価する
マルチタッチ	検討期間の長いジャーニー	チャネル間で貢献度を分割配分できる	ログレベルのデータ連携が必要

アトリビューションモデルの選択がパフォーマンスに及ぼす影響

不適切なアトリビューションモデルの選定は、キャンペーン評価に不正確なレポートをもたらします。歴史的に、成長チームはシンプルさゆえにシングルタッチフレームワーク、特にラストタッチ計測に頼っていました。しかし、コンバージョン貢献度の100%を最後の広告接触に割り当てることは、本来ユーザーをコンバージョンファネルへと導いた最初の発見や検討段階での接点を無視することになります。

この単一ポイントへのバイアスは、メディアバイイングにおいて財務リスクを生みます。動画広告やインフルエンサー施策といったファネル上部のキャンペーンは、本来ユーザーの興味喚起に貢献しているにもかかわらず、コンバージョン貢献度ゼロと見なされます。その結果、マーケティングチームは高パフォーマンスな発見チャネルへの資金を誤って削減し、既にコンバージョンする可能性が高かったユーザーに対するラストタッチを獲得しただけのファネル末端のリターゲティング広告に予算を集中させてしまう可能性があります。

マーケティング効率を評価するには、複数の接点がどのように一つの獲得に寄与しているかを評価する必要があります。最適なアトリビューションモデルは、ユーザーのジャーニー全体にバランスの取れた可視性を提供し、チームが真のマーケティング投資収益率（ROAS）を計算し、複雑なメディアミックス全体で顧客獲得コスト（CAC）を最適化することを可能にします。

シングルタッチとマルチタッチの比較

基本的なレベルで、モバイルキャンペーンの計測はシングルタッチとマルチタッチのフレームワークに分けられます。各フレームワークはユーザーの相互作用データを以下のように処理します：

• シングルタッチアトリビューション: ユーザーのジャーニーを、最初または最後のクリック/インプレッションという単一の相互作用から評価し、コンバージョン価値の100%をそこに割り当てます。
• マルチタッチアトリビューション（MTA）: コンバージョン以前の利用可能なユーザー相互作用をキャプチャし、加重ルールを適用して適格な全接点に貢献度を分割配分します。

30日間のコンバージョンサイクルで$49.99の年間サブスクリプション購入が発生した場合の例で、貢献度の配分を比較します：

• Day 0: ユーザーがTikTok動画広告を見てリンクをクリック（ブランド発見）。
• Day 3: ユーザーがGoogle検索でアプリを検索し、テキスト広告をクリック。
• Day 7: ユーザーがMeta広告のリターゲティングバナーをクリック。
• Day 30: ユーザーがアプリ内で$49.99のサブスクリプション購入を完了。

モデル	TikTok (Day 0)	Google検索 (Day 3)	Metaリターゲティング (Day 7)	検証済み購入 ($49.99)
ファーストタッチ	$49.99 (100%)	$0.00	$0.00	$49.99
ラストタッチ	$0.00	$0.00	$49.99 (100%)	$49.99
線形	$16.66 (33.3%)	$16.66 (33.3%)	$16.66 (33.3%)	$49.99
ポジションベース (40/20/40)	$19.99 (40%)	$10.00 (20%)	$20.00 (40%)	$49.99
データドリブン (アルゴリズム)	MLによる動的ウェイト	MLによる動的ウェイト	MLによる動的ウェイト	$49.99

アプローチを迅速に決定するために、データチームは以下の意思決定フローを使用します：

初回広告接触から24時間以内にコンバージョンしますか？
       │
      はい ──> ラストタッチモデル
       │
      いいえ
       │
コンバージョン前に複数の広告チャネルと接触しますか？
       │
      はい ──> マルチタッチモデル（ポジションベースまたはタイムディケイ）
       │
      いいえ ──> ファーストタッチまたは線形モデル

アトリビューションモデルによる貢献度配分の仕組み

アトリビューションモデルは特定の加重ルールを用いてキャンペーンの接点に貢献度を割り当てます。成長チームは通常、コンバージョンの複雑さに応じて以下の5つのルールベースモデルから選択します：

ラストタッチモデル

• 貢献度配分ルール: 計測期間内の最後のクリック（またはビュー）にコンバージョン貢献度の100%を割り当てます。
• 貢献度算出式: 最終接点の貢献度 = コンバージョン価値の100%。
• 活用シーン: 非常に簡潔ですが、発見チャネルを無視するため、リターゲティングやブランド検索に偏りが生じます。

ファーストタッチモデル

• 貢献度配分ルール: アプリにユーザーを導入させた最初のマーケティング接点に100%の貢献度を割り当てます。
• 貢献度算出式: 初回接点の貢献度 = コンバージョン価値の100%。
• 活用シーン: ブランド認知チャネルを強調しますが、その後のリターゲティングや最終コンバージョンのドライバーに関する可視性は得られません。

線形（リニア）アトリビューションモデル

• 貢献度配分ルール: 計測期間内のすべての記録された接点にコンバージョン価値を均等に配分します。
• 貢献度算出式: 各接点の貢献度 = 1 ÷ N（Nは記録された接点の総数）。
• 活用シーン: バランスは取れていますが、購入意向の低い広告閲覧と、購入意向の高いクリックを同等に扱います。

タイムディケイアトリビューションモデル

• 貢献度配分ルール: 最終コンバージョンに近い接点ほど高い貢献度を割り当てる減衰計算式を使用します。
• 加重算出式: 貢献ウェイト = 2^(-t/h)（tは経過時間、hは選択された半減期）。各接点のウェイトを算出した後、合計が100%になるよう正規化されます。
• 活用シーン: 購入決定に強い影響を与える、コンバージョンに近い接点が重視されます。

ポジションベースモデル

• 貢献度配分ルール: 最初の発見と最終コンバージョンに高いウェイトを置き、中間の接点に残りの貢献度を配分します。
• 中間配分: ファーストタッチ＝40%、ラストタッチ＝40%、中間タッチ＝残りの20%を均等配分。接点が2つしかない場合、プラットフォーム設定により均等配分などが適用される場合があります。
• 活用シーン: 最初の40%、最後の40%を割り当て、中間の20%を均等に分けるU型配分が一般的で、ブランド発見と購入実行のバランスを取ります。

ルールベース vs アルゴリズムアトリビューション

ルールベースモデルが静的なパーセンテージを適用するのに対し、アルゴリズム（データドリブン）アトリビューションモデルは、機械学習を用いてユーザー行動チェーンを動的に分析します。

アルゴリズムモデルは、過去のコンバージョンパスに基づいて、各接点の相対的な寄与確率を推定します：

• マルコフ連鎖モデル: 接点間の遷移確率を分析し、除去効果を通じてチャネル貢献度を推定します。
• シャープレイ値モデル: 協力ゲーム理論を用いて、各チャネルの増分寄与度を評価します。

アルゴリズムモデルは複雑なメディアミックスに適応しますが、ルールベースモデルは監査が容易で、透明性が高く、サードパーティチャネル間での照合も単純です。

決定論的（Deterministic） vs 確率論的（Probabilistic）アトリビューション

計測における根本的な技術の違いは、環境間でユーザーの相互作用を照合するメカニズムにあります：

• 決定論的アトリビューション: 認証済みIDFA、ログインID、デバイスIDなどの一意の識別子を使用して照合します。精度はほぼ完璧ですが、プライバシー同意率に制限されます。
• 確率論的アトリビューション: 識別子が利用できない場合、ブラウザ環境やセッションメタデータなどの文脈的シグナルを評価して照合します。現代のプライバシー制限下でより広いリーチを可能にします。

クリックスルー vs ビュースルーアトリビューション

キャンペーン計測における基本的な区分は、クリックとビューの違いです：

• クリックスルーアトリビューション（CTA）: 指定されたルックバックウィンドウ内での明示的な広告クリックをコンバージョンの要件とします。
• ビュースルーアトリビューション（VTA）: 広告をクリックせずに閲覧し、その後コンバージョンに至った場合にクレジットを与えます（クリックに比べ、通常非常に短いウィンドウを設定）。

多くのモバイル計測プラットフォームでは、クリックとインプレッションの両方が適格なウィンドウ内に存在する場合、クリックアトリビューションが優先されます。

アトリビューションとインクリメンタリティ：因果関係 vs 貢献度配分

現代のモバイルグロースにおいて重要なのは、両者の違いを理解することです。チームは頻繁にこれらを混同します：

• アトリビューション（貢献度配分）: 事前定義された照合ルールに基づき、どのチャネルに功績を与えるかを回答します。過去のチェーンを振り返り、財務的価値を分配します。
• インクリメンタリティ（因果的リフト）: A/Bテストやホールドアウト群を用いて、広告がなければ起こらなかったであろう増分コンバージョンは何かを測定し、真の因果関係を解明します。

あるチャネルはラストタッチモデルでは高く評価されますが、インクリメンタリティテストを行うと、ユーザーの90%が元々コンバージョンする予定だった「オーガニック層」であったということが判明する場合があります。高パフォーマンスなチームは、日々の最適化にはアトリビューションモデルを使い、期間ごとのチャネルリフト検証にはインクリメンタリティ実験を活用します。

プライバシー変更とSKAdNetworkの影響

現代のアトリビューションは、AppleのATT（App Tracking Transparency）やSKAdNetwork（SKAN）といったプライバシーフレームワークを考慮する必要があります。IDFAの利用が大幅に制限されています。

これらの変化はiOSでのアトリビューションに直接影響します：

• 集計型ポストバック: トラッキングを許可しないユーザーに対し、SKAdNetworkはユーザーレベルのアトリビューションに代わり、プライバシー保護のための集計キャンペーン計測を提供します。これは個人単位ではなく、インストール後の集計活動シグナルとなります。
• コンバージョン値マッピング: マーケターはアプリ内イベントを精緻なコンバージョン値にマッピングする必要があります。
• モデルベース/確率論的アトリビューションへの移行: グロースチームは、SKANの集計データとプライバシー準拠のファーストパーティトークン、およびインクリメンタリティテストを組み合わせ、チャネルパフォーマンスを正確に評価しています。

アトリビューション不正と計測リスク

不正トラフィックがアトリビューションの計算を歪めることを理解する必要があります：

• クリックインジェクション: 不正なスクリプトがアプリストアのダウンロードを検知し、初回起動の数ミリ秒前に広告クリックを偽造し、ラストタッチを奪取します。
• クリックスパミング: 大量の低意向なバックグラウンドクリックを生成し、オーガニックインストールに対してラストタッチの功績を主張します。
• インストールハイジャック: インストール後のシグナルを傍受し、正当な発見チャネルから功績を横取りします。

これらに対処するには、CTIT（Click-To-Install Time）分析、デバイスレベルの異常検知、サーバーサイドでの検証が不可欠です。

SANがアトリビューション精度に与える影響

モバイルアトリビューションにおける最大の課題の一つがSAN（Self-Attributing Network）の管理です。主要な広告チャネルは、デバイスレベルのクリックログを外部と共有しない閉じたエコシステムとして運用されています。これらのネットワークは、インストール発生時に自社のデータベースを照合してコンバージョンを主張します。

ユーザーがインストール前に複数のSANで広告に接触した場合、SANは外部からのアクセスを制限し、独自の内部アトリビューションシステムに依存するため、重複カウントが発生しやすくなります。

この対立を解決するには、独立したモバイル計測プラットフォーム（MMP）を導入する必要があります。MMPはコンバージョンタイムスタンプの正規化、重複排除、一貫したルールの適用を行うことで、これらの競合を解決します。

ビジネスに適したアトリビューションモデルの選び方

最適なモデルの選定には、ビジネスタイプ、平均的なユーザー決定サイクル、メディアの多様性を評価する必要があります。以下の意思決定マトリックスを参考にしてください：

ビジネスタイプ	決定サイクル	購入行動	推奨モデル
ハイパーカジュアルゲーム / ツール	短い (< 24時間)	衝動的なDL、単一クリック	ラストタッチ
EC / 小売	中間 (1 - 7日)	比較検討、SNS & 検索	タイムディケイ
サブスク / フィンテック	長い (1 - 3週間)	複数回のトライアル、リターゲット	ポジションベース or データドリブン
B2B SaaS / 高単価	極めて長い (> 1ヶ月)	コンテンツ発見、マルチデバイス調査	線形 or マルチタッチ

アトリビューションモデルと計測ウィンドウの違い

マーケターはモデルと計測ウィンドウを頻繁に混同しますが、これらは異なる計測機能を果たします：

評価項目	アトリビューションモデル	計測ウィンドウ（Lookback）
目的	貢献度の配分決定	適格なルックバック期間の定義
例	ラストタッチ、ポジションベース	1日クリック、7日クリック、30日クリック
回答する問い	誰に功績を与えるか？	どの接点が対象か？

計測ウィンドウ（ルックバック）の理解

適切なルックバック期間の設定も極めて重要です。これは、コンバージョン前のどの期間のクリックやインプレッションを有効とするかを定めます：

• 1日クリックウィンドウ: 超短期的な衝動コンバージョン用。
• 7日クリックウィンドウ: 多くのパフォーマンス広告の標準。
• 30日クリックウィンドウ: 数週間にわたる検討が必要なサブスクリプションやエンタープライズ製品用。

コンバージョンウィンドウを自然な購入タイムラインに合わせることで、ユーザーの決定に何の影響も与えていない古い広告接触に功績を与えるのを防ぎます。

マルチタッチアトリビューションが必要な時

キャンペーンが複雑化し、ラストタッチレポートの限界を感じた時にマルチタッチへの移行を検討します：

• マルチチャネルのユーザージャーニー: ユーザーがアプリインストール前に3つ以上の異なるメディアと接触している場合。
• メディア予算の拡大: 単一チャネルを超えた広告予算投入が行われ、精緻なクロスチャネルROAS検証が必要な場合。
• SANの重複: SANからの重複請求により、収益の二重カウントが起きている場合。
• サブスクリプション継続の重視: 顧客生涯価値（LTV）には、衝動的な購入ではなく長期的な維持が必要な場合。

モバイルアトリビューションの運用上の考慮事項

現場では3つの核心的課題に直面します：

• SANの重複: 独立したバックエンド判定基準を設け、重複排除を厳格に適用する必要があります。
• ウィンドウの不一致: ネットワークごとにデフォルト設定が異なるため、中央で標準化して比較しないとミスリードになります。
• インストール後のコンバージョン遅延: サブスク更新など、ダウンロード後数週間経ってから発生する高価値イベントの管理。

これを解決するため、以下の3つのパイプラインを分離して管理します：

1. インストールアトリビューション: アプリストアでのダウンロード起源を検証。
2. イベントアトリビューション: アプリ内ユーザー行動をキャンペーンパラメータに紐付け。
3. 収益アトリビューション: 金銭的注文額を元の獲得チャネルに紐付け。

技術的実装と生ログ（Raw Log）のエクスポート

ダッシュボードだけでなく、高度なデータチームはログレベルのデータが必要です。未集計の生データにより、データウェアハウス内で独自の加重アルゴリズムを構築できます。

生アトリビューションログには、セッション識別子、タイムスタンプ、広告クリエイティブID、正規化された収益額などが含まれます。これらはS2S（サーバー間）ポストバック、API、または定時のエクスポートによって配信されます。

[コンバージョン] ──> [照合サーバー] ──> [S2S Webhook] ──> [データウェアハウス]

生データエクスポートのドキュメントで詳細を確認してください。

{
  "event_type": "attribution_postback",
  "model_applied": "position_based",
  "touchpoint_count": 3,
  "total_revenue_cents": 4999,
  "currency": "USD"
}

アトリビューションモデル選定でのよくある間違い

• サブスク製品でのラストタッチ利用: ファネル上部の発見キャンペーンを過小評価し、獲得が枯渇します。
• 重複排除なしでのSANインストール合算: 収益指標の過大評価に繋がります。
• オーガニックアシストの無視: リターゲティングへの過剰投資を招きます。
• 過度に長いルックバックウィンドウ: コンバージョン意向と無関係な受動的な広告閲覧まで功績を与えてしまいます。

事例：スケーリングアプリでのマルチチャネル分析

課題

サブスクアプリで、検索、SNS、インフルエンサーに分散。ラストタッチに頼ると上部の動画発見チャネルが「不採算」に見え、キャンペーン中止の危機に。

実装

ポジションベースのマルチタッチモデルを導入し、独立プラットフォームの生ログを使用して重複を排除し、貢献度を再配分。

成果

インフルエンサー施策が実はインストールを支援していたことが判明。インストール総数を維持しつつ予算を最適化。

アトリビューションモデル比較一覧

評価軸	ラストタッチ	ファーストタッチ	線形（MTA）	ポジションベース
貢献度配分	最後100%	最初100%	均等配分	最初・最後重視(例:40/20/40)
適合サイクル	短/衝動型	認知拡大	中程度の検討	長/高検討
実装負荷	低い	低い	中程度	高い (生ログ必要)
上部ファネル可視性	ほぼゼロ	高い	中程度	高い

まとめと意思決定の枠組み

以下のような成長目的を持つ場合は、高度なマルチタッチアトリビューションへの移行を推奨します：

• ✓ マルチチャネルのメディアミックス: 有料ネットワーク、コンテンツ制作、リターゲティングなどを同時に運用している場合。
• ✓ 検討期間の長さ: ユーザーが購入までに数日間〜数週間のジャーニーを要する場合。
• ✓ SANの重複排除が必要: 複数の広告ネットワークでコンバージョンが重複主張されている場合。
• ✓ 精緻なROAS最適化: ファネル上部の認知から下部の転換までをトータルで評価する必要がある場合。

これらの状況では、マルチタッチアトリビューションへの移行がチャネル効率の正確な把握につながります。OpoInstallなどのプラットフォームは、Webhookベースのポストバックや生データのエクスポートをサポートしており、サーバーサイドでのアトリビューション基盤構築を支援します。

監修：モバイル計測スペシャリスト | 最終更新：2026年8月

関連コンセプト

概念	定義
アトリビューションモデル	マーケティング接点に価値を割り当てる計算ルール。
ラストタッチ	最後のクリックに100%の価値を割り当てるモデル。
マルチタッチ	ジャーニー内の複数の接点に価値を分散するモデル。
ファーストタッチ	最初の発見イベントに100%の価値を割り当てるモデル。
貢献度配分	個々の接点に割り当てられる部分的またはパーセンテージの価値。
生ログ（Raw Logs）	カスタム分析のためにエクスポートされる未集計のイベントデータ。

関連資料

関連コンセプト

• インストールアトリビューション: アプリのダウンロード元を特定する基盤パイプライン。
• 顧客獲得コスト (CAC): 単一の有効ユーザーを獲得するために必要な総費用。
• SAN（自己申告型ネットワーク）: 独自の内部データでコンバージョンを報告する大手プラットフォーム。

関連技術

• Google Play Install Referrer: Android上でインストール時のキャンペーンメタデータを渡すGoogleネイティブAPI。
• Universal Links: Webアクションをアプリ内画面に繋ぐAppleのネイティブディープリンク規格。
• App Links: AndroidのURLを処理するGoogleのディープリンクプロトコル。
• モバイル計測プラットフォーム (MMP): チャネル横断のシグナルを一元管理・重複排除する独立システム。
• SKAdNetwork: Appleのプライバシー保護を重視した集計型広告計測フレームワーク。

公式ドキュメント / 参照

• Google広告アトリビューションモデル ドキュメント
• Meta広告アトリビューション設定 ドキュメント
• Apple ATT（App Tracking Transparency）フレームワークガイドライン
• Apple SKAdNetwork ドキュメント
• Google Play Install Referrer API仕様