These answers cover measurement and operations.

More than one on each side, and enough total volume that the exposed series can move against its own daily noise. Our matcher ranks every candidate against the test market and the post-flight readout uses the best two, from a candidate list of twelve UK conurbations. The number that actually decides feasibility is not the market count but the required sample days, which comes out of the power calculation on your baseline mean and standard deviation. Two exposed markets with high volume and well-matched controls beat six thin ones.

Only if you are willing to withhold media somewhere, which is what makes it a test rather than a report. A campaign that buys everywhere has no holdout, so its incrementality cannot be measured this way. The alternative designs (modelled attribution, marketing-mix modelling) produce estimates rather than causal evidence, and should carry a different label when they do.

Because the number is not a weak result, it is a random one. An underpowered design produces estimates that swing across a wide range from noise alone, so the figure it returns says more about which fortnight you happened to run than about the media. Once that figure is in a slide it is indistinguishable from a measured one, and it will be defended in a budget meeting six months later. Returning the required sample days instead tells you what would have to change.

It depends on the lift you want to detect and how long you can run. At the noise floor, a 28-day test can detect a 15% lift from about 25 conversions a day in the test market, and a smaller effect or a shorter flight needs more. Real series are noisier than the floor, so check your own coefficient of variation against the first table before you plan the flight.

No budget figure answers that on its own, because the power check never reads the budget. What decides it is the extra conversions the test market has to produce, which the tables give you, times your own incremental cost per conversion. Compare that product with what the test market will actually receive, and if it falls short, change the design before you spend.

Because its baselines are deterministic sample data scaled to population, and they swing far less than a real advertiser's conversions: in every sandbox market the day-to-day variation is around a tenth of the mean. That exercises the method and says nothing about what your business can power, which is why this guide uses stated assumptions and leaves sandbox output out.

Sometimes, and the budget is the wrong place to start. The power check reads the test market's daily conversions and how much they swing, and never the budget, so a business with steady daily conversions in one region can power a test that a larger one with lumpy conversions cannot. The small-budget guide has worked tables for finding your row before you spend.

No. Marketing mix modelling answers a different question: it estimates each channel's contribution from historical patterns without needing identifiers, which makes it valuable for channels that cannot be tracked. It remains correlational, hungry for history and sensitive to specification: two competent modellers can produce materially different answers from the same data. It is evidence, but it is not the same evidence as a controlled experiment, and presenting a model output as proof of causation is the failure that separate evidence labels exist to prevent.

No. It is this platform's own construct, computed by its own compilers, and there is no external body defining or auditing it. What makes it useful is not authority but consistency: the same function produces it for every channel and every brief, the rationale is published beside the number, and the scores are comparable across the catalogue's channels because they answer the same question.

Only by changing the compilers, because each score is set in the compiler for its channel and every brief runs through the same one. The low scores (40 on cinema, 50 on out-of-home, 55 on addressable TV) are published in the same dataset as the 85 on CTV, so every channel is read on one scale.

No, and conflating the two is the misreading most likely to cost money. Fidelity measures how close the targeting is to your description of the audience. Performance depends on the creative, the offer, the medium's attention profile and the competitive context, none of which the score touches. Cinema has the lowest fixed score and can outperform a precisely targeted display campaign on the things cinema is good at.

Not through AdBuyMCP today. The consent-based identifier that would carry a first-party list onto streaming inventory requires a participation agreement, and the client built for it stays unused until one is signed. The compiler emits an empty identifier list, so no plan carries one. On the social platforms, list matching works because they hold the identifiers themselves, and that route is unaffected.

Clearance usually decides your start date, because it takes longer than securing the media. Clearcast asks you to allow two to three weeks for television, with script feedback within three working days and a final ad usually approved in two working days, and its Fast Track guarantees feedback within 24 hours for £660 plus VAT. The CAA aims to clear cinema copy within 24 hours of payment and guarantees 48 hours; AdBuyMCP's cinema workflow plans about eighteen days from brief to screen with clearance in the path, though cinema sits outside an AdBuyMCP awareness plan. Neither is a process to start after the flight has been booked.

Not for standard clearance of an ad up to five minutes long on a channel it clears for, because Clearcast's stakeholders pay for that service. Its Fast Track costs £660 plus VAT and its two-hour final approval £1,320 plus VAT per submission. The CAA charges £180 plus VAT to clear a UK-only cinema ad.

Not on this platform, and the block is structural rather than a setting. Consequential calls fail closed unless the incoming request matches an approval a human granted for those exact bytes; spend runs against a mandate carrying an explicit money ceiling and an expiry; and enabling spend on a live line is a separately granted action that an approval alone cannot perform. Agents also cannot revoke or replace authority, close missions, or resolve approvals: those operations have no agent tool at all.

The costly failures happen in operations, and the most common is a retried activation after an ambiguous supplier response, which produces two live campaigns spending in parallel. The others are an agent inheriting a human's session and approving its own work, an authority that never expires and is forgotten, and an approval granted for one action being spent on a different one. All four are prevented by design decisions rather than by prompting, which is why the questions worth asking of a vendor are infrastructural.

Less than you would expect, and that is the point of putting the controls in the product rather than in the prompt. The model extracts semantics, drafts creative, explains plans and proposes optimisations. It does not compute budgets (deterministic code does the arithmetic against adapter forecasts), and it never emits a vendor segment identifier, because registry tables do that. Where its output has consequences, a human approval bound to the exact action stands between the proposal and the money.

It depends entirely on what stands between the agent and the money, and that is an architectural question rather than a question about the model. The things to establish: that the agent uses the same execution path as a human rather than a parallel one, that consequential operations are absent from its surface rather than merely discouraged, that authority carries an explicit ceiling and expiry, and that an ambiguous supplier response stops the run rather than being retried. Where those hold, the model's fallibility is contained by design rather than by prompting.

On some platforms, yes. Meta's and Amazon's MCP servers let an assistant create and change campaigns there, and Google's, Microsoft's and Snap's let it read reporting. Each works inside one platform's account, so the assistant can operate each platform and still has no plan across them. Connect the read-only servers first, and set Meta's agent rules before you connect a write-capable one.

None of the platforms describes its server as one. Each server reads, and on some platforms changes, campaigns inside that platform, which makes it an operating tool for one account. A plan decides the split across platforms and channels before anything is bought, and that needs a view of all of them at once.

AdBuyMCP's connectors use each platform's advertising API. Its own MCP server is how your assistant drives AdBuyMCP. AdBuyMCP runs it. Joining the waitlist takes a short form and no card. James is setting the first customers up himself, so he reads every entry and comes back to you, and nothing is bought until the plan, the ads and the start date are confirmed with you. A compatible assistant connects to an approved workspace through Supabase OAuth after its own client identity and exact callbacks are approved. Its tools follow the workspace's enabled capabilities. There is no public connector or registry listing.