What to measure before you spend on app installs

Cost per install falls when you buy worse installs. That is the whole problem with it as a target.

App campaigns are good at finding the cheapest install available, and the cheapest install is usually on a device or a placement where the app opens once and never again. Spend moves there, the cost per install chart slopes pleasingly downwards, and the number of people who register stays flat. On the property we audited on 6 October 2026, 231 of 293 users in 28 days were new, about 98% of paid sessions came from one app campaign, and the only thing the campaign could be graded on was the install itself.

The second problem is that an install is not a decision about your product. It is a decision about a store listing. Everything you care about happens afterwards, and if none of that is measured the campaign is being marked on the easiest question on the paper.

Media and management are separate numbers. Our management fee is the higher of 15% of monthly media or ₹50,000 plus GST a month, and the rate on the whole budget falls to 10% from ₹20,00,000 of monthly media, 8% from ₹50,00,000 and 4% from ₹1,00,00,000. Media is paid to the platform directly.

A sensible media floor for an app campaign in India is ₹50,000 to ₹1,00,000 a month. Below that the campaign spends its life in the learning phase, and you learn about your budget rather than about your audience.

Hold part of the first month back. We would rather spend the first fortnight shipping sign_up, login and purchase than spend the same fortnight buying installs nobody can evaluate. The ad budget calculator will split a budget across channels; the table below is only the fee on the media.

Six events, in this order of usefulness: purchase, appointment_booked, test_complete, test_start, sign_up, login. That is close to the reverse of the order in which they are easy to get.

sign_up is the first honest signal. It means a real phone number, a verified code and a person who decided the app was worth an account. On an install campaign it is the earliest event that cannot be produced by a careless tap, which is why it ships first and gets marked first.

purchase has to carry value and currency as parameters, every single time. Without them the revenue column reads zero, which is exactly what we found on this property: $0 against 711 key events, because purchase had never been sent at all.

Link the two accounts, then mark the in-app events as key events, then the bidding options appear. In that order, and the order is not negotiable.

Google’s App campaign bidding documentation puts it plainly. To bid for in-app actions you need to set those actions up as conversion events in Google Ads, or use Firebase, and after you have linked Firebase and Google Ads you can bid on the in-app events you have set up as conversions. It also calls Firebase the simplest way to track all of your app conversions, which matches what we see. The alternative is maintaining conversion definitions in two systems that slowly disagree.

One sequencing detail costs people a week. GA4 marks an event with the star in Admin, Data display, Events once Analytics has received it, and an event that has not arrived yet can be marked ahead of collection so it counts from the first hit. Standard reports can take up to 24 hours to show it, and marking does not change historic data. Mark on release day.

Google’s bidding article for App campaigns lists target cost per install and maximise conversions for installs, maximise conversions for in-app actions, maximise conversion value, target cost per action for in-app actions, target cost per action for pre-registrations, and target return on ad spend.

Everything except the install options needs in-app conversions to exist. Target return on ad spend needs more than existence: it needs a revenue value on the event, which means value and currency on purchase, and a value that reflects the real order rather than a flat placeholder somebody put in to make the integration pass.

Pick one in-app action per campaign. A campaign asked to chase sign-ups and purchases at the same time blends two very different values into one target and aims at neither properly. We run installs and in-app actions as separate campaigns for that reason, and it is the first structural change we make in a Google Ads account we take over.

Switch it on now, even if nobody queries it for a year. The export is the only place raw event rows survive after GA4’s retention window closes, and you cannot backfill it later.

The limits, from Google’s documentation. A standard property has a daily BigQuery export limit of 1 million events, with filtering options to stay under it. Daily export delivers the previous day’s complete unsampled data, usually mid-afternoon in the property’s timezone, with no guaranteed time.

Streaming export is near realtime with no volume limit, is a best-effort service without a completeness guarantee, and adds $0.05 per gigabyte. You can start in the free BigQuery sandbox, and exports beyond the sandbox limits are charged along with the usual storage and processing costs.

For an app at a few hundred users a month, daily export only, into the sandbox, and nobody needs to look at it. It is worth setting up at that size precisely because it costs almost nothing at that size. The month you have to answer a question about last March is the month it stops being optional.

Android was about 87% of key events on this app, web about 8% and iOS about 5%. That is not a reason to drop iOS. It is a reason to stop reading blended numbers.

A blended cost per sign-up across an 87 to 5 split is an Android number with a rounding error attached. Split the campaigns so each platform carries its own target, because a single target applied to both gets set by whichever platform has the volume, and iOS then quietly underdelivers against a number that was never meant for it.

The 8% on web matters too. If people register on the web and use the app, or the other way round, the event names have to match on both sides or the funnel stops at the platform boundary. We use one plan across both when we build the app and the site together.

Nine checks, and we will not start an app campaign without them.

sign_up, login and purchase firing on a real device in DebugView. value and currency arriving on purchase. Event data retention set to 14 months rather than 2. session_start and screen_view not marked as key events. The six real key events marked. Firebase linked to the ad account. BigQuery export switched on. Screen names that read like screens instead of class names. And a saved funnel exploration, from first open to purchase, that one named person has agreed to open every week.

That list took two days on the app in this post, on 6 and 8 October 2026. Two days against a media budget that was already running is not a delay. Performance work that starts before the measurement does is how an account ends up with a year of cheap installs and no idea which campaign ever produced a customer.