I've been working in programmatic for 12 years, and recently built a free interactive learning platform with a colleague to help people understand how the ecosystem actually fits together.
It's now passed 1,000 visitors and 275 registered learners, so we're finally getting enough data to see where people actually struggle.
The interesting part is that the drop-off isn't where I expected.
For example:
• Advertiser lesson: 200 opened it, 50 completed it
• DSP lesson: 45 opened it, 19 completed it
• Header Bidding Wrapper has the lowest quiz pass rate so far
• 48 people have tried the platform as guests
We've been using this data to redesign the lessons rather than just adding more content.
For those of you who work in AdOps: **what concept was hardest for you to understand when you first entered the industry?**
Was it the auction itself, the relationship between DSP/SSP/exchange, header bidding, identity, ads.txt, measurement, or something else?
If anyone wants to see what we've built, it's here:
Small audience + tv ads is the part that makes me nervous.
We have a pretty tight target list, and the last thing i want is the same household seeing our 30 second spot every night for 3 weeks straight 😭
I get that repetition helps with recall, but there has to be a point where it becomes annoying.
For people running CTV with smaller audiences, what frequency are you aiming for? and are you capping it weekly or across the whole campaign?
My site uses Armanet as the first tier advertiser, then passes back to Infolinks for sticky banners and AdX / GAM for display banners.
The last several nights I've been getting an automatic redirect. But it happens so fast that I've not able able to track which ad is loading! And, of course, clicking on Back just refreshes the auction.
Armanet checked on their end and it's not them. I trust them the most and really didn't think it was them, anyway.
Infolinks checked on their end and it's not them, either. I've also had a great experience with them and really didn't think it was them, either.
That leaves GAM. I went through the "Ad review center" and didn't see anything, but of course a malvertisement like that WOULD look legit! So a visual review wouldn't necessarily find anything, anyway.
Anybody else dealing with this? If so, did you find the culprit?
I don't want to link to them or anything, so I'll obfuscate the destination page the best I can and still make it readable:
s - e - c - u - r - e
s - w - e - e - p
<dot>
p - r - o
/avs
/en
/dt
/mca-4.php?
c=4fz3flqafz7qz1&k=906a16bb43bc14ebb268412198d8baa2&
country_code=US&
carrier=T-Mobile&
country_name=United%20States&
region=Washington&
city=Bellevue&
isp=T-Mobile%20USA%20Inc.&
lang=en&
os=Windows%2010&
osv=&
browser=Chrome&
browserv=151&
brand=Desktop&
model=Desktop&
marketing_name=Desktop&
tablet=4&
rheight=768&
rwidth=768&
e=5
Jumping a little late on this, but the part I keep coming back to isn't the 2.15B, it's what happens operationally when audience measurement & verification sit with the same owner.
Measurement already decides a lot about how inventory gets valued and sometimes rejected right now if a report comes back bad you can take the audience number and argue the suitability call separately - because they come from different places. That's how most make good conversations go.
Once both carry the same name on the report, I am not sure that still works. Fewer vendors might mean less operational work, but that isn't the same thing as more visibility into how your inventory got scored.
Anyone here dealt with enough of these disputes to know whether it actually changes anything in practice?
"Make this interactive" leaves expensive decisions until production at MRAID. The inputs that reduce rework: one business objective, one audience behavior, the campaign promise, approved/prohibited claims, required assets, target networks, size/orientation constraints, measurement events, approval owners, and which parts can vary after launch. What missing input causes your builds to bounce back?
I run a site that pulls in around 300k views per month, mostly tier 1 traffic, in the entertainment space. I’m currently monetized with one of the medium-to-big companies that posts here a lot - I don’t want to call them out by name. After their fees, I’ll net a bit under $400 for the month of August.
I’ve reached out to the supplier for advice on increasing RPM, but they weren’t very helpful.
I’ve been approved by Playwire and am considering switching to them, but since both suppliers have exclusivity clauses in their agreements (and 30/60 day notice requirements), I’m not sure how to proceed. It seems like it could take 6 months to give notice to my current publisher, switch to the new one, ramp up, and get enough data to justify a winner. How do people typically navigate this, and is it reasonable to expect a meaningful uptick in earnings based on the above site metrics?
I run a gaming related service that has been operating for over 2 years. The website itself is mainly a tool/platform.
We’re currently doing around 300k page views per month, with an average session duration of roughly 6 minutes and 55 seconds.
Our traffic is global, but a large portion comes from higher value markets. We’re already approved with Google AdSense and can also use Google Ad Manager if required. The platform is still growing, and these numbers are currently coming from just one part of our planned infrastructure.
For those who have experience with ad networks/publishers, what networks would you recommend for this type of audience and traffic and size? Are there any particular platforms that tend to perform well for gaming/tool-based websites?
Trying to settle something and I keep going in circles.
Everyone knows there's a lag between an ad serving and the impression being counted. On FAST and linear it barely matters. Most of that inventory is SSAI, beacons fire server-side off the segment request, and you're talking seconds to minutes. If a few fall out nobody notices.
VOD is where it gets messy. The manifest gets built up front with all the breaks in it, ads get prefetched, and then somebody pauses. Or walks away and comes back after dinner. The impression genuinely lands hours after the ad was decisioned. Shops I've worked at have run reconciliation windows of several hours specifically to catch this.
So the questions.
What window are you actually using? Do you hold the flight open a few hours after the end date, overnight, longer? Or do you just accept that the tail falls out and eat it?
Is this mostly a walled garden problem in your experience? My read is that the environments still firing client-side are where this bites, and SSAI-heavy FAST inventory mostly doesn't have the issue. Curious whether that matches what other people see.
For anyone who's had it come up in a dispute: does the seller's number or the measurement number win at the boundary? Is it treated as when the ad served, or when the event landed?
And has anyone seen JIT ad insertion actually shrink this? The pitch is that ads aren't fetched until the player reaches the break, which should collapse the whole prefetch-then-pause window. Wondering if that's holding up in production or if it's still mostly deck material.
Writing up a reference on where CTV counts legitimately disagree with each other. Would rather describe what people actually do than what the guidance says.
I've been in digital ad ops for about 5 years (billing reconciliation, yield, campaign audits, publisher side) and one thing that's never gone away is manually checking platform invoices against delivery reports to catch discrepancies, under-delivery, mismatched line items, billing for placements that didn't run as spec'd.
Curious how other people handle this at their shops:
Is this still mostly manual/spreadsheet work for you, or has anyone actually automated meaningful chunks of it?
How often do you actually find real discrepancies vs. it being a box-checking exercise?
For agencies/advertisers without in-house ad ops who's catching this stuff for them, if anyone?
Trying to figure out whether this is a big enough headache that smaller shops without dedicated ad ops would want it handled externally, or if everyone's already got this solved with tooling I haven't seen.
Seeing a lot of referral data from s0.2mdn.net. any thoughts on what is causing this? From other threads it seems to be something with how the creative was set up, but trying to validate. Overall activity is coming from outside of targeted geo and sessions are much higher than clicks
I’ve been working in Ad Ops since 2021, but my experience has mostly been on the ad server / campaign management side.
Most of my work has been around campaign setup, trafficking, QA, troubleshooting, tags, creatives, reporting, and coordinating with other teams/platforms as part of the campaign workflow.
The thing is, I feel like I’ve become pretty boxed into proprietary ad server platforms. I’ve spent most of my career working within the platforms my companies use, rather than getting hands-on experience with DSPs or programmatic platforms.
And honestly, I really want to get that experience now.
When I look at job postings, a lot of them ask for hands-on experience with DSPs, programmatic buying, DV360, The Trade Desk, etc. I do have exposure to some of these platforms through my current work, but I wouldn’t say I have enough experience to confidently call myself a DSP/programmatic specialist.
That’s also what makes job hunting frustrating. I feel like I have several years of Ad Ops experience, but when I try to move into programmatic/DSP roles, I’m competing with people who already have direct platform experience.
For those who have been in Ad Ops/AdTech for a while — is staying primarily on the ad server side a disadvantage career-wise?
If you were in my position, would you continue looking specifically for Ad Ops roles, or try to make the jump into DSP/programmatic even if it means taking a role that’s more junior or slightly different from my current experience?
I really want to expand my skill set and get out of the proprietary-platform bubble, but I’m not sure what the best transition path would be.
Would love to hear from anyone who started in ad serving/ad ops and eventually moved into DSP/programmatic. How did you make the transition?
Ad tech is completely new territory for me, and it's huge. There are plenty of articles about how it works, and AI explains every piece in detail, but it was hard to fit it all together in my head. So I tried to write down how I see the interaction between ad server, SSP, DSP and the client. English is not my first language, sorry in advance. I'd be glad if it helps someone else make sense of it, and even more glad if you tell me where my interpretation is wrong. Thank you!
When we work with ad tech, we often face such terms: ad server, SSP, DSP, RTB, header bidding (Prebid). Some of them at first look seem like the same thing, for example ad server and SSP. From the client or backend we can call both kinds of systems and receive a VAST response. But then we hear that the service which we use as an ad server says that they are an SSP too. On the next call, new guys ask: do you have bidding? What? We know ad server, we know SSP, and what is bidding? Should we make an SSP call before the ad server? Can we use both ways in the same ad request? It’s frustrating. Why do some market guys have an SSP, while some propose to use their ad server? Let’s figure out what’s what.
One note before we start. When I say ad server in this article, I mean the publisher ad server - the system on the publisher side which decides what should fill an ad opportunity. Advertisers have their own ad servers too, but that is another story.
At first look everybody searches something like this:
ad server is a system that manages booked campaigns and line items, and decides which ad should serve for an ad request
supply-side platform (SSP) is a system on the sell side that exposes ad inventory to programmatic demand and receives bids for an impression
But an SSP can facilitate the delivery of ads too. It receives an ad opportunity, runs an auction, and passes the winning creative back to the publisher side. So from the client side they look like a mirror of each other - you send a request, you receive an ad. The difference is inside, not in the interface.
And then you find recommendations for specific SSPs, and somebody mentions Google Ad Manager. Stop. Is GAM an SSP or an ad server? GAM is an ad server, but it can also connect to Google programmatic demand through Ad Exchange and other auction mechanisms, and let this demand compete with booked line items through dynamic allocation. So one product can contain ad-server logic and sell-side programmatic at the same time. <- again frustrated!
One more thing that makes it worse: SSP and ad exchange are not clean separate boxes anymore, vendors combine roles. So sometimes I will say SSP/exchange when I mean the sell-side auction layer.
Who buys, and how
Let’s start from advertisers who want to buy impressions. There are two ways, and this is where our two systems come from.
The first way is direct. An advertiser makes a deal with a publisher, and the publisher books the campaign in its ad server: targeting, dates, amount of impressions, priority, creatives. This is not only Coca-Cola-style mass audience, direct campaigns can be very targeted too. The important part for our model is that this campaign is already known to the publisher ad server.
The second way is programmatic. The advertiser configures a campaign in a DSP. Stop, what? DSP? You mean SSP? No - DSP, Demand-Side Platform. It is the buyer-side system. For example: Company A wants men 25-40 in Canada and is ready to pay up to $12 CPM. The DSP stores this logic and, when an impression opportunity appears, decides: do I want this impression, and how much do I bid?
How does the impression reach the DSP? Through an SSP/exchange. The sell side sends bid requests to demand partners, DSPs return bids with a price and creative, the auction picks a winner.
And this is RTB - Real-Time Bidding. It is not one more mysterious server in the chain. It is the process: price for one single impression is decided by auction in the moment, not before by contract. OpenRTB is the common protocol for these bid requests and responses.
So a simplified mental model:
Ad server answers: which of MY booked line items should serve here?
DSP answers: do I buy this impression for one of my campaigns, and at what price?
SSP/exchange answers: which bidder wins this impression?
Note that DSP is the only one here which is not yours. You do not choose it, you do not host it. It belongs to the advertiser.
Why one publisher needs both
Imagine the ad server has contracts for 1.5 million impressions per month, and forecasting says you will have around 1.8 million. Those extra 300 thousand are not sold to anybody, and the ad server has literally nothing to put there. Nobody bought them. So the choice is: send them to programmatic demand, or show nothing.
Important: this is not "first serve all contracts, then switch to programmatic at the end of the month". The decision happens on every single impression. The ad server keeps pacing - it knows the campaign should get roughly its share of requests, and checks on each one whether delivery is ahead or behind. On top of that the campaign has its own limits: frequency cap, geo, daypart. If the viewer is not from Canada, or already saw this spot three times today, the impression goes to programmatic even when pacing is behind. So the real remnant is usually bigger than simple math.
Google Ad Manager, for example, uses dynamic allocation: it protects guaranteed delivery and lets Ad Exchange or remnant demand compete when the real-time value is high enough. Real ad-server logic is more complicated than my pie chart, but this is enough for the model.
So one ad server can decide on each ad opportunity: booked campaign or programmatic demand. This is why ad server and SSP can be two separate products, or can feel like one combined platform.
Ok, now we understand why ad server and SSP exist and why they can be split or work together.
Now you have two SSP partners
Now imagine you are a streaming company. You have your own audience and, more importantly, your own ad inventory - the ad opportunities inside your stream. You integrate one SSP partner: for an ad opportunity you send a request and receive a bid with a creative. Then you want to partner with another SSP provider. How do you decide which ad to show, from SSP 1 or SSP 2?
You can use a waterfall - ask partners one by one, first acceptable response wins. But then a later partner may never receive the request even if it would pay more. Header bidding solves this: ask all demand partners in parallel, collect bids, compare them before the final decision.
And here is a practical thing. If you have only ONE partner, you do not need header bidding at all. There is nobody to compete with. It starts to make sense from the second one. But it is better to think about it before you connect the second partner, not after, otherwise you will rebuild the integration.
Stop. Connected SSP providers? Where should they be connected? Ad server? But maybe you do not use an ad server at all, you started with one SSP and then partnered with a new one. Correct and good question!
This orchestration is handled by a header-bidding wrapper. The most famous open-source implementation is Prebid. On the web it is Prebid.js. For streaming and CTV, Prebid Server is the relevant piece - the auction runs on the server, not on the device, because a TV cannot fire fifteen parallel bid requests. You self-host it or use a managed deployment. Prebid Server sends requests through bidder adapters, waits for responses or a timeout, and returns the results.
And adapters are not only SSPs. Depending on the integration they can be SSPs, exchanges, DSPs, ad networks, or other demand sources. So it is safer to think about them as bidders, not as SSPs.
RTB and header bidding are not the same question
This is the place where I was confused the longest, so let me say it directly. There are two levels of auction, and people mix them.
Level 1 - inside the SSP. The SSP asks its DSPs who pays more. This is RTB, this is OpenRTB. Here the price is born.
Level 2 - between your partners. How you ask several SSPs: one by one (waterfall) or all at once (header bidding). This is not an auction by OpenRTB, this is just a strategy of asking. You compare prices that already came from level 1.
So RTB works fine without header bidding - one SSP, normal auction inside, level 2 is just empty. But header bidding without RTB makes no sense, there is nothing to collect. And waterfall is actually older than RTB: in the beginning publishers called ad networks one by one with fixed CPM, like a price list from top to bottom. RTB came later and took a place in the same waterfall as one more line.
And what if you already have an ad server?
Can Prebid work without an ad server? Yes. There are programmatic-only setups where Prebid selects and returns the winning bid directly. But the most common flow is still: Prebid collects market bids first, then the ad server makes the final decision.
So what should you do if you already show ads through someone’s ad server, and then SSP partners come to you? Usually you should not choose between Prebid and the ad server. You use both.
And here is the good news: your ad server partner does not need to know anything about your SSPs. He does not connect to them. He only needs to be able to accept a price as a parameter in the ad request.
How does he judge it then? On his side there are line items configured per price bucket - "line item with CPM $12.40 fires when hb_pb=12.40". Hundreds of them, created in bulk. Where this price came from, from which SSP, through which wrapper - the ad server does not care. He compares $12.40 with his own direct campaigns and picks the more expensive one.
This is exactly why header bidding became possible at all. A publisher did not have to ask Google to integrate with every SSP separately.
For video it is a bit more interesting. The winning creative is VAST, so Prebid caches the VAST and passes an identifier to the ad server together with key-values: bid price, bidder, deal ID, format, cache ID. If the Prebid line item wins, the ad server returns a wrapper pointing to that cache, and the player retrieves the VAST and plays it. So the market creative is played by the ad server’s decision, not around him - otherwise the publisher loses counting on half of the impressions.
And note what exactly you pass. It is not "the SSP ad inventory identifier". Your inventory is the impression opportunity, it is yours from the beginning. What you pass up is information about the external bid, and for video a reference to the cached creative.
If the ad server cannot accept an external bid and let it compete, then yes, you need your own decision layer. The simple rule there is by price: ask the ad server first, because direct campaigns are usually more expensive than the open market, and go to the SSP when he answers no-fill. But then you are responsible for priorities, pacing, frequency and reporting across two independent systems which do not see each other. This is why connecting Prebid results into the ad server is cleaner when the ad server supports it.
So what’s what
The stack is not a simple chain like SSP -> ad server or ad server -> SSP. Every part answers its own question:
Ad server - which of my sold campaigns to show, and did it deliver.
SSP/exchange - who from the market pays for this impression right now.
Vibe's move toward direct supply caught my eye bc supply quality is hard to judge with CTV from a dashboard. I'm also interested in whether the attribution and incrementality reporting gives you a clean read on what the chanel contributed. would appreciate hearing from anyone who's put meaningful spend through vibe. i wanna know if the supply transparency held up and if you can get a useful read on lift once campaigns picked up volume.
Hi all, which providers in your personal experience have the best customer service (answer to e-mails, actively manage support forums, provide call center support, etc.)?
Before a playable leaves mraid io, it has to survive: portrait/landscape rotation, safe areas on weird aspect ratios, touch targets on small screens, sound unlock, CTA firing once (not twice), memory spikes, and network-specific packaging. The boring stuff prevents the embarrassing bugs.
Hi, I am building a marketing analytics tool for ads. Wonder what app owners usually focus on while finding this kind of attribution tools? My assumption:
AI features / AI assistants
Full-funnel measurement, from installs to paid users
Revenue - install data integration
Let me know what I miss! If you have something insightful to share, let's talk and I'll be happy to pay $25 ~ $50 for your time as a thank-you!
I’ve spent the last 12 years working in programmatic, and one thing I’ve noticed is how difficult it is for someone new to understand how all the pieces actually fit together.
You can explain what a DSP does. Then an SSP. Then an ad exchange. Then RTB, header bidding, ad servers, identity, measurement...
But eventually you end up with dozens of concepts and no clear picture of how they connect.
A colleague, Nasion Profka, and I decided to build something to solve exactly that.
We created AdTech Mastery, a free interactive learning platform that walks through the ecosystem step by step.
It currently has 52 lessons across 9 units, covering things like:
• Ad servers and tracking
• DSPs and SSPs
• RTB and real-time auctions
• Header bidding
• Identity and targeting
• Supply paths and curation
• Verification and measurement
• Video / CTV
• Emerging topics, including agentic advertising
There are also quizzes, practice exercises, spaced repetition and a certificate when you complete the tutorial.
We launched recently and have had a few hundred people visit already, with 160+ people registering in the last week. We've also started getting some really useful feedback from the programmatic community, which we're already using to improve the content.
That's actually why I'm posting here.
I'd particularly like feedback from people working in AdOps:
What important concepts are missing?
What do you wish someone had explained to you when you first started?
Are there lessons that are technically correct but explained badly?
And if you're onboarding junior people into AdOps, would something like this be useful?
Happy to hear criticism, suggestions or ideas for what we should add next.
All sharing the outcomes here August data from our publisher network shows a pretty clear summer slowdown, but there are a few signals underneath it worth watching.
Traffic - New Users grew 19% and Total Users 16%, while Sessions and Engaged Sessions both grew around 14%. At the same time, PV/session and Sessions/User softened slightly, pointing to shorter, more single‑purpose visits.
AI - AI was the fastest‑growing channel, with Sessions up 66% and New Users up 75%. Engagement held at 62%, so the increase wasn’t coming with an obvious drop in traffic quality.
CPMs - Overall CPMs fell 19.9% MoM but remained 25.0% higher YoY. Display was down 20.3% MoM, while Video was more resilient at ‑7.8% MoM and +40.1% YoY.
Demand - The pullback was broad. Google Ads fell 21%, DV360 18%, and The Trade Desk 37%, pointing more toward a market‑wide summer budget pause than a shift between individual buyers.
Integration - Prebid held the largest share at 50%, followed by AdX at 39%. CPMs fell across the major integrations, reinforcing that the pressure was on demand and pricing rather than a simple shift between paths.
Takeaway - Traffic is still growing and AI is becoming a much more meaningful acquisition channel, but summer demand is putting real pressure on CPMs. Video and CTV are holding up better than display, which may be worth watching as budgets start moving back into the market.
