Amazon Ads Dayparting: Schedule Bid Rules Only Raise Bids, So You Build the Rest

Dayparting is simple to describe: spend more when your buyers convert, less when they don't. Every ads platform conversation eventually arrives at it.

So you look for the scheduling feature in the Amazon Ads API, and you find one that only does half the job.

That reframing matters, because it changes the project from "configure a schedule" into "operate a system that mutates live campaigns unattended" — which is a different and considerably more dangerous thing, and a fair moment to weigh building it yourself against buying Pacvue or Perpetua.

A 7×24 grid per target — seven days, twenty-four hours, one multiplier or state per cell. Store the intent; let an hourly job apply it.

Three properties make this survivable:

• The schedule is data. An operator edits a grid; nobody deploys to change a bid at 6pm.
• The worker is idempotent. Running it twice in an hour changes nothing the second time, because it diffs against live state before writing.
• Every write is logged with what changed, why, and which rule caused it. When someone asks why a campaign was paused at 2am, that log is the answer.

Apply it at more than one level if you can — campaign, keyword and target are all separately controllable, and the useful strategies usually live below campaign level.

An hour is not an hour. Three clocks are in play, and confusing them produces a schedule that is quietly wrong by several hours:

Store schedules against the marketplace clock, convert at execution time, and run your worker in UTC. Then handle daylight saving explicitly — twice a year one local hour occurs twice and another never occurs at all, and a worker that assumes 24 distinct hours will either double-apply or skip.

You are running unattended writes against live spend. The rules that matter are less about dayparting and more about not causing damage:

1. Dry run by default

   Log the intended change without sending it. Watch it for a few days. Enabling live writes should be a deliberate act, not the default state of a new deployment.

2. Bound every change

   Floor and ceiling on bids, maximum percentage change per run. A rule that computes a nonsensical multiplier should hit a cap, not a campaign.

3. Diff before writing

   If the live value already matches the target, do nothing. This cuts API calls enormously and makes reruns free.

4. Fail safe, not open

   If the worker cannot read current state, it must not write. A missed hour is recoverable; a write based on stale state is not.

5. Alert when a run is skipped

   Silence must not be indistinguishable from success. A dayparting worker that quietly stopped is a campaign stuck at 3am bids all week — if you would rather not own that layer, I build these Ads API automations.

Worth asking before building, because the answer is often no.

Dayparting decisions need hourly performance data — the same feed behind bid rules that react to the hour's actual numbers. The v3 reporting API is daily, and Amazon's new reporting API v1 keeps hour-level data for only 14 days. Deriving an hourly pattern from daily totals is not possible — you are guessing.

Hourly data on Amazon means Marketing Stream, which pushes into your own AWS and has its own setup sharp edges. On V1 it only accrues from the moment you enrol — there is no backfill.

Without it, you can still daypart on judgement and known business patterns, which is genuinely better than nothing. Just be honest that it is a hypothesis rather than a measurement.

Does the Amazon Ads API support dayparting?

Partly. Sponsored Products has schedule bid rules (POST /sp/rules/optimization with the SCHEDULE sub-category), but they can only increase bids by a percentage at set times, Amazon says changes take up to 24 hours to apply, and a campaign takes at most 20 of them. Lowering bids in dead hours, pausing, or adjusting from each hour's performance still means running your own hourly job that updates bids, budgets or campaign state through the normal endpoints.

How do I schedule Amazon ad changes by hour?

Store a 7×24 schedule per campaign, keyword or target, run a worker every hour that computes what should be true now, diff that against live state, and write only the differences. Log every change.

Which timezone should dayparting schedules use?

Store them against the marketplace's local time, since that is what "7pm" means to a buyer, and convert at execution. Run the worker itself in UTC and handle daylight-saving transitions explicitly, because one local hour repeats and another disappears twice a year.

Do I need Amazon Marketing Stream for dayparting?

To justify a schedule with data, effectively yes. Hourly patterns cannot be derived from daily totals, and Amazon's new reporting API v1 keeps hour-level data for only 14 days. Marketing Stream V2 delivers 70 days of history when you subscribe, though Amazon says it can arrive at a coarser grain than hourly, so subscribe before you need the history. V1, which had no backfill, stops delivering on 30 June 2027.

How do I stop an hourly worker from causing damage?

Default to dry run, bound bid changes with floors, ceilings and a maximum change per run, skip writes when live state already matches, refuse to write if current state cannot be read, and alert when a scheduled run does not happen.