"What should I bid on this term" is the most asked question in advertising, and whoever asks it expects a number back.
The keyword conversion endpoint returns 36 numbers for one term. That is not the endpoint being verbose — it is because the question is missing two qualifiers: which match type, and where in the market you intend to stand.
Where the 36 numbers come from
Four metric groups × three match types × three values each:
| Phrase | Exact | Broad | |
|---|---|---|---|
| Bid | phrasePpc | exactPpc | broadPpc |
| Cost per acquisition | phraseCpa | exactCpa | broadCpa |
| Suggested budget | phraseBudget | exactBudget | broadBudget |
| ACOS | phraseAcos | exactAcos | broadAcos |
None of them is a single value. Each is an object carrying min, max and value.
Note that value is the median, not a recommendation. That deserves emphasis, because the field name invites reading it as "the system suggests bidding this." What it actually means is: among advertisers running on this term, the middle of their bids sits here.
What bidding the median actually means
Set your bid to exactPpc.value and the result is parity with the market — you will not clearly win and you will not clearly lose. As a cold start on a new term that is reasonable. It is not a strategy.
The range is the part carrying information:
maxfar abovemin→ participants disagree sharply about this term. Usually it means its value differs a lot by product, and it is worth testing yourself- A narrow range → everyone's arithmetic agrees, so the further you sit from the median the more you need a reason
- Wanting to bid near
max→ only holds when your conversion rate is clearly above average
That last point is the load-bearing one. What lets you bid high is not a bigger budget, it is a higher conversion rate. On the same term, someone converting at twice your rate can bid twice as much at the same ACOS. So conversion comes before bids.
Read conversion first, bids second
The same call returns these:
| Field | Meaning |
|---|---|
searches | Search volume |
clicks | Clicks |
purchases | Purchases |
searchConvRate | Search conversion rate |
clickConvRate | Click conversion rate |
clickingRate | Top-three click rate |
conversionRate | Top-three conversion rate |
clickConvRate is the one to read first: it sets the ceiling on what you can afford to bid. A term converting at 2% and one converting at 8% support bids four times apart, even when their median bid is identical.
The order that works: estimate what the term is worth to you from clickConvRate, then use the exactPpc range to see where that estimate sits in the market. Doing it the other way round — checking what others bid and matching it — is pricing yourself using someone else's conversion rate.
The ACOS range rules out "not my problem"
phraseAcos, exactAcos and broadAcos return how ACOS is distributed across the market for that term.
This group works the same way as the market layer in rank monitoring: first establish whether the term is simply expensive, or whether you are running it badly.
- Your ACOS well above
exactAcos.max→ probably yours (conversion, listing, price) - Your ACOS inside the range and still unprofitable → that is what the term costs in this category; the decision is whether to run it at all
- The whole range is high → a heavily contested term, suited to someone with brand premium
The usual cost of skipping this step: repeatedly reworking creative and the listing for a term that was always expensive in that category, when the problem was never there. It is the same move as "rule out the market first" in Monitoring Amazon keyword rank, applied to advertising.
Why the three match types price differently
Exact, phrase and broad usually carry different ranges, and the reason is not platform preference. It is traffic purity.
- Exact brings the tightest traffic, usually the highest conversion, and therefore supports the highest bid
- Broad brings a large tail of unrelated searches, diluting average conversion, so it supports a lower bid
- Phrase sits between them
So when broadPpc comes in below exactPpc, do not read it as "broad is cheaper, therefore better value." It is cheaper because the traffic it brings is worse. Same currency, different goods.
Use the filters in reverse to find terms
The request takes a long list of min/max filters, which works in the other direction — not looking up one term's price, but finding terms by price conditions:
| Terms you want | Conditions |
|---|---|
| Cheap and converting | maxPpc with minClickConvRate |
| Manageable ACOS in the category | maxAcos |
| Volume that has not been bid up yet | minSearches with maxPpc |
| Acceptable acquisition cost | maxCpa |
includeKeywords and excludeKeywords add a root-word filter on top. This beats exporting a few thousand terms and filtering in a spreadsheet, and it costs fewer calls.
Three things this data cannot do
It cannot give you your own advertising reports. Your actual spend, actual ACOS and search term report live in Seller Central as authorized data. Everything here is the market-side distribution.
It cannot decide your bid. It gives you the market range and the conversion basis; the final number depends on your margin structure, which the endpoint does not know.
It is not a live auction price. It returns a statistical distribution over a window, not what the auction clears at right now. Use it to set strategy ranges, not for minute-level bid changes.
Questions
Can I use value as my bid directly?
As a starting point, yes, but it is a median rather than a recommendation. Bid the median long enough and your results match the market average.
Which match type should I run? Validate with exact to learn which terms actually convert, scale with phrase, and use broad for discovery alongside negative keywords. Set bids from each range separately rather than applying one number to all three.
Why does my actual CPC not match exactPpc?
A bid is a ceiling; what you pay is set by the auction and is usually lower. Beyond that, the endpoint reports a market distribution, while your real cost also moves with relevance and time of day.
How often does this data update?
The endpoint's timeType supports a weekly view and a trailing 90-day view. Pick one and stay on it when judging trends rather than comparing across the two.