Amazon Full Funnel Campaigns Beta: Automating SP, SB, and SD
Amazon's Full Funnel Campaigns is a new beta that takes a single prompt (your goal, budget, and flight dates) and stands up coordinated Sponsored Products, Sponsored Brands, and Sponsored Display campaigns, then keeps shifting budget and audiences across those formats while they run. It is aimed squarely at the setup problem: building a multi-format program by hand is slow, and this collapses hours of work into one instruction.
Should you use it? For a launch, a new ASIN, or an account where nobody has time to touch campaigns weekly, the beta is a reasonable way to get coverage live fast. For an account where performance already moves in ways you need to explain, the answer is more complicated, and the reason is not that the AI is bad at its job. The reason is that an orchestrator makes its decisions at runtime, inside a box you cannot open, and when the market shifts your only lever is to change the goal and wait. This post covers what the beta appears to do, where it genuinely helps, and the specific controls that go invisible when you hand execution over.
One note before we start. Amazon has not published full documentation for Full Funnel Campaigns, so the mechanics below are drawn from trade press and Amazon's own announcements at unBoxed 2025. Treat the specifics as reported, not confirmed.
Quick Answer
Full Funnel Campaigns is an agentic mode inside Amazon's new Campaign Manager that builds and runs cross-format Sponsored Ads programs from a few inputs. As reported, you give it goals, budget, and dates. It generates SP, SB, and SD campaigns with targeting, then continuously reallocates budget and audiences across those formats based on cross-format signals.
The trade: convenience for control. You gain speed and coverage. You give up per-campaign visibility into why spend moved, the ability to set different logic for different jobs, and hard floors and ceilings on bids. The beta decides. You watch the outcome.
Use it when speed matters more than explainability. Keep a rules engine, bidding zones, and a change log on the campaigns where you have to answer for the number.
What the Beta Appears to Do
The pitch rests on coordinating three formats that sit at different points:
- Sponsored Products: the workhorse, closest to purchase intent, usually the largest line in an account.
- Sponsored Brands: higher in the funnel, building brand recall and new-to-brand purchases.
- Sponsored Display: audience and product targeting on and off Amazon, including retargeting shoppers who viewed but did not buy.
You historically built and optimized each separately, with separate bids, budgets, and logic. Full Funnel Campaigns is Amazon's move to run all three (plus Sponsored TV in some reporting) as one coordinated program.
Here is what the beta appears to do, marked provisional:
- You provide a goal, a budget, and flight dates. The system generates coordinated SP, SB, and SD campaigns, including targeting, from that input.
- Once live, it continually shifts budgets, audiences, and tactics across formats based on cross-format signals, with the stated aim of lifting performance.
- It lives inside Campaign Manager, the unified console Amazon rolled out to bring the Ads Console and DSP into one place, and connects to the same agentic layer as the Amazon Ads Agent launched at unBoxed in November 2025.
- Amazon reported beta testers saw roughly 47% faster campaign creation with auto-generation. That is a setup-speed number, not a performance guarantee, and it is Amazon's figure.
What Amazon has not published: the exact reallocation rules, the bid logic per format, the guardrails on how far budget can swing, or the reporting that would let you reconstruct a decision after the fact. Until that documentation exists, assume those internals are not exposed to you. The beta appears to optimize toward your stated goal. It does not appear to show its work.
Full Funnel Campaigns turns three separate optimization jobs into one instruction. The value is real. But the mechanics you would need to manage it are the mechanics Amazon has not disclosed.
Where AI Orchestration Helps
Give the orchestrator its due, because it wins cleanly on some jobs.
Setup is the obvious one. Standing up a coordinated SP, SB, and SD program by hand means building each campaign, wiring targeting, splitting budget, and reconciling it all so the formats do not fight each other. That is genuinely slow work, and an agent that does it from one prompt removes hours of drag. For a new launch with no historical data to protect, there is little downside to letting the system build the structure.
Coverage is the second. Plenty of accounts run SP well and neglect SB and SD entirely, not because those formats do not work but because nobody has the time. An orchestrator that keeps all three live and funded is better than two of them sitting dark.
Reallocation across formats is the third, in the narrow case. When you truly have no strong prior about how budget should split between upper and lower funnel, letting the system move money toward whatever is converting is a defensible default. It is a better starting point than a static split you set once and forgot.
The common thread: orchestration earns its keep when you do not have a specific, defensible reason to want a particular setting, and when being roughly right fast beats being precisely right slow. Launches, thin-bandwidth accounts, and greenfield structure all fit that shape.
What Control You Give Up
Now the part the setup-time number does not mention.
When you hand execution to an orchestrator, three specific controls go invisible.
You give up the why. The system moves budget from SB to SP, or pulls back an SD audience, based on signals you never see. When ACoS jumps in week three, you cannot open the campaign and find the decision that caused it. You can see that the number moved. You cannot see why, and you cannot reconstruct the path. For an account where you answer to a P&L or a client, "the system decided" is not an answer you can give.
You give up per-job logic. Different campaigns have different jobs. A defend-your-bestseller campaign and a launch-a-new-ASIN campaign should not run on the same optimization logic, because winning looks different for each. An orchestrator applies one behavior across the program. One setting, many jobs. When the setting suits the average campaign, it is wrong for the ones at the edges, and those edges are usually where your margin lives.
You give up floors and ceilings. A rules engine lets you say a bid never drops below a floor that keeps you visible on a term you must own, and never climbs above a ceiling that protects margin. An orchestrator optimizing toward a goal will move bids wherever the goal points, which means a shift in the market can push spend somewhere you would never have authorized, and you find out after it happens.
The break point is specific. An orchestrator that routes SP, SB, and SD invisibly gives you no lever when the market shifts beyond changing the target and waiting for the system to respond. If a competitor floods your category next week, you do not adjust bids on the terms you care about. You edit the goal and hope the agent reads the situation the way you would have. Waiting is not a strategy when spend is live.
Convenience at setup is paid for with control at runtime, and runtime is where accounts are won and lost.
The Bigger Pattern: Execution Without Business Context
The Full Funnel beta is one instance of a broader shift, and the broader shift is where the risk lives.
Amazon spent the last year building the plumbing for autonomous execution. The Ads Agent launched at unBoxed in November 2025. The Amazon Ads MCP Server, which lets external AI agents drive campaign operations, hit global open beta on February 2, 2026. On March 4, 2026, Amazon updated its Business Solutions Agreement to formally govern how AI agents behave on the platform. The direction is clear: more of the account will be run by agents, faster.
The strongest public evidence for how much caution that deserves comes from Amazon itself. During Amazon's own MCP testing, trade press reported that one agent accessed three years of clean-room data nobody had asked it to touch, and another defaulted to a deprecated API. Amazon's response was not to make the agents smarter. It was to constrain them, forcing agents onto approved paths and writing new policy to govern them. When the platform vendor builds a cage around its own agent, the signal is not that AI is dangerous. The signal is that the tolerance for autonomous execution error inside a live account is low, and the people closest to the technology know it.
There is a second structural limit worth naming. The Amazon Ads MCP Server is ads-only. It has no view of your inventory, your real margin after fees, or your Buy Box status. So an agent can execute faster, but it executes without the business context that determines whether an action is a good idea. Bidding up on a term is wrong if you are about to stock out. Chasing conversions is wrong if the product's post-fee margin is thin. Faster execution without that context does not produce better decisions. It produces wrong decisions faster.
There is also a reliability ceiling. Grounding an LLM with MCP improves reliability from roughly 30% to somewhere in the 70-85% range. That is a real gain, and it is genuinely good enough for analysis, drafting, and summarizing an account. It is not good enough for continuous bid decisions on live spend, where a 15-30% error rate compounds every cycle. The right read is not that agents are useless. It is that they are strong for the analytical jobs and weak for the continuous-execution jobs, and Full Funnel Campaigns is a continuous-execution job.
The platform vendor built a cage around its own agent, which tells you where the line sits between useful automation and unsupervised execution.
Common Mistakes
The recurring errors we see when operators adopt an orchestrator:
- Treating the setup-time number as a performance number. Faster creation is real. It says nothing about whether the campaigns will perform, and Amazon has not claimed it does.
- Running it on the campaigns you have to explain. If you answer to a client or a board, do not put your accountable spend inside a box you cannot open. Use it where "the system decided" is an acceptable answer.
- Assuming reallocation respects your priorities. The orchestrator optimizes toward the stated goal, not toward the term you must own or the margin floor you never articulated. If it is not an input, it is not a constraint.
- Forgetting there is no floor or ceiling. Without explicit bounds, spend can move to places you would never have signed off on, and you learn about it after the fact.
- Confusing coverage with strategy. Keeping SP, SB, and SD live is good hygiene. It is not the same as knowing why budget should sit where it sits.
Where Operator-Selectable Logic Fits
If the break point is invisible execution, the fix is not to reject automation. It is to keep automation and keep the controls, which is the design behind Qinetix ads automation.
The difference is mechanism, not marketing. Qinetix runs a rules engine in parallel with the optimization algorithms, and it gives the operator the levers an orchestrator hides:
- Selectable optimization logic per campaign. You choose the behavior for each campaign, so a defend-the-bestseller job and a launch job run on different logic instead of one setting stretched across both.
- Bidding zones. Explicit floors and ceilings, so a bid never drops below where you stay visible and never climbs above where margin breaks, no matter which way the goal points.
- Guardrails. A learning-phase hold and down-only defaults, so the system does not overreact to early noise or spend up into a mistake.
- Change logs. A record of what changed and when, so when performance moves in week three you can find the decision instead of guessing at it.
- A simulator. You test a logic change against your data before it touches live spend, rather than deploying and hoping.
Put those side by side with the orchestrator and the trade becomes concrete.
| Amazon Full Funnel orchestrator | Qinetix operator-selectable logic | |
|---|---|---|
| Visibility | Sees the outcome, not the decision. Reallocation rules not disclosed. | Change log records what changed and when; simulator shows expected effect before deploy. |
| Control | One behavior across the program; goal is the only lever at runtime. | Per-campaign logic; bidding zones set floors and ceilings; guardrails hold the learning phase. |
| Effort | Low. One prompt builds and runs the program. | Higher. Selecting logic per campaign is operator work. |
| Setup speed | Wins. Reported ~47% faster creation from one prompt. | Slower. You configure logic, zones, and guardrails per campaign. |
Read the last two rows without flinching. The orchestrator wins on convenience. If your constraint is time and you have no prior worth protecting, one prompt beats configuring a rules engine, and that is a fair reason to use it.
The honest limit on the Qinetix side: visibility explains what changed, it does not prove the change was right. A change log tells you the floor kicked in on Tuesday. It does not tell you the floor was set correctly. Selecting logic per campaign is work, and it is judgment work, so this is control, not less effort. You are trading a black box that decides for you against a glass box that shows you decisions you still have to make. For accounts where the number has to be defended, that trade is usually worth it. For a launch nobody is grading yet, it may not be.
One boundary, by design: in the Trellis stack, ads and pricing run as parallel mechanisms that share visibility. They are never algorithmically coordinated behind your back. You decide how they relate. Nothing moves your price because your ads moved, or the reverse, without you in the loop.
The alternative to a black-box orchestrator is not more manual work. It is a glass box, and the price of the glass box is that the judgment stays yours.
Conclusion
Full Funnel Campaigns is a real convenience and a real trade. It collapses the slow, coordinated work of building an SP, SB, and SD program into a single prompt, and for launches, thin-bandwidth accounts, and greenfield structure, that is a good deal. The setup speed is not in dispute.
What you give up is runtime control: the why behind a budget move, per-job logic, and hard floors and ceilings on spend. Amazon has not published the mechanics, so treat the internals as a box you cannot open, and remember that when the platform vendor tested its own agents, the response to their mistakes was to build a cage. The MCP layer that powers this execution is ads-only, blind to inventory, margin after fees, and Buy Box, which means fast execution without business context produces wrong decisions faster. Reliability in the 70-85% range is fine for analysis and short of what continuous bid decisions require.
The operator is still the person who has to answer for the number. Use the orchestrator where speed beats explainability. Keep selectable logic, bidding zones, guardrails, and a change log on the campaigns where you have to show your work. That is not a rejection of automation. It is knowing which jobs to hand over and which to keep your hands on.
Frequently Asked Questions
It is an agentic beta inside Amazon's Campaign Manager that builds coordinated Sponsored Products, Sponsored Brands, and Sponsored Display campaigns from a single prompt (goals, budget, dates), then continuously shifts budget and audiences across those formats while they run. Amazon has not published full documentation, so the exact mechanics should be treated as reported.
Sponsored Products (SP) are keyword and product-targeted ads on search and product pages, closest to purchase intent. Sponsored Brands (SB) are banner ads with your logo, a headline, and multiple products, running higher in the funnel. Sponsored Display (SD) targets audiences and products on and off Amazon, including retargeting shoppers who viewed but did not buy.
Use it when setup speed and coverage matter more than control, such as a launch, a new ASIN, or an account nobody has time to manage weekly. Be cautious on accounts where you have to explain why performance moved, because the beta appears to optimize toward your goal without exposing the decisions behind budget and bid changes.
Three things: visibility into why budget and bids moved, the ability to set different logic for different campaigns, and hard floors and ceilings on spend. When the market shifts, your only lever is to change the goal and wait for the system to respond.
No. The MCP Server, in global open beta since February 2, 2026, is the plumbing that lets AI agents drive campaign operations through approved API paths. Full Funnel Campaigns is a specific agentic workflow. Both sit in the same push toward autonomous execution, and the MCP layer is ads-only, with no view of inventory, margin after fees, or Buy Box.
Grounding an LLM with MCP raises reliability from roughly 30% to about 70-85%. That is solid for analysis, reporting, and drafting. It is short of what continuous bid decisions on live spend require, where the remaining error rate compounds every cycle.
Qinetix runs a rules engine in parallel with the algorithms and keeps the operator's levers exposed: selectable optimization logic per campaign, bidding zones with floors and ceilings, guardrails like a learning-phase hold and down-only defaults, change logs, and a simulator to test changes before they go live. The honest limit is that visibility explains what changed, it does not prove the change was right, and selecting logic per campaign is judgment work you still own.
eCommerce News You'll Actually Use
