App Campaigns Rebuilt Around In-App Value, Not Installs

An app campaign bidding to installs will hit its cost-per-install target and starve revenue, because the bidder optimises exactly the event you name and nothing adjacent to it. This engagement moves the target event down the funnel — install, then registration, then first paid order — and holds it there through the relearning period, which costs money before it returns any. Whether that move is available at all is arithmetic rather than ambition: a campaign bidding to a target CPA needs on the order of ten of that event a day to stay out of permanent learning. At forty first orders a week you do not get to bid to first orders across four campaigns. You bid to it in one consolidated campaign, or you bid to a mid-funnel event and carry a modelled value forward. Measurement before bidding: The first week goes into event plumbing, because nothing downstream survives it being wrong. Which events the Firebase or GA4 SDK actually sends. Which of them are set as conversion actions in Google Ads, and which are counted twice because a server-side import was bolted on later and never reconciled against the SDK. Whether purchase value arrives gross, net of refunds and chargebacks, or as a placeholder somebody hard-coded during QA. On iOS I work through the SKAdNetwork conversion value schema and, from 17.4 upward, AdAttributionKit: the fine and coarse value mapping, and whether the postback windows are arranged so the event you care about can land inside the first one at all. Most schemas I open were written to count installs and never revisited after the app started charging for something. Structure that reporting can survive: Campaigns get split where the decision differs, not where the dashboard looks tidier. Asset groups are named so that six weeks later you can still tell which cut of which video carried the spend. Israel sits inside a worldwide campaign as a geo rather than as its own campaign, unless the Hebrew creative genuinely differs — for a delivery app it usually does, because the offer language does. I read the store listing because it feeds the ads and constrains what the system can assemble, and I tell you where it is fighting the campaign. I do not rewrite it. What I will not do: Run install-volume campaigns against a CPI target. Add campaigns to absorb a budget the event volume cannot support. Manage Apple Search Ads — a different auction and a different practice, and I will not pretend the two are run as one thing. Produce creative: I brief it, review it against what reporting can separate, and reject assets that cannot be attributed, but I am not your studio. Who should not book this: Pre-launch apps, where there is no post-install behaviour to bid toward and the honest answer is to wait. Apps monetised only through ad mediation, where the value signal is an eCPM estimate and the plumbing question belongs to someone else. Teams who want the account handed back after four weeks with a playbook, since the relearning period alone outlasts that. How it runs: One working session a week with whoever owns the SDK and one with whoever owns the P&L, because those two answers rarely match on day one. Every change goes into a dated log with its reason and its expected direction, so a result three weeks later is attributable to a decision rather than to memory. I hold targets steady through learning and say so in advance. Clients find that part hardest, and it is the part that makes the numbers readable at the end.