Yesterday your Meta campaign was buying app installs. Today the campaign switch is blue, the dashboard shows no trials, and someone wants to change the bid. Before they do, pull two columns: impressions and amount spent. A campaign that stopped serving needs a different owner from one that is still spending while the trial report sits at zero.
If your Meta app ads are not spending, compare impressions and spend over a completed time window. Check the Delivery column at the campaign, ad set and ad levels, then see whether another ad set or another app campaign still serves. If impressions continue but installs or in-app events disappear, trace the store destination, event receipt and attribution before changing delivery controls. The first missing number tells you where to look; it rarely tells you the cause on its own.
Save a before and after view
Pick a window that the account would normally have finished reporting and a comparable healthy one. Use the account time zone; compare like hours and days where the campaign has a regular rhythm. If it's a new launch, use the scheduled start and the last known eligible state instead of pretending there is a historical baseline. Record when you exported each report so you can distinguish a revised number from a new incident.
Export campaign, ad set and ad IDs, Delivery and any detail text, impressions, spend, destination clicks and the result column used in your decision. Add the app, operating system, market, event, attribution setting where visible, and whether the ad was published. In a second note, mark recent changes in Ads Manager, app releases, store listing edits and integration changes. Timestamps are useful even when you don't know whether a change caused the drop.
The fastest comparison is often already in the account. Look for a sibling ad set in the same campaign, another campaign for the same app and operating system, and a campaign for a different app or OS under the same account. Use the closest one that normally serves. The sibling is a scope check. It does not prove the auction, audience or eligible inventory is identical.
What you see in the same window What it establishes Next evidence to collect --- --- --- Zero impressions and zero spend across previously delivering campaigns The problem appears broader than one creative or app Account notices, billing and limits, date range, platform status One app or OS stops while other campaigns still serve At least some delivery is still possible in the account Affected app, OS, ad and ad set statuses; store destination; last app or settings change One ad set stays at zero while the parent campaign spends The campaign is serving elsewhere Ad set and ad eligibility, allocation settings, schedule and any visible warning Impressions and spend continue, while reported installs or trials disappear Ads served in the selected window Clicks, destination, app activity, event receipt and report definitions Spend and impressions decline, but neither reaches zero Delivery continues with lower volume Distribution across ad sets, budget and bid constraints, asset mix, and changes in response
Do not fill blank cells with zeros. A disabled breakdown, missing integration export or row outside the report window is missing evidence. Write down which owner can obtain it and what you can decide in its absence.
Check the object that can actually serve
Meta's delivery-status documentation distinguishes the campaign, ad set and ad. A parent campaign can show active while a child ad is in review. Read the Delivery message for the affected row and at least one eligible sibling. The toggle alone only tells you what was switched on or off. Meta also distinguishes saved drafts from published changes, so confirm the live ad contains the settings you think it does before you diagnose them.
If the relevant ad is scheduled or pending review, use the displayed status and schedule to decide when to look again. If it is rejected, capture the exact reason and affected ad before making edits. If Meta names an account, portfolio or identity restriction, resolve that object first; use the ad rejection versus account restriction guide to choose the right review path. A new creative or campaign is not a legitimate workaround for an unresolved restriction.
When the issue crosses campaigns, ask an authorized owner to confirm any payment failure, spending limit or account notice in the account itself. Check the official Meta Ads Manager status page for a matching delivery or reporting incident. Those are separate categories. A reporting incident can make a dashboard difficult to interpret; it is not evidence that this particular app stopped receiving traffic. Likewise, an empty status page does not clear a local billing or policy problem.
Distinguish lost delivery from spend moving elsewhere
A single ad set with no spend can look alarming in a filtered report. Clear the ad set filter and inspect the campaign total and its breakdown. If the parent is still spending, ask whether the affected cell is an experiment the team needs to fund or simply an eligible cell the current setup does not need to use. A campaign with more than one eligible ad set does not establish an equal delivery expectation across them. Meta's Advantage+ app campaigns training covers targeting, optimization, creative and testing; verify which controls are actually available in your campaign before you plan a change.
Record the budget location, bid or cost control if present, schedule, market, audience constraints and available ads. Look for something you can name precisely: a cost control tightened just before delivery changed, a market removed from eligibility, or the only approved ad switched off. A change near the incident is a hypothesis; the history cannot establish how much each factor contributed. If multiple settings changed together, preserve that uncertainty. Reversing three settings may restore some delivery and still teach you nothing about the cause.
Meta describes Learning limited as a state in which an ad set did not generate enough results to exit learning, in its Delivery column guide. Treat it as a prompt to inspect the results and setup, not as a suspension or proof of an event outage. Check whether the chosen action was actually received and available to the affected ad set before proposing a shallower event. If the business case depends on trials, buying more installs can restore activity while leaving the underlying acquisition decision unanswered.
Trace the exact app and event through production
The app name on a report is a weak join key. Start with the app identifier selected in Meta, the OS and store listing the actual ad opens, the production build, and the integration or partner that sends the optimization event. A staging event can have the same name as a live event. So can a subscription button tap and a successfully started trial. Write down which one the business intends to buy. Meta's app events training describes the role of app events in optimization and measurement; it does not tell you which event arrived for your app.
Make four observations in order:
Destination. Preview the affected creative and open the advertised destination on an appropriate device and market where you can test legitimately. Confirm which store listing or in-app screen it opens, and whether the app is available there. An Android sibling proving its destination works does not verify the iOS one.
Occurrence. Complete the relevant flow in an approved test context on the current production build. Confirm what the product or backend recorded and when. Use an existing test mechanism where possible, keep the record identifiable as test evidence and avoid introducing personal or payment data into the evidence packet.
Receipt. Ask whoever owns the SDK or measurement partner to show whether the event was sent and seen by the intended Meta app data source, using the evidence the account makes available. Compare event name, app ID, OS and timestamp. A debug event establishes one path on one configuration; it does not establish representative production volume or prove that live paid events use that path.
Selection and credit. Confirm what event the affected ad set is configured to use, and compare the reported result against the matching report definition. An event can be received without appearing as a credited result for that campaign. Check windows, app and OS filters, lag and aggregation before comparing with the store, partner or backend.
Write these as separate facts: the action happened; the integration received it; the campaign is configured for that action; the report credited a result. A screenshot of one does not stand in for the other three. If you need to decide whether an event is a sensible optimization target in the first place, start with the Meta app event selection guide. If the disagreement is between systems, use the Firebase versus MMP guide to give each feed a clear job.
When spend continues, keep the investigation downstream
Split the live funnel into paid impressions, destination visits or clicks as measured, installs or first opens, and the intended in-app outcome. Find the first row that moved after accounting for timing. If clicks are stable and fewer people install, inspect the store handoff, listing availability and the match between ad and store promise. Those observations can explain a conversion change. They do not establish why the campaign is paying a particular auction price.
If the platform reports fewer trials while product-side trials hold, compare cohort boundaries before deciding the channel is broken or healthy. Product totals can include organic traffic, other channels and users acquired earlier. Today’s trials can come from yesterday’s installs. Compare install cohorts with the same time to convert where you can; keep one aggregate view for revenue and a separate view for what each reporting system can attribute. A neat reconciliation is helpful, but do not force totals to match by treating different event definitions as interchangeable.
When impressions and spend have dropped along with response, a creative issue belongs on the list. It should still compete with the evidence on allocation, destination and tracking. The app creative fatigue diagnostic is useful once you can show that comparable assets reached enough people to judge response. A creative that never served is not evidence of audience fatigue.
Make the next action small enough to interpret
Start with the strongest observation and its owner. If a published ad is missing from the intended schedule, the media owner fixes that one setting and checks whether the ad becomes eligible. If the app stopped sending trial events, the product or measurement owner verifies the repair on the affected build. If a confirmed restriction blocks the account, an authorized owner follows Meta's indicated process. Do not run a spend experiment against an eligibility problem.
For a delivery test, name one control to change and the tradeoff you are willing to accept. For example, if a tighter cost control coincided with a drop and other checks pass, an authorized owner can test one preapproved change while keeping the app, event, market and ads fixed. Before touching it, agree on a maximum spend or exposure, a comparison window based on the app's normal reporting cadence, and the condition for restoring the prior setting. Judge the result against the signal the test was intended to recover. Returning impressions may answer the delivery question without answering the trial cost question.
If the best hypothesis is reporting lag, the safest test may require no edit. Save the original report, write down which cohort should mature by the next check, and re-export it at that point. If there is no comparable history, say so and define the first usable cohort. A second look that changes nothing in the campaign can be more informative than a reset that destroys the comparison.
A fictional incident: one campaign, two problems
A language app ships a new iOS build on Tuesday. On Wednesday, the campaign total still shows spend, but the iOS trial column is empty and one Android ad set has zero impressions. In the first hour, both are described as “Meta stopped spending.” The campaign export shows two different situations.
The Android ad set has one live creative, currently in review after a copy edit. A sibling Android ad set still has impressions. The media owner records the affected ad's status and checks it again against the review state in the account. They leave the campaign budget alone. There is no evidence of an account-wide delivery stop.
The iOS ads still have impressions and destination clicks. The team reproduces the trial flow and confirms the product records it on the new build. The partner owner can see the event on the previous build but cannot yet show receipt for the new one under the expected app source. The team checks the event mapping and separates report lag from missing receipt. It does not switch the campaign to installs to make the result column move. If receipt is confirmed and campaign credit still differs, the investigation moves to attribution and matching cohorts.
These figures and scenarios are illustrative, not client evidence. The practical lesson is that a campaign can contain a genuine eligibility problem and a measurement problem at the same time. Each needs a different success criterion: an eligible Android ad serving again, and a verified iOS event path with a report the team can interpret.
What to send when you escalate
Give support or your internal owner a short record they can use without reconstructing the timeline. Include the affected object IDs through authorized channels, the account time zone and comparison windows, the exact status message, the last known good observation and the first bad one. State which siblings still serve, what changed, and which hypothesis your checks ruled out. If the evidence points to app measurement, add app identifier, OS, build, event and source, and state whether the action occurred, was received or was credited. Redact customer data, access tokens and payment details.
If you need help deciding who should act, contact Sharply Labs with a redacted timeline and a before-and-after export. This is for app teams already running Meta acquisition that need to distinguish a delivery incident from an app or reporting problem. A scoped review can identify the first unresolved signal, the owner who should investigate it and a bounded next test or support handoff. See our mobile app growth and paid acquisition services for fit. The review does not promise approval, delivery recovery or performance.