A quick primer
The «Bid strategy constrained by target» status by itself doesn't say whether the target is realistic or not — it simply records the fact that the target is constraining volume. The problem is that a target can constrain volume in two fundamentally different ways: (1) it's genuinely demanding relative to the current state of the auction (a real, justified trade-off between efficiency and volume), or (2) it's artificially too low or too high because of an error in the calculation or the underlying data — in which case the "constraint" doesn't reflect a real business decision, but a technical problem.
The most common cause of an artificial constraint is a poorly calculated base that the target itself is derived from. For example, if tROAS is set based on "raw" revenue but the actual conversion value being passed is distorted (double-counted, understated by a static default value, or not adjusted for refunds), then the target derived from that data is itself flawed, and the constraint it creates is artificial. The official description of how conversion value should be passed correctly is in Google Ads Help's article on setting up conversion tracking. Another common cause is that the target was set a long time ago, based on economics or a competitive landscape that has since changed significantly, and hasn't been revisited to reflect the accumulated learning history of automated bid strategies since; technically that's not a data "error," but it's fundamentally the same problem — a decision made on information that's now outdated.
What to check before you touch anything
- How was the current target actually calculated — based on the account's real historical data, on industry averages, or is it an arbitrary figure inherited from the account's early days with no substantive calculation behind it?
- Is conversion value (for tROAS) or the conversion actions themselves (for tCPA) being passed correctly? Distortions at this level make the target derived from that data unreliable.
- When was the target last revisited, and what's changed in the auction, competition, or business economics since then?
- Does the target match what's actually achievable when running without a target (Maximize Conversions/Maximize Conversion Value)? A large gap between the "natural" result and the stated target suggests the target may have been set without a real anchor in auction data.
- Was the target set based on a one-off event (say, an unusually good or bad month) rather than a stable average trend?
Possible approaches
- If problems are found in how conversion data is passed (value, refunds, double-counting), fix those first, then reassess how realistic the target is based on corrected, reliable data.
- If the target was set a long time ago and never revisited, temporarily switch to Maximize Conversions/Maximize Conversion Value without a target, look at today's "natural" auction result, and build a new, current target from that number rather than trying to nudge an outdated value.
- If the target was set under the influence of a one-off anomalous period, recalculate it based on a longer, more representative stretch of data rather than relying on an atypical month.
- If the data is correct and the target has simply gone unreviewed for a long time, it's worth setting a regular review cadence (say, quarterly) for CPA/ROAS targets as part of standard account management, to avoid repeating this situation in the future.
- If, after checking the data and recalculating, the target turns out to be realistic and well-founded, the constraint really isn't artificial, and the decision to make isn't about fixing an error — it's a deliberate trade-off between efficiency and volume.
- Checking conversion data accuracy, target revision history, and comparing against the "natural" result without a target by hand requires pulling together data from several sections of the interface and the account's change history. Our tool (DataMind) checks the configuration of every goal in the account at once — including whether conversion value is being passed correctly — and immediately flags if the target itself, based on the underlying data, was set on shaky ground, before you even decide whether to change it.