The mobile app launch marketing playbook: store hygiene to paid scale, 2026

You get almost no organic distribution on day one. Your store listing is indexed but ranks nowhere, your paid campaigns stay unstable until they have accumulated conversions — Google's documented gate is the first 100 conversions, explicitly a count and not a time window — and your iOS attribution arrives in pieces: the first postback covers days 0–2 and is delayed 24 to 48 hours, and it is the only one that can carry a fine conversion value. Everything after it arrives 24 to 144 hours late in coarse buckets. The first real signal you can act on is usually 100 conversions deep, not day one.

Three structural facts shape everything that follows.

First, the volume story in India is over and the monetisation story has started. Sensor Tower's India numbers for Q2 2026, reported via TechCrunch, put quarterly downloads at roughly 6.3 billion — flat since 2023. Downloads are not growing. Money is: consumer spend in the same quarter was $345M, up 35% year on year, and non-gaming apps were 68% of India revenue in H1 2026, up from 58% three years earlier. You are not competing for a growing pool of installs. You are competing for a share of a fixed one, and the money is in what happens after the install. (One caution on that same article: its "~$4.60 per download" figure does not reconcile — $345M divided by 6.3B is $0.055. Do not reproduce it.)

Second, install volume in India is brutally concentrated. AppTweak's downloads-to-top-chart data puts number one in Sports on Google Play India at roughly 87,000 downloads per day, against roughly 13,000 for the same rank in the US. On that measure India is the most competitive Play storefront in the world — it takes about six and a half times the daily volume to hold the same position.

Third, retention is where most launches die. Adjust's published cross-app figures — which carry no stated measurement period on the page, so treat them as "Adjust, undated" and matching 2022–23-era numbers — show combined D1 26%, D7 13%, D14 10%, D30 7%. Read the platform and region tuples in that same D1/D7/D14/D30 order: iOS 27/14/11/8, Android 24/11/8/6, APAC 26/12/9/6 — so iOS D30 is 8%, not 11%. If you launch at 12% D1, no amount of spend fixes the arithmetic.

Plan a six to eight week launch window, not a launch day. Week one: store hygiene and tracking validation. Weeks two to four: Apple Ads and Android install velocity. Weeks five to eight: Meta and the first move down the event ladder. Faster than that and you are deciding on noise.

Six things must be finished before your first ad impression: tracking that fires and is verified end to end, an MMP decision, a written event taxonomy, store assets sized to spec, a pre-registration or pre-order plan, and — on Android with a personal Play account — the 12-tester, 14-day production access requirement started weeks earlier.

Tracking that you have personally verified

Not "the SDK is integrated". Verified: a fresh build on a clean device, tapped through registration and your key activation event, all of it landing in your analytics debug view with the right parameters, on both platforms. A large share of "the campaign isn't working" reports in week two are an event that never fired.

The MMP decision

There are seven certified App Attribution Partners: Adjust, Airbridge, AppsFlyer, Branch, Kochava, Singular and Tenjin — Google's own certification, not a vendor ranking. If Google is your only paid channel, Firebase is enough and free. The moment a second paid network exists, an MMP pays for itself in schema consistency. Full comparison below. In the EEA, capture consent before sending app conversions to an attribution partner.

A written event taxonomy

One page: event name, when it fires, what parameters it carries, which platform threshold it is meant to clear. Fix the names before launch — Firebase key events are not retroactive and a standard GA4 property caps you at 30 key events (50 on GA4 360).

Naming convention that survives contact with three platforms: snake_case, object_action order, present tense, no spaces, no camelCase, no platform prefixes, and never a name that differs by one character from a Firebase reserved or auto-collected name. Keep purchase, first_open and in_app_purchase for their reserved meanings — Firebase auto-marks them as key events. Parameters carry the variation; the event name never does, so subscription_start with a plan parameter, not subscription_start_annual and subscription_start_monthly as two events.

Copy this table into your own doc and replace every placeholder with your own app's names, parameters and measured rates before you write any SDK code:

The percentages above are illustrative placeholders, not benchmarks. No published source gives install-to-registration or install-to-activation rates by category — the spread is what a plausible funnel looks like, and yours will differ. Overwrite them with measured numbers before you use the table to choose an optimisation event, because that choice is entirely a function of the rate. Rung 3 is the one you have to name yourself; the category posts in this series each argue for a specific one.

Store assets to spec

Google documents App Campaign specs precisely: headlines 1–5 at max 30 characters, descriptions 1–5 at max 90 characters, images up to 20 per ratio at max 5 MB (1.91:1 → 1200×628, 4:5 → 1200×1500, 1:1 → 1200×1200), video up to 20 per ratio in 16:9, 9:16 and 1:1 at 10–60 seconds and hosted on YouTube first, HTML5 as up to 20 ZIPs per ad group at 5 MB each. Google auto-generates video from your store listing if you supply none — the output is usually poor enough to be a reason to supply your own. Keep at least one approved asset of each type per ad group and Ad Strength at "Good".

Pre-registration and pre-orders

Google Play pre-registration, per Google's documentation: 90 days maximum per country with the clock starting per country, maximum two apps in pre-registration at once, a day-one push to every pre-registered user, and automatic install on launch day for eligible devices. The size cliffs are the part nobody mentions: apps ≤200 MB auto-install on Wi-Fi and cellular, 200 MB–2 GB on Wi-Fi only, above 2 GB not eligible at all. Children's and enterprise-managed accounts are excluded. You get exactly one pre-registration reward for the lifetime of the campaign, uneditable and undeletable once created, and it must exist before the campaign starts. Google publishes no statement that pre-registration confers a ranking benefit and no aggregate conversion rate — the install-concentration mechanism is real, the ranking claim is inference.

Apple pre-orders: release date 2 to 180 days ahead, free and paid, customers charged the lower of the pre-order price or the release-day price, auto-download on release day. Hard limits: IAPs cannot be pre-ordered, app bundles are ineligible, and once you release in a region you can never offer pre-orders there again. And Apple Ads Maximize Conversions is unavailable for pre-order campaigns, so pre-order Apple Ads must run manual CPT.

Testing tracks and the Android gate

TestFlight: 100 internal testers, 10,000 external, 100 builds, 30 devices per tester, builds expire after 90 days, and the first build added to a group goes through Beta App Review.

Play testing tracks: internal 100 per app, closed up to 200 email lists of 2,000 users each, open unlimited or a specified minimum of 1,000. No public reviews on any testing track.

The one that wrecks timelines: Play production access requires 12 testers for 14 continuous days for personal Console accounts created after 13 November 2023. Organisation accounts are exempt. Testers who opt in for under 14 days then opt out do not count, and if a tester opts out and returns, the clock restarts. Review is typically within seven days after that. Older guides say 20 testers — outdated.

Apple indexes your app name, subtitle, the hidden 100-character keywords field, both your primary and secondary category, and your App Tags. Google Play has no keyword field at all — it draws terms from your title, short description and full description as free text. These are two different disciplines, and copying one listing into the other wastes both.

Apple: six indexed surfaces, three of them invisible to users

The field list and character limits below come from Apple's App Store Connect app-information reference, linked in Sources. Apple revises these limits without announcement, so treat the numbers as of September 2026 and confirm the current values in App Store Connect before you write copy against them. Apple publishes no weighting between these fields — the "highest weight" note on app name is the consensus reading of Apple's own search documentation, not a published figure, and no one outside Apple can verify it.

Three rules. Do not repeat a word across name, subtitle and keywords — Apple indexes the union, so repetition burns characters. Do not put your category name in keywords if it is already in your subtitle. Set the secondary category deliberately: Apple's developer guidance treats categories as a discoverability surface, not a label.

On App Tags: Apple generates them from your metadata and lets you manage them in App Store Connect. Apple has published no data on how much tags move search or browse placement, and neither has anyone else. Treat them as free hygiene, not a lever with a known return.

The mechanism matters more than the character counts, because the mechanism does not change when the limits do: Apple indexes a fixed, finite pool of characters you supply, and any word repeated across two fields is indexed once but paid for twice. Google indexes free text you write for humans with no declared field for keywords and no published weighting. Optimise Apple for coverage without duplication; optimise Play for readable prose that happens to contain the terms.

Set up Custom Product Pages before your first Apple Ads rupee. Apple documents up to 70 CPPs per app, requiring the Marketing role in App Store Connect, usable in search-results ad groups only, one active custom ad per ad group, and no new app version needed to create or edit one. That last point is why they matter: you can iterate creative against a live campaign without shipping a build.

Play: no keyword field, so the description is the keyword field

Google's "Get discovered on Google Play search" documentation is explicit that there is no keyword input. Your indexable free text is:

• Title, 30 characters
• Short description, 80 characters
• Full description, 4,000 characters

Google does not disclose the weighting between them and publishes no keyword-density guideline. Google's Metadata policy does prohibit keyword stuffing, unattributed testimonials, and performance or ranking claims in metadata — enforcement is real and it is the most common reason a listing update gets rejected.

Two Play-side items that are hygiene rather than ASO. Localisation: Google supports localised listings per language, and in India you decide early whether to run English-only or add Hindi and regional listings — a category call the fintech and astrology posts cover. Technical quality: Google publishes user-perceived thresholds of 1.09% crash rate and 0.47% ANR, and states apps above them are excluded from prominent discovery surfaces — the only ranking penalty either store has ever quantified. Check Android vitals before you buy a single install.

Two things worth stating as inference rather than fact, because neither store publishes them. Neither Apple nor Google documents reviews, screenshot text or your website as indexed search surfaces — that absence is not the same as a published confirmation that they are ignored, so treat "do not count on them" as the safe planning position rather than a rule. And download velocity is clearly a ranking input, but it is not the only one: the Android vitals thresholds in the paragraph above are a documented, quantified ranking input that has nothing to do with velocity. Anyone telling you rank is purely a function of installs is describing one input as the whole system.

Run four campaigns: Brand, Category, Competitor and Discovery, all on exact match with Search Match off except Discovery. Add every keyword from the first three into Discovery as exact-match negatives so Discovery only spends on genuinely new terms. This is Apple's own documented recommendation, not agency folklore.

Apple Search Ads was renamed Apple Ads on 14 April 2025. Two tiers: Advanced (cost-per-tap, four placements, keyword control, full API) and Basic (cost-per-install, search results only, capped at $10,000 per month per app, max 50 apps, no keywords). Basic is a reasonable place for a solo developer to start and a bad place to stay.

Four placements across roughly 90 countries: Today tab, Search tab, Search results, Product pages. Product page ads are unavailable in mainland China. Only search results supports target CPA and keywords; the other three are CPT-only.

The structure, with Apple's own definitions

The negative-keyword flow makes this work. Every keyword live in Brand, Category or Competitor goes into Discovery as an exact-match negative. Without it, Discovery cannibalises terms you already win cheaply and you pay twice for the same install. Rebuild the negative list every time you graduate a term.

Budget splits you will see quoted — 30/35/30/5 — are convention, not Apple guidance. Apple has published no recommended split. Start there if you have nothing better.

Apple has also published no guidance on how often to rebalance the manual four-campaign structure, or on a starting bid. Anyone quoting a review cadence in days is quoting habit. Rebalance on volume instead: move budget between campaigns once the campaign you are moving budget out of has accumulated enough taps for its cost per install to be worth reading — treat at least 100 taps and at least 30 installs in a campaign as the point at which its CPI is a number rather than a rumour, and until then leave the split alone. The one time-based number Apple does publish applies only to Maximize Conversions: run it at least two weeks before judging it.

For a starting bid, the only published anchor is AppTweak's CPT panel, and it is a range rather than a number. India-targeted Advanced campaigns have no India CPT figure published at all; the global median CPT is $0.92 and India's install-per-tap rate is high, so an opening max CPT of roughly $0.30–0.60 (₹26–53) on Brand and $0.50–1.00 (₹44–88) on Category and Competitor is a defensible starting point that you should expect to be wrong in your category. Bid up on terms that convert, not on terms that get taps.

On keyword counts: Apple documents no limit and no recommended number. In practice a launch structure that stays readable is roughly 5–15 exact-match keywords in Brand (your name, its misspellings, your company name), 20–50 in Category, and 10–30 in Competitor — one competitor brand per keyword, and only competitors a user would genuinely substitute for you. Larger lists are not wrong, but every keyword you add to those three must also be added to Discovery as an exact-match negative, and lists above a few hundred stop being maintainable by hand.

When does a Discovery term graduate? Apple publishes no criterion, so this is a rule you set and enforce rather than one you can cite. A workable one, stated as a judgement call: a search term graduates from Discovery into Category or Competitor once it has at least 30 taps (enough to read a conversion rate at all), an install-per-tap rate at or above your account average — AppTweak's India Apple Ads figure of 48% is a reasonable stand-in until you have your own — and a cost per install at or below your target CPI. Terms with volume and a good CPI but a below-average conversion rate are a product-page problem, not a keyword to graduate. Terms with a good conversion rate and a CPI above target graduate anyway, at a lower bid. On graduation, add the term to the destination campaign as exact match and add it to Discovery's negative list in the same session — the second half is the one people forget, and it is what stops you bidding against yourself.

The Maximize Conversions tension you have to decide about

Apple launched Maximize Conversions on 25 February 2026 for search results: automated bidding to a target CPA plus a daily budget. Apple's documented guidance is specific — budget for at least five conversions per day, run it for at least two weeks before judging it, it is not available for pre-order campaigns, and Search Match is mandatory on the automatic ad group. Target CPA is a weekly average goal, not a per-query ceiling, which is the single most misunderstood thing about it. The alternative strategy, Manage Bids, is manual max CPT with Search Match on by default and switchable off.

Here is the structural problem, and every honest playbook should name it: Maximize Conversions requires Search Match and operates at campaign level on a target CPA, which directly conflicts with the exact-match, Search-Match-off discipline that makes the four-campaign structure work. Apple has published no guidance reconciling the two. In practice you pick one of two paths — run the classic manual four-campaign structure, or run a Maximize Conversions campaign alongside it and treat them as separate books. Do not try to convert the four-campaign structure into Maximize Conversions and expect the negative-keyword logic to survive.

Two more 2026 changes. Lifetime budget campaigns were paused in June 2026 — daily budget is the only model now, so your monthly maximum is daily budget × 30.4. Apple documents no minimum daily budget for Advanced. CPA caps are reportedly being retired, but no firm sunset date has been published — treat that as unconfirmed.

What Apple Ads actually costs

This is the one channel with genuinely good third-party data. AppTweak's panel of roughly 3,500 apps, 50,000 campaigns and $1 billion in ad spend across 38 countries in 2025 reports:

One scoping note on that 48%: it is AppTweak's install-per-tap rate for Apple Ads in search results in India, not a store-page conversion rate and not a figure that transfers to App Campaigns, Meta or organic traffic. It tells you how many taps on an Apple Ads search-result placement become installs. Nothing in the panel measures what your listing does for a user arriving from a YouTube video or a Play search.

Cross-check against a second panel before planning on them. Adapty's dataset of over one million ad groups across 90 countries puts US CPT at $1.58 with a 62.71% conversion rate and 9.0% TTR — no India cut. SplitMetrics, from 4.44 billion impressions, reports a 67.2% average conversion rate across top categories, though the data is 2024 despite the 2025 report title. US CPT reads $1.58 or $1.91 depending on whose panel you use. Plan with a range, never a single number. Apple's own published figure: more than 60% average conversion rate for ads at the top of search results, November 2024 to October 2025.

One thing that does not exist: Apple Ads conversion rate by match type is not published by anyone. A table claiming exact converts at X% and broad at Y% is fabricated.

Other 2026 changes on the record: additional search-result slots further down the page from December 2025 on iOS 26.2+ (position not biddable), an Insights dashboard in March 2026, custom creative assets in June 2026 for the Today tab and search results, and Apple Maps Ads in August 2026. Attribution runs a 30-day window; the AdServices API retains data up to 21 days. Those are two different things and conflating them causes reconciliation arguments.

On Android you are buying install velocity through Google App Campaigns. The three numbers that decide whether it works: daily budget of at least 50× your target CPI bid, at least 10× your bid if you optimise to an in-app action, and no in-flight edits before 100 conversions have registered. Miss those and the campaign never leaves learning.

First, a naming correction that tells you whether a source is current: "UAC" is a deprecated product name. These are App Campaigns. Anyone still writing UAC in 2026 is recycling a 2019 post.

The three subtypes

• App campaigns for Installs (ACi) — includes Audience signals for cold start, no eligibility gate. Your launch campaign.
• App campaigns for Engagement (ACe) — requires a minimum of 50,000 installs, plus deep links, audience lists, and conversion tracking through Firebase or an App Attribution Partner. Not a launch tool.
• App campaigns for Pre-registration (ACpre) — Android only, requires an APK in a release track, must launch within 90 days, the app must not already be available in the targeted country, child-directed apps ineligible, bidding target CPpre only. Runs on Google Play, YouTube in-stream and Display. Reporting gotcha: Google Ads counts a pre-registration even if the user later un-registers, while Play counts only active ones — expect large discrepancies and decide up front which dashboard is your number.

The budget rules, which are documented and routinely ignored

Google documents these; they are not agency suggestions. Work an example: at a ₹40 (about $0.45) target CPI in India, ACi needs ₹2,000 per day, roughly $23 — about ₹61,000 a month, or $690. If you cannot fund that, lower the bid rather than under-fund the budget; an under-funded campaign does not deliver slowly, it delivers badly.

About the ₹40 figure, used as the worked example throughout this post. ₹40 is an illustrative bid, not a benchmark, and this is the only place it is defended. Google publishes no App Campaigns CPI benchmark for India or anywhere else, so there is nothing to anchor it to. The single published India CPI in this entire post is AppTweak's Apple Ads figure of $0.89, about ₹78 — roughly double ₹40, and from a different channel with a different auction. ₹40 is used here because it is a round number that makes the 50× and 10× arithmetic legible, and because Android install auctions in India generally clear below the Apple Ads figure. It is not a target, not a market rate and not something to put in a plan. Substitute your own tested bid the moment you have one, and re-run every budget floor in this post against it — at ₹78 the same 50× rule puts the ACi floor at ₹3,900 a day, about ₹1.19 lakh a month, which is roughly double the floor derived below and would consume almost the entire Android line of the Bootstrap scenario.

The learning gate is separate and stricter. Google's exact wording: "Making changes to your in-flight campaign before the first 100 conversions have registered may disrupt learning." It is a conversion count, not a time window. Calculate it for yourself: 100 conversions at a ₹40 CPI is ₹4,000 (about $45) of spend — two days at ₹2,000/day, eight days at ₹500/day. The low-budget case is where most teams lose patience and break the campaign.

Other documented Google guidance worth building into your setup: for target CPA, "it isn't recommended to select more than one action"; iOS bids should run around 1.5× Android; and when targeting users likely to take an in-app action, bid about 20% above your baseline target CPI.

Deep linking, and the two silent failures

Both fail quietly — no error, just worse performance you blame on creative.

1. Your robots.txt must allow AdsBot-Google and AdsBot-Google-Mobile to reach apple-app-site-association and assetlinks.json. The most common silent misconfiguration in the channel.
2. Android installs need deferred deep links enabled in your measurement SDK, or post-install routing drops users on your home screen.

ACe on Android also needs session_start events carrying the GCLID. Without it, ACe measures Display and YouTube only — not Search — and you will conclude Search re-engagement does not work when you simply never measured it.

Burst installs and CPI networks: the mechanics

Mechanics as vendors run them — all vendor-sourced, none independently verified: 24 to 72 hour delivery windows, budgets of $35,000 to $50,000 in published case studies, claimed movement of 5 to 20 chart positions, and vendors themselves conceding that ranking gains diminish within one to two weeks.

The install-threshold question has no honest answer, because there is no threshold. The widely circulated "10,000 installs" figure has no published basis anywhere. AppTweak's data puts number one in Sports on Google Play India at around 87,000 downloads a day versus about 13,000 in the US. The real number is a function of that category's daily download distribution in that storefront, and it moves weekly. A vendor quoting a flat figure is quoting a price list, not a measurement.

If you buy CPI, price in the fraud economics. AppsFlyer's State of Ad Fraud 2026, built on 106.4 billion installs — the largest dataset publicly available, though they sell the remedy — puts iOS fraud at 11.7%, Android at roughly 14–15%, and Finance around 31%. The split that should change your behaviour: affiliates around 40% versus self-reporting networks around 1%, a 40× gap — and "affiliate" is exactly how CPI networks are structured. Note the circularity: an MMP's reported fraud rate is its own detection rate, so read it as a floor. Then note that CPI-network rates typically run 30–60% below the equivalent App Campaigns or Meta rate for the same geo — a discount that lines up almost exactly with the affiliate fraud rate.

The insertion-order clauses to demand: your MMP is the source of truth, not theirs; fraud protection named in the IO with blocked installs non-billable; post-attribution clawback of at least 30 days, wider than the MMP's own 7-day window; full sub-publisher and site-ID transparency with blocklist rights; no incentivised or rewarded inventory, warranted in writing; a retention floor as a payment condition; holdout and incrementality rights; audit and termination for cause. They protect your money. They do not protect your account.

The two facts you cannot design around Apple's February 2026 Guidelines revision added a named clause, 5.6.3 "Discovery Fraud", under the Developer Code of Conduct — where the remedy is termination of the Developer Program account, not app rejection. Apple's sentence, in full: "Manipulating any element of the App Store customer experience, such as charts, search, reviews or referrals to your app, erodes customer trust and is not permitted." The Section 3 preamble reaches agencies too: "or engage with third-party services to do so on your behalf." You cannot contract out of this by hiring someone. Google states it filters incentivised installs out of its ranking systems, escalating to removal from top charts then from the store — the burst can be silently zeroed while you still pay. And the enforcement does not stop at the app or the account that ran the burst: "any related Google Play developer accounts will also be permanently suspended." One app's burst is a company-level risk. One honest number: the only independent causal estimate of paid spend's organic halo is MIT (Ju, Zhao and Aral, 2025), from three advertising-shutoff experiments across 6 apps over 500 days. Every $100 of ad spend produced roughly 37 paid installs and about 3 organic ones — a halo of roughly 8%, not the 1.5–3× vendors pitch. Six apps is a small sample; it is also the only causal estimate anyone has published.

One more piece of independent evidence. An ACM IMC '20 study ran real incentivised campaigns through three platforms at 500 installs each, observing 2,126 offers from 922 apps over three months. Top-chart appearance was 3.1% at baseline, 7.5% through vetted incentive platforms, 2.5% through unvetted ones — the cheap platforms produced no detectable ranking benefit at all. Install-only offers were priced at $0.06. One day after install, continued engagement was 1 to 4 users out of roughly 500 per platform.

A burst can also actively damage you. Google publishes those technical-quality thresholds — 1.09% user-perceived crash rate, 0.47% ANR — and states apps beyond them are excluded from prominent discovery surfaces. Dumping tens of thousands of low-intent installs onto an un-load-tested build is a reliable way to cross that line at exactly the moment you are trying to rank.

The legitimate version produces the same install curve. A pre-registration cohort, an email waitlist, a PR embargo, creator posts and paid campaigns all landing on the same day. Identical velocity signal to the algorithm, real users, no policy exposure. The casual game post builds this out, since games are where launch-day concentration matters most.

Start Meta on the App Installs objective, not on a deep event. Move to App Event Optimization only once a single ad set can generate roughly 50 optimisation events per rolling seven days — a figure that is trade-press reported and that Meta has never published. Consolidate into fewer, larger ad sets rather than splitting budget across many — that is the structural fix for learning-limited delivery, not a budget increase.

Meta also markets an automated buying product, Advantage+ App Campaigns, which sits over the optimisation goals below rather than replacing them. This post makes no performance claim about it, because there is nothing citable to make one from: every documented threshold in Meta app promotion is trade-press only, and the Advantage+ documentation that would settle how it interacts with the learning phase sits in the Business Help Center, which cannot be cited. Name it, test it against your own manual structure, and do not budget on a lift number you read anywhere.

A sourcing caveat before any number: Meta's Business Help Center is robots.txt-blocked, so it cannot be cited directly. Everything below marked as documented comes from developers.facebook.com. Every threshold figure in Meta app promotion is trade-press only. Attribute it that way and never cite Meta as the source for it, because Meta has not published it.

The optimisation goals, and which to use when

Meta documents these goals for app promotion:

• App Installs — Meta's recommended default, and your launch setting.
• App Event Optimization (AEO) — optimises to a chosen in-app event, charged on impressions, requires App Events enabled.
• Custom Event Optimization — ad set goal OFFSITE_CONVERSIONS.
• Value Optimization — requires purchase event data; Meta documents it as "available on a limited basis to partners and advertisers", so do not plan around having it.
• Link Click Optimization — Meta explicitly discourages this if the SDK is installed.

The ~50 events per ad set per 7 days threshold

The number you will see everywhere is approximately 50 optimisation events per ad set per rolling seven days to exit the learning phase. It is universally cited and consistent across trade sources, but it is not primary-verifiable — Meta has never published it. Use it as a planning heuristic and say so when you quote it.

Budget changes, creative swaps, audience changes and optimisation-event changes all reset it. This is why "raise budget to escape learning limited" is mostly wrong — raising budget purely to clear the label typically yields only a 5–10% improvement. The structural fix is consolidation: fewer ad sets, each carrying enough volume to clear 50 events a week on its own.

How few is "fewer"? Meta publishes no target ad-set count, so this is a judgement call rather than a citation: at launch, run one campaign with one ad set, and do not add a second until the first has cleared roughly 50 events a week on its own with budget to spare. Two to three ad sets is the practical ceiling for most India launch budgets, and each one must be able to clear the threshold independently — an ad set that cannot is not a test, it is a permanently learning-limited line item. Split by something that genuinely changes the auction (a distinct country, a distinct optimisation event), never by creative: creative belongs inside one ad set, where Meta can allocate across it.

Deriving a Meta starting budget from the ~50-events rule, in four steps you can run on paper:

1. Pick the optimisation event and estimate its rate as a share of installs from your own data — say registration at 40%.
2. Divide 50 by that rate to get the weekly installs the ad set needs: 50 ÷ 0.40 = 125 installs a week.
3. Multiply by your tested Meta CPI to get the weekly ad-set budget. There is no published Meta CPI for India or any geography — Meta publishes none and every table claiming one is invented — so this step needs your own test spend or an MMP panel that discloses its sample. If you have nothing, run a fixed-budget App Installs test purely to measure it before you plan anything.
4. Divide by seven for the daily budget, and add headroom: the threshold is a floor for exiting learning, not a target.

Work the same arithmetic before picking a deeper event. If your purchase rate is 2% of installs and Meta needs roughly 50 purchase events a week, you need about 2,500 installs a week through that ad set before purchase optimisation is viable. Below that, optimise to registration.

The iOS complication

On iOS, Meta's Aggregated Event Measurement gives you up to eight conversion events per verified domain, ranked by priority, and only the highest-priority event triggered in a session is reported. Reordering that list pauses affected ad sets for a 72-hour cooldown — trade-press reported, not published by Meta, but consistent enough to plan around.

The 2026 change most playbooks miss: the standalone AEM tab and the manual ranking step were removed for many web accounts, but the eight-event model still governs iOS app campaigns. A 2026 post claiming AEM is gone is describing web and mislabelling it.

Conversions API for App Events

If you are sending server-side app events, Meta documents four mandatory parameters: action_source = "app", advertiser_tracking_enabled (the ATT state), extinfo (device information), and event_id for deduplication. Deduplication matches on event_id plus event_name. One asymmetry to plan for: install events get automatic 90-day deduplication; post-install events do not. If you fire a registration event from both the SDK and your server without a shared event_id, you will double-count it and optimise against inflated volume.

What does not exist for Meta

Meta publishes no app-install CPM or CTR benchmarks by category or geography. None. Every page you will find offering "Meta app install CPM by vertical, India, 2026" is fabricated. If you need a planning number, derive it from your own test spend or from a named MMP panel that discloses its sample — do not borrow one from a listicle.

Pick the deepest event in your funnel that still clears its platform threshold at your intended budget. Then move down exactly one rung at a time: install, registration, key activation, monetisation. Re-clear the threshold at each rung before the next move. Never skip a rung, and validate on Android before porting to iOS.

install  →  registration  →  key activation  →  monetization
cheapest, weakest predictor        most valuable, lowest volume

The documented gates you are working against:

Why optimising too deep too early fails

Four mechanisms compound.

Statistical starvation. The campaign never exits learning, delivery is throttled, CPA inflates — and you read the inflated CPA as evidence the channel does not work.

Sparse-signal overfitting. With too few events, the model fits noise. Google's corollary is its own guidance not to select more than one action for target CPA.

Reset cascades. Every fix resets learning, so volume never accumulates. On Meta, an AEM reordering adds that 72-hour cooldown. Three "small optimisations" in a fortnight can mean a campaign that has never once completed a learning phase.

iOS signal decay — the mechanism most playbooks omit. Deep events land in conversion windows two and three, which return only coarse values, never fine. At Tier 0 crowd anonymity, windows two and three produce no postback at all. A deep monetisation event on iOS may be structurally unmeasurable at low volume regardless of configuration. You are not doing it wrong; the data is not being sent.

The sequence that works

Launch on install or target CPI. Clear 100 conversions on Google or roughly 50 events a week on Meta. Move one rung down. Re-clear the threshold. Repeat.

Validate on Android first, where attribution is deterministic, then port the working configuration to iOS. The reverse means debugging your funnel through a coarse, delayed, truncated signal — which is guessing.

The rung you can reach depends on your conversion rates. A casual game with 30% day-one tutorial completion can optimise to activation almost immediately. A stock broking app with a multi-day KYC funnel may never generate enough completed-KYC events per ad set and has to use a mid-funnel proxy.

If Google is your only paid channel, Firebase alone is enough and free. The moment a second network exists, get an MMP. Running Firebase for Google and the Meta SDK for Meta gives you two incompatible definitions of the same event, and reconciling them costs more than the MMP.

Firebase key events into Google Ads, exactly

1. Log the event with the Firebase SDK's logEvent().
2. Mark it as a key event — GA4 renamed "conversions" to key events. Admin → Events → star icon, or Admin → Events → Create event → exact name → toggle "Mark as key event". Limits: 30 key events per standard property, 50 on 360. purchase, first_open and in_app_purchase are auto-marked. Not retroactive. Needs Marketer access or above, and can take up to 24 hours to appear.
3. Link: Google Ads → Admin → "Google Analytics (GA4) and Firebase" → select property → Link. Requires Admin on Google Ads, Owner or Editor on Firebase/GA4, and Play Console ownership for Android.
4. Import: Conversions → App → source "Google Analytics (Firebase)" → import the events.

Google's documented advantage: you can "import Firebase conversions without needing to add new code to your app."

Firebase versus an MMP

The seven certified App Attribution Partners are Adjust, Airbridge, AppsFlyer, Branch, Kochava, Singular and Tenjin.

The settings that silently break re-engagement

If you later run App campaigns for Engagement, these documented per-partner settings each break measurement if wrong: AppsFlyer — enable Google Ads Retargeting; Adjust — inactivity window to 0 days; Singular — enable re-engagement tracking; Kochava — reengagement tracker with deeplink event mapping; Branch — inactivity window to 0 days.

iOS gives you delayed, aggregated, privacy-thresholded postbacks. Android gives you deterministic user-level attribution and will continue to, because Google cancelled Privacy Sandbox for Android in October 2025. Plan iOS around aggregate measurement and Android around deterministic measurement. They are not one channel with a bid multiplier.

AdAttributionKit (iOS 17.4+, and unlike SKAN it works with alternative marketplaces as well as the App Store) has these documented windows:

Three conversion windows run from first launch: days 0–2 (postback delayed 24–48h), days 3–7 (24–144h), and days 8–35 (24–144h).

Crowd anonymity determines what you actually receive:

Fine conversion values exist only in the first postback, and only at Tier 2 or 3. Windows two and three are always coarse. Encode your single most important signal into the first two days or you will never see it.

The winning network gets up to three postbacks (did-win: true); up to five other networks each get one non-winning postback, installs only — no runner-up postbacks for re-engagement. Maximum 15 view-through impressions per publisher app, each expiring after 24 hours. No ATT prompt is required to call the attribution APIs.

SKAN and AdAttributionKit coexist: one impression wins, .adattributionkit and .skadnetwork IDs are compatible, click-through always beats view-through, a maximum of six impressions are considered, and calling SKAN's updatePostbackConversionValue automatically mirrors into AAK. Be precise about SKAN's status: it is no longer receiving new versions, and Apple has published no deprecation. Anyone writing "SKAdNetwork is deprecated" is wrong.

On Android, Privacy Sandbox was cancelled — announced 17 October 2025. Retired: Attribution Reporting API, Protected Audience, Topics, Protected App Signals, SDK Runtime, On-Device Personalization, Private Aggregation, IP Protection, Related Website Sets, SelectURL. Continuing: CHIPS, FedCM, Private State Tokens. GAID persists. Deterministic user-level Android attribution continues. Any playbook telling you to prepare for an Android ATT-style event is out of date.

Bootstrap at ₹2 lakh a month (about $2,300) buys one platform done properly. Funded at ₹10 lakh (about $11,400) buys both platforms plus a real creative cadence. Scale at ₹50 lakh (about $57,000) buys event-optimised campaigns and the measurement infrastructure to trust them. In all three, the monthly figure is the total marketing spend, and creative production and tooling come out of it — they are not extras sitting outside the media budget.

All three assume India-only targeting. The only published India cost datapoint anywhere in this post is AppTweak's $0.89 Apple Ads CPI; the ₹40 App Campaigns CPI used in the arithmetic is the illustrative bid flagged earlier, not a benchmark. There is no published India CPI for App Campaigns or Meta — measure your own and re-run every floor below against it.

On the Apple Ads share, before you read the table: iOS is roughly 4–6% of Indian devices. Every Apple Ads line below is deliberately set above that device share, because Apple Ads is the only channel with published India cost data and iOS users in India monetise well above the Android average. That is a judgement, not a documented rule. If your own revenue is not iOS-weighted, move that budget toward device share and put it into App Campaigns. Do not let a channel with good data pull an India budget toward a platform with 5% of the handsets.

Every creative figure above buys assets to the Google App Campaigns spec set out in the pre-launch section — headlines 1–5 at 30 characters, descriptions 1–5 at 90 characters, images at 1.91:1 (1200×628), 4:5 (1200×1500) and 1:1 (1200×1200) under 5 MB, and video at 16:9, 9:16 and 1:1, 10–60 seconds, uploaded to YouTube first. Build the 9:16 cut every time: it is the only ratio that serves App Campaigns, Meta placements and Apple Ads custom creative without a re-edit. An "asset" in the counts above means one concept delivered in all three image ratios plus a 9:16 and 16:9 video cut, not a single JPEG.

₹2 lakh (about $2,300) buys one platform, and the table means that literally — at this tier you fund App Campaigns or you fund Apple Ads, never both. If you are India-Android-first, which most consumer apps here are, that is App Campaigns. At a ₹40 (~$0.45) target CPI, the documented 50× rule puts your floor at ₹2,000 a day — ₹2,000 × 30.4 = ₹61,000 a month — so ₹61,000 is the minimum, not a target, and ₹60,000 does not clear it. The ₹1.5 lakh in the table is roughly 2.5× that floor, which is what "headroom" actually means: room to hold the bid steady through the 100-conversion learning gate without the daily budget capping delivery. Do not run three underfunded campaigns instead. If you are genuinely iOS-first, swap the whole ₹1.5 lakh into Apple Ads Advanced on the manual four-campaign structure, leave App Campaigns unfunded, and accept that Discovery takes most of month one to produce graduatable terms.

₹10 lakh (about $11,400) buys both platforms, an MMP, and enough volume that the 100-conversion gate clears in days rather than weeks. It is the first budget at which the event ladder is genuinely available: at a ₹40 CPI, ₹4.5 lakh on App Campaigns is roughly 11,000 installs a month — enough for a registration-optimised tCPA test at the documented 10× rule. Note what the creative line costs here: ₹1.2 lakh, or 12% of the total, is the realistic price of a fortnightly refresh at 10–15 assets, and it is the line that gets cut first and shouldn't be.

₹50 lakh (about $57,000) buys measurement you can defend: holdout tests, incrementality reads, and enough events per ad set for deep-funnel optimisation to have signal. It also clears the 50,000-install threshold for ACe, turning retention into a paid lever. At this tier creative is a standing production line at ₹5 lakh a month rather than a project, because a weekly cadence across three channels and five ratios is not something a freelancer delivers between other work.

None of them buy a fix for weak retention. If your D1 is materially below Adjust's undated cross-app figure of 26% combined, spend the money on the product.

Judge a channel on the deepest metric it has enough volume to report. Never kill a Google campaign before 100 conversions — that one is Google's documented gate — or a Meta ad set before roughly 50 events in seven days, a figure that is trade-press reported and has never been published by Meta. Before those points you are reading noise. After them, kill on cost per activation, not cost per install.

Read it top-down, demoting to a shallower metric only when the deeper one lacks volume. The two documented gates are marked; every other "when it becomes readable" figure in this table is a judgement heuristic, not a published threshold. Nobody publishes the sample size at which an install-to-registration rate stabilises, and the numbers below are the point at which the estimate stops swinging wildly in practice — treat them as a prompt to check your own confidence interval, not as a rule you can cite:

Two things to hold in mind at rungs 5 and 6. AppsFlyer's State of App Monetization 2026 (January 2025 to March 2026, covering $900M IAP, $800M subscriptions and $7.2B ad revenue) reports the share of D60 revenue already realised by D7 as 89% for in-app advertising, 60% for in-app purchases, 52% for subscriptions — that tells you how early payback is readable by model. RevenueCat's State of Subscription Apps 2026 (115,000+ apps, $16B tracked; they sell subscription infrastructure, so the framing is not neutral) reports D35 trial-to-paid of 10.7% on a hard paywall versus 2.1% on freemium.

Kill criteria, in order — and every threshold in this paragraph is a judgement heuristic I am proposing, not a documented one. No platform or panel publishes a kill rule; these are the tripwires that have held up for me and you should set your own numbers against your own margin. After a channel has cleared its learning gate, kill it when cost per key activation is more than 2× your next-best channel for two consecutive weeks; or D7 retention from that source is below half your blended D7; or your MMP flags a fraud rate above your category norm. The only part of this that rests on published evidence is the negative: do not kill on CPI alone — the cheapest installs in the market are the $0.06 incentivised ones from the ACM study, and one day later 1 to 4 of every 500 were still engaged.