アプリ内購入計測で注意すべき7つの落とし穴

執筆者 Dubi Furie

アプリ内購入（IAP）の収益のおよそ45%が不正確に計測されていることをご存知ですか？信じられないかもしれませんが、これは私たちの数字が示していることなのです。理由は簡単で、データが適切に検証されていないために、税金、手数料、重複カウント等の無駄なものが取り除かれていないからです。

アプリ内購入の計測の精度は明らかに重要であり、これは憂慮すべきことです。アプリ内購入は言うまでもなく、ほとんどすべての種類のアプリで広く利用されており、その収益はかなりの成長を遂げています。事実として、2023年には非ゲームとゲームのアプリ内購入の収益がそれぞれ19%と11%急増しました。

正確さだけでなく、モバイルアプリ内の変化のスピードは、収益化がより大きな課題となることを意味します。プライバシー規制、経済の不確実性、熾烈な競争、新しいマーケティングチャネルなど、例を挙げればきりがありませんが、ユーザー獲得(UA)とマネタイズ戦略には大きな影響を与えます。

ビジネス環境の絶え間ない変化は、計測やユーザー獲得の取り組みにインパクトを与えます。例えば、景気が低迷しているときには、収益を最大化するために割引を使ったさまざまなプライシング戦略をテストする必要があります。その結果、計測が難しくなってしまいます。これはあらゆるマネタイズの計測に対して言えることなのですが、アプリ内購入の計測には特に当てはまります。

このブログ記事では、アプリ内購入の計測の課題を解明し、なぜ正しく計測することが重要なのかを学び、何がアプリ内購入の計測を妨げているのかを探ります。また、いくつかの代替策もご提案します。準備はいいですか？では、さっそく見ていきましょう。

なぜ正確なアプリ内購入のデータが重要なのでしょうか？

広告費回収率（ROAS）の計測は、おそらくグロースマーケターにとって最も重要なKPIです。

ROASを計測するには、2つのパラメーターが必要です：広告支出と収益です。最重要のKPIを見るなら、その正確さが大事であることは言うまでもないでしょう。ROASを把握することで、収益性の高いチャネルやキャンペーンに確実に予算を支出し、収益を促進することができます。

実際、データがわずか数％ずれただけで、キャンペーン全体が頓挫し、採算が取れなくなることもあります。

今、あなたはアプリ内購入の収益の数字を当然のように正しいものだと思っているかもしれません。しかし、それを疑うべきです。通常、ユーザー獲得チームは、アプリ内でユーザーが購入できるアイテムのカタログやその料金、割引などを管理していません。それはプロダクトチームやマネタイズチーム、あるいは他の誰かの役割でしょう。つまり、ユーザー獲得チームは収益の数字を提示されるだけで、それが正確でなければキャンペーン全体が危険にさらされるのです。

だからこそ、データが正確であると決めつけることはできず、その落とし穴を理解するために深く掘り下げることが重要なのです。

また、グロースマーケターとして、自分の直接の責任範囲外のアプリ内購入の収益データを調べることで、他のチームとの協力関係を改善し、ROASに影響する変更を調整することができます。これは、キャンペーンの成功を正確に計測し、新たな機会を特定し、ターゲティングのために新しいユーザープロファイルを非表示にしたい場合に重要です。

アプリ内購入データの正確性を脅かす落とし穴

アプリ内購入の収益を計測する際の精度の重要性を理解したところで、計測における潜在的な落とし穴について説明しましょう。当社の調査によると、以下の問題を解決することで、アプリ内購入の収益の精度を5～35％高めることができます！

1) 広告不正・詐欺行為

広告不正トラフィックは長年モバイルアプリ業界を悩ませてきました。お金のあるところには、それを狙う悪意を持った者が出てきます。このアプリ広告という数十億ドル規模のゲームで、詐欺師は常にシステムを欺く新しい方法を探しています。

これに対抗するためには、すべてのレシートをGoogle Playまたはアプリストアで検証し、その収益のみをレポートする必要があります。チームがレシートの検証を行っていない場合、不正なトランザクションとその収益をレポートするリスクがあり、ROASの精度に大きなダメージを与える可能性があります。

2) データの重複

重複したデータは、アプリ内購入計測の精度を10％も低下させる可能性があることをご存知ですか？

レポートデータの重複には複数の理由が考えられます。例えば、アプリのクライアント側とサーバー側で接続性の問題が発生すると、重複が発生する可能性があります。このシナリオでは、アプリが同じイベントを複数回レポートするため、収益が重複します。

iOS特有の別の例として、ユーザーが購入した商品を家族の一人と共有する場合（別名「ファミリー共有」）があります。App Storeはこの収益を複数回レポートする可能性があります。それを防ぐには、トランザクションのコンテキストを理解し、重複を確実に削除する必要があります。

3) 返金処理の考慮

ユーザーが返金を求める場合、関連する収益を差し引く必要があります。簡単なことのように聞こえるかもしれませんが、実はとても複雑なのです。レシートの原本を確認し、返金トランザクションと照合して、ユーザーに配信したキャンペーンから収益が差し引かれていることを確認する必要があります。

払い戻し処理を怠ると、データの精度が5～10％低下する可能性があります。

4) 未決済のトランザクション

一部の国のアンドロイドユーザーは、アプリ内で購入しても、アプリの外で（現金やその他のデジタル以外の手段を使って）代金を支払うことができる。

その結果、アプリ開発者は、必ずしも収益に結びつかない保留中のトランザクションの50％を記録してしまう可能性があります。このようなケースでは、ストアはこれらのトランザクションをレポートすることができますが、実際の支払いが行われるまで収益は計上されません。支払期日まで支払いが完了しない場合、そのトランザクションはキャンセルされ、収益は徴収されず、レポートもされません。

収益に変換されていない保留中のトランザクションを確認できることは、支払いファネルを最適化するために重要です。

5) トランザクションのマッピングとアトリビューション

アプリはデジタルレジなので、購入をレポートする主体です。つまり、プロダクトチームと協力して、モバイル計測パートナー(MMP) のSDKを実装する際に計測したいイベントをマッピングする必要があります。

前述したように、アプリ内購入のデータは通常プロダクトチームが担当します。しかし、プロダクトチームとマーケティングチームが同じ目標を共有しているわけではありません。つまり、このマッピングを要求し、アプリ内購入データが正しくレポートされるようにするのはマーケティングチーム次第です。正しいメディアソースにアトリビューションされ、適切な形式で処理する必要があります。これには通貨、タイムゾーン、その他のパラメーターが含まれます。

アプリ内購入のトランザクションは複数のステータスを持つ可能性があります。追加の購入が行われた場合には、最初のトランザクションと関連付ける必要があります。そうでなければ、データを完全に誤って解釈してしまう危険性があります。例えば、キャンペーンがうまくパフォーマンスしていると考えていても、実際にはその指標は返金を求めた獲得ユーザーに基づいているかもしれません。

6) 総収益

収益によって、収益性の高いキャンペーンに対する見方がガラリと変わります。

ストアが収益をレポートする際には、ストア手数料と税金を含んだ総収益を表示しています。ストア手数料は常に30％だと思っているかもしれませんが、そうではありません。App Store Small Business Programを適用した場合、収益が100万ドルまでに限り、ストア手数料は半減しわずか15％になります。また、ユーザーが12ヶ月以上継続してサブスクリプションする場合、そのサブスクアプリの手数料は15％になります。また、これだけでは不十分だとすれば、最近のAppleの欧州デジタル市場法（DMA）に対する反応によって、さらに複雑になっています。

消費税も複雑です。国によって規制が異なるため、消費税が含まれている場合と含まれていない場合があります。

次の例でわかるように、インパクトは大きなものになります：

7) 個人情報保護規制

プライバシーに起因するデータ制限は、主に多くの制限を持つSKANの導入により、iOSの成長戦略を大きく変えました。例えば、コンバージョン値が6ビットに制限されているため、正確なアプリ内購入の計測をサポートできません。

SKANの限られたインストール後データに対処するためには、そのアプリ内購入が含まれる可能性の高い収益範囲を設定する必要があります（例えば、0～10ドル、10～20ドルなど）。これらの収益範囲は、アプリ内の販売内容と統計的な支払い分布データに基づいて決定されます。第一に、収益範囲を見なければいけないということは、実際に発生した収益値はわからないということです。第二に、そもそも不正確な収益データに基づいてこれらの収益範囲に割り当てられれいる場合、SKANの収益計測データにもさらなるズレが生じます。

Googleもまた、インストール後の計測データを制限する同様の仕組みをプライバシーサンドボックスで提供予定であることに注意してください。

これらの落とし穴をストア連携で解決

これらの問題を解決するには、ストアとのAPIやSDK連携を実装する必要があります：Apple App Store、Google Play、その他。

これは複雑です：

各ストアやAPIには独自のルールがあります。
標準化されていないデータスキームでは、プラットフォーム間でのパフォーマンスを比較することが難しくなります。具体的には「どのプラットフォームでどの割引がより効果的だったか？」といった質問に答えることは難しくなるでしょう。
技術的なエラー、信号の喪失、再試行により、データが不完全で重複するリスクがあります。
ストアとの連携を導入する場合、それは一度だけの取り組みではありません。これらのAPIは頻繁に変更されるため、対応し続けることは開発リソースの消耗につながります。このため、AppleとGoogleが新機能を展開する際に、計測が不正確になるリスクが高まります。ポートフォリオ内のアプリ数が多ければ多いほど、維持コストは高くなります。

集中すべき重要なことは、広告キャンペーン

データの集計とクリーニングのようなタスクに、時間とリソースをかけすぎるべきではありません。それよりも、いかにして適切なユーザーを獲得し、効率的に収益化し、最適な体験を提供し、ユーザーを維持するかに注力すべきです。

さらに、アプリ内購入のレポートのためにストアと連携することは必須ですが、前述のように、ビジネスに中程度から大きなリスクをもたらします。

MMPにこの重荷を負わせることは、はるかに理にかなっています。彼らはあなたをサポートできるでしょう：

不正広告防止：MMPはすでにSDKを通じてアプリにアクセスしています。そこのアクセスを利用して、各トランザクションの不正広告を検証し、実際の購入がレポートされていることを確認することができます。
アトリビューション：収益アトリビューションは、追加購入のトランザクションの処理も含めて「すぐに使える機能」です。
より高いデータ精度：重複やエラーを排除した信頼性の高い高品質のデータは、MMPのサービスに不可欠な要素です。
プラットフォームデータの標準化：MMPはAndroidとiOSでデータレポートを標準化するため、好きなようにデータを加工できます。
トランザクションへの意味付け：MMPは、トランザクションのコンテキストを導き出し、保留中のトランザクション、払い戻し、家族共有などの複雑なロジックを処理することができます。
ストアAPIの変更対応：パフォーマンス指標にインパクトのあるストアのアップデートを、大小に関わらず気にする必要はありません。MMPはこれらすべてを管理します。
障害対応：MMPには、サポートチームと研究開発チームが常駐しており、強力な監視メカニズムによって実際のリアルタイムで動作していることを保証します。