AI campaign QA: Check localisation before scaling setup

What the 159-campaign example makes visible

In her published LinkedIn post, Aashna describes an AI-assisted launch of approximately 159 campaigns in different languages. She found city names that had not been translated and English keywords appearing in other-language campaigns. Some campaigns were not spending.

That is a reported account experience, not a controlled study of AI performance. It does not establish that every untranslated place name is wrong or that localisation alone explained every delivery issue. It does show why setup speed needs an independent check.

The workflow below develops that observation into a practical review method. It is a proposed approach to evaluate, not a claim that Aashna has already built a QA agent or measured a particular saving from one.

• Aashna’s original LinkedIn post: multilingual campaign setup and localisation gaps

Start with a brief that defines what correct means

Give each market an approved specification: language, geography, services, destination URLs, currency where relevant, offer terms and the conversion being measured. Include exceptions such as brand names or place names that should retain a particular form.

Translation and localisation are different tasks. A phrase may be grammatically translated while failing to match how customers search in that market. Conversely, a city may legitimately be known by its original name in a second language. The checker needs context before it can classify either case as an error.

Use a market reviewer to approve representative queries and offer wording. Keep those examples with the brief so the assistant has something concrete to compare against. A generic request to “make it local” leaves too much room for confident assumptions.

Give the checker a bounded job and a reviewable output

Begin with exports or read-only inputs. Ask the assistant to compare the build with the approved specification and return the exact rows that appear inconsistent. It should recommend a review, not silently rewrite or publish the account.

An illustrative instruction is: “Use only the supplied brief and campaign rows. Return campaign ID, field, observed value, expected rule, evidence and uncertainty. Flag missing rules. Make no changes. Treat approved brand and place-name exceptions as valid.”

Keep observations separate from proposed corrections. A mixed-language keyword is an observable difference; the correct market phrasing may require a native speaker. That distinction makes the report easier to evaluate and avoids turning the checker into a second unverified builder.

Test the QA assistant before trusting the clean report

Create a small evaluation set containing known errors and known-valid exceptions. Include wrong-language copy, a mismatched page, an unsupported service area and a place name that should remain unchanged. Keep this separate from a live account so the evaluation cannot spend money.

Track missed errors and false alarms separately. In a hypothetical sample with ten planted errors, catching eight means two remain missed. If the assistant also flags five correct rows, the human review burden is different from a checker that flags only the eight real problems.

Do not present that small exercise as a production accuracy rate. Vary the examples, include ambiguous cases and use unseen rows for the next evaluation. Keep examples used to write the instructions separate from the examples used to judge the result.

Review delivery without assuming every problem is a language problem

A campaign that does not spend can have several constraints. Inspect approval, dates, location settings, traffic availability, budget and bidding conditions alongside language. The localisation story is a reason to check one failure mode, not a complete troubleshooting tree.

Google’s ad-review documentation makes clear that creating or editing an ad starts a review process. Confirm actual status and delivery rather than treating a generated campaign export as evidence that ads are reaching buyers.

Then inspect the experience after the click. The correct-language ad can still lead to the wrong page or a form whose confirmation uses another language. Walk through the inquiry and follow-up with the market reviewer, including mobile behaviour.

• Google: ad review, eligibility and launch timing
• Keep AI support tasks separate from consequential account decisions

Scale the workflow after it demonstrates useful judgment

Start with one representative market and campaign group. Compare the assistant’s output with a human review. Record preparation time, review time, corrections and what the checker missed. A fast report is not useful if it shifts more hidden work to the reviewer.

Expand only when the output remains reliable under the conditions the next batch introduces. A different language, service or naming convention is a new source of uncertainty. Retain a person who can approve the final build and stop a launch when an important question remains open.

The first agent worth adding may be the one that makes the work easier to inspect. Its value comes from identifying specific discrepancies and preserving uncertainty. More campaign rows become useful after the business knows which ones it can trust.

• Agree launch boundaries and stop conditions

Frequently asked questions