What Is Amazon Marketing Stream? A Practitioner's Guide

What Amazon Marketing Stream Actually Is

Amazon Marketing Stream is a push-data API. Amazon sends hourly campaign statistics and change notifications - for Sponsored Products, Sponsored Brands, Sponsored Display, and Amazon DSP - directly to an AWS account you control, using Simple Queue Service (SQS) or Amazon Data Firehose. It isn't a dashboard, and it doesn't live inside the Amazon Ads console. It's a feed you build something on top of.

That distinction matters because most people searching this term want to know if Stream replaces the reports they already pull. It doesn't. Standard reports are something you request; Stream is something Amazon sends automatically, roughly every hour, whether or not you asked for that specific hour. The value is speed and granularity - you see performance shift within the day instead of finding out the next morning.

What You Need Before You Can Use It

Stream isn't a beta feature a marketing team switches on. It requires:

• An existing Amazon Ads API integration - the same access ID used for standard reporting works for Stream; there's no separate application process.
• An AWS account to receive the data, with an SQS queue or a Data Firehose delivery stream configured as the destination.
• Developer time, at minimum to set up the subscription and the receiving pipeline. Amazon's own onboarding guide is direct about this: you need someone who understands AWS, at least at the start.
• A reason to build a reactive application on top of it - bid rules, budget alerts, anomaly detection - because the raw feed by itself is just hourly numbers arriving in a queue.

If your team doesn't have a developer and isn't planning to work with a partner who does, Stream is the wrong tool to chase directly. Most advertisers who benefit from Stream never touch the raw feed themselves - a partner's software does.

A Worked Example: What the Hourly View Actually Buys You

Here's what hourly granularity does in practice, using real numbers from one book of Amazon DSP accounts. Across 30 advertisers in July 2026, the portfolio ran 78.4 million impressions at a $4.00 CPM and a blended $1.42 cost-per-click - the $0.41 CPC people quote in this category is online-video only, not the whole book. A daily report shows you that blended average and nothing else. Stream shows you the hours inside that average: whether CPC held steady all day or spiked in three specific hours while the rest of the day ran cheaper.

That's the actual use case - catching the expensive hours and the cheap hours separately, then adjusting bids or pacing inside the day instead of after it. It's also where the limits show up fast. Stream tells you what happened - clicks, cost, campaign status - at hourly grain. It does not tell you whether the resulting sale would have happened anyway without the ad. Blended cost per acquisition across that same book was $5.49 on 57,137 attributed purchases, with 20.1% of those purchases coming from shoppers new to the brand. Stream can't produce that new-to-brand split, and it can't tell you which purchases were incremental - it's reporting the same last-click-attributed numbers you already get, just faster and in smaller time buckets.

Common Mistakes (Including Ones We've Made)

The most common mistake is treating Stream as a measurement upgrade rather than a reporting-speed upgrade. It uses the same attribution logic as your standard reports - it just delivers it hourly instead of daily. If your standard reports overstate what display or DSP contributed, Stream will overstate it hourly instead. Faster wrong numbers are still wrong.

The second mistake is acting on single-hour data without checking sample size. An ASIN that gets four clicks in one hour can show a CPC or CTR that looks alarming and means nothing - it's noise from a small denominator, not a signal. We've made this mistake ourselves: early bid rules built straight off hourly CPC whipsawed budgets on lower-volume ASINs before we added rolling multi-hour windows to smooth it out.

The third mistake is assuming the feed is complete the moment it's turned on. Subscriptions can lag during setup, specific datasets can be missing from a subscription, and campaign-change events arrive separately from performance stats. It's easy to build a dashboard that's quietly missing a dataset for weeks without noticing.

When the Numbers Look Wrong

If an hour is missing or a queue looks empty, check the subscription and delivery-stream status in AWS before assuming Amazon's data is broken - a lapsed IAM permission or a full SQS queue is a far more common cause than an outage. Stream uses at-least-once delivery, meaning the same message can arrive twice; if numbers look inflated, check for de-duplication logic in your own pipeline before questioning the source.

If hourly figures don't reconcile with the next-day standard report, that's expected, not broken. Near-real-time data can be preliminary and gets adjusted as Amazon finalizes attribution windows. Treat hourly numbers as directional for same-day decisions and the standard report as the number of record.

If you built a bid rule off Stream data and performance didn't move, check budget caps and campaign eligibility first. A change that should work often does nothing because the campaign was budget-capped in a different hour - not because the rule was wrong.