Meta’s Ad ROAS – 101 Guide for UA Managers

Meta’s advertising platform has introduced a new campaign optimization method called Ad ROAS (Return on Ad Spend) that specifically uses in-app ad revenue as the optimization signal. In other words, instead of optimizing for purchases or installs alone, advertisers can now optimize for the ad monetization value that users generate. This is a significant development for app marketers, especially those in the mobile game and app publishing industry, whose revenue comes largely from ads. Meta’s solution allows these advertisers to find and bid for users who will generate the highest ad revenue in their apps, thereby maximizing ROAS. This feature was rolled out in late 2024 for Android app campaigns and represents a major shift in how we approach user acquisition for ad-monetized apps.

Why it matters: In the past, if your app monetized via in-app advertisements (IAA) rather than in-app purchases (IAP), you had limited options to optimize Meta campaigns for true revenue. You might have optimized for proxies like retention or engagement, or tried to pass ad revenue as “purchase” events as a workaround.

Now, Meta Ad ROAS with the AdImpression event enables direct value optimization based on ad revenue. This means the algorithm will seek out users who not only install your app but also generate high ad impression value over time​. For performance marketers, this can improve the efficiency of spend by focusing on high-LTV users that were previously hard to target with purchase-based optimization. It essentially unlocks ROAS-based bidding for ad-monetized apps, similar to how e-commerce apps optimize for purchase ROAS.

Share

What is the AdImpression Event, and How Is It Used in Optimization?

AdImpression is a predefined app event in Meta’s SDK and ad platform that represents an in-app ad impression (an ad view within your app) along with the revenue earned from that impression. In practice, when an ad is displayed to a user in your app (for example, a rewarded video or banner from an ad network), your app can log an AdImpression event to Meta, including details such as the type of ad and the ad revenue earned from that single impression. Meta then uses these events as conversion signals. When you optimize a campaign for “In-app ad impression value”, the AdImpression events (with their revenue values) are what Meta’s algorithm will try to maximize.

To break it down: each AdImpression event carries a monetary value (the revenue your app earned from that ad view). By sending this to Meta, you’re effectively telling the algorithm how much revenue each user is generating from ads.

Meta can sum these values per user or per cohort and prioritize delivering ads to people likely to generate more ad revenue (higher total value). This is analogous to optimizing for purchase value, but here the “purchases” are third-party ad impressions.

According to Meta’s event definitions, if you provide a value (often via the _valueToSum parameter) with the AdImpression event, that value is interpreted as ad revenue and can be used for value optimization.

In essence, AdImpression events allow Meta to treat ad monetization similarly to a purchase event for optimization purposes.

It’s important to note that AdImpression as an event is distinct from the normal ad impressions of your Facebook ad campaign. Here, we’re talking about impressions of ads inside your app (monetization ads, like AdMob or ironSource), not the impression of the Facebook ad itself. AdImpression is a standard event in the Meta SDK, with an event name constant provided in the SDK, used for third-party ad monetization tracking.

How it’s used in optimization: When setting up a Meta app install campaign, you choose a performance goal. With this new feature, you can select “Maximize Value of Conversions” and then choose “In-app ad impression” as the conversion event to optimize for. This tells Meta to optimize for the total value of AdImpression events generated by users coming from the ads. Essentially, Meta will bid for and target users in a way that maximizes the cumulative ad revenue (as reported by AdImpression events) per dollar spent – hence maximizing ROAS. Advertisers see this in Ads Manager as the campaign optimizing for AdImpression value (instead of purchase value). The AdImpression events you send (with revenue values) will show up in Meta Ads Manager metrics, and if properly configured,

Meta can calculate metrics like total conversion value and return on ad spend (ROAS) for your campaigns based on ad revenue. (Under the hood, historically, Meta treated all incoming revenue events as “purchase” value by default; with this feature, Android apps’ ad revenue events are explicitly mapped to the AdImpression event type instead of the purchase event type, allowing separate tracking of ad-derived revenue.)

Current platform availability: At the moment, this Ad ROAS optimization is available for Android app campaigns only. Meta’s rollout (as of Q4 2024) focused on Android because iOS has significant limitations due to ATT (App Tracking Transparency) and Aggregated Measurement. For iOS apps, you can still send ad revenue events, but they will be mapped to the traditional purchase event (fb_mobile_purchase) and used in aggregated ways.

In other words, iOS apps cannot yet select “In-app ad impression” as a conversion event for optimization in Ads Manager. Instead, any ad revenue you send from iOS will be added to your purchase ROAS or value reporting (a workaround some advertisers use by treating ad revenue as purchase revenue on iOS).

Meta will explore support for iOS in the future, as announced at one of their events. However, as of now, Ad ROAS with AdImpression is an Android-focused feature.

Benefits of Ad ROAS (AdImpression) over Traditional Event Optimization

Why is optimizing for AdImpression (ad revenue) so beneficial compared to the traditional ways of running app campaigns? There are several key advantages for marketers and some early data to illustrate them:

• Direct Revenue Optimization for Ad-Funded Apps: Previously, if your app’s income came from ads, you might have optimized for proxies like retention (assuming users who stay longer see more ads) or perhaps for a custom event, such as “ad watcher,” without a direct revenue attachment. These approaches were indirect.
  • Now, by optimizing for actual monetary value (ROAS) from ad impressions, you align the campaign directly with your business outcome. The algorithm gets a clear signal of value (in dollars or your currency) for each user. This tends to improve the quality of users acquired, similar to how purchase value optimization finds big spenders. In short, you can optimize for LTV even if that LTV comes from ad views instead of purchases.
• Higher ROAS and LTV: Early adopters have reported significant uplift. For example, one mobile game that monetizes via ads tested an Ad ROAS campaign against a regular optimization campaign. The results after one week were striking: Day 1 LTV was 378% higher for users acquired by the Ad ROAS campaign, meaning those users generated nearly 4x the ad revenue on their first day compared to the control group. Moreover, retention improved (Day 1 retention +15%, Day 3 retention +12.8%) in the Ad ROAS group​. After opening up AdROAS to the whole world, ROAS and retention numbers were a bit all over the place and hadn’t yet fulfilled the promise. But Meta is working hard on preparing a new D7 AdROAS model and more algo updates.
• Improved Targeting Efficiency: Meta’s algorithm has always excelled at using rich signals to find the right users. By feeding it ad revenue events, you give it a powerful signal to differentiate users. Not all app installers are equal — some might generate $0.10 in ad revenue and some $10 over a period. Traditional install or even event optimization wouldn’t see that difference clearly, but value optimization does. This leads to more efficient spend allocation: the budget shifts toward sources (audiences, placements, times of day, etc.) that attract users with a higher propensity for ad engagement. Over time, this can lower your effective cost per revenue (improving ROAS). It can also lower CAC (Customer Acquisition Cost) for a given revenue threshold, because the campaign stops spending on low-value users. Instead of just optimizing for the cheapest installs, it finds those “sweet spot” users who may cost a bit more to acquire but yield far more revenue, thus boosting profitability.
• Comparable to Purchase-Optimized Campaigns: This feature levels the playing field for different app business models. An e-commerce app can optimize for purchase value; now a free-to-play game with ads can optimize for ad value. Both can hit ROAS goals. This means marketers with ad-monetized apps can run campaigns optimized for true ROI just like any direct revenue app. In the long run, this should translate to better scalability (you can justify higher budgets when you know the returns in ad revenue will scale as well) and more stable performance, as the algorithm isn’t optimizing on a proxy metric but on actual dollars.
• Better User Experience Alignment: An interesting side effect noted in early tests is improved retention, as mentioned above. When you optimize for ad revenue, the algorithm may favor users who not only watch a lot of ads but also engage deeply with the app, thereby increasing their exposure to those ads. These could be users who genuinely enjoy the app content and thus see more opportunities for ads. If those users are having a good experience (e.g., willingly watching rewarded videos), they stick around. In contrast, if you optimized purely for retention without revenue, you might get users who stay but don’t monetize at all. Good old proxy events.

Share

In summary, Ad ROAS campaigns can drive stronger ROI by aligning Meta’s delivery optimization with the actual ad-generated revenue from users. The benefits include higher revenue per user, better retention (a sign of user quality), and the ability to scale spending with confidence that the algorithm is finding the right audiences for your monetization model. For any UA manager running user acquisition for an app that earns money through ads, this new optimization method can be a game-changer. You should definitely start experimenting with AdROAS.

Technical Overview and Implementation Considerations

Getting Ad ROAS optimization to work for your campaigns requires some technical setup and an understanding of the data flow. Here we’ll dive into how it works under the hood and what you need to implement.

Data Flow & Signal Collection: At the core of Ad ROAS optimization is the feedback loop of ad revenue events from your app back to Meta. The sequence is as follows:

1. In-App Ad Impression Occurs: A user sees an ad inside your app (for example, an interstitial, banner, or rewarded video from an ad network like AdMob, ironSource, Unity Ads, etc.). That ad impression generates some revenue for you, either an exact amount (in the case of a mediated network providing eCPM details) or an estimated value. Many ad networks provide callbacks or APIs in their SDKs to tell the app how much that impression was worth (impression-level ad revenue data).
2. Logging the AdImpression Event: Once your app obtains the revenue value for the ad impression, you log an AdImpression event via your analytics/attribution integration. This can be done in a few ways:
   • Using the Meta (Facebook) SDK directly: You would call the Facebook SDK’s app event logging function with the event name “AdImpression” and include the revenue value (and possibly currency) as parameters. The SDK will send this event to Facebook’s servers.
   • Using a Mobile Measurement Partner (MMP) SDK such as AppsFlyer, Adjust, or Singular: In this case, the MMP’s SDK might automatically capture ad revenue from integrated sources or via manual logging in the MMP SDK, and then the MMP forwards that event to Meta on your behalf as a postback.
   • Using Server-to-Server (Conversions API): If you collect ad revenue events on your backend (for instance, your ad mediation platform sends webhooks of user-level ad revenue), you can forward those to Meta’s Conversions API, creating AdImpression events server-side. (Meta explicitly supports sending app events via the Conversions API as well.)

   No matter the method, the key is Meta must receive an event called “AdImpression” with a value. The event will typically also carry an app user ID or advertising ID to match it to an install. If using the Meta SDK or an MMP, they handle user/device identification and attribution of the event to the original ad click.

3. Attribution and Aggregation: Meta receives the AdImpression event and attributes it to the appropriate campaign/ad that brought in the user (assuming it falls within the attribution window and the user has consented to tracking, where applicable). These events then show up in Meta Ads Manager as part of the campaign’s results. By default (in the past), if you sent ad revenue events without special handling, Meta would record them under the purchase event (fb_mobile_purchase) because that was the standard way to send any revenue. However, with this new system, Meta expects Android ad revenue events to come in tagged specifically as “AdImpression.” For example, Adjust notes that if you enable this feature, they will map your ad revenue data to Meta’s AdImpression standard event (instead of the usual fb_mobile_purchase)​. This distinction is what enables the “In-app ad impression” optimization goal in Ads Manager.
4. Optimization Loop: Once Meta has these events attributed, the campaign can use them to optimize. In a Value Optimization campaign (which is what Ad ROAS essentially is), Meta’s algorithm will try to maximize the total value (sum of revenue) of events per cost. The more AdImpression events (and greater their values) coming from certain users or targeting criteria, the more Meta will favor finding similar users. It will adjust bids in the auction dynamically, bidding higher for users predicted to generate high ad revenue, and lower for users predicted to generate little or none. Over time, as more data flows (and after the initial learning phase), the delivery should hone in on the best pockets of inventory that yield high ROAS. Advertisers can then look at metrics like In-App Ad Impression conversion value and ROAS (Return on Ad Spend) in the reporting to judge performance.

Eligibility and Training Data: One critical implementation consideration is that Meta requires a minimum amount of data before it allows value optimization. This is also true for purchase ROAS campaigns, historically. For AdImpression-based optimization, the requirement is roughly:

at least 15 attributed AdImpression events (with value) from your app in the last 28 days, with at least two distinct values.

These events must be coming from users acquired through active campaigns (Meta wants to ensure these aren’t all organic or from other sources). If this threshold isn’t met, when you try to set up a campaign and choose the conversion event, you might find “In-app ad impression” is greyed out or not selectable.

In that case, you need to generate more data first. Best practice is to run a normal install campaign or an App Event optimization campaign (perhaps optimizing for a simpler event, such as “ad_view”, or just for installs with broad targeting) to acquire an initial batch of users.

As they use the app and generate some ad impressions (and you send those events to Meta), you will accumulate the needed volume of AdImpression events. Once you cross the threshold (15+ events with value), Meta will unlock the ability to optimize for value.

Think of it as priming the pump – you need to feed the algorithm some examples of post-install ad revenue before it can start optimizing for it.

Technical Implementation – Key Requirements:

• Meta SDK or MMP Integration: You must integrate either the Meta App Events SDK or an MMP SDK that supports forwarding AdImpression events. Without an SDK or server integration, Meta won’t receive the signals. If you already use the Facebook SDK for login or analytics, you can use it to log events as well. If you prefer using your attribution partner (AppsFlyer, Adjust, Singular), ensure you are on a plan that supports user-level ad revenue tracking (e.g., AppsFlyer’s ROI360 or Adjust’s ad revenue integrations).​ This is because the MMP needs to obtain ad revenue data from the networks. On the app side, you might have to integrate each ad network’s SDK and the MMP’s ad revenue APIs (for example, AppsFlyer’s logAdRevenue API for each impression, or Adjust’s trackAdRevenue method).
• Event Mapping and Configuration: If using an MMP, you’ll need to map the MMP’s ad revenue event to Meta’s AdImpression event. For instance, AppsFlyer uses an event named af_ad_revenue for ad revenue, in the AppsFlyer dashboard, you should map af_ad_revenue -> Adimpression for Android (and to fb_mobile_purchase for iOS)​.

STEP BY STEP VIDEO

• Adjust provides a simple checkbox called “Enable AdImpression Mapping” which, when checked, will send ad revenue as AdImpression (if unchecked, it would send as purchase by default)​.

  

  VIDEO STEP BY STEP

• Singular similarly requires mapping their ADMON_USER_LEVEL_REVENUE event to “AdImpression” in the partner settings. The takeaway is that Meta expects a specifically named event to count as an in-app ad impression conversion. Make sure your integration is correctly labeling it. Otherwise, Meta might just treat it as a custom event (which wouldn’t unlock value optimization).

STEP BY STEP VIDEO

• Including Revenue Value: The quality of optimization heavily depends on sending an accurate revenue value with each event. Meta’s algorithm uses the _valueToSum (or equivalent) parameter to sum up ROAS. In practice, when logging the event via SDK or MMP, you provide the revenue amount (and currency, typically). For example, AppsFlyer’s SDK attaches an af_revenue parameter to the event, which Meta automatically maps to its _valueToSum internally. If you’re using the Facebook SDK directly, the logEvent function has an overload to include a numeric value. Ensure this value is in a currency Meta can interpret (usually your app’s default currency as set in your Meta analytics). If your ad revenue is coming in, say, USD, and your Meta account is USD, you’re fine. If it’s in another currency, you may need to specify that (some MMPs handle currency conversion or tagging via an af_currency parameter which Meta maps appropriately). Without a value, Meta cannot optimize for “highest value” – it would just count events. So this step is critical: always include the monetization value for each AdImpression event.
• Frequency of Events: Some apps might trigger very frequent ad impressions (e.g., if you have banner ads refreshing). Don’t worry – Meta can handle a high volume of events. However, extremely high event volumes could potentially throttle or get capped in reporting (Meta Analytics has some limits on event count and unique event names but AdImpression is a single event name). In general, send the events in real-time as they occur. If for some reason you prefer batching them, ensure the batch is sent within the attribution window. Real-time is ideal to give Meta’s ML the freshest data. Also, each impression should ideally be a separate event with its value, rather than summing up a user’s total and sending one big event occasionally. Granularity helps Meta learn incremental value from each additional ad view.

Privacy & Consent

Since ad revenue events tie back to user behavior post-install, ensure you comply with privacy regulations. On Android, this mostly means having a proper privacy policy and perhaps letting users opt out of personalized ads (which is more of a Google requirement). On iOS, if the user has not consented via ATT, the Facebook SDK will not send identifiable event data. In that case, events might be handled via SKAdNetwork or not at all. Currently, SKAdNetwork (Apple’s anonymous attribution) does not support value optimization in the same flexible way – it has conversion value schemes, but coordinating those for ad revenue is complex. Meta likely uses Aggregated Event Measurement (AEM) for iOS which can handle purchase values in aggregate; if you send ad revenue as purchase events on iOS, they might be aggregated. But again, you cannot run a dedicated Ad ROAS campaign on iOS right now. So privacy-wise, focus on Android (Google Advertising ID can be used if user didn’t opt out of personalization at the OS level). Always disclose in your app’s privacy policy that you share in-app events (including ad viewing events) with third parties for advertising/analytics.

• Meta Ads Manager Setup: On the campaign creation side, once everything is integrated and you have sufficient data, you will set up a Mobile App Install campaign (or App Event campaign) with the Performance Goal set to “Maximize Value” (instead of “Optimize for Installs” or “Optimize for Events”). Then in the conversion event dropdown, you should see “In-app ad impression” as an option (alongside others like Purchase, etc.). Select “In-app ad impression”. If it’s not there or greyed out: double-check the data and eligibility (as discussed). When it is active, also note the billing: Meta might still bill per install or outcome in some cases, but generally value optimization uses highest-value bid strategy. You might be asked for a target or minimum ROAS, but often Meta’s App ads don’t allow a target ROAS input (unlike web campaigns) – instead, you set a fairly high budget and let it optimize. Keep an eye on delivery: since this is a newer optimization type, it might stay in the learning phase longer if volume is low. Make sure you have an audience size and budget that can generate at least ~50 conversion events per week (Meta’s typical recommendation for stable delivery).
• Monitoring and Scaling: As the campaign runs, monitor the ROAS and cost per revenue metrics. You may see in Ads Manager something like “ROAS (AdImpression, D7)” which would be the return on ad spend measured by 7-day post-install ad revenue. If those numbers look good and stable, you can scale up budgets. If not, consider whether your input data is accurate (are all networks’ revenues captured?), or if perhaps your app’s ad revenue per user is so low that Meta struggles to differentiate (in which case, grouping multiple days of value might help – though Meta does that inherently by looking at multi-day ROI). Also, compare against a control if possible – for instance, run a holdout or a campaign optimizing for installs with manual bids, and see if the Ad ROAS campaign yields higher total revenue for the same spend.

Key Takeaways (Technical): To implement Meta’s Ad ROAS optimization, you must instrument your app to send AdImpression events with revenue, ensure Meta gets those events (via SDK or partner integration), and have enough event volume to train the algorithm. The system is Android-only for now, requiring some setup in MMP dashboards or your code. It’s a collaboration between your app (providing data) and Meta’s ad delivery (using that data). Proper implementation and data accuracy are crucial – if events are missing or mislabelled, the optimization won’t work. But when set up correctly, this closed-loop system will continually move your campaigns toward better ROAS by focusing on what matters: actual dollars earned from users.

Real-World Use Cases and Measurable Improvements

Let’s explore some real-world scenarios and results where Ad ROAS with AdImpression has made an impact. This will give context on what types of apps should use this and what gains to expect.

1. Mobile Gaming (Hyper-casual / Ad-Driven Games):
Use case: A hyper-casual game studio releases free games that monetize exclusively through ads (rewarded videos, interstitials, banner ads). Traditionally, they ran Facebook App Install campaigns, optimizing for installs or a proxy event like “level_completed”, hoping that would correlate with retention and ad views. After enabling AdImpression optimization, they started feeding actual ad revenue values to Meta.

Result: The campaigns quickly identified a cohort of users who not only installed and played but consistently watched many ads (e.g., players who don’t mind watching ads for extra lives or rewards). The studio observed a significant jump in Day 7 ROAS – something they couldn’t even properly measure before. For example, one campaign report showed a 20% Day 7 ROAS. This was a big improvement over the 5-10% they saw with install-optimized campaigns. Over 30 days, the ROAS for the AdImpression-optimized campaign increased to 100%, while the install-optimized campaign plateaued at around 50%. No shit. Install campaigns are no longer driving any monetary value.

Use wisely as an addition to your Ad-driven UA stack where you have Applovin, Mintegral, Google, and most probably TikTok!

2. Hybrid Monetization Apps (mixed IAP and Ads):
Use case: A mobile game that has both in-app purchases and ads (many mid-core or casual games do this – e.g., players can buy items, but non-payers will see ads for bonuses). These apps have two revenue streams. Before AdImpression optimization, the UA team likely optimized for purchases (value optimization for IAP ROAS) because it was a straightforward metric, and they may have ignored ad revenue or counted it indirectly.

The risk was that the algorithm might favor big spenders only, overlooking ad whales (users who don’t spend money but watch a lot of ads). Or putting too much emphasis on the number of lower monetary events from Ads. Turning the whole “workaround” into a pile of … With the new method, they have a choice: run separate campaigns, one optimizing for purchase value and one for ad impression value. They decided to test an Ad ROAS campaign targeting countries where purchases are rare but ad engagement is high (for example, some emerging markets users tend not to spend but will watch a lot of ads).

Result: The AdImpression-optimized campaigns outperformed the purchase-optimized ones in terms of overall profit. The purchase campaigns struggled because few people were making IAPs, whereas the Ad ROAS campaigns thrived by capturing the ad monetizers. The measurable improvement was seen in overall ARPU (Average Revenue Per User) from those campaigns – when they added up IAP + ad revenue, the users from the AdImpression-optimized campaign had 1.3x higher total ARPU than users from the purchase-optimized campaign in those regions. This taught the team that they should tailor campaign optimization by market: in high-IAP markets, purchase ROAS is king; in high-ad markets, Ad ROAS brings in more revenue. They also realized you could run parallel campaigns – one focusing on big spenders, another on big ad consumers – to cover both dimensions of monetization.

Share

4. Improved CAC and Payback:
Across these scenarios, a common theme emerges: using AdImpression events for optimization can improve your customer acquisition cost (CAC) payback period. CAC (cost to acquire a customer) may not necessarily drop in absolute terms – in fact, to get high-value users, your CPI bid sometimes goes up.

However, because those users generate so much more revenue, the net effect is that you recover your costs faster and more fully. For example, in the gaming case, maybe the average CPI increased by 20% (because now you’re competing for higher-quality users), but the Day 7 revenue per user increased by 300%.

That trade-off is extremely favorable. Marketers often target a certain ROAS by day 7 or day 30 to consider a campaign successful. Ad ROAS campaigns allow previously untapped ad revenue to count toward those targets, making it easier to hit them. In effect, you reduce the effective CAC for a given amount of revenue.

If it used to cost $5 to acquire a user who produces $5 of revenue (breakeven), it might now cost $6 to get a user, but they produce $10 of revenue, so $4 net gain, where previously it was $0. This is huge for scaling and profitability.

In summary, the real-world impact of Ad ROAS optimization has been very positive for the right kinds of apps. Ad-monetized games, content apps, and any app with significant ad revenue stand to gain the most. They can now treat ad-engaged users with the same importance as purchasers. The measurable improvements include higher ROAS percentages, improved retention and engagement metrics, more balanced monetization (not relying only on IAP), and the ability to unlock spend in markets or audiences that were previously hard to justify. Marketers should still test and compare – for example, allocate a portion of budget to an Ad ROAS campaign and the rest to a traditional campaign as a control – but early case studies strongly advocate for testing this ASAP​ if it’s available to you.

Best Practices and Potential Pitfalls

While AdImpression-based optimization is powerful, getting the most out of it requires following best practices and being aware of potential pitfalls. Here are some tips and cautions:

Best Practices:

• Ensure Data Quality and Integration Accuracy: Double-check that your AdImpression events are firing correctly. This means verifying in the Meta Events Manager or your MMP dashboard that events are coming through with the expected values. A simple mistake like sending the wrong currency or an incorrect value (e.g., cents vs. dollars) could skew the optimization. For instance, $0.05 mis-sent as $5.00 would completely confuse the algorithm. Use test devices to generate a couple of ad impressions and confirm the events show up in Meta with the right parameters.
• Meet the Minimum Event Volume: As discussed, you need a baseline of conversion events. If you’re just launching and don’t have that volume, plan a staging period. You might start with a cost-per-install bid campaign or a campaign optimizing for an easier event (like “app open” or “level complete”) for a few weeks to gather data. Once you log enough AdImpression events, then switch to value optimization. Essentially, be patient and feed Meta the data it needs. Starting a value optimized campaign without enough data will likely result in the campaign struggling (limited learning or not spending at all if it’s below the threshold).
• Use Broad Targeting Initially: The algorithm works best with a wide net when optimizing for value. Don’t narrow your targeting too much initially – allow Meta to explore different segments to find those high ad-engagers. Lookalike audiences of payers might not help here because we want ad “payers” (different profile). Instead, consider lookalikes of users with high session counts or just go broad (age/geography) with maybe some interest filters relevant to your app. Let the conversion optimization do the heavy lifting. Over-segmentation can reduce the chance of finding the golden cohorts.
• Budget for Learning: Value optimization campaigns may require a higher daily budget to exit the learning phase, because the events are typically fewer (not every install will immediately generate an AdImpression event with value, or even if they do, the value might be small). Meta’s learning phase usually needs ~50 conversions per week per ad set. Ensure your budget and expected install volume can support that. If your app gets an average of 1 ad impression per user per day valued at $0.01, then 50 conversions is only $0.50 of value – which might require quite a few installs. So scale your budget in accordance with the revenue per user you expect, to generate enough signal. You might also use a cost cap or bid cap strategy initially to control costs until performance proves out.
• Separate Campaigns for Different Revenue Streams: If your app has both IAP and ads, consider running separate campaigns: one optimized for purchase value (IAP ROAS) and one for ad revenue (Ad ROAS). This allows each algorithm to specialize and find the respective user types. Some advanced strategies could involve combining values (e.g., sending a single “total revenue” event that sums IAP + ad revenue for each user). However, that is complex and you risk muddying the waters. It’s usually simpler to have one campaign target purchasers and another target ad-mon users. You can allocate budget between them based on which revenue stream you want to grow. That said, avoid targeting the exact same audience with both in a way that competes; maybe use value rules or geo-split if needed. Monitor for overlap (Meta’s overlap tool) to ensure you’re not bidding against yourself for the same users.
• Leverage MMP Features: If you’re using an MMP, take advantage of any advanced features they offer for ad revenue. For example, AppsFlyer’s ROI360 not only provides the event forwarding but often gives analytics on ROI by campaign. Adjust and Singular have dashboards to validate ad revenue data per source. Use these to cross-check Meta’s reports. Sometimes, MMP reports might show a slightly different revenue total than Meta (due to attribution differences or timing). Keeping an eye on both can help you catch issues (like a partner integration failing to send data). Also, ensure no double counting: if your MMP by default sends all revenue events as purchases and you also enabled AdImpression mapping, you want to avoid sending the same revenue twice under two different event names. (Most platforms prevent this, but it’s worth mentioning.) For instance, Singular warns not to use a catch-all “REVENUE” event along with individual ad revenue events, to avoid duplicates​.
• Optimize Ad Experience in-App: This is more on the product side, but because we are now optimizing for showing ads, make sure your app’s ad placements are optimized for user experience. The goal is to have users engage with a lot of ads because they enjoy or at least don’t mind them, not because they are bombarded in a short time and leave. The better your ad engagement rates and the longer users stick around, the more conversion value you send to Meta. It becomes a virtuous cycle: good UX -> higher retention -> more ad impressions per user -> more revenue -> Meta finds more users like them -> good UX for them -> and so on. So avoid the temptation to suddenly crank up ad frequency for new users hoping to improve ROAS; that could backfire by reducing retention. Instead, use this as an opportunity to identify high-LTV users and perhaps learn from them (e.g., maybe they prefer rewarded ads over forced ads, etc.).
• Keep an Eye on Pacing and Bids: Initially, you might see fluctuating cost per result as the campaign learns. It’s often best not to interfere too early. But do monitor daily. If after a while the campaign isn’t meeting ROAS goals, consider adjusting your bid strategy. Meta sometimes allows a Target ROAS for value campaigns (though for app ads this has historically not been widely available; it’s more common in web e-commerce campaigns). If it is available, you could set a target (e.g., 100% D7 ROAS) – but be cautious, setting it too high might restrict delivery. Alternatively, use cost caps if you have a sense of allowable CPI or CPA. The guidance from Meta is usually to optimize for value without caps for a bit, then gradually introduce caps if needed.
• Geo and Platform Considerations: Right now, since this is Android-only, focus your campaigns on Android users. If you run mixed OS campaigns, split them so iOS isn’t lumped in with an Android Ad ROAS campaign (that would just waste iOS spend since it can’t optimize properly). Also, consider geo differences in ad monetization. In some countries, ad rates (CPMs) are high, in others low. This affects the value of AdImpression events. Meta’s algorithm will inherently factor that in, but you might find that certain geos yield much better ROAS. Use that info to allocate budget geographically. For example, if Tier 1 countries have higher revenue per user but also higher cost, the ROAS might actually be better in a Tier 2 country with moderate cost and decent ad engagement. Be open to the algorithm finding value in places you might not have targeted aggressively before.

Pitfalls to Avoid:

• Not Meeting Meta’s Criteria and Forcing the Campaign: If you try to run an Ad ROAS campaign without the sufficient prior data, you risk the campaign stalling or underperforming. This could lead to mis-concluding that the strategy doesn’t work, when in fact it just wasn’t given a fair shot. Always check if the option is enabled and not greyed out. Meta provides a tooltip if it’s greyed out – it means you haven’t met eligibility. The fix is usually “send more conversion events for a while and try again.”​Don’t ignore those signals.
• Using Incorrect Event Mapping on MMPs: A common mistake could be mapping the wrong event or duplicating. For instance, if on AppsFlyer you accidentally map af_ad_revenue to a Custom event instead of the predefined AdImpression, Meta might treat it as a generic custom event (which cannot be used for value optimization at this time). Ensure it’s mapped to the exact Meta event “AdImpression” (capitalization and spelling exactly as required). Similarly, on Adjust, you must tick the “AdImpression Mapping” checkbox in addition to enabling ad revenue data sharing. Missing one of these steps would result in events still coming in as purchases or not at all. A misconfiguration could silently fail to optimize, so it’s worth doing a sanity check after setup. One way is to intentionally run a small campaign optimizing for purchase value and see if the ad revenue shows up as “purchases” vs. if you switch it to AdImpression and see if the campaign starts counting those conversions properly.
• Depending on MMP Plan: As mentioned, some MMPs gate the ad revenue feature behind premium plans (e.g., AppsFlyer ROI360)​ If you don’t have access, you might attempt to implement a workaround by sending ad revenue as a custom event. But be aware: Meta’s platform currently doesn’t allow optimizing for custom events for app campaigns (custom events are mostly for analytics or building custom audiences, not for AEO/VO campaigns). So if you can’t use the official AdImpression or purchase events, you might be stuck. One workaround could be manually calling the Facebook SDK in addition to the MMP (so the MMP does attribution and you still send events via FB SDK for optimization). That can work, but it adds complexity and potential data duplication. The pitfall would be either overspending on an MMP plan you don’t need except for this feature, or implementing a hacky solution that might break. Evaluate the cost-benefit: if Ad ROAS could significantly boost your revenue, it might justify upgrading the MMP plan or spending dev effort to integrate the FB SDK directly just for this event.
• Overestimating Revenue (be realistic): The algorithm can only optimize based on the data you give. If your app’s ad revenue per user is inherently low (say your average user only generates $0.10 total), the campaign might have trouble because even “good” users don’t provide much room for improvement. You should set expectations accordingly. Ad ROAS optimization isn’t magic – it can’t suddenly make users watch 10x more ads unless those users exist. It will find the best available, but if your app monetization is limited, you might see only modest improvement. A pitfall would be expecting huge jumps in ROAS in an app that simply doesn’t have much monetization potential or where ad revenue is capped by design. Make sure your monetization strategy in-app is sound; then the ads campaign can amplify it.
• Ignoring Other Funnel Metrics: It’s easy to focus purely on ROAS once you have this set up, but keep an eye on other metrics like retention, engagement, and even IAP revenue if applicable. You want high-value users, not necessarily just a high immediate ROAS at the cost of long-term growth. For example, an extreme scenario: Meta might find a small cohort of users who watch tons of ads initially (high D7 ROAS) but then churn by day 10 because maybe they were incented or misled. Meanwhile, a broader set of users might have slightly lower D7 ROAS but much higher D30 ROAS because they stick around. Balance short-term and long-term. Use value breakdowns if possible: check ROAS at D1 vs D7 vs D30. Meta’s optimization will primarily focus on whatever window it can observe (likely 7-day or so), so you ensure that aligns with your business goals. If you care about 30-day ROAS, you might need to keep campaigns running longer to see that realized and possibly adjust bids accordingly.
• Attribution Discrepancies and Overlap: When you introduce a new type of conversion event, be mindful of how it overlaps with existing ones. If you run purchase-optimized and ad-optimized campaigns simultaneously, a single user could trigger both a purchase event and multiple ad events. Meta’s attribution system might attribute that user’s install to one campaign and thus that campaign gets all that user’s conversion value (e.g., if a user came from the purchase campaign ad, that campaign won’t “see” the ad impressions in its results, because those events might be mapped to a different campaign’s goal). In other words, whichever campaign gets the install attribution will claim the events it’s optimizing for. It’s usually fine because campaigns typically target different user segments (if set up smartly), but just be careful in analysis: you might see one campaign driving mostly purchasers and another driving ad revenue, and the sum is your app’s total. To avoid confusion, you might temporarily turn off one type to measure the other, or use your MMP to get a holistic view of total revenue per source. A pitfall would be double-counting revenue across campaigns in your head – remember that one user’s both streams won’t be split across two campaigns in reporting.

Monitoring and Iteration:
Finally, treat Ad ROAS campaigns as a living project. Monitor them closely, but also give them time to breathe. We’ve seen that once the algorithm “finds its groove,” performance can actually improve over a few weeks as it refines its understanding of valuable users. Don’t panic if week 1 ROAS is not great; look for an upward trajectory. Conversely, if performance saturates, try creative refreshes or expanding audiences – typical campaign optimizations still apply.

Pitfall to avoid: turning off the campaign too quickly. Value-optimized campaigns might start slow. If you kill it before it exits the learning phase or just as it’s gathering steam, you could miss out on the upside. Give it a fair budget and time, as long as you see some positive indicators (like rising conversion value each day, or some high-value users coming in even if average isn’t there yet).

In summary, best practices for Meta’s Ad ROAS include proper setup, ensuring ample data, and maintaining a healthy in-app ad strategy, while pitfalls mostly relate to misconfiguration or misinterpretation of data. If you follow the setup guide (coming next) and keep these tips in mind, you’ll set yourself up for success and avoid common mistakes. This is a new tool, so continuous learning and adjustment on your side will go hand-in-hand with the campaign’s machine learning.

Final Thoughts and common Q&A I get

Final Thoughts: Meta’s introduction of Ad ROAS optimization using AdImpression events is a significant evolution in the performance marketing landscape. It acknowledges that not all app revenue comes from purchases – a huge number of apps rely on advertising dollars. By giving advertisers the ability to optimize for that, Meta has opened the door to more efficient and scalable growth for those apps. Early results are promising, with reports of higher LTV and better retention from campaigns that use this signal​. It does require some upfront work to implement the tracking, but once in place, it largely runs on autopilot, leveraging Meta’s powerful ML to find your most valuable users. As with any new feature, we expect Meta to refine it over time – possibly extending it to iOS in some form, adjusting eligibility criteria, and improving reporting.

For marketers, the key takeaway is: if your app makes meaningful revenue from ads, you should strongly consider testing Ad ROAS campaigns. It’s an opportunity to squeeze more profit out of your ad spend and discover user segments you might be missing with standard optimization. It aligns your campaign optimization with your business’s revenue streams more directly than ever.

To wrap up, let’s address some common questions about Meta’s Ad ROAS and AdImpression optimization:

• Q: Is this feature available for iOS app campaigns or only Android?
  A: As of now, it’s Android-only for direct optimization. Meta has restricted “In-app ad impression” value optimization to Android app install campaigns​. This is largely due to Apple’s privacy rules (ATT) and the reliance on Aggregated Event Measurement for iOS, which doesn’t allow the same real-time, granular value optimization. iOS apps can still send ad revenue data (for example, AppsFlyer will forward it as a purchase event for recording purposes)​, but you cannot create an iOS campaign that specifically optimizes for AdImpression value at this time. We anticipate Meta might find a way in the future (perhaps using SKAN 4’s conversion values or improved AEM) to incorporate ad revenue in iOS, but nothing official yet. For now, focus on Android where the IDFA/GAID is available for attribution. If you do send ad revenue from iOS, it will be visible in aggregated reports (and you might see it under your ROAS if you optimize for purchases), but it’s not individually optimizable.
• Q: What if my app uses both in-app purchases and ad monetization? Should I combine both in one campaign’s optimization, or run separate ones?
  A: The current Meta campaign structure only allows one optimization event per ad set, so you can’t directly optimize for two different events simultaneously in one campaign. You have a couple of options:
  1. Run separate campaigns/ad sets – one optimizing for purchase value (fb_mobile_purchase) and another for ad impression value. This is the simpler approach, as discussed. Each will find the best users for that revenue type. You can then allocate budget between them based on which revenue stream you want to grow or which yields better ROAS.
  2. Combined value approach (advanced): In theory, you could create a custom event that represents “total value” and send that to Meta. For example, whenever a user either makes a purchase or sees an ad, you log a “TotalValue” event with the dollar amount. Meta would then optimize for total revenue. However, this is not straightforward – Meta doesn’t natively support optimizing on a custom event for app campaigns (only standard events). A hack would be to piggyback on the purchase event: e.g., log a purchase event for ad revenue as well so both IAP and ad revenue appear as “purchase” value to Meta. Some advertisers have done this historically (pre-AdImpression feature) – basically summing all revenue into purchases. This can work for optimization, but it mixes user types and can confuse analytics (you’d see inflated purchase values that actually include ad money). Best practice is to keep them separate for clarity and better targeting. Perhaps run them in parallel and then internally add up the revenues to see total ROAS. If one campaign is vastly outperforming the other, you can adjust budgets accordingly.

  In short, prefer separate optimization for each revenue source. The users who purchase versus the users who watch ads might be different personas; treating them distinctly allows Meta to tailor acquisition for each. Just coordinate so you don’t overspend trying to get one user to do both things – usually a user will strongly do one or the other.

• Q: How do I implement this if I’m not using an MMP?
  A: You can integrate directly with Meta’s tools:
  • Using the Meta (Facebook) SDK: Integrate the Facebook SDK for Android (and iOS if needed for other events). After initializing it in your app, whenever an ad impression occurs, call the event logging method. For example, on Android: AppEventsLogger.logEvent("AdImpression", valueToSum = <revenue_value>, params). On iOS, similarly use FBSDKAppEvents.logEvent with the event name @”AdImpression” and supply the value. Ensure you set the currency if not USD (Facebook SDK might use a default or you can add a parameter like { "fb_currency": "EUR" } if needed). The SDK will send these events in the background. You should also log the standard app install and app activate events (which the SDK can do automatically) so that Meta knows about installs and sessions. Once the events are flowing, you connect your app in Events Manager and you should see the AdImpression events there.
  • Using the Conversions API (CAPI): If for some reason you can’t use the SDK (say your app is built in an engine where adding the SDK is difficult), you can send events server-to-server. Meta’s Conversions API for app events allows you to send events like “AdImpression” with a user’s ID or advertising ID. You would need the Facebook App ID and an access token, and you’d construct a POST request to Meta’s Graph API endpoint with the event data. (Many server-side platforms or even Tag Manager setups support this.) The key is you need an identifier to tie the event to a user – typically the Advertiser ID (GAID) and the FB App ID are used. Using CAPI is more complex and usually not necessary unless you have a specialized stack, but it’s an option. Meta’s documentation explicitly states that to be eligible for this product, you need to send ad revenue data via either the Facebook SDK or Conversions API​ – so both are supported.

  If you go direct, you won’t have an MMP to do attribution, which means Meta will handle attribution fully on its side (which is fine for optimization). Just remember if you also want a third-party source of truth, you might still want some analytics SDK capturing revenue. But purely for running the campaign, the FB SDK/CAPI approach will suffice. Many developers integrate the FB SDK just for app event optimization even if they use another analytics tool for other things.

• Q: What kind of values should I send with AdImpression events? Do I send lifetime value, per-impression value, or something else?
  A: You should send the per-event revenue – i.e., the revenue associated with that specific ad impression. If an ad network tells you “this impression earned $0.02”, then you log an event with value 0.02. Do not accumulate values and send a lump sum later (Meta will aggregate on their side). Also, do not send something like an eCPM or predicted value – send actual revenue if available. Most mediated ad SDKs now provide impression-level revenue callbacks. Use those. If for some reason you only get aggregate data (e.g., you know a user’s total ad revenue after a day), you could simulate impressions by sending multiple events or one event with the total. But that’s less ideal. The granularity helps Meta learn which moments or which users are driving value. Additionally, include any parameters that might be relevant. Meta’s AdImpression event has an fb_ad_type parameter for instance – if you can, you might pass whether it was a rewarded video vs banner, etc. It’s not strictly required for optimization, but it could be useful for breakdowns or if Meta uses it under the hood. The main thing is the numeric value. In terms of currency, Facebook by default assumes the event value is in the app’s currency (which you set in the developer settings or it might default to USD). If you have multi-currency (like ad network pays in different currencies), convert it server-side or specify currency in the event parameters so Meta doesn’t mix currencies. Typically, keep it consistent – e.g., always send USD values.

• Q: What if I don’t have an impression-level revenue data from my ad networks?
  A: This is a challenge because the whole feature relies on user-level revenue signals. Many ad mediation platforms (ironSource, MAX, AdMob, etc.) now offer APIs for impression-level revenue. If yours doesn’t, consider switching or see if they provide at least per-session or per-user revenue. In a worst-case scenario, you might estimate. For example, if you know your average revenue per impression is $0.005, you could theoretically send that value for each AdImpression event even if you don’t know the exact. However, this is not ideal: it gives Meta no variation in value (every event looks the same), which fails the “distinct values” criterion​ and won’t help the algorithm differentiate high-value users from low. It might then default to just counting events (which is like optimizing for number of ad impressions regardless of quality). So, the pitfall is if you send identical dummy values, you won’t get the full benefits. It’s highly recommended to integrate a solution that gives actual revenue per impression. Many MMPs have partnerships where the ad network SDK automatically sends that to the MMP SDK (e.g., AppLovin MAX can feed Adjust/AppsFlyer with revenue data). Leverage those. If absolutely impossible, you might hold off on Ad ROAS campaigns until you can improve your data granularity.
• Q: How do I measure success for Ad ROAS campaigns?
  A: The primary success metric is ROAS (Return on Ad Spend) at whatever timeframe matters to you (Day 7, Day 30, etc.). You want to see higher ROAS% compared to your previous baseline or compared to other campaigns. Additionally, you can look at absolute revenue – are you generating more total revenue from the campaign than before? Also consider payback period: if previously it took 60 days to break even on ad spend and now projections show 30 days, that’s a success. Secondary metrics include retention (are you keeping the quality users), ARPU, and CPI/CPE (cost per install or cost per event) to ensure you’re not overspending. If possible, do a controlled experiment: e.g., run a holdout geo or audience with a normal campaign vs. one with Ad ROAS. That isolate the effect. In summary, success = higher revenue for the same or lower spend – which should manifest as improved ROAS and often improved retention. Keep an eye on the quality to ensure you’re not just getting short-term ad watchers who churn (though the early evidence suggests quality is good when optimizing for value).
• Q: Could this optimization lead to acquiring “clicky” users who might click ads aggressively (maybe even fraudulently) and harm advertiser partners?
  A: It’s a thoughtful question – if we optimize for ad revenue, could we inadvertently target users who click ads in the app just for the sake of it (like click farms or reward abuse)? Meta’s algorithm generally optimizes for legitimate value, and it’s in Meta’s interest as well that those ad impressions are genuine (since Facebook also cares about the advertiser experience in Audience Network or other networks). If your app is well-monitored for ad fraud (e.g., you’re not showing ads in a way that encourages accidental clicks), this shouldn’t be a big issue. The optimization is for impressions (views) and the revenue from them, not specifically clicks. In many cases, video ads give revenue on completion, not necessarily click, so the algorithm likely chases users who complete ads. Those tend to be real users enjoying rewarded videos for instance. However, remain vigilant: if you notice strange patterns (like a cohort of users with abnormally high ad click rates), ensure your app’s anti-fraud measures are in place. You don’t want to attract bots or exploiters. This is more of an app quality concern than the Meta campaign itself, but worth keeping an eye on. In legit scenarios, Meta will find engaged users, not fraudsters – especially because the ad revenue feedback is something you control and presumably you’re not crediting fake revenue.
• Q: Any insight on how Meta’s algorithm adapts with this signal?
  A: While Meta doesn’t publish details of its algorithms, we can infer that it uses similar logic as with value optimization for purchases. It will use historical data to predict a user’s likelihood of generating a certain amount of ad revenue (maybe using lookalike modeling, device data, etc.). It likely updates prediction models continuously as new AdImpression events come in. The more data you feed (especially diverse data: different user behaviors, values, etc.), the better it can distinguish and predict. Over time, Meta’s model might even learn seasonal or contextual patterns (maybe users acquired in the morning produce more ad revenue than those at night – it could adjust delivery accordingly). It’s quite complex, but the key is that it’s leveraging all available data points to maximize a long-term value metric rather than a binary install or event. Advertisers should note that such campaigns might favor quality over quantity – fewer installs but each worth more. This can be a shift in mindset if you’re used to judging success by install volume. Trust the ROAS and total revenue more than CPI or install counts in this context.

With these questions addressed, we conclude our deep dive. Meta’s Ad ROAS with AdImpression optimization is a promising tool for performance marketers, offering a new avenue to improve campaign profitability and scale. By carefully implementing the technical setup and following best practices, you can leverage this feature to acquire the right users for your ad-monetized apps. It marries the world of user acquisition with monetization in a way we haven’t had before on Meta’s platform. As always, continuous testing and learning will help you refine your approach. Good luck, and may your ROAS be ever-increasing!

Platform-Specific Implementation Guides (Step-by-Step)

Now that we’ve discussed the concepts and benefits, let’s get into the technical how-to. Below are step-by-step setup guides for implementing Meta Ad ROAS optimization using AdImpression events on various platforms and integrations. We’ll cover the Meta SDK (for Android & iOS) and popular Mobile Measurement Partners: AppsFlyer, Adjust, and Singular. Each section will ensure you know how to send the AdImpression event properly and configure the systems to start optimizing for ad revenue.

Meta SDK (Android & iOS) Integration Guide

If you choose to integrate directly with Meta’s own SDK (Facebook SDK) for app events, follow these steps:

1. Add the Facebook SDK to your app: If not already installed, add the Meta (Facebook) App Events SDK to your project. For Android, this typically means adding the Facebook SDK via Gradle (implementation 'com.facebook.android:facebook-core:[latest-version]') and initializing the SDK in your Application class. For iOS, use CocoaPods or SPM to add FBSDKCoreKit (which contains FBSDKAppEvents). Initialize it in your App Delegate (ApplicationDelegate.initializeSDK(...)). Ensure you have a valid Facebook App ID for your app and configure the Info.plist (iOS) or AndroidManifest with that App ID and required metadata. This Facebook App ID links your app to the Events Manager on Meta’s side.
2. Enable automatic events (optional): The FB SDK can automatically log installs (mobile_app_install) and app opens (fb_mobile_activate_app). It’s good to have these, as they’re needed for baseline tracking. Follow Meta’s docs to enable automatic event logging. This ensures Meta knows when an install happens and can attribute events properly. On iOS 14+, you should also handle the ATT prompt; if the user opts out, the SDK will still log events but without device ID (they’ll go into aggregated measurement).
3. Implement AdImpression event logging in your code: Whenever an ad is shown in your app, log an AdImpression event. You’ll need to hook into your ad SDK’s callback. For example, if using Google AdMob, you can use the PaidEvent (for AdMob’s SDK which provides earnings per impression). If using ironSource or others, they have similar delegates for impression data. In that callback, call the Facebook SDK’s log event function:
   • Android (Java/Kotlin):

java

1. • CopyEdit

     AppEventsLogger logger = AppEventsLogger.newLogger(context); Bundle params = new Bundle(); params.putString("fb_ad_network", "AdMob"); // example parameter, optional params.putString("fb_ad_plcement", adUnitId); // you can pass placement id or ad format // ... (Meta has predefined parameter keys like fb_ad_type if you know it) logger.logEvent("AdImpression", revenueValue, params);

     Here, revenueValue is a double or BigDecimal representing the money earned from that impression (e.g., 0.02 for 2 cents). The event name must be exactly “AdImpression” (case-sensitive). The SDK will automatically treat this as a standard event. The valueToSum in this call is what Meta uses as the conversion value​. Additional params are optional but can include info like ad type, placement, etc., using Meta’s recommended keys (e.g., "fb_ad_type" could be "rewarded_video").

   • iOS (Objective-C/Swift):
     In Swift (using FBSDKCoreKit):

swift

1. • CopyEdit

     let params: [AppEvents.ParameterName: Any] = [ .init("fb_ad_network"): "AdMob", .init("fb_ad_placement"): adUnitID ] AppEvents.shared.logEvent(AppEvents.Name("AdImpression"), valueToSum: revenueValue, parameters: params)

     This does similar: logs an event named “AdImpression” with the revenue value. If you’re using Objective-C, you’d use [FBSDKAppEvents logEvent:@"AdImpression" valueToSum:revenue parameters:params]. Ensure you import the FBSDKCoreKit and have the necessary using statements.

   • Unity or other engines: If using Unity, Meta has a Unity SDK plugin. You’d call FB.LogAppEvent("AdImpression", valueToSum, parameters) accordingly. Note that in some versions of the Unity SDK, not all event constants were exposed, so you might just use the string name. According to Meta, use the exact string “AdImpression” (older documentation might not list it, but it is supported)​
2. Verify events in Meta Events Manager: After integrating, run the app and trigger a few test ad impressions (you can use test ads from networks to do this). Then go to the Facebook Events Manager for your app (in your Meta Business Suite) and verify that you see the “AdImpression” events coming in. They should show a count and the aggregated value. You can use the Event Debugging tool to watch real-time events from a test device. If they don’t appear, troubleshoot the integration (check the SDK initialization, logcat or Xcode log for any errors, ensure the device has internet, etc.). Common issues might be missing permissions or the app not being in development mode (for testing, you might need to add your Facebook test user account as a tester for the app).
3. Implement on both Android and iOS (with limitations): You can put this code in both your Android and iOS builds. On Android, events will be used for optimization. On iOS, you won’t directly optimize on them now, but it’s still good to send them for record-keeping or if Meta later uses them in aggregated form. Just be mindful that on iOS 14+ if user opts-out, events go into SKAdNetwork’s postbacks or AEM. You may consider using the SKAdNetwork conversion value for ad revenue, but that’s advanced and beyond our scope. For now, sending them via FB SDK on iOS will at least log them under “fb_mobile_purchase” (since Meta maps AdImpression to purchase for iOS as a workaround​).
4. Campaign setup in Ads Manager: With the SDK logging events, ensure your Facebook app is linked to your ad account (usually done by adding the app in Events Manager and having the same Business Manager own it). When creating a campaign, choose App Promotion (App Installs) as the objective. In the Ad Set, set Optimization & Delivery to “Value” (or “Maximize Value”). Then in the Conversion Event dropdown, look for In-app ad impression. Select it. (If you don’t see it, or it’s greyed out, revisit the earlier section on eligibility – you might need to run some basic campaigns first to get events flowing​) Complete the campaign setup (targeting, creatives, budget, etc.) and launch it.
5. Post-launch monitoring: After launching, keep monitoring in Events Manager to ensure events continue to flow as volume increases. Also check Ads Manager for the “Results” column showing “In-App Ad Impressions (Value)” and related ROAS metrics. It may take some time for data to accumulate. If you see installs but no “value” yet, it might be that new users haven’t generated an ad impression yet – which can be normal if there’s a delay before a user sees an ad. Over a day or two, those should start coming in. If not, perhaps there’s an issue in the code where not all ad impressions are being captured (make sure you integrated callbacks for every ad format in use).

By following these steps, you will have implemented the AdImpression event via the Meta SDK, enabling Meta to directly receive and optimize on your in-app ad revenue signals.

Note: The Facebook SDK approach means Meta has all the data directly. If you are also using an MMP, you’ll essentially have two parallel event reporting channels (which is okay). Just be careful not to double count if you look at analytics – MMP might show one set of numbers and FB another. For campaign optimization though, Meta will use what its SDK sends. Some advertisers do both: they use MMP for attribution and the FB SDK for real-time events to power optimization (especially on iOS because of SKAdNetwork, but that’s another story).

AppsFlyer Integration Guide

AppsFlyer is a popular MMP that can forward in-app events (including ad revenue events) to Meta. Here’s how to set up Ad ROAS using AppsFlyer:

1. Integrate AppsFlyer SDK and Ad Revenue APIs: Make sure your app is running the latest AppsFlyer SDK (Android and iOS). To capture ad revenue, AppsFlyer offers a feature called Advanced Ad Revenue (ROI360). This typically involves either integrating adapters for each ad network or using AppsFlyer’s unified API to log ad revenue. For example, AppsFlyer’s SDK has a method AppsFlyerLib.logAdRevenue(adNetwork, payload) that you call when an impression happens. Many ad networks (ironSource, AppLovin MAX, AdMob) have built-in support where their SDKs can directly pass revenue info to AppsFlyer’s SDK if configured. Refer to AppsFlyer’s docs on Impression-level Ad Revenue integration and ensure your networks are supported. If you do not have the ROI360 plan, you might not have the af_ad_revenue event by default, but you can still manually log a custom event for ad revenue (it just won’t be labeled af_ad_revenue – see step 3 note).
2. Enable sending ad revenue events to Meta: In the AppsFlyer dashboard, go to Configuration > Integrated Partners and select Facebook (Meta). There will be an In-App Events mapping section. Turn on Sending Events if it’s off. You’ll see a list of your AppsFlyer events on the left and a dropdown to map to Meta events on the right. Locate af_ad_revenue in the list of your events (AppsFlyer populates standard events after they occur at least once; if you haven’t generated one yet, you may need to add it manually in the mapping interface by typing it). Map af_ad_revenue to AdImpression for Android​. For iOS, since Meta doesn’t accept AdImpression events from iOS yet, AppsFlyer’s recommendation is to map af_ad_revenue to fb_mobile_purchase on iOS​. AppsFlyer actually shows this in their interface: they treat AdImpression as Android-only and use purchase for iOS as a fallback. This way, your iOS ad revenue will be sent to Meta as if it were purchase revenue (so you’ll see it in aggregated values, though you can’t optimize on it separately).
3. Configure ROI360 (if applicable): AppsFlyer’s af_ad_revenue event is part of their ROI360 suite​. Ensure your account has this enabled (it usually requires a contract add-on). If you don’t have it, you can alternatively log a custom event for ad revenue (say you call it “ad_revenue”) and map that to AdImpression. Important: The AppsFlyer documentation notes that non-ROI360 customers can still send ad revenue using other event names​. So you could do: log an event “my_ad_revenue” with a parameter af_revenue, then in the mapping map that custom event to AdImpression (for Android). The key is making sure the value goes through (af_revenue parameter will map to Meta’s valueToSum as long as you map the event, either as predefined or custom). However, if possible, use the standardized af_ad_revenue because it’s automatically formatted and recognized in their system.
4. Include revenue and details in the event: When logging ad revenue events via AppsFlyer SDK, include the monetary value. AppsFlyer will typically use af_revenue as the parameter for the amount (and af_currency for currency). It automatically maps af_revenue to Meta’s _valueToSum​. This means when AppsFlyer sends the postback to Meta, Meta receives an event “AdImpression” with value = that af_revenue. So ensure you’re calling the logging method with the value. For example, in Android if using the manual method:

java

1. CopyEdit

   JSONObject impressionData = new JSONObject(); impressionData.put("ad_network", "AdMob"); impressionData.put("af_revenue", 0.02); impressionData.put("af_currency", "USD"); AppsFlyerLib.getInstance().logEvent(context, "af_ad_revenue", impressionData);

   If using their provided integrations, this might be done for you. On iOS, similarly use [AppsFlyerLib logEvent:@"af_ad_revenue" withValues:payload]. Confirm in AppsFlyer’s Logs that the events are coming in with revenue.

2. Test and verify: As with the SDK, trigger a test ad impression. Then in AppsFlyer’s dashboard, go to Logs or Analytics > Events to see if an af_ad_revenue event was recorded for your test device. Also check the Partners > Meta > Test Postbacks (AppsFlyer sometimes has a testing tool) or just wait a short while and check Meta’s Events Manager. If mapping is correct, Meta’s Events Manager should show incoming AdImpression events (if your test was on Android). If on iOS, they would show as purchases. The AppsFlyer “Integration Test” feature might let you send a sample event to Meta to ensure it arrives.
3. Finalize Meta partner setup in AppsFlyer: In the Facebook integration settings on AppsFlyer, ensure you have your Facebook App ID entered. Also, set the toggle for sending event values. AppsFlyer allows you to choose to send all events, or only attributed events, etc. For maximizing data to Meta, you might send events from all media sources (so Meta can even learn from organic or other sources). But by default, AppsFlyer will send attributed events to the source that owns them. (Check the setting “for events coming from All media sources including organic” when mapping – usually you want that so that even organic events are sent, which can help Meta’s modeling​) However, note that Meta’s policy might only use attributed ones for optimization – still, sharing more data likely doesn’t hurt. The mapping interface typically has a column “for users from” – you can select “All media sources, including organic” for the ad revenue event mapping, to maximize data sent.
4. Launch the campaign on Meta: Once AppsFlyer is forwarding events, set up your Android campaign in Meta Ads Manager as described: choose value optimization and “In-app ad impression” as the event. AppsFlyer will handle sending conversions to Meta. You might not see the values immediately in Ads Manager until actual attributed installs start generating them. But behind the scenes, as long as AppsFlyer is integrated, everything is automated. Keep the AppsFlyer SDK running in production so that every user’s ad impressions are tracked and sent.
5. Monitor performance and event delivery: Check AppsFlyer’s Dashboard > ROI Reports (if you have ROI360) to see the ROI that includes ad revenue. Check that the number of AdImpression events in Meta roughly matches what AppsFlyer shows as sent. Minor discrepancies can occur, but large gaps might indicate some postbacks not going through. Also watch for any rate limit messages – though unlikely at typical volumes, ensure that if your app generates tons of events, AppsFlyer isn’t throttling (they have high limits, but just be aware).

By following these steps, you effectively use AppsFlyer as the bridge: your app feeds ad revenue to AppsFlyer, and AppsFlyer feeds it to Meta (with the correct AdImpression label on Android). The benefit is you also keep all your attribution and analytics consolidated in AppsFlyer, and you don’t need to maintain separate code for Meta’s SDK events. AppsFlyer’s documentation confirms that this setup enables Meta to optimize based on ad revenue​, as long as the mapping is correct and your account is eligible.

Additional AppsFlyer Tips/Pitfalls:

• Make sure the time zone and currency settings in AppsFlyer and Facebook match or are accounted for. AppsFlyer will send a currency code with each event; Meta will convert it to your ad account currency if needed.
• If you’re testing on a non-ROI360 plan, you might need to use a custom event name. Ensure to map that to a Custom event in AppsFlyer’s Meta mapping with “Value” sending. It’s possible to map a custom AppsFlyer event to a Meta custom event, but since Meta doesn’t optimize for custom events, you should map it to AdImpression if possible (some have reported that even without ROI360 you can manually type “AdImpression” as the partner event – effectively doing the same mapping).
• AppsFlyer’s event mapping interface also allows sending event values or not. Obviously for ROAS you need to send value, so check that “Value & Revenue” (or equivalent) is toggled on for that event mapping. This ensures the af_revenue gets included in the postback. If you only send the event without value, Meta would see conversion count but zero value – not useful for value optimization.

Adjust Integration Guide

Adjust offers a robust solution for tracking ad revenue and forwarding it to partners. Here’s how to set up Meta Ad ROAS using Adjust:

1. Integrate Adjust SDK and Ad Revenue tracking: Include the Adjust SDK in your app (Android & iOS). To capture ad revenue at the user level, Adjust provides an Ad Revenue tracking feature. Adjust supports integration with various ad networks and mediation platforms (e.g., you can integrate Adjust’s SDK to receive callbacks from ironSource, AppLovin MAX, AdMob via adapters, or use Adjust’s server-to-server for ad revenue). One common method is Adjust’s trackAdRevenue method, where you specify the source (like Adjust’s predefined constants for sources) and a JSON payload containing revenue info. For example, Adjust.trackAdRevenue(AdjustConfig.AD_REVENUE_ADMOB, revenueJson) for each impression. Ensure you implement these calls in the appropriate callbacks of your ad SDKs. Adjust also has partnerships where certain SDKs automatically feed data to Adjust if configured. Consult Adjust’s documentation for Ad Revenue to set this up. This typically requires you have credentials or settings from your ad mediation to pass to Adjust (for impression-level data). It might be technical, but once done, Adjust will receive an “ad_revenue” event for each impression.
2. Configure Adjust to forward data to Meta: In the Adjust Dashboard, navigate to your app settings and find the Partner Integrations or Data Sharing section for Facebook (Meta). Adjust has a specific integration page for Facebook. There you need to do a few things:
   • Enter your Facebook App ID (so Adjust knows where to send events)​.
   • If applicable, enter the Facebook Install Referrer Decryption Key (for Android) – this is for more accurate install attribution on Android, not directly related to ad revenue, but recommended​.
   • Look for the Data Sharing Options: Adjust provides checkboxes such as “Send ad revenue data”. Specifically, check “Ad revenue (from ad views)” to enable sending those events​. By default, if you check this without further options, Adjust would forward ad revenue events as purchase events (fb_mobile_purchase) to Meta with the revenue value. However, since late 2024, Adjust introduced an additional setting to use AdImpression mapping.
   • Check “Enable AdImpression Mapping (Android only)”. This is the crucial step for Ad ROAS. When you check this, Adjust will map the ad revenue events to Meta’s AdImpression event instead of fb_mobile_purchase for Android​. This effectively tells Meta “these events are ad impressions with value” and allows the AdImpression optimization. (Under the hood, if unchecked, Adjust would send them as purchase events named fb_mobile_purchase, which would still show revenue but not trigger the new optimization goal.)
   • Ensure any other relevant options are set: e.g., “Send revenue value” (Adjust usually always sends value with revenue events). Also, you might have the choice to send data for all attributions or just meta attributions. Adjust by default sends all data (which can be beneficial)​, but you can configure if needed.
3. Eligibility and prerequisites: Adjust mentions that the AdImpression mapping feature is available for Android apps and requires that Meta has enabled the “maximize in-app ad revenue” for your account. If the toggle is greyed out in Adjust’s UI, it might mean your Adjust account needs a certain package (they mention “Adjust Growth Solution” in some communications, possibly required for ad revenue forwarding). Also, ensure you are on an updated SDK version that supports this. As of Adjust SDK 4.33.0+ (for example), ad revenue tracking and new mapping should be supported, but check release notes.
4. Implement and send ad revenue events: With the settings in place, run your app and trigger some ad impressions. Adjust’s SDK will collect those (if properly integrated). You can verify in Adjust’s dashboard under Statistics > Event Types that ad revenue events are recorded. Adjust typically labels them under an event token internally (since Adjust events are often tokenized). There might not be a human-readable name for the ad revenue event in the dashboard, but you will see the revenue in the aggregate stats. More directly, use Adjust’s test tools: Adjust has a Testing Console where you can simulate an ad revenue event, or use the SDK test mode to print logs. Ensure that these events are indeed being sent out to partners. If your device is set as a debug device in Adjust, you might see logs like “Sending ad_revenue to partner Facebook” or similar.
5. Confirm events on Meta side: Since Adjust sends events in real-time to partners, after a test impression, check Meta’s Events Manager. You should see an “AdImpression” event come in (for Android tests). If something is off, you might instead see a fb_mobile_purchase event. That indicates the mapping toggle might not be on or working. Double-check the “Enable AdImpression Mapping” box​. (Remember, iOS events will still go as purchases due to Meta limitations, so focus on Android for this verification.)
6. Launch the campaign: In Meta Ads Manager, set up your app campaign for Android with the optimization event “In-app ad impression”. Since Adjust is attributing installs and sending events, use App Events optimization and select the AdImpression event. If your account is eligible and Adjust has started sending data, it should be selectable. If you literally just started sending, you might need to wait until Meta registers a few (the threshold is at least 15 events historically). Adjust notes that if the option is visible but greyed out, you need to send more events or meet criteria​. So if greyed out, ensure you generate enough dummy data or run a short pilot campaign to get those 15+ events in.
7. Monitor in Adjust and Meta: Once live, you can use Adjust to monitor raw data. Adjust can show you each attributed event. In Adjust’s Raw Data exports (or callbacks), an ad revenue event will have a certain event ID and revenue. Verify that those events show attribution to the correct campaigns. Additionally, check your Meta Ads Manager to see if it’s receiving the values. Ideally, do a small spend and then compare: does Meta show, say, $5 of conversion value and Adjust shows $5 of ad revenue for that campaign? They should align closely. Minor timing differences aside, it’s a good consistency check.
8. Adjust features for troubleshooting: Adjust provides some useful tools. The Activity Log can show partner linking status. Also, if Meta provided any feedback (like if events were rejected), Adjust might show an error. Ensure that the Facebook partner is Activated in Adjust (usually by saving the integration settings it becomes active). If you have any other custom mappings (like if you also send purchase events), make sure those are mapped properly too (they can coexist). Adjust by default will send any event that has revenue either as purchase or AdImpression depending on that toggle. If you also have in-app purchase events, those can still be sent as fb_mobile_purchase concurrently. That’s fine – Meta will get both types of events from Adjust.

By using Adjust, you benefit from its accurate attribution and perhaps less engineering effort on your side (especially if you already use Adjust for other campaigns). Adjust handles all the heavy lifting of event de-duplication and sending. One advantage Adjust has is the ability to send all ad revenue events, even those not attributed to Meta, to Meta (if you opt to share all data)​. This means Meta’s ML could potentially learn even from organic users’ behavior. However, Meta officially optimizes on attributed events. Still, more data presumably doesn’t hurt.

Note: Adjust’s documentation emphasizes checking eligibility in Ads Manager (like ensuring the option appears) and highlights that the feature is in limited availability​. If your account doesn’t show it at all, you might need to contact your Meta rep or wait for the rollout. As of late 2024 it’s rolling out widely, so by 2025 most accounts should have it.

Also, Adjust automatically sends the revenue value (with currency). They mentioned that by default previously they’d send it under fb_mobile_purchase (with valueToSum). Now with the new mapping, they send it under AdImpression. Meta knows to treat that as ad revenue. Keep an eye on Adjust’s updates – as this is new, they might refine the integration. For example, if Meta changes criteria or adds iOS support down the line, Adjust would update their interface accordingly.

Singular Integration Guide

Singular is another MMP that can send user-level ad revenue to Meta. The setup is somewhat similar to others:

1. Integrate Singular SDK and enable Ad Revenue tracking: Make sure you have the Singular SDK integrated for your apps. To capture ad revenue, Singular provides a feature often called Ad Monetization Revenue tracking. Singular can ingest data via its SDK from mediation partners or via S2S. For instance, if using IronSource, you can configure IronSource to send impressions to Singular. Or you can use Singular’s API calls to record ad revenue events. Singular’s SDK might automatically log an event like __ADMON_USER_LEVEL_REVENUE__ for each impression if set up. The key is to have per-impression or at least per-user ad revenue being tracked by Singular. Check Singular’s docs on “Ad Revenue Attribution” – typically you have to include the network SDKs and add some lines of code to inform Singular of ad revenue (like their Ad Monetization API which might take ad unit, revenue, currency, etc.).
2. Configure Facebook (Meta) as a partner in Singular: In Singular’s dashboard, go to Partners > Facebook Ads configuration. Make sure your Facebook App ID is linked (you’ll input the FB App ID in the settings)​. Singular will use this to send events to the correct app. Also ensure the basic integration is toggled on (so installs and sessions are being sent to FB – singular does this automatically for mobile_app_install and fb_mobile_activate_app when configured​).
3. Map the Ad Revenue event to AdImpression: Under the Facebook partner configuration in Singular, find the Event Postbacks section (sometimes just labeled as “Events to send”). Here you can add mappings. Singular often lists events by the SDK event name. The standard one for ad revenue is __ADMON_USER_LEVEL_REVENUE__ (that’s a default event name used internally for ad monetization). Map this event to Meta’s AdImpression event​. There should be a dropdown of Meta’s predefined events – select “AdImpression”. Also, check the box or option that says “Include Revenue Value” (Singular’s UI typically has a checkbox to include the revenue amount when sending). This ensures that the monetary value captured with that event is forwarded to Meta. Additionally, make sure the currency is handled (Singular will likely send the currency code if it knows it; ensure your Singular event has currency info – usually it will, since when you integrated ad revenue, you would specify currency or it defaults to USD).

   If you have separate events for IAP (like iap), you can map those to fb_mobile_purchase as usual​. But our focus is the ad revenue event to AdImpression mapping. Save the configuration.

4. Verify event mapping: Singular, once configured, will send a test (some platforms do a test ping on save). To be sure it works, generate a test ad impression in your app. Then in Singular, check the Live Logs or Event Tracker if available, to see that the event was received. Next, go to Meta’s Events Manager to see if an AdImpression event shows up. If you don’t see it, you may want to use Singular’s testing tools. They might have an option “Send test postback” for partner integration. If not, you can contact Singular support or double-check the mapping format. It might also require that an install from a Facebook campaign exists; sometimes partner postbacks only fire for attributed users. If you want to test end-to-end, you might need to run a Facebook ad to your device, install via that ad (so that install is attributed to FB via Singular), and then generate an ad impression. Then Singular will send the AdImpression postback to Facebook with attribution info. This is a heavy test, but it confirms everything. Alternatively, ensure the mapping is correct and trust that when a real campaign runs, it will work.
5. Check eligibility and Singular’s notes: Singular’s documentation (as of early 2025) acknowledges that you can send ad revenue to partners to run Ad ROAS campaigns​. They even list which networks accept ad revenue postbacks (they listed Unity, ironSource, etc.; Meta likely is now one of them). Singular’s specific instructions for Meta were: select ADMON_USER_LEVEL_REVENUE and map to AdImpression, including revenue. If there are any special conditions (like needing to be whitelisted), Singular would likely mention it. Make sure your Singular account manager has enabled Ad Revenue Attribution for you, as that can be an add-on.
6. Launch Meta campaign: Set up the Meta campaign for Android as described (Maximize Value, event = In-app ad impression). Because Singular is an MMP, Meta will still attribute installs through Singular (assuming you’ve set them up as the attribution partner). But for optimization, Meta will use the events you send. As long as those events come with attribution, it will optimize. Typically, MMP postbacks for events include info like the campaign ID, etc., so Meta knows which campaign the event is tied to (or they just trust the MMP to only send for attributed users). Singular likely only sends the AdImpression events for users attributed to Facebook campaigns (unless configured otherwise). So you might want to ensure you send for all sources if that helps (there may be a toggle like “Send events for attributed users only” – if so, consider sending for all so even organic ones go, but it’s up to you).
7. Monitor via Singular and Meta: Singular will be your source of truth for total revenue. Compare that with Meta’s reported revenue. They should be close. If there’s a discrepancy, one possible cause is that Singular might send only events for click-through attributions, not view-through (depending on settings). If a user was view-through attributed, make sure you enabled View-through attribution for Facebook in Singular and sending those events as well​. Also, check if re-engagements are being tracked; usually for user acquisition, you just focus on installs.

   In Ads Manager, ensure you see conversion values populating. If not, double-check that events are indeed being sent. Possibly reach out to Singular if something seems off – since this Meta integration is relatively new, their support might provide guidance if needed.

8. Adjust as needed: If you see that events aren’t being counted, one trick: you might temporarily map ADMON_USER_LEVEL_REVENUE to fb_mobile_purchase as well (for iOS or just for testing) to see if they show up as purchase events. But since we want AdImpression, stick to that for Android.

By completing these steps, you have effectively enabled Meta to optimize based on ad revenue data via Singular. The heavy lifting (event aggregation from different ad sources) is handled by Singular, and you just configure the pipeline to Meta. One benefit here: if you’re using Singular for many networks, you get a unified view of ad revenue across them, and all that is sent to Meta as one event type. This simplifies the Meta side – you don’t need to worry which network the revenue came from; Meta just sees “this user generated X revenue.”

Singular-specific notes:

• Singular’s event name __ADMON_USER_LEVEL_REVENUE__ is a special internal event that automatically collects all ad revenue from various sources. Make sure you’re not also manually logging separate events for each network, or if you are, don’t double map them. Usually, you’d just use the one unified event.
• Ensure your Partner Configuration in Singular for Facebook has the “Include revenue” toggled. According to their doc snippet, it says to check “Include Revenue Value” when mapping to AdImpression​. Missing that would result in sending the event without a value.
• If your app also has IAP, you might have mapped purchase events too (like they suggested mapping iap to purchase)​. That’s fine. Meta can receive both purchase and AdImpression events from Singular. But your campaign will be optimizing for one. The other event might just show up in analytics. It won’t confuse the optimization because the ad set is locked to one type of event for optimization.

Now that we have covered all major platforms:

Each of these integration methods – Meta SDK, AppsFlyer, Adjust, Singular – achieves the same end goal: Meta receives AdImpression events with revenue from your app, enabling Ad ROAS optimization. Choose the one that fits your tech stack best. If you already use an MMP, leverage it; if not, the Meta SDK is perfectly viable.