The Prime Day Qore Playbook: Event-Driven Skills, Not Time Triggers

Look at what a typical Prime Day plan contains. Raise budgets 40 percent at midnight on day one. Cut the auto campaigns at noon. Push top-of-search boosts at 6pm. Revert everything the morning after it ends. Every one of those is a time trigger, an instruction that fires because the clock said so, written before anyone could see what the event was doing.

Time triggers are bets, and some of them are good bets. But the clock does not know that your hero SKU capped its budget at 9:40am, that CPCs on your defensive terms jumped harder than the rest of the account, or that the campaign you planned to cut is the one converting. Amazon reports all of that hourly while the event is still running.

Across a multi-day window the auction reprices faster than your reporting cadence, and almost everything the account does was decided before any of it started. What follows is for operators who already have an event doc and want a better version of it: which hourly signals are worth acting on, three workflows built on them, and how to decide line by line which of your existing instructions should fire on a clock and which should fire on a condition.

Quick answer

• The shift. Replace calendar instructions with conditions read off Amazon Marketing Stream, Amazon's push service for hourly ad metrics and budget status.
• What you gain. Actions fire only when the account is actually in the state you wrote them for, so a surprise in hour six changes what happens in hour seven instead of being discovered after the window closes.
• Skill one, a budget ladder. Raise spend 10 to 15 percent at a time, only while the campaign is budget-limited and efficiency holds. The stop conditions matter more than the step size.
• Skill two, an hourly exception check. Report only the campaigns that crossed a line. A full readout across a few hundred campaigns is 96 reports nobody opens by day two.
• Skill three, trigger on the event itself. A workflow can be hooked to a signal rather than a clock, so a campaign going budget-limited fires it on arrival instead of up to an hour later. Every action still carries a stop-and-revert.
• On approval. Consequential moves route to a person, and the routine ones you have already watched can run on their own. Across a 96-hour event you want both.
• The trap to know about. Hourly ACoS is provisional, because conversions attribute back to the hour of the click. Judge on two consecutive closed hours or you will cut campaigns that were converting fine.

Why calendar-based Prime Day plans break in the first six hours

Operators plan carefully. The plan and the event just run on different clocks.

A time trigger is a bet placed before the auction opens

Cost per click typically climbs 20 to 40 percent during Prime Day as more advertisers bid into the same auction, and your headroom stops being theoretical the moment that happens. Amazon adds a second layer: a daily budget is not a hard ceiling. Per Amazon Ads' Sponsored Products budget guidance, the daily budget is averaged across the calendar month and Amazon can spend up to 25 percent more than the average on a given day when it detects high purchase intent. A 40 percent raise written in a planning doc becomes something else in practice, and it lands on your broadest-targeting campaign first, because that campaign always spends fastest.

By hour six of day one you have already learned more about the auction than the plan knew. The plan cannot use any of it.

Amazon is reporting the event while it happens

Amazon Marketing Stream is Amazon's push-based data service: you subscribe with your Amazon Ads API credentials, name an AWS destination, and Amazon delivers hourly performance and near real-time budget messages to Simple Queue Service or Amazon Data Firehose rather than making you poll the reporting API. Amazon does not charge for the stream itself, though AWS usage costs apply, and most brands reach it through a tool provider instead of standing up their own pipeline.

The practical consequence for event week is that the data your plan lacked exists, hourly, while the event is still running. What is usually missing is a standing decision about what to do when a specific number crosses a specific line.

The signals worth building a Prime Day playbook on

Not every dataset in the stream earns a place in an event runbook. These are the ones that change a decision inside 96 hours.

Budget usage is available in every marketplace except India, which matters if your event plan spans regions.

Skill one: a budget ladder that stops itself

The most useful Prime Day automation is also the least dramatic. Instead of one large raise, take small steps, and put more thought into when the ladder stops than into how big each rung is.

A workable shape: on each hourly run, for every campaign in the event set, raise the daily budget by 10 to 15 percent if the campaign was budget-limited in the last closed hour and its ACoS across the last two closed hours sits under the threshold you set for that campaign's posture. Otherwise do nothing.

Small steps buy you something a single large raise cannot: a reading between each one. A 3x jump gives you one data point and no way to tell which part of it worked. Six 12 percent steps give you six, each with an efficiency check in front of it, and they arrive in the order the demand did.

The stop conditions carry the real weight, and they should be explicit before the event rather than improvised during it:

• The campaign hits the ceiling you set for it. The ladder never invents headroom you did not approve.
• ACoS runs above the posture threshold for two consecutive closed hours. One hour is noise.
• Days of cover on the ASIN drops below your floor. Funding a SKU into a stockout is an expensive way to win an auction.
• The campaign is no longer budget-limited. It has what it needs.
• The event window closes. Every rung reverts, without anyone remembering to do it.

Set the threshold against the margin the product carries after the deal discount, rather than against a number that felt comfortable in a calmer quarter. If you have not sized that yet, the Prime Day budget guide covers building the number by SKU job, margin and where conversion concentrates, and the Spend Planner turns it into a figure you can defend.

Laddering does not repair a campaign that converts badly. It moves money toward campaigns that are already working and away from the ones that are not, faster than a person watching a console can.

Skill two: an hourly check that only speaks when something changed

The second piece is a monitoring run, and its defining feature is silence. Every hour, pull the last closed hour, compare it to the thresholds, and report only the campaigns that crossed one.

The checks worth running during an event window:

• Campaigns budget-limited before your peak conversion hours, ranked by the revenue behind them.
• Spend velocity against the day's plan at account level, not just campaign level, so reallocation is visible before a ceiling raise looks necessary.
• ACoS drift by posture, since a launch SKU and a hero SKU on a deal should not be judged against the same line.
• Price and stock changes on any ASIN in the event set, because a bid ceiling set against yesterday's margin is wrong the moment the price moves.

Exception reporting is the whole point. A full hourly readout across a few hundred campaigns is 96 reports nobody opens by day two. A run that stays quiet until something crosses a line is one that people still read at 3am on day three. The budget pacing SOP has the year-round version of this cadence and the decision matrix behind it; event week is the same discipline compressed from daily to hourly.

Skill three: trigger on the event, not the clock

The two skills above run on a schedule, and hourly is a schedule. Gating them on a condition already fixes most of the problem: the clock decides when you look, and the signal decides whether anything happens.

You can go a step further than that. A Qore workflow does not have to wait for its next scheduled run. It can be hooked to a specific event, so the trigger is the signal itself: a budget-consumption message arrives saying a campaign has gone budget-limited, and the workflow fires then rather than up to fifty-nine minutes later when the hourly run comes round. Where the gap between the state changing and you responding is the cost, that difference is the whole point. A hero SKU that caps at 9:40am should not wait until ten.

Both shapes earn a place, and they answer different questions. A scheduled run with a condition gate asks whether anything is true right now that should change what you are doing. An event trigger asks what a thing that just happened authorises. The ladder and the exception check are natural schedules. Budget-limited, out of stock, price moved below the floor, and a change nobody authorised are natural events.

Either way the contrast with a calendar instruction holds. A time-triggered action fires whether or not the state that justified it exists. A condition-gated or event-triggered action fires only when the account is in the state you wrote the action for. Completely different behaviour when the event surprises you, which it does.

Written out, an event-driven Prime Day playbook is a short list of conditions and the action each one authorises:

• Budget-limited plus efficient plus under ceiling, so raise one rung.
• Above threshold twice in a row, so hold, and flag for a human read.
• Days of cover under the floor, so stop the ladder and cap the campaign.
• Price moved below the floor you set, so pause the campaigns pointing at it.
• Window closed, so revert every event change to its pre-event value.

Only the last one has a legitimate claim on the clock, and even that is better expressed as a condition, because events get extended and your revert should not fire into a live surge.

If you also need dayparting inside the window, build it the same way. Hourly dayparting works when it is grounded in what the stream reports about your own conversion hours, and it fails when it is grounded in a general belief about when shoppers buy.

Where a manual pass and native rules break down

Everything above is doable without a platform, and it is worth being clear about what each option keeps.

By hand, you can watch the console, read the hourly numbers your provider surfaces, and make every one of these calls yourself. You will make them better than any rule for the first eight hours. Then you sleep.

Amazon's native budget rules cover more of it than most operators use. Schedule-based rules raise budgets across set dates and revert on their own, which solves the missed-revert problem outright. Performance-based rules adjust budgets when a campaign hits a threshold you define, which is genuinely condition-gated. What they do not do is reason across the account: each rule fires on its own campaign, with no view of whether the account total is already ahead of plan, and no read on inventory or price. They are a good floor and a poor ceiling.

The break point is the combination. Ninety-six hours, an hourly cadence, several hundred campaigns each with a different posture, conditions that reference data living outside the ads console, and an expectation that on the following Monday someone can explain every change that fired and why. Discipline does not fix that. It is a volume problem with a memory requirement attached.

Where Qore fits: your Prime Day runbook, in a form that executes

Qore is where a check you currently run by hand becomes a workflow that runs on its own: you describe the routine once, review the steps and thresholds it assembled, lock it, and let it run on a schedule or on an event you name. Trellis calls it the codified-workflow layer, but the operator version is simpler. It is your Prime Day runbook, written down in a form that executes.

For event week that means the ladder, the hourly check and the condition set stop being a document and start being three skills you load before the window opens. The thresholds are yours. The logic is inspectable, so the same inputs produce the same output and you can read why a rung fired at 4am. And because a workflow can hook the signal rather than poll for it, your response time on the moves worth reacting to immediately is not capped by your refresh interval.

Approval is where a new skill starts, and it is a setting you tune rather than a permanent state. Across a 96-hour event most teams want both settings running at once, and the way to get there is to make the rules conservative enough that the routine moves need no supervision: a rung inside an approved ceiling, on an efficient campaign, with stock cover above the floor, is a change you would have approved anyway, so let it fire and read it afterwards. Keep approval on the consequential ones, a pause, a ceiling raise, anything touching a hero SKU. Both live in the same skill, which is what lets the checks run whether or not anyone is awake.

Qore reads the account, analyzes it, and makes the change once you approve it, no matter what runs your bids. It sits alongside whatever bid manager of record you already use, or works with no automation platform at all. If a third-party tool later overwrites a change you approved in Qore, that is a constraint of that tool's execution model rather than a limit on Qore, and it is worth knowing which of your tools behaves that way before the window opens. If you want continuous bid execution running underneath the playbook, that is Qinetix, our always-on layer for bid and price management inside a floor and a ceiling, with a log of what changed. The honest limit sits elsewhere: Qore does not set your thresholds. It applies the standard you wrote, at a cadence you could not hold by hand, and it will apply a bad threshold just as faithfully as a good one.

Agencies running this pattern across a roster have a different problem, which is seeing every account at once rather than steering one deeply. That is a command centre question, and a different build.

Hourly ACoS is provisional: why Prime Day numbers restate

One correction that saves a bad decision at hour three of day one. Conversions in the stream attribute back to the hour of the click, not the hour of the purchase, so a recent hour's ACoS is provisional and improves as late conversions land against those earlier clicks. Read the newest closed hour as final and you will cut funding on campaigns that were converting fine.

Two habits follow. Judge efficiency on two consecutive closed hours rather than the latest one, and lag your ACoS read by an hour during the event. And reconcile the hourly stream against the daily reports afterward rather than treating it as the system of record: advertisers comparing the two on Amazon's own developer forum have reported differences in the low single digits on clicks and sales for the same date range. Small enough to steer by hourly. Not the number you report to finance.

Load the playbook before the window opens

The work is front-loaded, and the fall event in early October is the next place to spend it. Before the window:

1. Confirm your stream access, directly or through your provider, and check that budget usage and the Sponsored Products traffic and conversion datasets are flowing for the marketplaces you sell in.
2. Sort the event set by posture, and write one ACoS threshold and one budget ceiling per posture. This is the input everything else depends on.
3. Write the ladder rule: step size, minimum hours between steps, and every stop condition.
4. Write the hourly check as exceptions only, and decide who reads it during which hours.
5. Convert your remaining calendar instructions into conditions, then sort those conditions into the ones worth a scheduled check and the ones worth hooking to the event directly.
6. Define the revert as a condition, and test it on a small campaign set before the event rather than during it.
7. Run the whole set for a normal week first. A playbook that has never executed is not a playbook, and Prime Day is a poor first run. The peak season calendar has the rest of the dates worth rehearsing against.

Put the Prime Day playbook on conditions

An Amazon Prime Day PPC playbook built on time triggers is a forecast, and it competes with an auction that reprices hourly. A playbook built on conditions is a set of standing decisions that only fire when the account is in the state you wrote them for. The stream reports the state. Your thresholds decide what counts. The schedule decides how often you look, and for the moves that cannot wait, the signal itself decides when.

Start with the ladder and the stop conditions, since those two carry most of the value and are the easiest to write down. Add the hourly exception check next. Then go through your event doc line by line and ask, for each instruction, whether it should fire because of the time or because of what the account is doing.

The bottom line for ecommerce teams

• Go through the event doc line by line. For each instruction, ask whether it should fire because of the time or because of what the account is doing. Most of them should not be on a clock.
• Sort the survivors by urgency. A condition that can wait for the next hourly run is a scheduled check. One where the delay is the cost belongs hooked to the event itself.
• Write the stop conditions before you pick a step size. A ceiling, an efficiency threshold across two closed hours, an inventory floor, and a revert when the window closes.
• Set thresholds against post-discount margin. The number that felt comfortable in a calmer quarter is the wrong input for a deal week.
• Never read the newest closed hour as final. Late conversions land against earlier clicks, so a fresh hour always looks worse than it turns out to be.
• Reconcile the stream against daily reports afterwards. Differences run in the low single digits. Fine for steering hourly, wrong for the number you give finance.
• Rehearse on an ordinary week. The most expensive auction of the quarter is a poor place for a first run.

If you would rather see the ladder, the hourly check and the revert running against your own account first, book a walkthrough before the window opens.