多くのチームは、どのキャンペーンが実際に売上を生んでいるのかを知りたいと考えています。それを阻むのがアトリビューションです。購入データはシステムごとに異なる形式で分散しており、それをどの配信が引き起こしたのかを結びつける作業自体が、1つの別プロジェクトになってしまいます。そのため多くのチームは、すでにダッシュボードに表示されている開封率とクリック率に頼らざるを得ません。
解決策は、売上データをマーケティングプラットフォームが実際に扱える形式で取り込むことです。Pushwooshでの具体的な方法を紹介します。
売上データがマーケティングプラットフォームに届かない理由 💰
原因はフォーマットにあります。売上データは決して1つの形で届きません。
例えば、SDKはユーザーがゲーム内通貨を購入するとアプリ内購入イベントを発火します。バックエンドは独自のOrderPlacedを送信します。StripeやShopifyは、サブスクリプションやストア注文に対してそれぞれ独自のwebhookイベントを送ります。それぞれフィールド名も、構造も、「金額」の定義も異なります。
これらすべてのソースを横断して売上を集計するには、ソースごとに専用のロジックを書き、常に同期を維持する必要があります。ほとんどのチームはこれを後回しにします。四半期末のレビューまでは優先度が上がらないからです。そしてその時点では、データがそもそも存在しません。こうして売上追跡は先送りされ続け、チームはすでに接続済みの開封率だけを報告し続けることになります。
しかし、これは早期に解決できる問題です。要は、売上を1つの一貫したフォーマットに集約することに尽きます。
すべての売上を1つのイベントで
Pushwooshは、このフォーマットの問題を1つの組み込みイベントで解決します: PW_Conversion。元のソースが何であれ、売上は固定フィールドセットを持つ1つの正規化されたレコードとして格納されます:
- value — 取引金額
- currency — 例：JPY、USD、EUR
- transaction_id、product_id — 任意の識別子
これだけです。サブスクリプションの更新、アプリ内購入、Shopifyの注文——すべてが同じ種類のイベントになります。売上がPW_Conversionとして届いた瞬間から、以降のすべての機能が同じデータを参照します：RFMセグメンテーション、Customer Journey、ダッシュボード、そしてManyMoney AIです。
開始する2つの方法
コンバージョンイベントはアプリケーションごとに設定し、2つの経路があります。既存の購入データの流れに合った方を選んでください。
- 既存のイベントをマッピングする——コード不要。 購入データがすでに別のイベントを通じてPushwooshに流れている場合は、Pushwooshをそのイベントに向けるだけです。ソースイベントを選び、フィールドをマッピングします：どの属性が価格を、どの属性が通貨を保持しているか。以降、そのイベントが発火するたびにPushwooshが自動的にPW_Conversionレコードを生成し、アプリのコードは1行も変更する必要がありません。複数のソースを同時にマッピングすることも可能です——独自のpurchase_completedイベントと、StripeやShopifyのwebhookを併用するといった形です。
- コードから直接PW_Conversionを送信する。 売上を明示的に送信したい場合は、アプリまたはバックエンドで購入が完了する箇所にpostEvent呼び出しを追加します。この方法は開発チームの協力が必要ですが、小規模かつ一度きりの実装で済みます。
売上に変換できるイベント（できないイベント）
マッピングの方法は、金額情報を持つあらゆるイベントに適用できます：
- カスタムイベント — purchase_completed、subscription_renewed、order_placedなど独自のイベント。
- デフォルトイベント — 有料アクションを表す場合。
- インバウンドWebhookイベント — Stripe、Shopify、その他接続済みの決済ソース。
マッピングできないものは、読み取れる金額を持たないイベントです。App_open、screen_view、push_openedはユーザーの行動を記録するだけで、金額がないため変換のしようがありません。
売上が入ってきたら測定できること
ここからが本当の効果です。売上が正規化されることで、以前はカスタム開発が必要だった3つのことが標準機能になります：
- 消費額でセグメントする。 RFMセグメンテーションはPW_Conversionを直接読み取るため、最も消費額の大きい顧客が自動的にChampionsセグメントに入り、ロイヤルティ施策の配信先として即座に活用できます。
- どのJourneyが実際に購入につながったかを証明する。 任意のCustomer JourneyでPW_Conversionをコンバージョンゴールとして設定します。実行後、ゴールの統計は開封数ではなく、実際に購入したユーザー数を示します。「このフローは本当に効果があったのか」という問いに、キャンバス上で直接答えが得られます。
- ダッシュボードで売上をレポートする。 他の重要なアプリパフォーマンス指標と並べて表示でき、購入イベントごとに個別のロジックを構築する必要はありません。
自社アプリのケースを見つける
同じ設定が、アプリが実際に売上を生む仕組みに合わせて適用できます。自社に近い行を探してください：
| アプリの種類 | マッピングまたは送信するイベント | 最終的に見えるもの |
|---|---|---|
| EC・小売 | order_placedをマッピング + ShopifyまたはStripeのwebhook（LINE公式アカウント連携も含む） | どのカゴ落ち復旧フローが実際の注文につながっているか；消費額別RFMでリピーターを特定 |
| ゲーム | コードからiap_completed、battle_pass_boughtを送信 | レベル後のオファーが単に開かれるだけでなく、実際にコンバージョンしているか；高額課金プレイヤー向けの消費額ベースセグメント |
| サブスクリプション（メディア、ストリーミング） | subscription_renewed、plan_upgradedをマッピング（Stripe、App Store） | ウィンバックJourneyが実際の再契約につながっているか；更新の直近性によるRFM |
| フィンテック | premium_subscribed、first_tradeまたは決済webhookをマッピング | どのオンボーディング施策が実際に入金済みアカウントにつながっているか；取引量別セグメント |
| フードデリバリー | バックエンドからorder_placedをマッピング | どの再エンゲージメント通知が再注文につながっているか；直近の注文日によるRFM |
| 旅行・予約 | booking_confirmed + seat_upgradedなどの追加サービスをマッピング | どの値下げ通知フローが予約に転換しているか；旅行金額別セグメント |
order_placedをマッピング + ShopifyまたはStripeのwebhook（LINE公式アカウント連携も含む）iap_completed、battle_pass_boughtを送信subscription_renewed、plan_upgradedをマッピング（Stripe、App Store）premium_subscribed、first_tradeまたは決済webhookをマッピングorder_placedをマッピングbooking_confirmed + seat_upgradedなどの追加サービスをマッピングマーケターがすでに働いている場所で売上を可視化する
コンバージョンイベントは、Pushwooshが目指すより大きな方向性の1つの要素にすぎません。それは、マーケターがわざわざ取りに行かなければならないレポートではなく、すでに作業している場所で売上を可視化することです。
皆さんはすでに、何を、誰に、どのくらいの頻度で送るかを決めています。現在その判断は開封率とクリック率に基づいていますが、それは私たちがお返しできる情報がそれだけだからです。PW_Conversionを送信すれば、同じ判断を売上ベースで行えるようになります。どのキャンペーンを継続し、どれを止めるか、どのセグメントがより多くの配信に値するか——そして、どのセグメントが何の見返りもなく配信停止だけを増やしているかも分かります。
売上が流れ始めると、そこに複利的な効果が加わります：
Pushwooshで売上追跡を実践する
負担の少ない方法から始めましょう。すでに送信しているイベントをマッピングするか、開発チームにpostEventのサンプルを渡してください。次のJourneyでPW_Conversionをコンバージョンゴールとして設定し、開封率やクリック率の隣に売上が表示されるのを確認してください。
