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.

Prebid.js vs Amazon TAM vs Google Open Bidding: the wrapper you buy through shapes your bid

A wrapper orchestrates the header-bidding auction on the publisher's side. The three dominant ones treat your bid differently, which matters even though you do not control the wrapper.

1. Prebid.js (open-source, client-side): transparent, every SSP called simultaneously in the browser. You compete on even footing, but you inherit browser timeout risk — a slow bid response is simply dropped.

2. Amazon TAM (Transparent Ad Marketplace): a server-side wrapper. Lower latency, but a more closed pipe; visibility into the auction is thinner.

3. Google Open Bidding: server-side, run by the same company that runs the ad server beneath it. Convenient, but the structural conflict (auctioneer also bidding) has been the subject of long-running scrutiny.

4. The buyer-side tell: which wrapper a publisher uses changes your effective timeout, your match rate, and how your schain reads. Prebid paths show many parallel SSP nodes; server-side wrappers collapse into fewer.

Why it matters: the same campaign wins more on a fast server-side wrapper and times out more on a slow client-side one, independent of your bid price. Segment win-rate by wrapper signature in log-level data. If you are losing auctions on a specific wrapper at a competitive bid, the loss is latency, not price — raising bids there is wasted budget.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

Log-level data vs aggregated reporting: the resolution gap that hides your real cost

Log-level data is one row per impression (or per bid). Aggregated reporting is the same data pre-summed into daily or campaign rollups. The choice between them determines which problems you can even see.

1. Aggregated reporting gives you averages: blended CPM, overall win-rate, daily spend. Fast, cheap, and it hides every distribution.

2. Log-level data gives you the distribution: the bid-to-clear gap on each auction, the seller ID on each impression, the exact path, the per-impression cost. Heavier to store and query, but it is the only place certain problems live.

3. The problems that are invisible in aggregates: self-competition across SSPs, fat-tail frequency leakage, a single placement dragging average CPM, over-shading on your best segment. An average of $2.40 CPM can hide a chunk bought at $9.

4. The tradeoff is operational: log-level needs pipeline and storage; aggregates need neither. Most teams default to aggregates and stay blind by convenience.

Why it matters: nearly every tactic in programmatic is diagnosed from a distribution, not a mean — yet most decisions get made on means. If you cannot pull per-impression rows, you cannot verify whether bid shading, SPO, or capping is actually working. The log is not a luxury for analysts; it is the instrument that makes every other tool legible.

Bid multipliers vs base-bid plus floor awareness: two ways to value an impression

When one audience segment is worth more to you, you can express that two ways inside the DSP. They interact with publisher floors very differently.

1. Bid multipliers: you set a base bid and apply percentage modifiers per signal (this geo +30%, this daypart -20%, this domain +50%). Stacked multipliers compound — three +30% modifiers do not add to +90%, they multiply to roughly +120%, often pushing bids far above intent.

2. Flat base bid with floor awareness: you bid a considered value and let bid shading negotiate against the publisher floor (the minimum the seller will accept). Simpler, less prone to runaway compounding.

3. The tradeoff: multipliers give granular control but compound silently and can blow past the clearing price, making shading work harder to claw the bid back. Flat bids are blunt but predictable.

4. The hidden interaction: a hard floor truncates your shaded bid. If your multiplied bid is $9 and the floor is $5, you clear at $5 regardless — your fancy +120% never mattered, you just paid the floor.

Why it matters: stacked multipliers create the illusion of precision while the publisher floor quietly sets your real price. Compare your intended bid, your post-multiplier bid, and your actual clear price per auction in log-level data. Where you keep clearing exactly at floor, your multipliers are decoration — the floor is doing the pricing.

CTV: programmatic guaranteed vs open-exchange biddable — why the auction barely exists here

Connected TV inventory is bought through the same programmatic pipes as display, but the tool tradeoff is inverted because the supply is scarce and premium.

1. Programmatic guaranteed (PG): fixed price, fixed volume, reserved. The dominant CTV path because publishers protect premium video and buyers want guaranteed delivery against a real impression.

2. Open-exchange biddable CTV: an auction does run, but thin. Far less liquidity than display, higher floors, more fraud risk on long-tail apps, and weak identity (no cookies, IP/device-ID only).

3. The tradeoff: PG gives certainty and quality but no auction price discovery — you pay the negotiated rate whether or not it is competitive. Biddable gives price flexibility but exposes you to scarce, floor-heavy, harder-to-verify supply.

4. The identity wrinkle: frequency capping and audience targeting both degrade on biddable CTV because matching runs on IP at the household level. PG deals often come with publisher-side audience guarantees that the open exchange cannot replicate.

Why it matters: applying display instincts — chase the open auction for cheap CPMs — backfires on CTV, where the open exchange is the riskier, not the cheaper, path. Validate any biddable CTV spend against schain and app authenticity in log-level data. If you cannot verify the app and the household-level cap, the PG premium is buying you the verification you would otherwise lack.