Mobile Ad Revenue Stagnation: A Diagnostic Checklist

Mobile ad revenue stagnation has ten structurally different root causes. In priority order: demand-side failures (network paused, account flagged), supply chain drift (app-ads.txt, sellers.json), mediation SDK or adapter version lag, floor or waterfall calibration decay, ATT prompt rate decline, demand mix shift, seasonal softness, geographic cohort changes, policy or eligibility changes, and reporting attribution drift. Most cases resolve at step 1, 2, or 3. Working through this list in order is faster than diagnosing by intuition.

Before you start: what stagnation actually looks like in your data

Not every flat revenue period is worth a full diagnostic. The first step is confirming you are looking at a real signal before you start changing things.

Four criteria. All four should hold before you commit time to the full checklist.

Duration: 14 or more consecutive days. Short-term variance from weekend traffic patterns, incomplete reporting windows, or single-network fill fluctuations is normal. Three to five days of flat revenue is noise until proven otherwise. Fourteen days is the threshold worth taking seriously.

Traffic baseline is stable. Pull your daily active users, sessions, or impressions served. If traffic and revenue dropped proportionally, you are looking at a traffic problem, not a monetization problem, and this checklist is the wrong tool. Confirm sessions, DAU, and impressions served are holding before proceeding.

The decline is in eCPM, fill rate, or both, not in impressions. Pull your mediation dashboard and confirm what changed. Stable impressions with declining revenue means the monetization layer is the issue. Declining impressions means the traffic layer is the issue.

The period does not include a known external event. January 1 through mid-February is always lower CPM than Q4. If the stagnation window includes the Q1 demand reset, confirm the decline is materially larger than expected seasonal softness before diagnosing. Year-over-year comparison works better than month-over-month for this check.

How to read the baseline in your mediation platform:

AdMob: Reports > Ad unit report. Filter by date range, segment by ad unit. Look at estimated earnings, eCPM, match rate, and impressions. A flat or declining eCPM with stable impressions is the entry condition for this checklist.
AppLovin MAX: Dashboard > Analytics. Filter by ad unit and geo. Look at eCPM, fill rate, and revenue together. eCPM dropping while fill rate is stable points to demand-side or floor issues. Fill rate dropping while eCPM is stable points to supply chain or SDK issues.
Unity LevelPlay: Monetization > Analytics. Separate the revenue-per-impression signal from the impressions-served signal before diagnosing.

Once you have confirmed genuine stagnation (14-plus days, stable traffic, eCPM or fill rate down, no obvious external event), work through the diagnostics below in order. Stop as soon as you find the cause. Most operators find the cause in steps 1 through 4.

If you are not sure whether you are looking at genuine stagnation or normal variance, that distinction is the right starting point for the free call. Bring the last 30 days of mediation data and we can confirm it in the first 10 minutes. Book at /contact.

Diagnostic 1: Demand-side failures (paused networks, flagged accounts, rejected campaigns)

This is the most common cause. Check it first because it takes the least time to rule out and resolves immediately when found.

What to check:

Log into every demand partner's publisher-facing dashboard directly. Not your mediation aggregated view. Mediation reports lag real-time network status and will not show you that a network has silently paused fill.

Check in this order:

Account status. Is the account active, flagged, or under review? Look for policy flags, payment holds, and invalid activity notices. Flagged accounts reduce fill rate silently. They do not always produce an error in the mediation report.
Campaign status. Are active campaigns filling your inventory? Some networks run campaign-level fill. Budget exhaustion or a targeting mismatch can look like a network-level fill drop from the mediation side.
AdX rejection signals (for publishers with GAM/AdX access). Pull your AdX auction report and check for increased rejection rates at the impression level. Common rejection reasons: policy violation flags, seller identity mismatches from a recent sellers.json update, or account-level policy holds.

What the signal looks like if this is your problem:

In your mediation report, one or more specific networks show a fill rate drop to near-zero while others are unchanged. In the network's own dashboard, you find an account notification, policy hold, or campaign-level status showing inactive.

One thing to watch for: eCPM from the remaining networks may actually increase slightly as they fill a larger share of inventory. Do not read that as a positive signal. It means floor competition dropped.

The fix:

Respond to the network's policy notification directly. Payment holds usually resolve after updating billing information. Campaign budget exhaustion resolves when the budget cycle resets, or by contacting your rep to request a new campaign targeting your inventory.

For AdX rejection issues: pull the AdX diagnostics report in GAM and address the specific rejection reason. If the rejection is tied to a sellers.json mismatch, Diagnostic 2 covers it.

Exit condition:

If all network accounts are active, no flags exist, and fill rates per network are within normal range, move to Diagnostic 2.

Diagnostic 2: Supply chain drift (app-ads.txt, sellers.json, ads.txt mismatches)

Supply chain files are the most quietly destructive cause of fill loss. They break slowly, often triggered by a network rebranding, changing their seller ID, or the operator pushing an app update without reviewing the supply chain files. Most operators check them at launch and do not look again.

What to check:

app-ads.txt. Fetch your current app-ads.txt from its hosted URL (typically yourdomain.com/app-ads.txt). Compare every line against the current authorized sellers lists from each network you are running. Networks update their seller IDs, domain names, and certification types. A line that was correct 12 months ago may now mismatch.
sellers.json. Confirm you are listed correctly as a seller in each network's sellers.json file. If a network updated their sellers.json and changed your entry (different seller ID, changed to confidential, or removed entirely), buyers running SPO filters will skip your inventory without any visible error in your mediation report.
ads.txt (if running web inventory alongside the app). Same pattern. If you have a companion web property, confirm ads.txt is current and matches your authorized sellers.
Run the AdMob Approval Checker to surface app-ads.txt errors against AdMob's current seller ID list before doing manual checks.

Full implementation and maintenance process: app-ads.txt Enforcement and Implementation.

What the signal looks like if this is your problem:

Fill rate drops across multiple networks simultaneously, not just one. (If only one network dropped, Diagnostic 1 is more likely.) The drop often corresponds to an app update, a domain change, or the onboarding of a new network. eCPM may be stable or slightly up because the buyers who remain are the ones whose supply path checks passed.

The fix:

Update app-ads.txt to match the current authorized seller records from every active network. Do not delete old lines without confirming the network is no longer active. Removing a line while the network is still filling inventory will cut that network's authorized fill immediately.

For sellers.json mismatches: contact the network directly to update your seller record. This typically requires a support ticket and takes 24-72 hours to propagate.

Exit condition:

If app-ads.txt is clean, sellers.json entries are correct, and supply chain files match current network records, move to Diagnostic 3.

Diagnostic 3: Mediation SDK and adapter version drift

SDK and adapter version drift is the silent revenue problem that most operators do not check until something visibly breaks. A network may release a new adapter version that changes auction participation, fill logic, or bid eligibility. If your adapter version is not current, you are running against a version the network no longer prioritizes, and they will not send you a notice about it.

What to check:

In your mediation platform (MAX, AdMob, LevelPlay), pull the current SDK and adapter version for each active demand partner. Compare against the network's current published adapter version.
Look specifically for adapters that are two or more versions behind the current release. One version behind is common and generally tolerable. Two or more versions behind can mean missing auction eligibility updates, bidding protocol changes, or format support for ad unit types the network's buyers are targeting.
Check the mediation SDK itself. Mediation platform SDK updates often include changes to the auction orchestration layer, signal passing to demand partners, and impression attribution. A stale mediation SDK can reduce bid quality across all demand partners simultaneously.
Run the Mediation SDK Checker to surface version mismatches across your adapter stack before doing the manual review.

Full version compatibility matrices and update procedures: Mediation SDK & Adapter Compatibility Guide.

What the signal looks like if this is your problem:

Revenue decline is distributed across multiple networks, not concentrated in one. (Single-network drops point back to Diagnostics 1 or 2.) The stagnation started around the same time as an app release where you did not update the mediation SDK or adapters. Bid rates in MAX analytics are declining for multiple demand partners at the same time.

The fix:

Update the mediation SDK to the current stable release. Update adapters for all active demand partners to their current stable release. Test in a staging build before pushing to production. Note: adapter updates occasionally break a specific format integration. Test rewarded, interstitial, and banner fill rates after updating before going wide.

Exit condition:

If SDK and adapter versions are current and bid rates are stable across demand partners, move to Diagnostic 4.

Diagnostic 4: Floor and waterfall calibration decay

Floors decay. A floor that was correctly calibrated six months ago against the market is now probably wrong in at least two directions: too high for some geos (causing fill loss) and too low for others (leaving revenue on the table). Market eCPMs shift seasonally, network budget cycles change, and the competitive auction environment evolves. Floors do not update themselves.

What to check:

Last calibration date. When did you last review and update your floor prices? If the answer is more than 90 days ago, floor decay is a candidate regardless of what your current metrics show.
Fill rate vs eCPM relationship. In your mediation dashboard, look at fill rate and eCPM together by geo over the stagnation period. If fill rate is declining while eCPM is flat or increasing, your floor may be too high for current market conditions. Bids are arriving but not clearing the floor, and you are losing impressions rather than monetizing them at a lower rate. If fill rate is stable and eCPM is declining, floors may be too low and the market is not competing to fill impressions at the floor price.
Waterfall tier ordering. If you are running a waterfall (or hybrid waterfall/bidding), pull the current tier structure. Are the CPM tiers at the right intervals? Are there networks in the waterfall that have not filled an impression in 30 days? Stale waterfall tiers with dead demand sources slow fill and distort eCPM reporting.
Bidding floor settings. If you are running in-app bidding, confirm your bidding floor is set at or above your waterfall's top tier for each geo. A bidding floor below the waterfall's top tier means you are accepting bids at prices below what the waterfall would have captured.

Full calibration framework: Mediation Waterfall vs In-App Bidding.

What the signal looks like if this is your problem:

Fill rate declining across multiple ad units in specific geos. eCPM reporting stable or slightly up while total revenue declines. The stagnation period corresponds to a seasonal transition. The Q4-to-Q1 pattern is the most common trigger: floors calibrated against peak Q4 demand are too high for Q1 market rates.

The fix:

Recalibrate floors using the last 30 days of per-geo eCPM data. Set floors at 85-90% of the 30-day average eCPM per geo, not at the peak eCPM. Re-order the waterfall to remove dead demand tiers and adjust network positions to reflect current fill rates. For bidding, adjust floor prices to match current market clearing prices.

Floor calibration and waterfall tuning are the two areas where a structured outside review most consistently finds recoverable revenue. If floors have not been reviewed in 90 days, the free call is the fastest way to confirm whether that is the source of your stagnation. Book at /contact.

Exit condition:

If floors are current, the waterfall has no dead tiers, and bidding floors are correctly set, move to Diagnostic 5.

Diagnostic 5: Privacy signal degradation (ATT prompt rate, SKAN reporting cliff)

This diagnostic is specific to iOS. If your app is primarily Android, you can skip it. If you have meaningful iOS traffic, check it. ATT prompt rate degradation is invisible in your mediation report and produces symptoms that look identical to demand-side problems from the outside.

What to check:

ATT opt-in rate. Pull your ATT consent data from your analytics platform or your MMP (AppsFlyer, Adjust, Branch). What percentage of iOS users are granting App Tracking Transparency consent? If this rate has dropped more than 5 percentage points from your historical baseline, your addressable demand has shrunk. Buyers who require consent for targeting will not bid on non-consented inventory, or will bid at materially lower CPMs.
ATT prompt display rate. A less obvious failure mode: your ATT prompt is not displaying consistently. This can happen after an iOS update changes the prompt timing requirements, or after an app update where the ATT prompt flow was accidentally broken. If the prompt is not displaying, users are neither granting nor denying consent. Most networks treat that ambiguous state as non-consented.
SKAN reporting completeness. Pull your SKAdNetwork postback volume from your MMP. If postback volume has dropped relative to install volume, buyers relying on SKAN signals for conversion optimization will have degraded model calibration and will bid less aggressively on your inventory. This is a slow-moving effect that compounds over time.
iOS vs Android revenue split. Compare iOS vs Android eCPM trends over the stagnation period. If iOS eCPM is declining while Android is flat, ATT-related signal degradation is the likely candidate.

Full SKAN 4 implementation reference: SKAdNetwork 4.0 Conversion Value Setup.

What the signal looks like if this is your problem:

An iOS-specific eCPM decline that does not appear in Android data for the same app or the same period. ATT opt-in rate below 35% (the rough market average for iOS apps in 2026 running a standard system prompt without a pre-permission screen). SKAN postback volume dropping relative to install volume.

The fix:

For low ATT opt-in rates: implement or improve a pre-permission screen that explains the value exchange before the system prompt fires. Apple permits this, and a well-designed pre-permission screen typically improves opt-in rates by 8-15 percentage points.

For broken ATT prompts: audit your ATT implementation in the current app version. Confirm the prompt is firing at the correct lifecycle point and that the consent status is being passed correctly to your mediation SDK.

For SKAN postback issues: confirm your SKAdNetwork implementation is current for your active networks' SKAN IDs.

Exit condition:

If ATT opt-in rate is stable, the prompt is displaying correctly, and SKAN postback volume is proportional, move to Diagnostic 6.

Diagnostic 6: Demand mix shift (one network changed its auction model)

Networks change their auction participation model without announcement. A network that was competing aggressively in open auction last quarter may have shifted budget toward direct deals, changed targeting parameters, or moved to a bidding-only model that your current waterfall position does not access. From your mediation report, this looks like a single-network fill rate or eCPM decline. From the network's side, it is a deliberate product decision.

What to check:

Per-network eCPM and fill rate over 90 days. In your mediation platform, segment revenue, eCPM, and fill rate by demand partner over a 90-day window, not just the current period. A gradual decline over 60-90 days on a specific network usually means the network shifted budget or targeting. A sharp drop in the last 14 days usually points back to Diagnostics 1 through 3.
Has the network moved to bidding-only? Meta Audience Network, AppLovin, Mintegral, and IronSource/LevelPlay have all materially shifted their primary demand toward in-app bidding. If one of these networks is in your waterfall as a static CPM instance rather than a bidding group, you are accessing their secondary demand pool. Pull the network's current publisher documentation and check whether their primary fill model has changed.
Direct deal migration. Some networks run promotional periods of open auction fill and then shift to direct deals when campaign budgets are exhausted. A strong Q4 campaign window followed by a return to the lower-budget open auction baseline looks like a demand drop. It is a normal demand cycle.

Network-specific bidding configurations: AdMob Mediation vs AppLovin MAX.

What the signal looks like if this is your problem:

One specific network's contribution to total revenue has declined disproportionately, but other networks are stable. The declining network is one that has publicly moved toward bidding (Meta, AppLovin, Mintegral) and it is configured as a waterfall instance, not a bidding source. Your network rep has mentioned product changes.

The fix:

If the network has moved to bidding: add them as a bidding source in your mediation group. If you are on AdMob mediation, use their bidding adapter. If you are on MAX, confirm the network is in your bidding group at the ad unit level.

If the shift is a direct deal cycle: discuss upcoming direct deal inventory with the network rep. Networks often run campaigns for specific verticals or seasonal windows and return to open auction fill in between.

Exit condition:

If demand mix across all networks is proportionally stable and no network has recently changed its auction model, move to Diagnostic 7.

Diagnostic 7: Seasonal and market-level demand softness

This is the diagnostic that most operators underweight. Mobile advertising demand follows a predictable seasonal cycle driven by advertiser budget calendars, not publisher traffic. Q4 (October through December) is the strongest demand period globally. Q1 (January through mid-February) is the weakest. Q3 has a secondary dip. These patterns are real, they are large, and they are independent of anything the operator is doing.

What to check:

Year-over-year comparison. Pull revenue, eCPM, and fill rate for the same 14-day window in the prior year. If the current decline matches the prior-year decline in the same calendar window, you are looking at seasonal softness. This is the fastest ruling-in test for this category.
Vertical-specific demand cycles. Advertising demand varies by app vertical. Gaming apps typically see stronger Q1 demand from gaming-related advertisers than general consumer apps. Finance and tax apps see Q1 demand spikes. Shopping and retail apps see Q4 spikes. Confirm whether the current period corresponds to a known soft window for your specific vertical.
Industry data reference. In Q4 2024, US digital ad spend reached $34 billion, a 9% year-over-year increase (SensorTower Digital Market Index, Q4 2024). The Q1 reset from that peak is structurally significant. A 10-15% revenue decline from December to January is within normal seasonal range and does not require a stack change.
Platform-specific budget cycles. AppLovin, Meta, and Google all have quarterly budget cycles that affect fill rate and eCPM in early January, early April, and early July.

What the signal looks like if this is your problem:

Revenue decline matches the prior-year seasonal pattern in the same calendar window. eCPM declining proportionally across most networks simultaneously, not just one. DAU and traffic are stable or growing. The stagnation window is 2-8 weeks, not ongoing.

The fix:

Nothing to change structurally. Seasonal demand softness is not a stack problem. The correct response is to confirm the diagnosis accurately, hold floor prices at the seasonally appropriate level (not the Q4 peak level), and use the quiet period to run the remaining diagnostics and address any structural issues before demand returns.

If the YoY comparison comes back flat or down, the seasonal pattern is not the full explanation and at least one of the other diagnostics is contributing.

Exit condition:

If the stagnation does not match prior-year seasonal patterns and is not within the expected magnitude of seasonal softness, move to Diagnostic 8.

Diagnostic 8: Traffic mix shift (geo or cohort composition changed)

Your eCPM is an average. If the composition of traffic generating that average has shifted toward lower-eCPM geographies or lower-LTV user cohorts, average eCPM will decline even if nothing in the monetization stack changed. The stack is working correctly. The input changed.

What to check:

Geo mix over 90 days. In your analytics platform (Firebase, AppsFlyer, or similar), pull the daily breakdown of sessions or active users by country over the stagnation period. Compare current geo distribution to the 90-day prior period. If US or Tier-1 geo share dropped by more than 5 percentage points while total traffic held, lower-eCPM geographies grew their share. This will reduce average eCPM with no stack change.
Organic vs paid traffic composition. If you are running user acquisition campaigns, check whether the campaign targeting changed. Campaigns that expanded to lower-CPI geos to reduce acquisition costs will bring in users with lower ad monetization potential. The eCPM drop follows the acquisition cohort with a 30-60 day lag.
App store feature or ranking change. If your app received an App Store or Google Play editorial feature in a non-Tier-1 market, the install volume from that feature will carry a materially different eCPM profile. Cross-reference your install data with any store editorial placements.
Session depth and retention. If a recent app update increased install volume but reduced session depth or D7/D30 retention, the impressions-per-user metric may be declining even if DAU is stable. Pull impressions per DAU, not just total impressions.

What the signal looks like if this is your problem:

Average eCPM declining while per-geo eCPMs are stable (the mix changed, not the per-geo rates). Tier-2 or Tier-3 geo share increasing in your install or session data. A specific acquisition campaign recently launched or scaled in a new geo.

The fix:

There is no stack fix for a geo mix shift. The stack is working correctly for each geo. The structural response is either to recalibrate floor prices for the growing geos (if they were set for Tier-1 rates, they need adjustment for Tier-2 market rates), or to address the acquisition targeting if the geo shift was unintentional.

If the geo mix shift was intentional, update your floor calibration to reflect the new distribution and adjust your reporting benchmarks accordingly. Comparing current average eCPM to prior-period average eCPM is a misleading benchmark when the geo mix changed.

Exit condition:

If geo distribution is stable and cohort composition has not changed, move to Diagnostic 9.

Diagnostic 9: App store or policy changes (impression eligibility narrowed)

App store policy updates and ad network policy changes can narrow impression eligibility without producing visible error messages in your mediation report. The most common pattern: a network policy update expands the definition of non-compliant ad placement, and a subset of your impressions that were previously filling now return no-fill or are excluded from monetization without any notification.

What to check:

App Store / Play Store recent policy changes. Review the App Store Review Guidelines and Google Play Ad Policy changelogs for any updates in the 60-day period preceding your stagnation window. Areas to check: content policies that affect ad placement eligibility (ads near child-directed content, apps that received content rating changes), placement guidelines (ad density limits, proximity to interactive elements), and SDK requirement updates that affect minimum version eligibility.
Network policy notifications. Log into each network's publisher portal and check the policy notification center, not just the dashboard metrics. AdMob, Meta, AppLovin, and LevelPlay all have separate policy notification sections that do not appear in the main revenue dashboard.
App content rating change. If you recently changed your app's content rating, or if the store re-rated your app during a policy review, the eligible demand pool may have narrowed. Apps with child-directed content flags are excluded from interest-based targeting by most demand sources.
New ad format policy. If you launched a new ad format around the time stagnation began, confirm the implementation meets current placement guidelines for each network. Google has specific interstitial placement rules (timing, frequency caps, user flow) that, when violated, reduce demand eligibility for the affected ad unit.

For ad placement compliance context: Balancing Ad Revenue and User Experience on Mobile Apps.

What the signal looks like if this is your problem:

A specific ad unit or ad format showing fill rate decline while others are stable. A policy notification in the network's publisher portal that correlates with the stagnation window. An app content rating change or store review notice in the 60 days prior to stagnation.

The fix:

Address the specific policy violation or eligibility issue identified. For content rating issues: do not reclassify your app's content to work around the policy. Address the underlying content or placement issue.

For SDK requirement updates: update the network SDK to the version that meets the current eligibility requirements.

Exit condition:

If no policy notifications exist, the app content rating is unchanged, and ad placement implementations meet current guidelines for all active formats, move to Diagnostic 10.

Diagnostic 10: Reporting attribution issues (revenue is fine, just not where you expect it)

The last diagnostic is not a stack problem. It is a measurement problem. Revenue is being generated but it is not appearing in the dashboard you are checking, or it is attributed to a different period, source, or segment than where you are looking.

What to check:

Reporting lag. Most ad networks report revenue with a 24-72 hour lag. AdMob's estimated earnings update throughout the day but finalize 24 hours after the day closes. Meta's reporting can lag 72 hours. If you are comparing today's revenue to last week's same-day revenue, you are comparing a preliminary estimate against a finalized number. Always compare finalized periods (more than 72 hours ago) to each other.
Currency and payment cycle. If you operate across multiple currencies or if a network changed their reporting currency, what looks like a revenue decline may be a currency conversion artifact. Check whether reporting currency changed for any active network.
Mediation platform data source. If you recently changed mediation platforms or added a new one alongside an existing platform, impressions may now be attributed to the new platform while revenue from those impressions is still being reported through the old platform's attribution. The aggregate looks flat because both platforms are showing partial revenue.
Third-party vs platform-reported discrepancy. If you are comparing MMP-reported revenue to revenue reported directly by the network, expect a 5-15% discrepancy. That is normal. If the discrepancy suddenly widened, check whether SDK-to-SDK attribution is correctly configured after a recent update.
Revenue reclassification. Some networks reclassify revenue retroactively after invalid traffic audits. A revenue drop that appears suddenly on a historical period (not on today's data) is almost always an IVT reclassification, not a current stagnation problem.

What the signal looks like if this is your problem:

Revenue is down in your mediation aggregated view but not in individual network dashboards. Revenue is down for the current period but finalized revenue from seven days ago looks normal. A specific network's reported revenue in your mediation platform does not match what that network reports in its own dashboard.

The fix:

For lag issues: use finalized periods only for trend comparison. Set a reporting calendar convention and hold to it (compare week-over-week at the same reporting cutoff).

For discrepancies: contact mediation platform support to confirm whether the data pipeline for the affected network is functioning correctly. SDK-to-SDK integrations can have connection issues that cause revenue to appear in one platform but not the other.

If you have checked all 10 and still cannot find it

Some revenue stagnation causes survive all 10 diagnostics. They are real, they are not uncommon, and they share a common feature: they require a view you cannot build from inside your own stack.

The patterns that most reliably reach step 10 without a clean finding:

Multi-cause interactions. Two or three of the diagnostics each show a minor issue that individually seems within tolerance. Together, they account for a 15-20% revenue decline. Operators working through each diagnostic in isolation tend to rule each one out as "probably fine" and miss the compounding effect. Holding all 10 signals in view simultaneously is not easy to do from inside your own dashboard.

Demand-side confidential changes. Some demand-side changes are not disclosed in publisher-facing documentation. A network may have deprioritized your app's inventory category without publishing a policy notice. The signal looks like a demand-side problem (Diagnostic 1) but the account is active and no flag exists.

Stack architecture problems that require an external comparison point. Your waterfall or bidding configuration may be underperforming not because anything is broken, but because the architecture is suboptimal relative to what is available for your app size, geo mix, and demand profile. You cannot diagnose a suboptimal architecture from within the architecture.

Floor decay compounded with seasonal shift. A floor that was always slightly wrong and a seasonal dip that would have been manageable individually are both below the diagnostic threshold on their own. Together, they create a stagnation that does not point clearly to either cause.

These are not edge cases. If you have worked through all 10 diagnostics, given each one a clean ruling rather than a quick scan, and still cannot locate the cause, the problem is not that the cause does not exist. It is that the cause requires a view you do not currently have.

That is exactly what the free 30-minute call covers. Bring the data from the 10 diagnostics above: mediation report exports, per-network fill rate and eCPM trends, app-ads.txt, SDK version list, ATT consent rate, geo distribution. The call is a working session, not a sales pitch. If there is nothing to find, you will hear that directly.

Book the free 30-minute call

Frequently Asked Questions

Why is my mobile app's ad revenue flat?

The most common causes, in priority order: a demand partner account has been flagged or paused (check each network's dashboard directly, not just the mediation aggregated view), app-ads.txt or sellers.json drift has reduced authorized fill (check supply chain files against current network seller IDs), an SDK or adapter version is too far behind to participate in current auctions, or floor and waterfall prices have not been recalibrated and no longer match market rates. Work through these four before investigating less common causes like privacy signal degradation, demand mix shifts, or traffic composition changes.

What is the most common cause of mobile ad revenue stagnation?

Demand-side failures are the most common cause and the fastest to check: a paused account, a policy flag, or a campaign that exhausted its budget. The second most common is supply chain drift where app-ads.txt or sellers.json no longer accurately reflects the current authorized seller list for one or more networks. Both are invisible in the mediation aggregated view, which is why operators frequently miss them. Log into each network's own dashboard and check account status directly. Pull app-ads.txt from the hosted URL and compare each line against the network's current authorized seller records.

How do I check if my floors are too high?

Pull fill rate and eCPM together by geo in your mediation dashboard. If fill rate is declining while eCPM is flat or increasing, your floor is likely above what the current market will clear. Bids are arriving but not meeting the floor price, and you are losing impressions rather than monetizing them at a lower rate. Compare your current floor prices to the 30-day average eCPM per geo. If your floor is above 90% of the average eCPM for a given geo, it is likely cutting fill. Reset floors to 85-90% of the 30-day average eCPM and monitor fill rate recovery over 7 days.

Could an SDK version mismatch be causing my revenue drop?

Yes, and it is more common than most operators expect. Demand networks update their SDK and adapter versions to include new auction eligibility rules, bidding protocol changes, and ad format support. An adapter that is two or more versions behind the current release may be excluded from certain campaign types or auction formats without any visible error in the mediation report. The fill rate for that specific network will decline, often gradually. Use your mediation platform's SDK integration status or the sdk-checker tool at monetizationguy.com to compare your current adapter versions against each network's latest stable release.

Is my mobile ad revenue dropping because of seasonal demand?

Possibly. Mobile advertising demand follows a predictable annual cycle: Q4 (October through December) is peak demand, Q1 (January through mid-February) is the lowest, with Q3 a secondary soft period. A 10-15% revenue decline from December to January is within normal seasonal range. To confirm: compare eCPM for the current period to the same period in the prior year, not to Q4. If the year-over-year comparison is flat or positive, you are seeing seasonal softness, not structural stagnation. If year-over-year is also down, the seasonal pattern is not the full explanation and one of the other diagnostics is contributing.

When should I move from self-diagnosis to getting outside help?

When you have worked through the full 10-step diagnostic, given each step a clean ruling rather than a quick scan, and still cannot identify the cause with confidence. The patterns that most reliably survive self-diagnosis: multiple minor issues that are each below the threshold for concern but compound together to a 15-20% revenue decline, demand-side changes that were not disclosed in network documentation, and architecture problems that require an external comparison point to identify. At that point, the issue is not that something obvious is being missed. It is that the cause requires a view that cannot be built from inside a single operator's stack.