Unity Ads ROAS Campaigns Now Need Revenue Events: What iGaming Teams Must Fix

In early October Unity changed the rules for launching ROAS campaigns. A new campaign will not start until the source receives purchase events with a revenue amount attached. For an app owner that is one checkbox in the MMP. For a media buyer running traffic to a rented app, it is a conversation with whoever controls the data, plus a few days of waiting.

What Changed and Why

Before, a ROAS campaign could go live even when value data was incomplete or missing altogether. Now Unity first checks that purchase events with revenue are coming in, and only then lets the campaign into the auction. The platform's reasoning is simple: an algorithm that sees real money gets better at finding people who pay.

Why This Matters More in Gambling Than It Seems

In iGaming a "purchase" is a deposit, and deposits vary a lot. One player tops up $10, another $150, and for a ROAS model those are two different audiences. Without the amount, the algorithm only sees that a payment happened and cannot favour the people who pay more.

Two conclusions follow:

• Registration no longer works as a ROAS signal. It is fine for early tests, but a campaign optimising for payback simply will not launch without a deposit that carries an amount.
• For iGaming the revenue source is always IAP. A casino app earns from deposits, not from ads shown inside it. Ad Revenue and Hybrid modes are built for games, not gambling, however hard the platform promotes them.

If the App Is Rented, You Do Not Own the Signal

Most affiliate teams in in-app do not have their own apps. Development is expensive, and a store can ban an app on any given day. So teams rent apps and get a ready MMP SDK with postbacks already set up as part of the deal. We covered how that setup fits into a Unity launch in our Unity Ads guide for iGaming.

The downside of renting is that the buyer has no access to the AppsFlyer or Adjust dashboard. Event setup, amounts, currency and which partners receive the data all sit with the provider. The provider will configure all of it, but only on request. Responsibility for checking still lies with the buyer: "the provider said everything works" proves nothing. Only events showing up in a report do.

The Revenue Signal Check: Five Questions for Your App Provider

Ask these before the campaign is queued for launch. Each answer should be specific, not "everything is set up".

1. Which event goes to Unity as a purchase? The first deposit or every deposit? That decides what the algorithm actually optimises for and how you should read ROAS.
2. Is the amount passed, and in which currency? If the provider cannot send the exact deposit amount, Unity accepts a static value. In that case you need to know the number, or the ROAS in your account means nothing.
3. Are in-app events enabled for the Unity partner specifically? It happens that installs are shared but events are not, and the campaign stalls at the check for no obvious reason.
4. How are test deposits kept out? A test payment with an amount that slips into the stream teaches the algorithm to look for a player who does not exist.
5. Can you see proof? Ask for an event export from day one or a screenshot of the partner settings. Add your own test registrations and a test deposit through your tracker.

Three Clocks to Build Into Your Launch Plan

Launches fail more often because of timing than because of wrong settings. Between "we are launching" and "we can draw conclusions", three clocks run in parallel:

• The provider's clock. Every change on the app side (an event, an amount, an export) takes one to two days of back and forth. Anything that needs the provider should be done before the deadline, not on launch day.
• Unity's clock. The platform checks the integration roughly once a day. Turn on event sharing today and the campaign starts tomorrow at the earliest. One more detail that is easy to miss: the campaign needs at least one approved, active creative pack. Removing a rejected pack is not enough if all the others are paused.
• The postback clock. Deposits reach the source with a delay of up to three days. Judging a campaign on day two is premature because the numbers have not matured yet. For fast decisions, look at the provider's export or your own tracker rather than the Unity dashboard.

Add the three clocks together and an honest verdict on a campaign is possible no earlier than three to four days after launch. A team that plans for this in advance does not kill a working setup because day one looked empty.

The Bottom Line

Unity's new rule moves control to wherever the revenue data lives. Renting an app buys you a fast start, and the price is part of your control over the signal. You get that control back with the right questions to the provider and a realistic timeline. Teams that verify the signal before launch get an algorithm hunting for payers from day one. Teams that do not lose a week on a campaign that never started, or on conclusions drawn from numbers that were not ready.

We launch Unity campaigns on rented apps every day and teach the full in-app flow, from the first questions to the provider to reading the first week of data. If you are moving into in-app, get in touch and we will look at your setup.