7 Red Flags Your MMP Setup Is Broken (And How to Fix Each One)

Lakshith Dinesh

Lakshith Dinesh

Reading: 1 min

Updated on: Mar 16, 2026

In roughly 6 out of 10 attribution audits we review, at least one critical MMP configuration error has been silently running for weeks before anyone notices. The dashboard still shows numbers. Campaigns still report installs. The team still makes budget decisions every Monday morning. But the data underneath those decisions has been quietly wrong, sometimes for months.
The dashboard never goes blank. That is exactly why broken setups survive so long.
The reason these issues stay hidden is simple: MMP dashboards never show blank screens when something breaks. A misconfigured postback does not trigger an error alert. It just stops sending data to one ad network while everything else looks normal. A broken attribution window does not crash anything. It just shifts credit between channels in ways nobody detects until someone finally runs a manual reconciliation.
This post covers seven specific warning signs that your MMP setup has a configuration problem, the root cause behind each one, and a step-by-step fix you can run this week.

Why Broken MMP Setups Stay Hidden for So Long

MMP configuration errors are uniquely dangerous because the feedback loop is delayed. If your website goes down, you know immediately. If your MMP postback to TikTok stops working, you find out three weeks later when someone asks why TikTok ROAS dropped to zero.
Three factors keep these issues hidden. First, MMP dashboards always produce output, even when completely misconfigured. Second, teams optimise on whatever numbers are in front of them. If the dashboard says Meta drove 4,000 installs last week, the team allocates budget accordingly. Third, a single broken postback running for four weeks on a Rs5 lakh monthly spend can misallocate Rs50,000-Rs1,00,000 before anyone investigates.
The weekly audit habit helps catch some of these early. If you do not already have one, the weekly attribution audit checklist provides a 20-minute routine that prevents most compounding errors.

Red Flag 1: Organic Install Share Suddenly Spikes or Drops

The symptom: Your organic percentage jumps from 30% to 60% overnight, or collapses from 40% to 10% without any corresponding change in marketing spend or app store ranking.
Why this happens: Organic install share is the residual bucket. When attributed installs drop (because a postback broke, a token expired, or an attribution window was changed), those installs do not disappear. They get reclassified as organic. The reverse happens when attribution windows are accidentally widened or a new network starts over-claiming.
The root cause is usually one of three things: a broken postback connection to one or more ad networks, an expired authentication token between your MMP and an ad platform, or an attribution window change that shifted credit between paid and organic.
How to fix it:

  1. Pull your organic/paid ratio for the past 90 days and identify the exact date the shift occurred

  2. Check postback health for every active ad network on that date. Look for any network that stopped receiving postback data

  3. Verify authentication tokens for Meta, Google, and TikTok integrations. Tokens expire quarterly

Red Flag 2: Platform ROAS and MMP ROAS Diverge by More Than 20%

The symptom: Meta Ads Manager shows 3x ROAS for a campaign. Your MMP shows 1.2x for the same campaign and time period. A 10-15% difference is normal. Anything above 20% signals a structural issue.
Why this happens: Ad platforms and MMPs count conversions differently. Meta uses its own pixel and conversion API alongside view-through attribution by default. Your MMP uses click-based attribution with different windows. When event mapping between the two does not align perfectly, the gap widens.
The root cause is usually: event mapping mismatch (the event Meta calls "Purchase" maps to a different event in your MMP), view-through inclusion (Meta counts view-through conversions by default, your MMP may not), or revenue postback lag (your MMP receives revenue data 24-48 hours after Meta has already counted the conversion).
For a comprehensive diagnostic workflow on this specific discrepancy, the Meta ROAS troubleshooting guide walks through every common cause and fix.
How to fix it:

  1. Export event-level data from both Meta and your MMP for the same 7-day period

  2. Compare event names and definitions side by side. Ensure "Purchase" in Meta maps to exactly the same trigger in your MMP

  3. Align attribution windows. Set both to the same click and view windows, then re-pull the data

Red Flag 3: Install Counts Match but Revenue Attribution Is Missing

The symptom: Your MMP accurately tracks 10,000 installs per week. But revenue attributed to those installs shows zero or a fraction of what your backend payment system reports.
Why this happens: Install tracking and revenue tracking are separate configuration layers. The SDK handles install detection automatically, but revenue events require explicit mapping. If the revenue event is not configured, not firing correctly, or has a currency mismatch, installs track fine whilst revenue attribution is completely blind.
The root cause is typically: the revenue event was never mapped in the MMP (the team set up install and registration events but skipped purchase), a server-side revenue event is not firing or is firing with incorrect parameters, or there is a currency mismatch (the app sends revenue in USD but the MMP expects INR, or vice versa).
For a detailed walkthrough on diagnosing attribution gaps across all event types, the attribution discrepancy diagnostic guide covers 12 common root causes and fixes.
How to fix it:

  1. Check your MMP event configuration. Confirm that a revenue event exists and is actively receiving data

  2. Run a test purchase on a device with debug logging enabled. Verify the revenue event fires with the correct value and currency

  3. Compare MMP revenue totals against your payment processor for the past 30 days. The gap tells you how much attribution data you are missing

Red Flag 4: One Ad Network Shows Zero Installs While Campaigns Are Live

The symptom: TikTok or Google shows zero attributed installs in your MMP dashboard, despite active campaigns with confirmed ad spend on those platforms.
Why this happens: This is almost always a postback integration issue. The ad network is running campaigns and driving clicks, but the MMP is not receiving attribution data for that network. The installs are happening. They are just being classified as organic.
The root cause is usually: the postback integration for that network was never set up, the wrong app ID or package name was entered during integration, or a required module activation was not enabled in the MMP dashboard.
How to fix it:

  1. Go to your MMP's partner/integration settings and confirm the ad network is listed and active

  2. Verify the app ID and package name match exactly between the ad network and MMP

  3. Monitor for 48 hours to verify installs start appearing

Red Flag 5: Duplicate Installs or Inflated Install Counts

The symptom: Your MMP reports 13,000 installs for the week, but the App Store and Play Store combined show only 9,500 downloads for the same period. A 30-50% inflation is a serious red flag.
Why this happens: Install counting seems straightforward, but several configuration issues can inflate numbers. Re-attribution windows that are too short cause re-installs to count as new users. SDK initialisation bugs can fire multiple "first open" events per device. Re-engagement campaigns can trigger re-attribution events counted alongside genuine new installs.
The root cause is typically: re-attribution window misconfiguration (set too short, causing returning users to count as new), SDK initialisation firing multiple times per session, or device-level deduplication not configured.
How to fix it:

  1. Compare MMP install counts against store download numbers for the past 30 days. Identify when the inflation started

  2. Review your re-attribution window settings. For most apps, 90 days is a reasonable default

  3. Check whether re-engagement campaigns are creating new user records instead of updating existing ones

Red Flag 6: Deep Link Routing Works but Attribution Credit Is Missing

The symptom: Users click a campaign link, land on the correct in-app screen, and the user experience works perfectly. But the campaign that drove that user gets zero attribution credit. The install or re-engagement appears as organic or direct.
This is the cruelest failure mode. Users land on exactly the right screen. The UX works perfectly. Everyone is happy, except the campaign that drove that user gets zero credit. Perfect routing, invisible attribution. The user experience team thinks everything is fine. The growth team wonders why their campaign ROAS is tanking.
Why this happens: When deep link routing and attribution tracking are handled by different tools (or different link types within the same tool), the routing layer can successfully send users to the right screen whilst the attribution layer never receives the click signal.
The root cause is usually: the deep link and the attribution link are separate (the deep link handles routing, but a separate tracking link was supposed to handle attribution and was not included), or the fallback routing path bypasses the attribution layer entirely (users who need to install the app first go through a fallback flow that strips the attribution parameters).
This is exactly why separating deep linking from attribution creates blind spots. The deep linking and attribution integration guide explains why unified links eliminate this failure mode entirely.
Platforms like Linkrunner solve this structurally by unifying deep linking and attribution in a single link. Every link is both a routing mechanism and an attribution signal by default, so routing success always includes attribution credit.
How to fix it:

  1. Audit your link architecture. Identify which links handle routing and which handle attribution

  2. Test 5 campaign links end-to-end: click, install (or open), and verify both routing and attribution fire correctly

  3. Check fallback flows. When a user clicks a deep link but does not have the app installed, trace the install path and confirm attribution parameters survive the store redirect

Red Flag 7: SKAN Postback Volume Drops to Near Zero on iOS

The symptom: iOS SKAN data that previously showed hundreds of postbacks per week suddenly drops to single digits or zero. iOS attributed installs essentially disappear from your reports.
Why this happens: SKAN postbacks are sensitive to configuration changes. An app update can break SKAN registration if the conversion value schema is not maintained across versions. Apple's privacy thresholds mean that campaigns below a certain volume may not generate postbacks at all. And conversion value mapping can silently become outdated when monetisation events change.
The root cause is typically: the conversion value schema was not updated after a product change (new subscription tiers, new purchase flow), an app update broke SKAN registration by missing the required call, or campaign volume fell below Apple's privacy threshold for a specific network.
For a thorough walkthrough of SKAN 4.0 configuration, the SKAN privacy measurement framework covers postback mechanics, anonymity thresholds, and conversion value strategies across app types.
How to fix it:

  1. Verify SKAN registration is active in the current app build. Check that the SKAdNetwork registration call fires on first launch

  2. Review your conversion value mapping against current in-app events. If you added or changed monetisation events, the mapping may be stale

  3. Check campaign volume per network. Apple suppresses postbacks for campaigns below anonymity thresholds. Consolidate smaller campaigns to meet minimum volumes

Frequently Asked Questions

How often should we audit our MMP setup for configuration errors?
Run the full health check above monthly. Between monthly checks, a weekly 20-minute audit covering postback health, organic/paid ratios, and platform ROAS comparison catches most issues before they compound.
What is the most common MMP setup mistake that wastes the most budget?
Missing revenue postbacks. When ad networks only receive install signals (not revenue events), their algorithms optimise for volume instead of value. Fixing this single issue often produces the largest incremental ROAS improvement of any configuration change.
Can a broken MMP setup affect ad network algorithm optimisation?
Yes, directly. Ad network algorithms learn from the conversion data you send via postbacks. If postbacks are broken, delayed, or sending the wrong events, the algorithm optimises toward incorrect outcomes. A campaign optimising for installs instead of purchases acquires fundamentally different users.

Catching Problems Before They Compound

Your next MMP health check is either on your calendar or it is not. That single difference, scheduled versus reactive, is what separates teams who catch these red flags in week one from teams who discover them in the quarterly review.
Every red flag in this list shares one characteristic: the longer it runs undetected, the more expensive it becomes. A broken postback that runs for one day costs you one day of suboptimal algorithm learning. The same issue running for 30 days means an entire month of budget decisions built on incomplete data.
The fix is not complex. It is consistent. Monthly health checks, weekly quick audits, and a clear owner who monitors these signals prevent most configuration drift from becoming budget waste.
If you want to reduce the manual overhead of these checks, request a demo from Linkrunner to see how real-time integration testing and automated postback monitoring surface configuration issues before they reach your budget.
Start with the health check. Fix the highest-priority red flags first. Then build the monitoring habit that keeps them from returning.

Empowering marketing teams to make better data driven decisions to accelerate app growth!

Handled

2,288,163,365

api requests

For support, email us at

Address: HustleHub Tech Park, sector 2, HSR Layout,
Bangalore, Karnataka 560102, India

Empowering marketing teams to make better data driven decisions to accelerate app growth!

Handled

2,288,163,369

api requests

For support, email us at

Address: HustleHub Tech Park, sector 2, HSR Layout,
Bangalore, Karnataka 560102, India