Signal Engineeringとは何か、ATT以降の何を直すのか

おそらくこのページに来た理由

これらはいずれもメディアバイイングの問題ではありません。シグナルの問題であり、その大半は直せます。

• MetaはあるROASを報告し、RevenueCatはその半分を報告し、経理部門はどちらも信用していない。両者はけっして一致しません。その理由をチームの誰も説明できない。
• SKANのコンバージョン値が大半のキャンペーンで空のまま返ってきて、その理由が誰にもわからない。
• Metaは問題なくスケールする。同じクリエイティブなのに、GoogleとTikTokは伸び悩む。
• 価値最適化に切り替えたら、かえって悪化した。
• トライアル開始は安く獲得できるのに、有料転換がまったく続かない。
• アプリの中に3つのSDKが入っていて、どれがコンバージョン値の管理権を持っているのか誰も答えられない。

Signal Engineeringが直すもの

5つの層を、私が構築する順番で並べます。

• イベント層。貴社のアプリに対する唯一の正規イベント体系を作り、Metaの標準イベント、Googleのコンバージョンイベント、TikTokのイベント、そして貴社のMMPに明示的にマッピングします。トライアル開始、初回課金、更新、解約、返金。それぞれに値、通貨、IDを付与します。
• サーバーサイド配信。Metaのアプリイベント向けConversions API、TikTokのEvents API、Googleのアプリコンバージョン設定を、貴社のMMPまたはFirebase経由でサブスクリプションのバックエンドと接続し、アプリが閉じられていても更新、返金、トライアルの転換がプラットフォームに届くようにします。イベントIDで重複排除するため、二重にカウントされることはありません。
• iOSのコンバージョン値スキーマ。Appleが送り返すことを許している小さな値は、トラッキングを拒否したユーザーについて得られる唯一のインストール後シグナルです。この値は貴社のファネルと数量に合わせて設計し、キャンペーンがAppleのプライバシー閾値をクリアして、何も返さない状態に陥らないようにします。この値の管理権は1つのSDKに持たせます。2つのSDKが書き込むと最後の呼び出しが勝ってしまい、いまのところそれはたいてい事故です。
• 入札のための価値シグナル。購入価値、マージン、または予測LTVを、Metaを含むすべてのプラットフォームに送ります。ただし、その値がユーザーの実際の支払いと相関しているかを確認した後に限ります。誤った値は、アルゴリズムに間違ったユーザーをより速く買うよう教え込んでしまいます。
• 突き合わせビュー。プラットフォーム、MMP、RevenueCat、ストアの支払い額を月次で一つの表に比較し、想定されるギャップをあらかじめ書き出しておきます。次に数字が食い違ったとき、それが構造的なものかバグなのかを5分で判断できるようにするためです。

ATT以降に直せないこと、そしてそれを明言する理由

iOS 14.5以降、App Tracking Transparencyを拒否したユーザーはユーザー単位でアトリビューションできません。AppleのSKAdNetworkとAdAttributionKitは、デバイス識別子のない、遅延した集計ポストバックを返し、少量のキャンペーンについては意図的に詳細を伏せます。どのConversions API連携も、どのMMPの機能も、どのアトリビューション復元ツールも、これを変えることはできません。MetaはそれらのイベントをAggregated Event Measurement経由で処理します。Googleはモデリングで補い、TikTokもモデリングで補います。

ですから、私は決定論的なアトリビューションを約束しません。約束するのは、自分たちでコントロールできるシグナルが正しいこと、プラットフォームが最適化のために可能な限り最良の入力を得られること、そしてどの食い違いが正常なものかを貴社が把握できるようになることです。この作業が終わった後も、プラットフォームのROASとサブスクリプションの売上は一致しないままでしょう。ただし、その理由は説明できるものになります。もし別のベンダーが違うことを言うなら、そのユーザーIDがどこから来ているのか尋ねてみてください。

iOSではどのシステムが何を報告するのか

同じiOSキャンペーンのインストールとコンバージョンを、5つのシステムがそれぞれ数えています。数字が食い違っても、どれかが間違っているとは限りません。数えているもの、ウィンドウ、遅延がそれぞれ違うからです。下の表は各ベンダー自身のドキュメントをもとにまとめたもので、2026年9月29日に確認しています。

GoogleのiOSの数字を揃えるには、貴社側での作業が必要です。Integrated Conversion Measurementについて、Googleは次の条件を挙げています。インストール向けのiOSアプリキャンペーンが稼働していること、MMPのfirst_openとインストール後のイベントがGoogle Adsにインポートされていること、イベントデータを使ったデバイス上の測定が有効であること、そしてMMPのSDKが最新であることです。イベントデータを使ったデバイス上の測定には、iOS 12以降、バージョン11.14.0以降のGoogle Analytics for Firebase SDK、Google Adsにリンクされたアナリティクスのプロパティが必要で、GoogleはEEA、英国、スイスのユーザーについては無効になるとしています。つまりGoogle Ads、MMP、SKANの数字は、仕組みの上で一致しません。Google自身の案内でも、ICMを導入済みならICMのビューを、未導入ならGoogle AdsかSKANを見るよう勧めています。連携ルートごとのICMの設定と、Google Ads、MMP、SKANを私がどう突き合わせるかは、それぞれ別の記事にまとめています。

定義とはまったく関係のないギャップもあります。私が運用していたあるGoogleアカウントでは、値のないコンバージョンのときに売上イベントが$0ではなく$1を送っており、Googleが報告するROASが全体的に、特にiOSで大きく水増しされていました。私の入札戦略テストを行ったアカウントです。突き合わせビューは、まさにこの種のバグを見つけるためのものです。

iOSのMetaキャンペーンで、SKAN 4とAdAttributionKitはどう機能するのか

何が返ってくるかを決めるのはAppleです。勝った広告1つにつき最大3回の遅延したポストバックが届き、それぞれに貴社のアプリがデバイス上で書き込むコンバージョン値が付きます。キャンペーンが小さいほど、詳細は少なくなります。Metaでは、iOSのアプリプロモーションの各広告セットが、最適化イベントの適格性に応じて、このSKAdNetworkのアトリビューションか、Meta独自のAggregated Event Measurementのどちらかを使います。

SKAN 4とAdAttributionKitは、どちらも3つのポストバックウィンドウを返し、詳細な値を運べるのは1つ目だけです。キャンペーンの規模が小さくユーザー集団を保護できない場合、Appleは粗い値、あるいは値なしにまで落とします。7日間のトライアルの初回課金は7日目か8日目、つまり第2か第3のウィンドウに、数日遅れて粗い値として現れます。だからこそ、このスキーマはテンプレートをそのまま流用するのではなく、貴社のファネルと数量に合わせて設計する必要があり、また、ジオとクリエイティブの分割が多すぎると、すべてのキャンペーンが一気に閾値を下回ってしまうのもそのためです。トライアルの長さごとにどのウィンドウに入るのか、誰が値を書き込むのかは、無料トライアル後の課金をSKANで計測できるかで解説しています。

MetaのCAPIとイベントマッピングは誰が直せるのか

アプリのSDKとMMPから、サブスクリプションのバックエンド、Events Managerまで、イベントの経路全体に責任を持てる人です。Metaのシグナルのバグの多くは、これらのうち2つが接する箇所にあるからです。リテイナーでは私が担います。SDKとサーバーの作業には私のネットワークからアトリビューションエンジニアが加わり、貴社側には変更をリリースできる開発者が1名いる体制です。

アプリイベント向けConversions APIは、SDKやMMPがデバイスから送るのと同じイベントを貴社のサーバーから送信し、Metaはそれをイベント単位で重複排除します。その役割は網羅性と価値の担保です。更新、返金、アプリが閉じているときに発生するコンバージョンを、それぞれ値と通貨とともに送ります。ただし、トラッキングを拒否したユーザーのアトリビューションを復元するものではなく、それらのイベントは引き続きAggregated Event Measurement経由で処理されます。回避策ではなく、やる価値のある施策です。イベントがMetaに届いているのにAEMの対象外と表示される場合の確認手順は、ルートごとにトライアルと購入のイベントがMetaのAEMの対象にならない理由にまとめています。

pLTVと価値最適化

モデルは、最初の1〜2日の行動から各新規ユーザーの価値を予測します。その数値はプラットフォームに購入価値として送られるか、iOSではコンバージョン値に圧縮されて送られます。プラットフォームは、その高価値予測に似たユーザーに対して入札します。どのイベントとどの入札モードがどのアプリに合うかは、Metaへの$1.2Mの支出から書き上げています。

Videaでは、この層、すなわちカスタムのCAPI購入シグナルと入札への予測LTVの組み込みが、D0 ROASを20%から週間記録の43%まで引き上げました。$606Kのテストは、デイゼロの価値がコストパーパーチェスよりもD28 ROASをよく予測することを決着させました。

どのイベントに最適化すべきか

アカウントをより深いイベントに進める前に、私が順番に確認する3つの質問です。インストールから上へ続く段階の全体像は、サブスクリプションアプリはどのイベントに最適化すべきかにまとめています。

1. 貴社の数量で、有料イベントはプラットフォームの学習閾値をクリアしていますか。Metaの目安は、最後の大きな編集から1週間で広告セットあたり約50件の結果です。クリアしていなければ、トライアル開始とアクティベーションイベントの組み合わせに最適化します。クリアしていれば、質問2に進みます。
2. トライアルから有料への転換は健全ですか。健全でなければ、トライアル開始とアクティベーションイベントの組み合わせにとどまります。移行するには両方の条件を満たす必要があります。健全であれば、購入に移行して質問3に進みます。
3. 送ろうとしている値は、ユーザーの実際の支払いと相関していますか。相関していなければ、購入にとどまります。相関していれば、値を送ります。予測LTVにはさらに3つの条件が必要です。予測が実際に成熟したコホートに対して較正されていること、十分な数量があること、そしてアトリビューションウィンドウが閉じる前にプラットフォームがその情報を受け取れることです。早くオンにしすぎると、自信満々に間違ったユーザーへ最適化してしまいます。

プラットフォームROASとサブスクリプション売上を国をまたいで突き合わせる

プラットフォームは、アトリビューションされたコンバージョンとモデリングされたコンバージョンを、自らのウィンドウ内で、総額かつクリック日付で計上します。RevenueCatは取引日付で、返金を差し引いた上で、単一通貨で受領額を計上します。ストアの支払いは、手数料と現地税を差し引いた上で、会計カレンダーに沿って入金されます。これらは構造的なギャップであり、想定内のものです。一方、月ごとにギャップの大きさが変わる場合は、たいていその裏にバグがあります。購入イベントの重複、通貨の不一致、片方のプラットフォームにしか届いていない値、などです。

複数国のROASでは、さらにコホートの成熟度が絡んできます。年間契約のユーザーが多い国は、月額契約中心の国と比べて7日目には悪く見え、90日目には良く見えます。そのため、どの国に予算を割くかを決める前に、同じ経過日数、単一通貨、手数料控除後という条件でコホートを比較します。$383Kの監査は、それを実際のアカウントで行うとどうなるかを示しており、ROASが意味を持つまでに何件の購入が必要かが、各切り口の下限を設定します。

この仕事の進め方

Signal Engineeringはリテイナーの一部であり、最初に着手します。診断はGrowth Auditから始まります。各プラットフォームが現在何を受け取っているか、何に向けて最適化しているか、そして想定される差異を書き出した4者間の比較です。診断の後、優先順位付けされたリストをもとに、チーム自身で修正を実装するケースもあります。各項目にはエンジニアリング工数の見積もりを添えます。あるいは、私にアカウント運用を任せるケースもあります。どちらでも構いません。

SDK関連の作業やサーバー上で動く処理については、私のネットワークからアトリビューションエンジニアを連れてきます。設計とこの層に対する責任は私が持ち、エンジニアリングの実作業はスペシャリストが担います。必要なのは、契約期間中に変更をリリースできる開発者が1名いること、そしてEvents Manager、MMP、RevenueCatまたはサブスクリプションのバックエンド、広告アカウントへの閲覧権限です。

まだリテイナー契約を結ぶ段階ではなく、契約なしで診断だけを受けたい場合は、有料の90分セッションで貴社のセットアップと、何をどの順番で直すべきかを確認します。予約は初回通話と同じカレンダーから行えます。

よくある質問