Engineering · 19 May 2026

Why the same impression arrives five times

Queries per second are not inventory. A transaction ID is how you prove five bid requests were one chance to show one ad.

Server racks with network cables in a data hall
Every extra copy of a bid request spends DSP capacity the impression will never repay.

A DSP pays for servers by how many bid requests it must read. That volume is QPS, queries per second. Publishers sometimes hear a high QPS number and think it means demand. Buyers hear it and think it means waste, unless each query is a distinct, buyable impression.

The usual waste is duplication. One person, one ad slot, one moment — and five requests — because several SSPs, a wrapper, and a reseller all offered it.

How one slot becomes five requests

  • The page calls three header-bidding partners, and each forwards the slot to the same DSP.
  • An app mediation platform and a direct OpenRTB seat both represent the same rewarded video.
  • A reseller forwards a request it already received from the publisher’s primary SSP.
  • The DSP itself sends multiple bids in one response (multi-bid). That is one request, not five. It should not be confused with five inbound copies.

If the buyer bids on every copy, it competes with itself. If it refuses all of them because the pattern looks like fraud, the publisher earns nothing. Neither result is what anyone wanted.

The transaction ID

OpenRTB’s transaction ID (source.tid) is a shared label for one impression opportunity. Every path that represents that same slot should carry the same tid. A different slot, refresh, or later page view gets a new one.

With a stable ID, a DSP can:

  • group the copies and bid once
  • prefer the shortest authorized path, which is the heart of supply path optimization
  • report one impression instead of five in measurement
  • tell multi-bid replies apart from duplicated requests

A random ID that changes on every hop is not a transaction ID. It is noise. Generate it once, where the impression is created, and pass it unchanged.

How an SSP should shape QPS

  1. Do not send a request the DSP cannot buy: missing consent, missing app-ads.txt authorization, or a placement the seat has blocked.
  2. Do not fan one impression out through several of your own seats.
  3. Cap refreshes. A slot that reloads every few seconds looks like new QPS and rarely looks like new attention.
  4. Watch the DSP’s timeout and no-bid rate. A partner that stops answering is telling you the QPS is too high or too low quality.
  5. Put source.tid on the request before you talk about “scale.”

What publishers can check without a packet capture

Ask each SSP how many bid requests they emit per thousand page views, and how many of those share a transaction ID with another partner. If requests per page are several times the number of ad slots, you are selling copies. Buyers will notice before the revenue report does.

FAQ

Is a high QPS bad?

High QPS on distinct, authorized impressions is scale. High QPS on repeated copies of one slot is a cost. DSPs throttle the second kind.

Who creates the transaction ID?

The system that first represents the impression opportunity. Downstream exchanges should forward it, not replace it.

Does tid stop invalid traffic?

It stops accidental double-counting of one opportunity. It does not prove a human is present. You still need the usual invalid-traffic controls.

← All posts · What is QPS? · Supply path optimization · OpenRTB integration