Adobe's Cyber 5 forecast: plan five daily Sume bulk queues

Adobe's projection, as reported by Digital Commerce 360, puts online spending from Thanksgiving through Cyber Monday (Cyber 5) at $47.5 billion, or 17.3% of the season, so a creative team has five consecutive days where ad variants matter most. On Sume, a clean way to plan that is five bulk queues, one per day, each created with its own idempotency key and a spend cap on every item. A queue holds up to 100 items, so a day of up to 100 variants fits in one request.

The numbers behind the plan

The Adobe figures below are from the article, which reports the projection and not a result. The Sume figures are from the bulk-runs and Format-call docs.

Steps

Cyber 5 in 2026 runs from Thursday November 26 to Monday November 30, so the five queues map to five calendar days.

• Build each day's list in advance and send it as items, with one Format-run body per variant.
• Create the queue with an Idempotency-Key that names the day, such as cyber5-2026-11-27, so a replay returns the same queue and not a second batch.
• Set generation_spend_cap_usd on each item. Worst case for a queue is the sum of the item caps, and Sume does not enforce a queue-level limit.
• Poll GET /v1/format-run-queues/{id} with backoff and branch on counts.failed and counts.canceled, since completed only means every item is terminal.

What Sume does not do

The Adobe projection is a forecast, and this post does not claim the creative will lift sales. Sume does not publish the finished ads for you or place them in a campaign. A queue also has no webhook of its own: each item may carry a communication.webhook_url, and queue progress comes from polling.

If one item is bad, the create fails with 400 invalid_request and details.index before any queue exists, so validate a day's list before the day starts and not at midnight. We did not cite Adobe's separate figure for Cyber Monday because the article gives a date for it that does not match the 2026 calendar.

Why one queue per day

One queue per day keeps the blast radius small. If a day's list has a problem, only that day's idempotency key is involved, and you can fix the list and use a new key without disturbing the other four. It also keeps the polling simple: five queue ids, each polled until its status is completed, each then checked for failed and canceled counts.

A second reason is pacing. With a concurrency of 16 at most, a 100-item queue drains in waves, and a child that fails to start becomes a failed item while the rest continue. Starting each day's queue the evening before gives the window time to drain before the traffic you are targeting arrives. The docs do not promise a duration for a queue, so measure your first small batch and scale your lead time from that.