Mobile App Campaign Launch Checklist: 48 Checks Before You Spend

The campaign goes live tomorrow. Budget is approved, creative is loaded, the team is confident. Three failures are already baked in, and none of them will show up until the Monday report: the deferred deep links break on Android so installs land on the home screen instead of the promoted offer, the revenue events were never mapped so every purchase reports as zero value, and the postbacks are firing to last quarter's pixel. By the time anyone notices, a week of spend has been optimised against numbers that were wrong from the first rupee.

Campaigns rarely fail loudly. They fail silently, in the gap between "the campaign is live" and "the data is trustworthy", and launch day is far too late to find the gap. This is a numbered, 48-point pre-launch protocol across six categories. Each check tells you what to verify, how to verify it, and what a pass looks like. Run it before you spend, not after finance asks why the numbers do not reconcile.

Why Campaigns Fail Silently, and Why Launch Day Is Too Late

A pre-launch checklist exists because attribution failures are invisible at launch: the campaign delivers, installs arrive, and only the downstream data is broken, so nothing looks wrong until the numbers are reported days later. The cost is a week of misoptimised spend.

The three failure classes we see most often in pre-launch audits:

• Routing failures. Deferred deep links that break on one platform, sending paid users to a generic screen and tanking conversion while installs still count.
• Measurement failures. Revenue events that fire with no value, or events that never fire at all, so the campaign looks unprofitable when it may be your best.
• Signal failures. Postbacks pointed at the wrong pixel or account, quietly training the ad platform on the wrong optimisation signal. All three pass the only test most teams run, which is "did the campaign start". None of them pass a real acceptance check. The 48 checks below are those acceptance checks.

Checks 1-8: Tracking Links and Deep Link Routing

Links are the first thing a paid user touches and the first thing to break. Verify routing before anything else, because a broken link makes every downstream metric meaningless.

1. Every campaign link resolves to the correct store or destination on both Android and iOS. Pass: manual tap lands correctly on each platform.
2. Deferred deep links route post-install to the promoted screen, not the home screen. Pass: install from the link, confirm the exact destination opens. This is deferred deep linking, and it is the single most common silent failure.
3. Direct deep links route for existing users straight to the destination without a reinstall. Pass: tap as an installed user, land on target.
4. Links carry the correct campaign parameters so attribution can read them. Pass: parameters present and correct in the link.
5. Fallback behaviour is defined for unsupported devices or desktop taps. Pass: a sensible fallback page loads.
6. Short links and branded domains resolve without certificate or redirect errors. Pass: no browser warning, clean redirect.
7. Links are tested on a real device matrix, not just the simulator. Pass: at least two Android and two iOS versions verified. Use the guide to QA-ing deep links before launch for the full matrix.
8. QR and offline entry points, if used, route identically to digital links. Pass: scanned code lands on target.

Checks 9-18: SDK, Install Attribution and Event Firing

With links verified, confirm the SDK is capturing what the campaign depends on. This is the largest category because it is where revenue reporting quietly breaks.

1. The SDK is initialised on app launch with the correct production key. Pass: SDK logs a live session.
2. Install attribution** fires** for a paid test install and credits the correct source. Pass: dashboard shows the test source.
3. Organic installs attribute as organic, not misassigned to a paid source. Pass: organic test install reads organic.
4. Reinstall and reattribution cases behave as configured. Pass: a reinstall attributes per your rules.
5. The activation event fires once, at the right moment. Pass: single event, correct trigger.
6. Key conversion events fire with correct names matching your taxonomy. Pass: names match the plan exactly.
7. Revenue events carry a value and currency. Pass: purchase reports the correct amount, not zero. This is the check that most often saves a launch.
8. No duplicate events fire for a single action. Pass: one action produces one event.
9. Event properties are populated, not null, for the fields you will segment on. Pass: properties present.
10. Events are validated in a test build before production, using the integration testing docs as the model. Pass: every planned event verified in test.

Checks 19-26: Postbacks and Ad Network Connections

Postbacks are how the ad platforms learn what worked. Point them wrong and you optimise the campaign toward the wrong users from day one.

1. Each ad network shows a live, authorised connection. Pass: connection status active for Meta, Google, and TikTok.
2. Postbacks** fire to the correct account and pixel**, not a stale one. Pass: the network's event manager shows the incoming event.
3. The right events are mapped to each network's optimisation slots. Pass: purchase maps to purchase, not to a generic event.
4. Value-based postbacks send revenue, so networks can optimise toward paying users. Pass: value arrives in the network event.
5. No test events leak into the production pixel, which would poison the optimisation set. Pass: test traffic isolated.
6. Deduplication is configured so self-attributing networks do not double-count. Pass: one install, one credit.
7. Postback timing is acceptable, with events arriving within the network's window. Pass: events land in time to inform bidding.
8. The mapping matches your postback strategy end to end, per the complete postback setup guide for Meta, Google, and TikTok. Pass: strategy and configuration agree.

Checks 27-34: Naming Conventions, UTMs and Creative Tagging

Disciplined naming is what lets you read the report a month from now. Sloppy tagging is invisible at launch and infuriating at analysis.

1. Campaign names follow the convention so they sort and filter cleanly. Pass: names match the agreed pattern.
2. UTM parameters are consistent across every link in the campaign. Pass: no ad-hoc variants. The discipline is covered in our guide to UTM naming conventions that scale.
3. Ad set and ad-level names encode what you will need to segment by. Pass: names carry channel, audience, and concept.
4. Creative is tagged so creative-level performance is readable. Pass: each creative has a stable identifier.
5. Naming is unique per campaign, with no collisions against past campaigns. Pass: no duplicate names.
6. Language and geo variants are labelled distinctly. Pass: variants distinguishable in the report.
7. Placeholders and test names are removed before launch. Pass: no "test" or "draft" strings live.
8. The naming maps to your dashboard filters, so the cuts you need actually resolve. Pass: a test filter returns the right rows.

Checks 35-42: Budgets, Bids, Audiences and Exclusions

This is where money is actually committed. Verify the spend controls before the spend starts.

1. Daily and lifetime budgets are set to the intended figures. Pass: numbers match the media plan.
2. Bid strategy matches the objective and the event you can actually measure. Pass: bidding on a tracked event.
3. The optimisation event is one you are capturing. Pass: the event fires and postbacks confirm it.
4. Audiences are the intended ones, with no leftover test segments. Pass: audience list reviewed.
5. Exclusions are applied, including existing users where you do not want to pay to reacquire them. Pass: exclusion lists live.
6. Geo and language targeting match the creative and destination. Pass: targeting and creative agree.
7. Frequency caps and schedules are set where relevant. Pass: caps configured.
8. Spend guardrails or alerts exist for runaway delivery. Pass: an alert threshold is set.

Checks 43-48: Dashboards, Alerts and Reporting Cuts

The final category makes the campaign readable the moment it goes live, so problems surface in hours, not at the weekly review.

1. The reporting dashboard shows the campaign with the cuts you need on day one. Pass: campaign visible, cuts resolve.
2. Cost per install and cost per action populate correctly from first data. Pass: metrics compute, not blank.
3. ROAS** and revenue cuts** are wired to the revenue events. Pass: ROAS reflects real value.
4. Anomaly or spend alerts are active so a break pages someone. Pass: a test alert fires.
5. The first-week reconciliation view exists, comparing MMP data to network and payment numbers. Pass: the comparison cut is ready.
6. Ongoing hygiene is scheduled, so the setup does not decay after launch. Pass: monthly checks booked, per our guide to monthly MMP data quality checks.

Running the Checklist: Who, When, and the 90-Minute Version

A checklist nobody runs is decoration. Assign it, time it, and gate the launch on it.

• Who runs it: a single named owner, usually on the growth or analytics side, with engineering on call for the SDK and postback checks and marketing confirming destinations and audiences.

• When: the day before launch, after creative and budgets are final but before spend is scheduled. Not launch morning, when there is no time to fix what you find.

• The 90-minute version: if you genuinely cannot run all 48, run the ten that catch the silent failures. Verify deferred deep link routing on both platforms (checks 2 and 7), revenue events firing with value (check 15), postbacks hitting the correct pixel (check 20), the optimisation event being one you capture (check 37), and the day-one reporting cut resolving (check 43). These are the checks that fail silently and cost the most. Two practices make the protocol stick beyond a single launch:

• Keep a signed launch log. Record who ran the checklist, when, and which checks passed. A launch that went live without a completed log is a launch nobody certified, and the log is what turns a habit into a standard.

• Feed failures back into the template. When a check catches a real problem, note it, and when a new failure mode slips through, add a check for it. The 48 points are a living protocol, not a frozen list. The whole protocol is a gate, not a suggestion. If a check fails, the fix happens before spend, because every one of these failures is cheaper to catch on a test device than in a week of reporting.

The First 48 Hours After Launch

The checklist gets you to a clean launch. The first two days of live traffic are where anything the test environment could not surface shows up under real volume, so watch them deliberately rather than waiting for the weekly review.

• Hour one: confirm data is flowing. Installs, events, and spend should all be populating the dashboard within the first hour. Silence on any one of them is a failure to fix now, not a delay to wait out.
• Hour six: check the first reconciliation. Compare early MMP installs against the network's reported delivery. A large divergence this early usually means a postback or connection issue that passed the static check but breaks under live traffic.
• Day one: verify revenue is landing with value. The first real purchases should report the correct amounts. Zero-value revenue at real scale is the failure that most often survives QA and only appears with genuine transactions.
• Day two: read the first cohort. Confirm the day-one cohort retains and behaves plausibly. A cohort that installs and never activates points to a routing or targeting problem the launch checks might have missed. Tech Explainer: why silent failures pass the "is it live" test. An ad platform reports a campaign as delivering the moment impressions and clicks flow, and installs will count as long as the SDK fires, regardless of whether the deep link routed correctly or the revenue event carried a value. The platform has no visibility into your in-app destination or your event values, so its "healthy" status is blind to exactly the failures that matter most. This is why launch health cannot be read from the ad manager alone. It has to be read from the attribution dashboard, against test cases with defined pass criteria, which is the entire reason this protocol exists.

If the first 48 hours reconcile and the cohort behaves, you have a launch you can scale. If they do not, you have caught the failure in two days of spend instead of a full reporting week, which is the whole return on running the checklist.

Frequently Asked Questions

Who should run the launch checklist?

A single accountable owner, typically in growth or analytics, with engineering available for the SDK and postback items and marketing confirming destinations, audiences, and budgets. Diffusing it across a team is how launches go live with nobody actually certifying the setup.

When should the checklist run?

The day before launch, after creative and budgets are locked but before spend is scheduled. Running it on launch morning leaves no time to fix routing, revenue-event, or postback failures, which are exactly the ones that stay invisible until the weekly report.

What if there is no time for all 48 checks?

Run the ten highest-leverage checks: deferred deep link routing on both platforms, revenue events firing with value, postbacks to the correct pixel, an optimisation event you actually capture, and the day-one reporting cut. These catch the silent failures that cost a full week of misoptimised spend.

Catching the Silent Failures Before They Cost You

Campaigns do not usually blow up on launch day. They quietly report the wrong numbers for a week while the team optimises against them, because the failures live in routing, revenue events, and postbacks that all pass the naive "is it live" test. The 48-point protocol turns "it is live" into "it is verified", one pass criterion at a time.

If many of these checks collapse into a single dashboard view because deep linking and attribution share one platform and one SDK, that is the practical advantage of a unified stack, and it is what platforms like Linkrunner are built around. You can request a launch review from Linkrunner to run your next campaign against it, or download the 48-point checklist and make it the gate every launch has to pass before a single rupee is spent.