DSP-native frequency capping vs identity-graph capping: why your caps leak

Frequency capping limits how many times one user sees your ad. The tool you cap with determines how badly it leaks across devices and environments.

1. DSP-native, cookie-based capping: counts impressions against a cookie. The moment the same person appears on a new device, browser, or cookie-less environment, the counter resets. Your '3 per day' cap silently becomes 9.

2. Identity-graph capping: counts against a persistent person-level ID that stitches devices together. Holds the cap across screens, but only for users the graph can resolve — unresolved users still leak.

3. Channel-level capping (CTV especially): on connected TV there is no cookie at all; you cap against IP or device ID. Households share IPs, so an IP-level cap can over-suppress (capping a whole family as one user) or under-suppress.

4. The tradeoff: tighter identity resolution gives truer caps but covers fewer users; looser methods cover everyone but count wrong.

Why it matters: an advertiser reports 'we cap at 3' while a heavy user sees 15 because each device, each cleared cookie, each app is a fresh counter. Pull impression-per-unique distribution from log-level data, not the average. If the long tail of your impression-per-user curve is fat, your cap is leaking and the fix is the identity layer, not a lower number.

Pre-bid viewability filtering vs post-bid measurement: pay-to-avoid vs measure-to-learn

Viewability — whether an ad actually entered the user's screen long enough to count — can be handled before you bid or after you win. The choice trades cost against precision.

1. Pre-bid filtering: a vendor predicts the impression's viewability likelihood and your DSP only bids when the prediction clears a threshold. You never pay for predicted-unviewable inventory, but you pay a per-bid fee and act on a probability, not a fact.

2. Post-bid measurement: you bid on everything, then measure actual viewability after serving. You get ground truth and can optimize toward it, but you already paid for the unviewable impressions.

3. The tradeoff: pre-bid saves spend but filters on a model that is wrong at the margins, sometimes excluding viewable inventory and shrinking reach. Post-bid wastes some spend but teaches you the real distribution to feed back into bidding.

4. The mature setup uses both in sequence — post-bid measurement to learn the true viewability of each placement, then pre-bid rules built from that learned data rather than the vendor's generic model.

Why it matters: running pre-bid alone means optimizing on a prediction you never validate. Cross-check predicted vs measured viewability by placement in log-level data. Where the model consistently mispredicts a placement you value, override the pre-bid filter with your own measured floor.

Even pacing vs ASAP pacing: how your delivery setting decides what you pay

Pacing controls how your budget spends across the flight. The two default modes produce different costs and different audiences from identical targeting.

1. Even pacing: the DSP spreads spend smoothly across the day, throttling bids to hit a steady hourly rate. Smoother cost, but the throttle means you skip auctions during demand spikes — sometimes the very moments your audience is most active.

2. ASAP pacing: spend as fast as you can win until the budget is gone. Captures every early auction, but front-loads delivery into whatever hours open first and often clears at higher prices because you are not price-disciplined.

3. The mechanism behind the cost gap: even pacing effectively lowers your win-rate during peak hours (it is holding back), so you win more of the cheaper off-peak supply. ASAP wins peak supply at peak prices.

4. When to use which — even pacing for steady-demand goals where average cost matters most. ASAP for time-sensitive moments (a launch, an event window) where missing the peak is the real cost.

Why it matters: teams blame the algorithm for a high CPM when the pacing mode chose expensive peak inventory. Plot win-cost by hour against your pacing setting in log-level data. If ASAP is buying your spend into the three priciest hours, even pacing will lower CPM without changing a single targeting parameter.