tCPI, tCPA or tROAS: Choosing the Right Bid Strategy

Start with eligibility, not preference — Google publishes a conversion-volume requirement for target ROAS on App campaigns, and it disqualifies most of the accounts that ask for it. The bid strategy debate that consumes a planning meeting is usually settled in one line of documentation.

Google's Target ROAS bidding documentation lists eligibility by campaign type. For App campaigns the requirement is stated as at least 10 conversions every day, or 300 conversions in 30 days. That is conversions of the biddable event you intend to optimise toward, not installs in aggregate, and for a purchase event on a young app it is a demanding bar.

The same logic applies one rung down. Google's Target CPA documentation advises measuring performance over periods that have at least 30 conversions, which tells you something about the volume at which a target becomes readable at all. Below that, you are not evaluating a bid strategy — you are reading noise and calling it a result.

So the order of operations is fixed. Ask what your biddable event produces per day, then pick the most specific strategy that volume supports. Across the 300+ apps we have managed since 2013, the single most common cause of a stalled App campaign is a target defined for an event that fires a handful of times a week. The campaign is not underperforming; it has nothing to learn from. If yours is not spending at all, the causes are slightly different and we cover them in why your App campaign is not spending.

Each strategy is a different statement about what you are willing to pay for, and the wording in Google's own documentation is more precise than the shorthand teams use. Getting the definitions straight removes half the confusion before you compare them.

Google's App campaign bidding documentation defines them plainly. Target cost per install lets you choose how much you are willing to pay to acquire a new user for your app. Target cost per action lets you choose how much you are willing to pay for a new user for your app who is more likely to complete the in-app event you selected. Target ROAS lets you set how much dollar value you want back for every dollar you spend. Maximize conversions comes in three variants — for installs, for in-app actions, and for conversion value — and automatically sets bids to get the most conversions, or the most conversion value, while spending your daily budget.

Read the target CPA definition again, because it is routinely misread. You are not paying per in-app action. You are paying per install, and telling the system to prefer installs that look likely to complete the action. The target is expressed against that action, but the auction you are entering is still an install auction.

Google's overview of App campaigns also names the campaign subtypes that constrain the menu: App campaigns for installs, App campaigns for engagement, and App campaigns for pre-registration. Pre-registration carries its own strategy, target cost per pre-registration, and engagement campaigns target existing users rather than new ones — so the tCPI-versus-tCPA-versus-tROAS question really only applies within the installs subtype.

Because the optimal bid can exceed your entire daily budget, and Google says so outright: campaigns in that position may not be able to get any conversions. This is the failure mode that produces a campaign spending nothing and a team blaming the creative.

The bidding documentation states it directly. For Maximize conversions campaigns with small budgets, the optimal bid per conversion may be higher than your budget, and Maximize conversions campaigns with small budgets may not be able to get any conversions. There is no target to relax, so there is no lever to pull other than the budget itself.

Google's Maximize conversions documentation adds the other half of the risk. The strategy will try to fully spend your average daily budget, and if you are currently spending much less than your budget, Maximize conversions could increase spend significantly. Both failure modes come from the same design: the budget is the only constraint the strategy respects.

What is not publishable is the threshold. Google does not state a currency amount at which a budget becomes "small", and it varies by market, event and competition — so we will not print one. The workable test is arithmetic you can do yourself: if your daily budget does not comfortably cover several conversions of the type you are optimising toward, at the cost you have historically paid for them, the budget is small in the sense the documentation means. In our portfolio that is the check that catches it, not a benchmark table.

The practical consequence is that Maximize conversions belongs where budget is genuinely uncapped in spirit and you want the system to find the ceiling. Where cash is the binding constraint, a target-based strategy at least keeps the cost per outcome inside a number you chose. We work through the cash side of that in budgeting user acquisition against payback.

When you do not yet have enough post-install signal for anything else to learn from, or when the install itself is genuinely the outcome you are buying. tCPI is the default not because it is crude but because it is the only strategy whose feeding event fires on every single conversion.

Three situations make it correct rather than merely convenient:

• A new app or a new market. There is no post-install history for the system to generalise from, and a target defined on a rare event gives it nothing to optimise. Our guide to soft launch sequencing covers what to establish before you tighten the objective.
• A biddable in-app event that does not clear a usable daily volume. If registration fires a few times a day, a target on registration is a target on noise.
• Genuine install-value businesses. Where monetisation is ad-based and largely uniform per user, the install really is close to the unit of value, and the extra specificity of tCPA buys little.

The known weakness is worth stating plainly, because it is the reason nobody wants to stay on tCPI. The strategy is indifferent to what happens after the install. It will happily find you the cheapest installs available, and cheap installs are frequently cheap for a reason. That is not a defect in the bid strategy; it is the objective you gave it.

Which is why tCPI should be treated as a stage rather than a destination. The job while you are on it is to accumulate enough of the post-install event you actually care about to become eligible for something more specific. Instrument the event, verify it is firing and attributing correctly, and watch its daily count. When that count is consistently supporting a target, move. Until then, tightening the objective just starves delivery.

Google's overview describes the system testing asset combinations and serving the best-performing ads across several formats and networks, so an underfed creative set can look like a bidding problem — we separate those in creative strategy for app campaigns.

When one event reliably predicts the value of a user, fires often enough to be learnable, and is measured properly — all three, not two of three. Moving from tCPI to tCPA is the highest-return change most App campaign accounts can make, and also the one most often made too early.

Pick the event on predictive power, not on how important it sounds. The right event usually sits earlier in the funnel than the commercial event: not the subscription, but the step that most reliably precedes it. That trade is deliberate — you give up some correlation with revenue in exchange for a volume of signal the system can learn from.

The measurement precondition deserves the emphasis it gets in step one. In our experience, a clear majority of failed tCPA migrations are attribution problems wearing a bidding costume: the event fires in the app, never reaches the ads account, and the campaign optimises toward an outcome it never observes. Our attribution guide covers the plumbing, and why Firebase numbers look wrong covers the discrepancies that follow.

Because a target applied to two events becomes an average of two things you value differently — and Google explicitly advises against it. This is the most common self-inflicted wound in App campaign bidding, and it is invisible in the interface.

The setup guidance is unambiguous: it is not recommended to select more than one action, as doing so effectively makes your set tCPA a blended target for two or more actions with potentially different values. The interface will let you tick both boxes. Nothing warns you at the point of the mistake.

Consider what that blend does. Suppose you select registration and purchase together. A registration is worth a fraction of a purchase to you, but the target treats a conversion as a conversion. The strategy can hit your blended number by finding registrations cheaply, and it will, because they are more plentiful and cheaper to find. You will hit target and miss the point.

The setup guidance also flags a related trap: optimising for frequent actions such as session start results in a higher number of conversions than usual. A high-frequency event will dominate any target it is part of, and will make the campaign look extremely efficient against a metric with no commercial meaning.

The fix is structural. One campaign, one biddable action, one target. If you want registrations at one price and purchases at another, that is two campaigns, and the reporting is cleaner besides.

A specific SDK, values attached to your events, and a stated conversion volume — and the SDK requirement alone rules out a lot of stacks that assume otherwise. tROAS is the only App campaign strategy that can tell a high-value user from a low-value one, which is exactly why its preconditions are the strictest.

Google's bidding documentation states that target ROAS requires the Google Analytics for Firebase SDK. That is a hard integration requirement, not a preference, and teams running a third-party measurement partner without Firebase in the app frequently discover it at the point of trying to switch. Google Analytics for Firebase is described as an app measurement solution, available at no charge, that provides insight on app usage and user engagement, with unlimited reporting on up to 500 distinct events.

Then the values. A return target is meaningless unless your events carry monetary value, which in practice means logging purchase events with a value and a currency parameter, as Firebase's ecommerce measurement documentation sets out. An event that fires without a value contributes a conversion count to a strategy that is trying to optimise a sum.

Then the volume, from the Target ROAS documentation: for App campaigns, at least 10 conversions every day, or 300 conversions in 30 days.

One more property to plan around. Google notes that a higher ROAS target will narrow the pool of potential installs, whereas a lower ROAS target will typically enable the campaign to have more potential to scale. tROAS is therefore a volume dial as much as an efficiency dial, and an aggressive first target will simply shut delivery down. The related documentation for the strategy makes the same point in general terms: setting a target that is too high may limit the amount of traffic your ads may get.

If you are working out what your target should be in the first place, that is a unit economics question rather than an ads question — our ROAS and CAC guide sets out the arithmetic.

Set it from what you have actually observed, then change it slowly, because the documented behaviour is that the bidder reacts immediately but needs one to two conversion cycles to reach a new target. Most target-based campaigns are not badly configured; they are edited too often to ever settle.

For tROAS, the setup guidance gives the calculation directly: conversion value divided by ad spend, multiplied by 100%, equals your target ROAS percentage. It also directs you to identify your biddable event's conversion window first, which is the step people skip. If value arrives over a fortnight and you compute a target over a week, you will set an impossible number and conclude the strategy does not work.

Two documented behaviours should shape your editing rhythm:

• Targets are averages, not caps. Google describes your average target ROAS as the traffic-weighted average ROAS that your bid strategy optimised for, and states for target CPA that Google Ads will try to keep your cost per conversion equal to the target you set. Individual conversions above the target are expected behaviour, not a malfunction.
• Reaction is instant; convergence is not. After a change, the bidder reacts immediately but needs some time to hit the new target — Google suggests giving it one to two conversion cycles. Editing again inside that window means you never observe the result of the previous edit.

On direction of error, the documentation cuts both ways and it is worth holding both. Setting a target that is too low may cause you to forgo clicks that could result in conversions, resulting in fewer total conversions. Setting one too high may limit the amount of traffic your ads may get. Neither over-tight nor over-loose is the safe default, which is why the observed-cost starting point matters more than the philosophy.

Google Ads also offers a comparative route rather than a destructive one: rather than editing a working campaign directly, the target CPA documentation describes saving a change as an experiment, which runs your new settings against the original campaign. When the stakes are a live spending campaign, that is the version to use.

Work down from the most specific strategy your measurement and volume can support, and stop at the first one that holds. That single rule replaces almost every framework you will be offered for this decision.

This decision is not a permanent commitment — the correct strategy for an app changes as its measurement matures, and reviewing it once a quarter is reasonable. Where the campaign competes against other channels entirely, that is a different comparison and we set it out in Google App campaigns versus Meta versus CPI networks.

One deliberate omission in this article: we have not printed benchmark target CPIs or ROAS figures by vertical or market. Google does not publish them, they vary enormously by country, event definition and season, and a benchmark quoted from an unverifiable source is worse than no benchmark, because it becomes the number your team optimises toward. Your own observed cost per event over a readable window is the only starting target we will endorse.

If you want a second opinion on which strategy your account is actually eligible for, and what the measurement work is to reach the next one, tell us what your biddable event does per day — or see how we structure paid acquisition in our user acquisition work.