Daily reporting collapses twenty-four hours into one row. That row is an average, and averages hide the thing you would have acted on.
A campaign that spends its daily budget by three in the afternoon and misses the evening entirely looks, in a daily report, like a campaign that spent its budget. The number is correct. It is also useless, because the interesting fact happened inside the day and the report cannot represent it.
Marketing Stream removes that limitation. You get the hours. Then you discover the actual problem, which is that having twenty-four numbers instead of one only helps if something in your operation can respond to them, and for most brands nothing can.
This post covers what Stream is, the two things people consistently get wrong about it, and an honest answer on whether it is worth building.
What Stream Actually Is
Amazon Marketing Stream is a data-delivery service within the Amazon Ads API. Its public developer documentation is one of the few genuinely open primary sources in Amazon advertising, which is worth knowing if you want detail beyond this article.
The mechanics matter because they explain both the capability and the cost.
| Aspect | Reporting API | Marketing Stream |
|---|---|---|
| Model | Pull. You request a report and wait for it. | Push. Data arrives without being asked for. |
| Latency | Commonly reported at 12 to 24 hours | Near real time, typically minutes after the hour closes |
| Granularity | Daily rows | Hourly, plus change notifications as they occur |
| Destination | Your request, your response | An AWS destination you own, such as an SQS queue |
| Coverage | Sponsored ads and DSP | Sponsored Products, Brands, Display, and Amazon DSP |
The AWS requirement is the part that decides whether this is a project or a purchase. Stream pushes to infrastructure you own, typically an Amazon SQS queue or a data firehose, which means you need an AWS account, somewhere to store hourly messages, and something that reads them. That is not a marketing task.
Access to Stream itself is reported as free for eligible advertisers with Amazon Ads API credentials. The cost is everything downstream of the queue.
A Faster Pipe, Not New Data
One source describes Stream in a single sentence that is more useful than most full articles: it is a faster pipe for data you could already get.
That is the correct frame and it disciplines expectations. Stream does not expose metrics that were previously hidden. Impressions, clicks, spend, and conversions were all available. What changes is when you receive them and at what resolution.
The value of Stream is entirely latency and granularity. If neither of those is currently limiting a decision you make, Stream will not improve anything, however impressive the architecture looks.
This matters because the pitch usually arrives wrapped in real-time language that implies new capability. Real-time is a property of delivery, not of insight. A brand receiving hourly data and reviewing it weekly has bought nothing, since the weekly review would have worked identically on daily reports.
The corollary is more encouraging. If you already have a process that would act faster given faster data, Stream is genuinely valuable and the benefit is immediate. The question is which of those two brands you are, and most are the first.
What Hourly Granularity Reveals
Set the implementation question aside and the data itself is genuinely interesting, because performance within a day is not uniform and daily reporting is structurally incapable of showing that.
- Budget exhaustion timing. The clearest case. A campaign hitting its cap at 3pm is invisible in a daily report and obvious hourly, and it means you are absent for the evening.
- Conversion rate by hour. Traffic and conversion do not peak at the same time in every category. Paying peak bids during a high-traffic, low-conversion window is a common and invisible waste.
- Weekday and weekend divergence. Patterns differ enough that a single dayparting schedule applied across all seven days is usually wrong on at least two of them.
- Intra-day anomalies. A spend spike, a sudden click-through collapse, a competitor's campaign launching. Found the same hour rather than the next morning.
- New-to-brand timing. Reporting indicates new-to-brand metrics moved to hourly in 2026, so you can see which hours acquire new customers rather than repeat buyers, which is a different optimization target.
Notice what these have in common. Each is a fact about timing that a daily average necessarily conceals, and each has an obvious action attached. That is what makes hourly data interesting rather than merely finer.
For the strategy side of acting on those patterns, our existing guide to PPC dayparting covers the scheduling approach. This post is about the data layer underneath it.
The Delta Problem
One implementation detail causes more wrong dashboards than anything else in Stream, and it is easy to get wrong in a way that looks plausible.
Stream delivers delta values. Each message carries the change in a metric during that hour, not a running total. If a campaign generated 50 clicks between 2pm and 3pm, the message says 50 clicks for that hour. To produce a daily figure your application sums the hourly deltas.
The design is deliberate and sensible. Sending deltas means you can act intra-day without reloading full historical datasets on every update, which is what keeps the stream light.
It also means correctness is your responsibility. A team that assumes cumulative values will produce numbers that are plausible, internally consistent, and wrong, which is the most expensive kind of wrong because nobody questions it. If you build this in-house, reconcile your summed daily totals against Amazon's daily reports for a fortnight before trusting anything.
Stream Does Not Act
This is the misunderstanding that wastes the most money, and multiple sources state it plainly enough that it should not persist.
Marketing Stream provides the insight needed for dayparting decisions. Actual bid or budget adjustments must be implemented through automation tools or API workflows. Stream is a data feed. It has no ability to change anything in your account.
Receiving messages from the queue, deduplicating, handling late arrivals, and writing them somewhere durable. This is where Stream ends.
Summing deltas correctly, joining to campaign structure, and producing figures a human or a rule can read without misinterpreting them.
Rules stating what constitutes a signal worth acting on, with thresholds, guardrails, and enough history behind them to be trusted.
Writing bid and budget changes back through the Ads API. A separate integration with its own failure modes and its own risk.
Layer three is where most in-house projects stall. Engineering delivers layers one and two competently, the data arrives, and then nobody has written down what should happen when conversion rate drops in a given hour. The pipeline works and nothing changes.
That is the same failure described in the clean-room and analytics world, and the same fix applies: define the decision before building the pipeline that feeds it.
Where Hourly Genuinely Pays
Four cases where the latency reduction is worth real money, and they are narrower than the pitch suggests.
Budget pacing on constrained campaigns. If campaigns regularly exhaust budget before the day ends, hourly visibility lets you intervene the same day. This is the most reliably valuable use and the easiest to justify.
Peak events. Prime Day and holiday periods compress a normal month into a day or two. Learning at 9am that something is broken rather than the following morning is worth a great deal during an event and considerably less in February.
Launches. A new product's first days determine a lot, and hourly feedback shortens the loop when you are still establishing whether targeting works at all.
Anomaly detection. A competitor entering aggressively, a listing suppression killing conversion, a tracking break. Catching these within hours rather than a day limits the damage, and this benefit does not require any automation beyond an alert.
Absent from that list is routine steady-state optimization of a stable account. Weekly bid review on daily data remains adequate for most mature campaigns, and treating hourly data as a reason to intervene more often usually makes performance worse rather than better, for reasons in section ten.
Build Or Buy
Two paths, and they are not close for most brands.
Build. Apply for API access, configure AWS subscriptions, stand up storage for hourly messages, write ingestion handling duplicates and late arrivals, build aggregation, define decision rules, and integrate write-back to the Ads API. One vendor describes this as a multi-quarter engineering investment, and while the source has an obvious interest in you agreeing, the scope described is realistic.
Buy. Most PPC platforms of any size already consume Stream. You connect an account and inherit the pipeline, paying a subscription instead of salaries and keeping control of strategy and guardrails.
The build case is genuinely strong in a narrow set of circumstances: you already run a data team, you have proprietary logic worth protecting, and your spend is large enough that a few percentage points justifies the engineering. Outside that, building your own Stream pipeline is expensive infrastructure to arrive at capability you could have subscribed to.
Whichever route you take, insist on understanding the decision rules. A tool that adjusts bids hourly using logic you cannot inspect is making consequential changes to your account on a basis you cannot audit. Ask what triggers a change, what the guardrails are, and how to override it before switching anything on.
The wider question of what to automate and what to keep human is covered in our comparison of AI against human PPC management, and the principles there apply directly here.
What Changed In 2026
Two developments worth knowing, both reported rather than confirmed on an Amazon page.
Unified reporting across DSP and sponsored ads. Reporting indicates a 2026 integration connects DSP impressions to Sponsored Products conversions within the same stream, with managed service DSP accounts gaining full integration in the first quarter. For brands running both, that removes a manual reconciliation between two exports, which was genuinely painful work.
New-to-brand at hourly resolution. Reporting indicates new-to-brand metrics moved to hourly in 2026, meaning you can see which hours and targeting combinations acquire new customers rather than repeat purchasers.
The second is the more interesting one strategically. New customer acquisition and repeat purchase are different objectives with different acceptable costs, and being able to separate them by hour means a dayparting schedule optimized for acquisition can differ from one optimized for volume. That is a real capability rather than a resolution increase.
Whether it is worth acting on depends on whether new-to-brand is something you actively manage. If it is a metric you report rather than optimize, this changes nothing for you. Our guide to Amazon DSP for growing brands covers where new-to-brand fits in a full-funnel program.
The Ecom Profit Box
Our collection of ecommerce growth resources, including the advertising frameworks we use with clients.
Get It FreeWould Hourly Data Change Anything?
We do not sell Stream tooling. We can tell you whether your account has a decision that faster data would actually improve.
Book A CallThe Vendor Numbers
Two performance figures circulate in Stream marketing. Both come from companies selling Stream-based tooling, and both deserve reading carefully rather than quoting.
| Claim | Source Type | How To Read It |
|---|---|---|
| 5% average ROAS improvement over six months versus non-users | Vendor selling Stream-based optimization | No published methodology. Managed advertisers differ from non-users in many ways besides Stream, so selection effects alone could produce this. |
| +273% sales and +570% new-to-brand units during Prime Day for one brand | Single vendor case study | One brand, during an event when nearly everything rises, with no control. This is the weakest evidence format there is. |
Neither figure is necessarily false. The first is even plausible as a direction, since removing latency should help at the margin. What neither supports is a business case, because a business case requires knowing what would have happened otherwise and neither claim establishes that.
The Prime Day figure is worth dwelling on because it is the kind of number that circulates fastest. During a major event, a brand doing everything right will post enormous percentage increases whether or not it uses hourly data. Attributing that lift to one tool, without a holdout, tells you nothing about the tool.
The honest position is that Stream's value is mechanistic rather than measured. The mechanism is sound: faster information should enable faster correction. The published magnitude is not trustworthy, and you should size your investment on the mechanism rather than on someone's case study.
The Noise Problem
Finer data is not automatically better data, and hourly resolution introduces a statistical problem most brands are not prepared for.
Divide a day's clicks by twenty-four and most campaigns produce hourly cells with very few observations. A campaign with 240 clicks a day averages ten an hour, and at ten clicks a conversion rate is essentially unmeasurable. The difference between one conversion and zero in a given hour is noise, and it looks exactly like signal.
Act on that and you will make things worse, because you will systematically cut bids during hours that happened to convert poorly by chance and raise them during hours that got lucky. The pattern you are chasing is not there.
Dayparting schedules should be learned from weeks of accumulated hourly data, not from yesterday. Aggregate the same hour across many days until each cell has enough observations to be meaningful, then set a schedule and leave it. Use live hourly data for anomaly detection and budget pacing, where a single large deviation is genuinely informative, rather than for bid decisions on thin cells.
That distinction is the practical heart of using Stream well. Historical hourly aggregation answers what your pattern is. Live hourly data answers whether something is going wrong right now. Those are different jobs and conflating them is how brands end up over-optimizing into noise.
Bid mechanics generally reward patience over reactivity, which our breakdown of Amazon's bid rules covers in more detail.
A Realistic Starting Point
If you want the benefit without a multi-quarter project, this is the sequence.
- Write down the decision first. One thing you would do differently with hourly data. If you cannot name it, stop here and save the money.
- Check whether your existing tools already consume Stream. Many do, and brands regularly build what they were already paying for.
- Start with budget pacing alerts only. A notification when a campaign is on track to exhaust its budget early. Highest value, lowest complexity, no automation required.
- Add anomaly alerts second. Spend spikes and conversion collapses. Still alerts, still no automation, still valuable.
- Accumulate weeks of hourly history before any dayparting. Aggregate by hour across many days until cells are meaningful.
- Set a schedule and leave it. Revalidate periodically rather than continuously, and expect weekday and weekend patterns to differ.
- Automate execution last, with guardrails. Maximum change per adjustment, floors and ceilings, and a manual override that works.
Steps three and four deliver most of the practical value and require no bid automation whatsoever. A brand that stops there has captured the reliable benefit and avoided the risky part, which is a perfectly good outcome rather than an incomplete implementation.
Most Brands Should Not Build This
The honest conclusion, and it is not the one the tooling industry prefers.
The constraint on most advertising accounts is not data latency. It is decision velocity. A brand where bid changes require a weekly meeting, or where nobody is accountable for intra-day performance, will not act differently on hourly data because the bottleneck is organisational rather than informational. Faster data arriving into a slow process changes nothing except your storage bill.
Before investing here, ask what happens today when something breaks at 10am. If the answer is that someone notices tomorrow and discusses it later in the week, Stream will not fix that, and the fix is cheaper than the pipeline.
The brands that should build are identifiable. Large spend where a small percentage is material. An existing data capability, so this is an addition rather than a first project. Genuine intra-day volatility, meaning events, launches, or constrained budgets. And somebody empowered to act inside the day without convening anyone.
The Cheaper Version Almost Everyone Should Do Instead
Pull hourly data periodically through whatever tooling you already have, aggregate it across several weeks, look at your actual pattern by hour and by day of week, and set a dayparting schedule from it. That is a one-off analysis producing most of the durable benefit, and it does not require a streaming pipeline, an AWS account, or a subscription.
The recurring benefit of live Stream data is real but narrower than advertised: alerting, pacing, and event periods. If those matter to you, buy a tool that already does it rather than building one. And if your account is stable, your budgets are not constrained, and nobody is watching intra-day anyway, the correct amount of Marketing Stream for your business is none. Our Amazon PPC strategy guide covers the work that usually pays better.
What To Remember
- Stream is a faster pipe for data you could already get. It exposes no new metrics, so its entire value is latency and hourly granularity.
- Stream does not act. It surfaces signal; bid and budget changes require separate automation through API workflows or a tool. Subscribing does not produce dayparting.
- Messages carry delta values, not running totals. Your application must sum hourly deltas, and assuming cumulative produces dashboards that are wrong in a plausible-looking way.
- Access is free for eligible advertisers with Ads API credentials, but delivery is to AWS infrastructure you own, so the real cost is engineering and the decision process.
- Hourly cells are statistically thin. Learn dayparting schedules from weeks of aggregated history rather than reacting to yesterday, or you will optimize into noise.
- The circulating performance figures are vendor-sourced. A 5 percent ROAS claim has no published methodology and a Prime Day case study has no control, so size investment on the mechanism rather than the numbers.
- The binding constraint is usually decision velocity, not data latency. Faster data arriving into a slow process changes nothing.
Where This Came From
- Amazon Ads, Amazon Marketing Stream developer documentation, and the Marketing Stream product page.
- AWS, Amazon Simple Queue Service, the delivery destination Stream commonly pushes to.
- Industry reporting on the push versus pull model, reported reporting-API latency of 12 to 24 hours, hourly delivery within minutes of the hour closing, coverage across Sponsored Products, Sponsored Brands, Sponsored Display and Amazon DSP, and the delta-value delivery design.
- Industry reporting on 2026 changes including unified reporting connecting DSP impressions to Sponsored Products conversions and the move of new-to-brand metrics to hourly resolution.
- Vendor-published performance claims, including an average 5 percent ROAS improvement over six months for managed advertisers using Stream-based intraday optimization versus non-users, and a single case study reporting 273 percent sales growth and 570 percent new-to-brand unit growth during Prime Day. Both originate from companies selling Stream-based tooling, neither publishes methodology, and neither includes a control. They are discussed in section 09 and are not treated as benchmarks.