EmCube
Home/Case Studies/Consumer App · SKAN Revenue Signal Fixed
CASE STUDY

How a consumer app fixed a broken revenue signal before a single ad campaign ever used it

Seven different events all reported revenue, and the SKAN buckets were too wide to tell purchases apart. Both fixed before the first campaign launched.

7 Events
reporting revenue
Skan 4.0
Revenue ranges Optimized
1 week
to fix all of these
ENGAGEMENT:Consumer AppAppsFlyerSKAN 4.0Revenue Signal Audit
THE SITUATION

Seven different events were all reporting revenue. Almost none of it could be trusted.

This consumer app had AppsFlyer and SKAN already in place, and was preparing to launch its first paid campaign on a Meta ads. Before that campaign went live, the team wanted the revenue signal checked. Not because anything looked broken, but because nobody had verified it end to end.

The review found two separate problems, both invisible from the dashboard, both quietly distorting what the Meta campaigns would have seen from day one.

WHAT THEY CAME WITH
AppsFlyer and SKAN already in place, ahead of a first paid campaign
Seven separate events all independently reporting revenue to the ad platform
SKAN revenue buckets so wide that most real purchases fell into a single bucket
THE GOAL

Make sure the revenue signal reaching the ad platform was accurate and differentiated, before the first dollar of paid spend went out.

WHAT WE FOUND

Two ways a revenue signal can lie, both happening at once.

Neither of these would show up as an error. Both would just quietly feed the ad platform the wrong picture.

FINDING 01
SEVEN EVENTS, ALL REPORTING THE SAME REVENUE

A code review found seven distinct events all independently flagging revenue back to the Appsflyer. When several of them fired on the same transaction, that one sale could be counted multiple times over.

IMPACT: Reported revenue was inflated in a way that looked exactly like real performance
FINDING 02
SKAN REVENUE BUCKETS TOO WIDE TO DIFFERENTIATE ANYTHING

The SKAN conversion value ranges were set wide enough that the large majority of real purchases landed in a single bucket. SKAN's entire value to an ad platform's optimization depends on telling a high-value purchase apart from a low-value one. If most transactions report the same value, there's nothing left for the algorithm to learn from.

IMPACT: The ad platform had no way to tell a high-value customer from a low-value one
SCREENSHOTBefore · Revenue reporting across multiple events
hq.appsflyer.com · LTV revenue by media source
REVENUE FIGURES BLURRED
Before · Revenue reporting across multiple events
Fig. 1. Seven separate events, each independently reporting revenue for the same transactions.
SCREENSHOTBefore · SKAN conversion value ranges
hq.appsflyer.com · SKAN Conversion Studio
Before · SKAN conversion value ranges
Fig. 2. Revenue buckets configured in wide, arbitrary ranges rather than around actual purchase distribution.
SCREENSHOTBefore · Revenue bucket concentration
hq.appsflyer.com · Revenue range analysis
Before · Revenue bucket concentration
Fig. 3. More than half of all paying users landed in a single bucket, leaving the ad platform almost nothing to differentiate.
HOW WE FIXED IT

Two fixes. One trustworthy revenue signal, before the campaign went live.

Neither fix required new infrastructure. Both were corrections to what was already reporting, made before any ad spend depended on it.

01
REVENUE EVENT CONSOLIDATION
Seven overlapping events reduced to one clean signal.

Reviewed the codebase to identify every event triggering a revenue report, then worked with the team to designate a single, clean event as the source of truth for revenue passed to the ad platform.

02
SKAN REVENUE BUCKET REBUILD
Conversion value ranges rebuilt around actual purchase distribution.

Reconfigured the SKAN revenue ranges so they reflect how real purchases are actually distributed, rather than arbitrary round-number bands, giving the ad platform enough resolution to tell a high-value purchase from a low-value one.

SCREENSHOTAfter · Revenue bucket distribution, rebuilt
hq.appsflyer.com · Revenue range analysis
After · Revenue bucket distribution, rebuilt
Fig. 4. Purchases now spread across seven distinct buckets, giving the ad platform real signal to optimize against.
THE OUTCOME

What was true before a single ad ever ran.

No campaign had launched yet, so this isn't a performance story. It's a readiness one: the signal was fixed before anything depended on it being right.

REVENUE SIGNAL
Consolidated
one trustworthy event, not seven overlapping ones
SKAN REVENUE RANGES
Rebuilt
purchases differentiated instead of collapsed into one range
FIRST CAMPAIGN
Launched clean
on a revenue signal that had already been fixed
THE REAL IMPACT

The campaign hadn't launched yet, which meant there was still time to fix this before it mattered. A revenue signal that overcounts and under-differentiates doesn't just report badly, it teaches the ad platform's algorithm the wrong lesson from the very first dollar spent.

Fixed
before a single dollar of paid spend depended on the signal being right
LAUNCHING A NEW CAMPAIGN SOON?

If your revenue signal has never been checked before the first campaign goes live, this is exactly the moment to check it.

No commitment. Just a clear read on whether what you're about to feed an ad platform is actually true. Because the signal you feed an ad platform on day one is the one it optimizes against for months.

Get My Revenue Signal Right