Field guide

The PPC field guide for AI-tool buyers

A working operator’s guide to evaluating, buying, and integrating AI-marketed tools into a paid-search stack. Practical, not theoretical.

R
Ruchika Rajput
PPC strategist · LinkedIn

If you’re here, you probably read a vendor pitch claiming AI and wanted a second opinion. This guide is the second opinion. It covers how to read AI marketing claims architecturally, how to evaluate a tool before buying, what to do after buying, and what the recurring failure modes are.

Section 1: How to read AI marketing claims

The single most useful skill in this category is decoding vendor language back to architecture. Three patterns to watch for:

The “AI-powered” tell

Real ML teams describe their systems by architecture name: “a gradient-boosted bid model,” “a per-account neural-network optimizer,” “a transformer-based audience expansion model.” The architecture is part of the description because the architecture determines the capabilities.

“AI-powered” as a phrase is overwhelmingly used by marketing teams that don’t have a technical description to use. If a vendor’s primary description of their product is “AI-powered,” that’s a flag.

The “trained on industry data” flag

When a vendor says their model is “trained on industry data” without specifying which industry data, where it came from, or how it’s refreshed, the phrase is doing rhetorical work. Real ML training data is named: “our model is trained on the customer’s own conversion stream,” or “our model is trained on aggregated benchmark data from the 12,000 accounts on our platform.” Specificity is the signal.

The “our AI” phrasing

Real ML systems are plural and named: “our bid model, our pacing model, our audience-expansion model.” A vendor that refers to “our AI” as a single entity is usually describing a wrapper, not a system.

Section 2: The pre-purchase diagnostic

Before buying any tool that claims AI, run the six-question diagnostic from the methodology page:

  1. Is there a machine-learning model in the product? What type?
  2. What does the model take as inputs?
  3. What does it output?
  4. How is it trained? On what data? Refreshed how often?
  5. If the AI were removed, would the product still function?
  6. Can you provide technical documentation that supports the above?

Insist on the questions being answered by a product engineer or product manager, not a sales engineer. The answers from sales are systematically less accurate — sales engineers are trained to redirect technical questions to outcomes.

Section 3: Match the tool to the spend tier

Real ML bidding tools require conversion data volume to train per-account. Below the data-volume threshold, the model doesn’t see enough conversions to outperform Google’s portfolio-trained Smart Bidding. The threshold varies by tool but generally falls around $20–25K/month in paid-search spend.

Section 4: Post-purchase — what to do in week one

The first week with any new tool is the make-or-break window. The most common reason a tool deployment fails is operator over-intervention — the human keeps adjusting bids and breaking the model’s exploration phase. Three rules:

Rule 1 Don’t intervene for 14 days. The first two weeks are the model’s exploration phase. Performance will be volatile. Resist the urge to adjust bids, change budgets, or switch strategies. If something is genuinely broken (account is paused, no conversions are firing), fix it. Otherwise, let the model run.
Rule 2 Audit conversion events first. Real ML systems optimize against your conversion events. If the events are wrong (firing twice, misclassified, missing offline data), the model will systematically waste budget on the wrong thing. Audit before activation.
Rule 3 Set a measurement window. Decide in writing how long you’ll let the test run before judging. 90 days is the typical agency-tested window. 30 days is too short. 60 days is borderline. Without a pre-committed window, the test gets killed prematurely.

Section 5: The recurring failure modes

Across roughly thirty client deployments, these patterns repeat:

Failure 1: The tool is real ML but the conversion event is wrong

The most common cause of a failed deployment. The model is doing its job — optimizing the metric you told it to optimize. The metric is just the wrong thing. Fix is upstream: audit and rebuild the conversion-event taxonomy before activating the tool.

Failure 2: The operator can’t stop intervening

Especially common for senior operators who built their reputation on hands-on bid management. The model’s exploration phase looks like failure; the operator intervenes; the model resets; the operator concludes the tool doesn’t work. The intervention itself is the failure.

Failure 3: The account is too small for per-account training

Sub-$10K/month accounts. The model literally doesn’t have enough data to train on. Native Smart Bidding outperforms because it has access to portfolio data the third-party doesn’t. Match the tool tier to the spend tier.

Failure 4: The vertical is too seasonal

Models trained on the past 90 days lag a sharp seasonal shift. A summer-DTC ecom brand that activates a tool in March and hits Black Friday in October finds the model wasn’t trained on holiday patterns. The fix is either to skip seasonal-peak activation, or to apply manual overrides during known seasonal shifts.

Section 6: What to ask vendors that you usually don’t

Three questions that vendors universally don’t want to answer but you should ask anyway:

Section 7: When NOT to buy any AI marketing tool

The biggest mistake in this category is buying a tool when the actual problem is upstream:

The category does a lot of good work; it can’t do work upstream of itself. Buyers who treat tools as the answer to non-tool problems pay for tools and then conclude that tools don’t work. The tools didn’t fail; the diagnosis did.