What Does a Good SSP Actually Need to Provide a DSP?

In programmatic advertising, SSPs often describe themselves by the amount of supply they can provide:

“We have enormous volumes of impressions every month.”

For a DSP, that number alone means very little.

A DSP does not simply need more supply. It needs supply that can be understood, evaluated, trusted, priced, and purchased efficiently.

An SSP sits between publishers and buyers, and its real value is not just generating bid requests. Its job is to make publisher inventory easier for DSPs to evaluate and buy.

A good SSP should therefore provide much more than an OpenRTB endpoint.

It should provide clean signals, transparent supply paths, predictable infrastructure, strong fraud controls, meaningful inventory metadata, and enough consistency for a DSP to make automated decisions at scale.

At Amli Media — as both an SSP for publishers and a path for demand partners — this is how we think about buyability: volume without clarity is noise. So what does a good SSP actually need to provide to a DSP?

1. Clean and complete OpenRTB signals

The foundation is simple: send the information a DSP needs to make a bid decision.

An SSP may have excellent inventory, but if the bid request is incomplete, inconsistent, or poorly structured, the DSP cannot accurately value it.

Depending on the environment, useful signals can include:

• publisher.id
• site.domain
• app.bundle
• app.name
• device.ifa
• device.ua
• IP information
• geo signals
• device type
• OS and OS version
• browser information
• ad position
• inventory type
• content information
• language
• video metadata
• floor price
• auction type
• privacy signals
• supply-chain information
• seller information
• user signals where legally permitted

The important point isn’t simply sending more fields.

It is sending accurate and consistent fields.

For example, sending:

site.domain = example.com

is useful.

Sending:

site.domain = unknown

for a large percentage of traffic makes the inventory considerably harder to evaluate.

Likewise, an SSP should avoid sending contradictory signals such as an app bundle that doesn’t correspond to the application identity, or a device type that doesn’t match the underlying environment.

Data completeness is a buying signal

DSPs increasingly use automated supply-quality models.

That means missing or unreliable fields can directly affect:

• bid probability
• bid price
• campaign eligibility
• fraud scores
• contextual classification
• targeting
• optimization
• supply-source selection

A good SSP should therefore treat OpenRTB data quality as a product feature, not simply an integration requirement. Incomplete CTV requests are a clear example — see why CTV supply is harder to validate.

2. Accurate publisher and inventory identity

One of the biggest questions a DSP needs to answer is:

What exactly am I buying?

For web inventory, that may mean:

• domain
• publisher ID
• placement
• ad unit
• page URL
• content category

For apps, it may mean:

• app bundle ID
• app name
• store information
• publisher
• placement
• application category

The SSP should provide stable identifiers whenever possible.

If the same publisher appears as:

publisher_123
pub123
123
publisher-123

depending on the request, downstream systems have to treat them as separate entities unless additional normalization is performed.

That creates problems for:

• reporting
• frequency management
• supply optimization
• allowlists
• blocklists
• fraud analysis
• publisher-level bidding

A good SSP should make identity stable, deterministic, and explainable. Related: why DSPs reject otherwise good traffic.

3. Supply-chain transparency

This is where the SSP’s responsibility becomes much more important.

DSPs don’t only want to know which publisher generated the impression.

They increasingly want to understand:

How did this impression get from the publisher to me?

This is where schain becomes important.

A good SSP should provide accurate and complete SupplyChain information rather than treating it as an optional decoration.

But there is an important distinction:

A valid-looking schain does not automatically mean a trustworthy supply path.

A SupplyChain object is ultimately based on the information passed through the ecosystem. A technically valid chain can still contain incorrect or misleading information.

Therefore, strong SSPs should complement schain with additional validation mechanisms.

For example:

• seller identity validation
• ads.txt
• app-ads.txt
• publisher authorization
• reseller relationships
• contract-level authorization
• domain/app verification
• seller account mapping
• historical traffic analysis

The goal should be to build an authorization map.

Instead of asking only:

“Does this request contain a schain?”

the better question is:

“Does this supply path make sense, and is every seller in that path authorized to sell this inventory?”

That distinction is extremely important for DSPs — and sits at the heart of supply-path optimization (SPO).

4. ads.txt and app-ads.txt alignment

An SSP should not simply pass publisher inventory to DSPs.

It should understand whether it is authorized to sell that inventory.

For web inventory, this means validating against ads.txt.

For mobile applications, this means checking app-ads.txt.

A strong SSP should ideally maintain an internal mapping similar to:

Publisher
   ↓
Domain / App
   ↓
Publisher's authorized sellers
   ↓
SSP account
   ↓
Seller ID
   ↓
DSP-facing supply source

This allows the SSP to identify situations such as:

• unauthorized seller IDs
• unexpected resellers
• incorrect publisher IDs
• mismatched domains
• suspicious supply paths
• inventory being sold through an unexpected intermediary

This information is valuable to a DSP because it reduces uncertainty.

5. Meaningful inventory classification

A DSP doesn’t want to treat every impression equally.

A $0.20 CPM impression on an unknown mobile web property is very different from a premium CTV impression on a recognized publisher.

The SSP should therefore provide enough information for the DSP to classify inventory.

Useful signals may include:

Web

• domain
• page URL
• content category
• publisher category
• ad position
• above/below fold information
• environment
• language

Mobile app

• bundle ID
• app category
• app name
• store identity
• placement
• device type
• OS
• app content metadata

Video

• instream/outstream
• placement type
• player size
• duration
• position
• content category
• content length
• livestream/VOD
• skippability

CTV

• app/service identity
• device type
• content genre
• content rating
• program information
• channel/network information
• stream type
• ad pod information

The objective is not to send every possible OpenRTB field.

The objective is to provide enough context for the DSP to value the impression correctly. The same principle applies across Amli Media formats — display, native, video, CTV, and programmatic DOOH.

6. Privacy signals must be correct

Privacy information is another area where SSP quality matters significantly.

DSPs need to know whether user-level targeting is permitted.

Depending on the market and implementation, this may include signals related to:

• GDPR
• TCF
• US privacy frameworks
• consent
• opt-out
• limited data processing
• device-level privacy controls

A good SSP should not simply forward privacy information blindly.

It should:

1. correctly interpret the applicable privacy signal,
2. enforce the required restrictions,
3. avoid exposing identifiers when consent isn’t available,
4. communicate the restriction clearly to downstream buyers.

For example, if a request indicates that user-level processing is restricted, the SSP should not simultaneously provide a rich set of identifiers that effectively bypasses that restriction.

Privacy should be treated as a traffic-processing rule, not merely another OpenRTB field.

7. Strong IVT and fraud controls

One of the fastest ways for an SSP to lose DSP demand is to send large volumes of suspicious traffic.

A DSP doesn’t care that an SSP generated enormous request volume.

If a significant percentage is invalid traffic, those impressions may become economically worthless.

A good SSP should therefore have multiple layers of traffic-quality controls.

These can include:

• data-center traffic detection
• automated browsing detection
• bot detection
• device anomaly detection
• abnormal request-rate detection
• duplicate identifier analysis
• impossible geo/device combinations
• SDK integrity checks
• suspicious publisher detection
• domain/app reputation
• traffic-source monitoring
• external IVT validation

And importantly:

Fraud detection should happen before the traffic reaches the DSP.

The SSP should not expect the DSP to act as its fraud-filtering layer.

DSPs will obviously run their own systems, but an SSP that proactively removes obvious bad traffic creates a much healthier relationship.

8. Traffic consistency matters more than traffic volume

This is an underrated point.

Suppose an SSP normally sends:

100K QPS

and suddenly starts sending:

500K QPS

without any explanation.

A DSP may immediately become suspicious.

Was there:

• a new publisher?
• a new app?
• a traffic acquisition partnership?
• a configuration change?
• a technical retry loop?
• duplicated requests?
• a bot spike?
• a supply-path change?

A good SSP should monitor traffic behavior and communicate major changes.

DSPs value predictability.

Stable traffic allows DSPs to:

• allocate infrastructure
• optimize bidding
• manage budgets
• forecast spend
• detect anomalies
• maintain supply-source scores

9. Reasonable auction and floor-price behavior

The SSP controls an important part of the auction.

That means the DSP needs predictable auction behavior.

A good SSP should clearly communicate:

• auction type
• floor price
• currency
• timeout expectations
• deal information
• price transparency
• bid-response requirements

Floor prices should also make commercial sense.

If an SSP sends low-value inventory with an artificially high floor, DSPs will simply stop bidding.

Similarly, constantly changing floors without a logical pricing strategy can make optimization difficult.

A DSP should be able to learn:

“When this SSP sends this type of inventory at this floor, this is roughly the expected value.”

Predictability helps the DSP optimize — the same discipline behind dynamic floors that do not starve fill.

10. Low latency is a product feature

For a DSP, every SSP connection consumes infrastructure.

If an SSP sends requests with:

• inconsistent latency
• excessive timeouts
• slow connections
• large payloads
• unnecessary fields
• repeated requests

the DSP’s infrastructure costs increase.

Imagine a DSP receiving steady high QPS from an SSP.

If the SSP’s average processing or network behavior adds unnecessary latency, the DSP may have to allocate more resources just to maintain the same response rate.

A good SSP should therefore optimize:

• connection reuse
• request payload size
• timeout configuration
• compression where appropriate
• request batching where supported
• geographic routing
• endpoint health
• retry behavior

Don’t make the DSP pay for your inefficiency.

This is particularly important at large scale — and why timeout discipline on wrapper and S2S paths (including Prebid timeouts) is part of supply quality, not only publisher UX.

11. Duplicate and retransmitted requests should be controlled

Duplicate bid requests are extremely problematic.

If the same impression is sent multiple times to a DSP, the DSP may interpret the requests as separate opportunities.

That can cause:

• unnecessary CPU consumption
• duplicate bidding
• inflated QPS
• incorrect optimization signals
• increased infrastructure costs
• inconsistent reporting

SSPs should implement mechanisms to identify and control:

• retries
• duplicated auctions
• duplicated impression opportunities
• accidental fan-out
• request replay

A high-quality SSP should be able to answer:

“How confident are you that one real impression opportunity results in one meaningful auction opportunity?”

12. The SSP should provide useful reporting

A DSP needs more than bid requests.

It needs feedback.

At minimum, an SSP should provide useful reporting around:

• requests
• bids
• wins
• impressions
• spend
• revenue
• CPM
• win rate
• timeout rate
• response rate

More sophisticated reporting can include breakdowns by:

• publisher
• domain
• app
• placement
• country
• device
• format
• SSP account
• deal
• supply path

This allows the DSP to identify where performance is coming from.

For example:

SSP
 ├── Publisher A → strong performance
 ├── Publisher B → high IVT
 ├── Publisher C → low viewability
 ├── Publisher D → high win rate
 └── Publisher E → poor conversion

Without this visibility, the DSP has to treat the SSP as a black box.

13. Viewability and attention signals

For many advertisers, buying an impression isn’t enough.

They want impressions that have a reasonable probability of being seen.

SSPs can provide signals around:

• viewability
• ad position
• viewport information
• player visibility
• screen size
• placement
• above/below fold
• measurable vs non-measurable inventory

For video and CTV, additional quality signals can be even more valuable.

However, the SSP should distinguish between:

Observed measurement

and

Declared expectation.

If an SSP says an inventory source has 85% viewability, the DSP should ideally understand how that number was calculated.

Was it:

• SSP-measured?
• publisher-reported?
• third-party measured?
• modeled?
• historical?

Transparency increases confidence.

14. Don’t hide supply behind generic IDs

One of the biggest frustrations for DSPs is opaque supply.

For example:

publisher_id = 847392
domain = unknown
app = unknown
seller = SSP123

Technically, this may be a valid bid request.

Commercially, it is difficult to value.

A good SSP should expose enough identity for buyers to understand what they’re purchasing while respecting publisher privacy and commercial constraints.

The more opaque the supply becomes, the more likely the DSP is to:

• reduce bids
• apply conservative pricing
• exclude the source
• restrict targeting
• classify it as lower-quality supply

Transparency usually improves monetization.

15. A good SSP should understand its own supply

This may be the most important point in the entire article.

An SSP should know:

Where its traffic comes from.

It should be able to answer questions like:

• Which publishers generate the traffic?
• Which apps generate the traffic?
• Which reseller is responsible?
• Which countries are growing?
• Which sources have high IVT?
• Which publishers have abnormal request patterns?
• Which traffic sources have poor viewability?
• Which seller IDs are authorized?
• Which supply paths are direct?
• Which paths contain multiple intermediaries?
• Which sources suddenly changed behavior?

If the SSP itself cannot answer these questions, expecting the DSP to trust the supply is unrealistic.

16. Fast incident response

Even good SSPs will eventually have problems.

A publisher may get compromised.

A traffic source may suddenly generate bot traffic.

A configuration change may cause duplicate requests.

A reseller may introduce questionable inventory.

A DSP may detect an anomaly before the SSP does.

What matters is how quickly the SSP responds.

A good SSP should have:

• clear technical contacts
• escalation procedures
• monitoring
• traffic kill-switches
• publisher-level blocking
• source-level blocking
• fraud investigation processes
• incident communication

If a DSP reports:

“We’re seeing abnormal traffic from publisher X.”

the ideal response isn’t:

“We’ll investigate.”

and then silence for two weeks.

It should be:

“We isolated the source, stopped the traffic, and are investigating the affected supply path.”

That builds trust.

17. Supply quality should be measurable

SSPs should maintain internal quality scores for their supply.

For example:

Publisher Quality Score
-----------------------
Identity completeness
Supply-chain validity
IVT rate
Viewability
Latency
Bid rate
Win rate
Historical DSP performance
Traffic consistency
Authorization status

This allows the SSP to proactively identify problematic inventory before DSPs start blocking it.

The best SSPs don’t wait for DSPs to say:

“This traffic is bad.”

They identify it themselves.

18. Don’t optimize only for QPS

This is a common mistake.

An SSP may optimize its business around:

“How many bid requests can we send?”

But DSPs care about:

“How many valuable impressions can I actually buy?”

These are very different metrics.

For example:

All requests
        ↓
Eligible
        ↓
High-quality
        ↓
Targetable
        ↓
Bids
        ↓
Wins

Increasing the top number doesn’t necessarily increase the bottom numbers.

A good SSP should optimize for qualified opportunities, not raw request volume — the same mindset we use when advising publishers on JS tag vs S2S: more pipes are not always more revenue.

19. Direct supply is valuable — but it should be proven

SSPs often advertise:

“We have direct publisher relationships.”

DSPs should be able to validate that claim through the available supply-chain and authorization signals.

Directness matters because every additional intermediary can introduce:

• additional fees
• latency
• data loss
• duplicate auctions
• less transparency
• additional fraud risk

But simply claiming “direct” isn’t enough.

A good SSP should make directness verifiable.

20. Commercial transparency matters too

Technical transparency is only half the equation.

DSPs also need to understand the economics.

Questions include:

• What is the SSP’s fee?
• Are there additional intermediary fees?
• How are floors determined?
• Are deals passed correctly?
• Are there differences between gross and net pricing?
• Are there hidden routing costs?
• Are multiple auctions being run for the same opportunity?

The cleaner the economics, the easier it is for a DSP to determine the true value of the supply.

21. The ideal SSP → DSP relationship

The ideal relationship looks something like this:

That is how Amli Media approaches demand-partner integrations: OpenRTB 2.5/2.6, Prebid, and JS tags hitting one auction core, with identity, quality, and transparency treated as part of the product. Integration options →

A practical checklist for SSPs

Before connecting with a serious DSP, an SSP should be able to answer “yes” to most of these questions:

Supply identity

• Do we provide stable publisher IDs?
• Do we provide accurate domains or app bundle IDs?
• Can we explain where the traffic originates?
• Can we distinguish direct and reseller supply?

Supply authorization

• Do we validate ads.txt?
• Do we validate app-ads.txt?
• Do we maintain seller authorization mappings?
• Can we explain every meaningful node in the supply path?

Data quality

• Are OpenRTB fields accurate?
• Are identifiers consistent?
• Are geo and device signals reliable?
• Are privacy signals correctly processed?
• Are floors and currencies accurate?

Traffic quality

• Do we proactively detect IVT?
• Do we monitor abnormal traffic spikes?
• Do we detect duplicate requests?
• Do we monitor publisher-level anomalies?
• Do we have traffic kill-switches?

Performance

• Is our latency predictable?
• Are timeouts controlled?
• Do we avoid unnecessary request retries?
• Is our endpoint stable?
• Do we monitor DSP-specific performance?

Transparency

• Is schain accurate?
• Can DSPs identify the inventory?
• Can we explain our supply path?
• Are commercial terms understandable?
• Do we provide meaningful reporting?

Operations

• Do we have a technical escalation contact?
• Can we investigate suspicious traffic quickly?
• Can we block problematic publishers immediately?
• Do we communicate material traffic changes?

The real product of an SSP isn’t bid requests

This is perhaps the biggest mindset shift.

An SSP’s product isn’t:

“We can send you more bid requests.”

Its product should be:

“We can give you understandable, authorized, measurable, high-quality opportunities to evaluate — and we can explain where they came from.”

That’s a very different proposition.

For a DSP, supply quality can be thought of as:

Value = Identity + Quality + Transparency + Targetability + Performance − Risk

More traffic only increases value when those other components remain strong.

A smaller SSP with clean, transparent, authorized inventory can therefore be much more valuable to a DSP than a massive SSP sending poorly understood traffic.

Final thought

The best SSPs don’t try to make DSPs trust them.

They build systems that make trust verifiable.

They provide accurate OpenRTB signals.

They maintain clean supply paths.

They validate publisher authorization.

They remove obvious invalid traffic.

They provide meaningful inventory metadata.

They keep latency predictable.

They communicate changes.

And when something goes wrong, they can identify the source and stop it quickly.

That’s what a good SSP actually provides to a DSP:

not just supply, but confidence in the supply.

And in an increasingly crowded programmatic ecosystem, that confidence may be the SSP’s most valuable product.

FAQ

What does a DSP need from an SSP?

More than an OpenRTB endpoint: accurate bid-request signals, stable publisher and app identity, verifiable supply paths (schain, ads.txt, app-ads.txt), privacy enforcement, proactive IVT filtering, predictable latency and floors, and reporting that explains where performance comes from.

Why is OpenRTB data quality important for DSPs?

DSPs use automated supply-quality models. Missing, inconsistent, or contradictory fields reduce bid probability, price, campaign eligibility, and targeting accuracy — even when the underlying inventory is real.

Does schain alone prove a trustworthy supply path?

No. A technically valid SupplyChain object can still contain incorrect or misleading hops. Strong SSPs complement schain with authorization files, seller maps, domain/app verification, and traffic-history analysis.

How does Amli Media approach SSP quality for demand partners?

We treat buyability as a product: clean OpenRTB 2.5/2.6 signals, authorization-aligned supply, quality controls before the open auction, transparent paths across web, app, video, CTV, and DOOH, and reporting demand partners can act on.

← All posts · What is an SSP? · What is a DSP? · Demand partners · Publisher monetization