Measuring supply path quality with entropy
Supply path optimization (SPO) is choosing the fewest, cleanest routes from your DSP to a given publisher instead of buying the same impression through five resellers. Most teams audit SPO by counting paths. A sharper tool is borrowed from information theory: entropy.
1. For one publisher domain, list every seller path you won impressions through and the share of spend each carries.
2. Compute the spend distribution's concentration. One dominant path equals low entropy; spend evenly smeared across many resellers equals high entropy.
3. High entropy for a single domain is a red flag — it means you are buying the same audience through many intermediaries, each taking a cut and each a place where a bid request could be misrepresented.
Why entropy beats a raw path count: a publisher legitimately sold through two SSPs (an exchange that represents publisher inventory) is fine. The same publisher appearing across nine paths with spend spread thin is reseller sprawl, even though both are 'multiple paths.'
The action is to collapse toward the lowest-entropy route that still gives you scale — usually the direct or near-direct seller with the highest declared sellers.json relationship.
Why it matters: entropy turns a vague 'we should consolidate paths' into a ranked list of domains where consolidation recovers the most margin and removes the most spoofing surface.
Supply path optimization (SPO) is choosing the fewest, cleanest routes from your DSP to a given publisher instead of buying the same impression through five resellers. Most teams audit SPO by counting paths. A sharper tool is borrowed from information theory: entropy.
1. For one publisher domain, list every seller path you won impressions through and the share of spend each carries.
2. Compute the spend distribution's concentration. One dominant path equals low entropy; spend evenly smeared across many resellers equals high entropy.
3. High entropy for a single domain is a red flag — it means you are buying the same audience through many intermediaries, each taking a cut and each a place where a bid request could be misrepresented.
Why entropy beats a raw path count: a publisher legitimately sold through two SSPs (an exchange that represents publisher inventory) is fine. The same publisher appearing across nine paths with spend spread thin is reseller sprawl, even though both are 'multiple paths.'
The action is to collapse toward the lowest-entropy route that still gives you scale — usually the direct or near-direct seller with the highest declared sellers.json relationship.
Why it matters: entropy turns a vague 'we should consolidate paths' into a ranked list of domains where consolidation recovers the most margin and removes the most spoofing surface.
Why first-price auctions are not truthful, and what that costs you
A second-price auction (you win but pay the runner-up's bid plus a cent) has a famous property: bidding your true value is optimal. You can never be punished for honesty. First-price auctions, now standard in display, threw that away.
1. In second-price, your bid sets whether you win; the price is set by someone else. So you bid exactly what the impression is worth to you.
2. In first-price, your bid sets both whether you win and what you pay. Bidding true value means overpaying every time you win against weak competition.
3. The rational response is to shade below true value by an amount that depends on how much competition you expect.
The consequence is that every first-price bid encodes a guess about the rest of the auction. Get the guess wrong and you either overpay or lose winnable inventory. This is precisely why the shading engine became a core DSP feature rather than a nicety — it is doing the strategic math that the auction format now demands of every bidder.
Why it matters: in second-price you could reason about value in isolation. In first-price your optimal bid depends on competitors you cannot see, so the quality of your DSP's competitive-landscape modeling now directly determines your effective CPM. Evaluate vendors on that, not on UI.
A second-price auction (you win but pay the runner-up's bid plus a cent) has a famous property: bidding your true value is optimal. You can never be punished for honesty. First-price auctions, now standard in display, threw that away.
1. In second-price, your bid sets whether you win; the price is set by someone else. So you bid exactly what the impression is worth to you.
2. In first-price, your bid sets both whether you win and what you pay. Bidding true value means overpaying every time you win against weak competition.
3. The rational response is to shade below true value by an amount that depends on how much competition you expect.
The consequence is that every first-price bid encodes a guess about the rest of the auction. Get the guess wrong and you either overpay or lose winnable inventory. This is precisely why the shading engine became a core DSP feature rather than a nicety — it is doing the strategic math that the auction format now demands of every bidder.
Why it matters: in second-price you could reason about value in isolation. In first-price your optimal bid depends on competitors you cannot see, so the quality of your DSP's competitive-landscape modeling now directly determines your effective CPM. Evaluate vendors on that, not on UI.
From the network
Want more on Affiliate network reviews? @VerdictDesk covers it daily and goes deeper than most. Solid follow.
Want more on Affiliate network reviews? @VerdictDesk covers it daily and goes deeper than most. Solid follow.
The deal ID priority myth
Many buyers assume a Deal ID (a negotiated agreement encoded as a string passed in the bid request) guarantees priority access to inventory. For most deal types it does not. Understanding the taxonomy prevents expensive misunderstandings.
1. Preferred deals and private auctions are still auctions. Your deal often unlocks a price floor and audience, but you compete — sometimes against the open market, sometimes against other deal holders.
2. Programmatic Guaranteed is the only common structure that actually reserves volume at a fixed price; it bypasses the auction for the committed impressions.
3. Whether a non-guaranteed deal outranks open-market bids depends entirely on the publisher's ad server prioritization, not on the deal existing.
So a private marketplace deal at a $5 floor can lose to an open-exchange bid of $6 unless the publisher configured the line item to win on tie or near-tie. The deal gave you access and a floor; it did not give you the impression.
Why it matters: when a 'premium PMP deal' underdelivers, the cause is usually that it was never guaranteed and you were outbid or deprioritized in the publisher's ad server. Confirm the deal type and the publisher's prioritization before you blame your DSP.
Many buyers assume a Deal ID (a negotiated agreement encoded as a string passed in the bid request) guarantees priority access to inventory. For most deal types it does not. Understanding the taxonomy prevents expensive misunderstandings.
1. Preferred deals and private auctions are still auctions. Your deal often unlocks a price floor and audience, but you compete — sometimes against the open market, sometimes against other deal holders.
2. Programmatic Guaranteed is the only common structure that actually reserves volume at a fixed price; it bypasses the auction for the committed impressions.
3. Whether a non-guaranteed deal outranks open-market bids depends entirely on the publisher's ad server prioritization, not on the deal existing.
So a private marketplace deal at a $5 floor can lose to an open-exchange bid of $6 unless the publisher configured the line item to win on tie or near-tie. The deal gave you access and a floor; it did not give you the impression.
Why it matters: when a 'premium PMP deal' underdelivers, the cause is usually that it was never guaranteed and you were outbid or deprioritized in the publisher's ad server. Confirm the deal type and the publisher's prioritization before you blame your DSP.
The hidden economics of the header bidding timeout
Header bidding lets a publisher solicit bids from many demand sources in the browser before calling the ad server, so exchanges compete simultaneously instead of in a waterfall. The single most consequential setting is the timeout — how long the page waits for bids.
1. A short timeout (say 500ms) protects page speed but cuts off slower bidders, including some that would have bid highest. The publisher trades yield for latency.
2. A long timeout (1500ms+) captures more bids and lifts revenue per impression, but worsens Core Web Vitals and can reduce sessions, shrinking total impressions.
3. The optimum is not a number — it is the point where marginal revenue from one more bidder equals the marginal revenue lost to slower pages.
For buyers, the timeout is a silent filter on which auctions you even reach. If your DSP's bidder consistently responds in 600ms and a publisher runs a 500ms timeout, you are structurally excluded from that supply regardless of how much you would have paid.
Why it matters: when you can't win a known publisher at any price, measure your bidder's response latency against their timeout before assuming it's a deal or targeting issue. Latency is a competitive variable, not just an engineering one.
Header bidding lets a publisher solicit bids from many demand sources in the browser before calling the ad server, so exchanges compete simultaneously instead of in a waterfall. The single most consequential setting is the timeout — how long the page waits for bids.
1. A short timeout (say 500ms) protects page speed but cuts off slower bidders, including some that would have bid highest. The publisher trades yield for latency.
2. A long timeout (1500ms+) captures more bids and lifts revenue per impression, but worsens Core Web Vitals and can reduce sessions, shrinking total impressions.
3. The optimum is not a number — it is the point where marginal revenue from one more bidder equals the marginal revenue lost to slower pages.
For buyers, the timeout is a silent filter on which auctions you even reach. If your DSP's bidder consistently responds in 600ms and a publisher runs a 500ms timeout, you are structurally excluded from that supply regardless of how much you would have paid.
Why it matters: when you can't win a known publisher at any price, measure your bidder's response latency against their timeout before assuming it's a deal or targeting issue. Latency is a competitive variable, not just an engineering one.
Reading sellers.json as a graph, not a list
sellers.json (a public file where an exchange declares every seller account and whether it's a publisher or an intermediary) and the supply chain object in the bid request together let you reconstruct the full path of an impression. The skill is reading them as a connected graph.
1. Each hop in the supply chain object names a selling entity and its seller ID in that exchange's sellers.json.
2. Walk the chain: publisher to SSP to reseller to your DSP. Each node should be declared, and each declared 'PUBLISHER' node should appear only where a publisher legitimately sits.
3. A reseller declared as PUBLISHER, or a chain that names a domain whose ads.txt never authorized that seller, is a break in the graph — a sign of misrepresented or laundered inventory.
The graph view catches things a flat path list hides: the same impression sold through two chains that converge on an undeclared intermediary, or a 'direct' relationship that ads.txt contradicts.
Why it matters: validating supply chain objects against sellers.json and ads.txt is the cheapest fraud filter you have, and it runs on data already in your log-level feed. Inventory whose graph doesn't close is inventory you should stop buying before you optimize anything else.
sellers.json (a public file where an exchange declares every seller account and whether it's a publisher or an intermediary) and the supply chain object in the bid request together let you reconstruct the full path of an impression. The skill is reading them as a connected graph.
1. Each hop in the supply chain object names a selling entity and its seller ID in that exchange's sellers.json.
2. Walk the chain: publisher to SSP to reseller to your DSP. Each node should be declared, and each declared 'PUBLISHER' node should appear only where a publisher legitimately sits.
3. A reseller declared as PUBLISHER, or a chain that names a domain whose ads.txt never authorized that seller, is a break in the graph — a sign of misrepresented or laundered inventory.
The graph view catches things a flat path list hides: the same impression sold through two chains that converge on an undeclared intermediary, or a 'direct' relationship that ads.txt contradicts.
Why it matters: validating supply chain objects against sellers.json and ads.txt is the cheapest fraud filter you have, and it runs on data already in your log-level feed. Inventory whose graph doesn't close is inventory you should stop buying before you optimize anything else.
Stop optimizing to average CPM; model the clearing price distribution
Average CPM is a single number standing in for a distribution, and that abstraction hides the levers that actually move your win rate. The richer object is the clearing-price distribution: for a given segment, the full curve of what it took to win.
1. Pull every auction you bid on for one segment and record the minimum winning price where known (from win notices and loss reasons in log-level data).
2. Plot the distribution. You will usually see it is right-skewed — most impressions clear cheaply, a long tail clears expensive.
3. Your win rate is just the fraction of that curve sitting below your bid. Raising your bid sweeps you further up the curve, but with diminishing returns once you've cleared the dense low part.
This reframes bidding from 'pick a CPM' to 'pick a percentile.' Bidding to the 60th percentile of the clearing distribution might win 60% of available impressions; chasing the 90th costs far more per incremental win because the tail is expensive and sparse.
Why it matters: the distribution tells you where the cheap, winnable volume sits and where you're about to overpay for scarcity. Two segments with identical average CPMs can have completely different efficient bid points once you look at the shape.
Average CPM is a single number standing in for a distribution, and that abstraction hides the levers that actually move your win rate. The richer object is the clearing-price distribution: for a given segment, the full curve of what it took to win.
1. Pull every auction you bid on for one segment and record the minimum winning price where known (from win notices and loss reasons in log-level data).
2. Plot the distribution. You will usually see it is right-skewed — most impressions clear cheaply, a long tail clears expensive.
3. Your win rate is just the fraction of that curve sitting below your bid. Raising your bid sweeps you further up the curve, but with diminishing returns once you've cleared the dense low part.
This reframes bidding from 'pick a CPM' to 'pick a percentile.' Bidding to the 60th percentile of the clearing distribution might win 60% of available impressions; chasing the 90th costs far more per incremental win because the tail is expensive and sparse.
Why it matters: the distribution tells you where the cheap, winnable volume sits and where you're about to overpay for scarcity. Two segments with identical average CPMs can have completely different efficient bid points once you look at the shape.
Loss reason codes are the most underused field in the bidstream
When you lose an auction, many exchanges return a loss reason code: a small integer telling you why you lost. Most teams discard it. It is arguably the highest-signal field in log-level data.
1. Codes broadly split into 'lost on price' (you bid, someone bid more) and 'lost for non-price reasons' (creative rejected, below floor, bidder timeout, blocklisted advertiser, currency mismatch).
2. Aggregate the codes for a campaign that's underdelivering. If 70% of losses are non-price, raising bids does nothing — you are being filtered for a creative or eligibility reason.
3. 'Below floor' as a dominant code means the publisher's floor exceeds your bid; that's a targeting or PMP-negotiation problem, not a bidding problem.
The trap is that win-rate dashboards lump all losses together, so a campaign losing on creative policy looks identical to one losing on price. The reason codes are the only thing that separates them cleanly.
Why it matters: before you change a bid, pull the loss reason distribution. A surprising share of 'we can't win this inventory' problems are creative rejections or floor mismatches that no amount of money fixes. The field is already in your feed — wire it into your reporting.
When you lose an auction, many exchanges return a loss reason code: a small integer telling you why you lost. Most teams discard it. It is arguably the highest-signal field in log-level data.
1. Codes broadly split into 'lost on price' (you bid, someone bid more) and 'lost for non-price reasons' (creative rejected, below floor, bidder timeout, blocklisted advertiser, currency mismatch).
2. Aggregate the codes for a campaign that's underdelivering. If 70% of losses are non-price, raising bids does nothing — you are being filtered for a creative or eligibility reason.
3. 'Below floor' as a dominant code means the publisher's floor exceeds your bid; that's a targeting or PMP-negotiation problem, not a bidding problem.
The trap is that win-rate dashboards lump all losses together, so a campaign losing on creative policy looks identical to one losing on price. The reason codes are the only thing that separates them cleanly.
Why it matters: before you change a bid, pull the loss reason distribution. A surprising share of 'we can't win this inventory' problems are creative rejections or floor mismatches that no amount of money fixes. The field is already in your feed — wire it into your reporting.
Soft floors, hard floors, and why first-price killed the trick
A price floor is the minimum a publisher will accept. There were historically two kinds, and the distinction used to be exploitable.
1. A hard floor rejects any bid below it. Simple.
2. A soft floor (under second-price rules) was a threshold below which you paid your own bid, and above which you paid second price. Clever buyers bid just over the soft floor to win cheaply.
3. With the move to first-price, the soft-floor game collapsed: you now pay your bid regardless, so there's no second-price discount to engineer toward.
What remains is a strategic interaction between your shading engine and the publisher's floor. If the publisher sets a dynamic floor that learns from your bids, and your shading learns from clearing prices, you have two adaptive systems pushing against each other. Floors can ratchet up to capture the surplus your shading was trying to keep.
Why it matters: dynamic floors are why a publisher's effective CPM can rise even as the open market softens — the floor is harvesting the gap shading leaves. When a specific publisher's clearing price climbs against the market trend, suspect a learning floor and test how your DSP responds to floor signals in the bid request.
A price floor is the minimum a publisher will accept. There were historically two kinds, and the distinction used to be exploitable.
1. A hard floor rejects any bid below it. Simple.
2. A soft floor (under second-price rules) was a threshold below which you paid your own bid, and above which you paid second price. Clever buyers bid just over the soft floor to win cheaply.
3. With the move to first-price, the soft-floor game collapsed: you now pay your bid regardless, so there's no second-price discount to engineer toward.
What remains is a strategic interaction between your shading engine and the publisher's floor. If the publisher sets a dynamic floor that learns from your bids, and your shading learns from clearing prices, you have two adaptive systems pushing against each other. Floors can ratchet up to capture the surplus your shading was trying to keep.
Why it matters: dynamic floors are why a publisher's effective CPM can rise even as the open market softens — the floor is harvesting the gap shading leaves. When a specific publisher's clearing price climbs against the market trend, suspect a learning floor and test how your DSP responds to floor signals in the bid request.
Duplicate bid requests: the same impression asks you twice
In a header-bidding world, one ad slot can generate multiple bid requests that reach your DSP through different exchanges. You are being asked to bid on the same physical impression more than once, and how your DSP handles it changes your economics.
1. Identify duplication by hashing stable fields — user ID, slot/placement ID, timestamp window, page URL — across exchanges in your log-level data.
2. If your DSP bids independently on each copy, you can win the same impression's auction on two paths and effectively bid against yourself, or you win one and waste compute on the rest.
3. Worse, duplication inflates your apparent available supply and corrupts reach and frequency math, because two requests look like two opportunities when they're one.
The mitigation is request deduplication before bidding and choosing the single best path per impression — which is SPO operating at the request level, not just the seller level.
Why it matters: if your DSP doesn't dedupe, your supply path optimization is incomplete and your frequency capping is leaking, because the unit of analysis (a unique impression opportunity) is being double-counted upstream. Measure your duplication rate per publisher; double-digit percentages are common and quietly distort everything downstream.
In a header-bidding world, one ad slot can generate multiple bid requests that reach your DSP through different exchanges. You are being asked to bid on the same physical impression more than once, and how your DSP handles it changes your economics.
1. Identify duplication by hashing stable fields — user ID, slot/placement ID, timestamp window, page URL — across exchanges in your log-level data.
2. If your DSP bids independently on each copy, you can win the same impression's auction on two paths and effectively bid against yourself, or you win one and waste compute on the rest.
3. Worse, duplication inflates your apparent available supply and corrupts reach and frequency math, because two requests look like two opportunities when they're one.
The mitigation is request deduplication before bidding and choosing the single best path per impression — which is SPO operating at the request level, not just the seller level.
Why it matters: if your DSP doesn't dedupe, your supply path optimization is incomplete and your frequency capping is leaking, because the unit of analysis (a unique impression opportunity) is being double-counted upstream. Measure your duplication rate per publisher; double-digit percentages are common and quietly distort everything downstream.
Win notices bias your training data, and the bias is systematic
A win notice is the callback an exchange fires to tell you that you won and at what price. DSPs learn clearing prices largely from these notices. The problem is that win notices are a biased sample of all auctions, and the bias is predictable.
1. You only get a clean price signal on auctions you win. Auctions you lose return, at best, a loss code — rarely the actual clearing price.
2. This is censored data: the expensive auctions you lost are systematically missing from your observed price distribution.
3. A model trained naively on wins alone will underestimate true clearing prices, because it never sees the high-priced auctions it couldn't afford.
This is the same censoring problem that haunts bid shading, viewed from the data-science side. The fix is survival-analysis-style methods that account for the missing losses, or deliberate high exploration bids to occasionally observe the expensive tail.
Why it matters: any pricing model that learns only from won impressions will drift optimistic and gradually price you out of competitive inventory without anyone noticing. When evaluating a DSP's bidding intelligence, ask specifically how it corrects for censored losses — it's the difference between a model that holds calibration and one that slowly hallucinates a cheaper market than exists.
A win notice is the callback an exchange fires to tell you that you won and at what price. DSPs learn clearing prices largely from these notices. The problem is that win notices are a biased sample of all auctions, and the bias is predictable.
1. You only get a clean price signal on auctions you win. Auctions you lose return, at best, a loss code — rarely the actual clearing price.
2. This is censored data: the expensive auctions you lost are systematically missing from your observed price distribution.
3. A model trained naively on wins alone will underestimate true clearing prices, because it never sees the high-priced auctions it couldn't afford.
This is the same censoring problem that haunts bid shading, viewed from the data-science side. The fix is survival-analysis-style methods that account for the missing losses, or deliberate high exploration bids to occasionally observe the expensive tail.
Why it matters: any pricing model that learns only from won impressions will drift optimistic and gradually price you out of competitive inventory without anyone noticing. When evaluating a DSP's bidding intelligence, ask specifically how it corrects for censored losses — it's the difference between a model that holds calibration and one that slowly hallucinates a cheaper market than exists.
Take-rate stacking: where your CPM actually goes
The price you pay and the revenue the publisher receives are separated by a stack of take rates — the cut each intermediary keeps. Supply path optimization is, concretely, take-rate reduction. To optimize it you have to be able to see it.
1. Each hop (SSP, reseller, sometimes a second SSP) takes a percentage. These compound: a 15% SSP cut on top of a 10% reseller cut leaves the publisher roughly 76% of your spend, not 75%.
2. Some intermediaries take a fixed margin; others take a dynamic, undisclosed margin that varies by auction. The undisclosed ones are where money disappears.
3. You can estimate take rate per path by comparing your spend on a publisher through path A versus path B for matched inventory — the path that delivers the same audience for less is the lower-take path.
Log-level data from both sides (your spend, the publisher's payout, where you can get it) lets you measure the stack directly. Without it you are inferring.
Why it matters: SPO's real prize is not 'fewer paths' for tidiness — it's routing spend through the lowest-take path that preserves the publisher relationship, often recovering 10–20% of media cost. You can't manage a take rate you've never measured, so make path-level effective cost a standing report.
The price you pay and the revenue the publisher receives are separated by a stack of take rates — the cut each intermediary keeps. Supply path optimization is, concretely, take-rate reduction. To optimize it you have to be able to see it.
1. Each hop (SSP, reseller, sometimes a second SSP) takes a percentage. These compound: a 15% SSP cut on top of a 10% reseller cut leaves the publisher roughly 76% of your spend, not 75%.
2. Some intermediaries take a fixed margin; others take a dynamic, undisclosed margin that varies by auction. The undisclosed ones are where money disappears.
3. You can estimate take rate per path by comparing your spend on a publisher through path A versus path B for matched inventory — the path that delivers the same audience for less is the lower-take path.
Log-level data from both sides (your spend, the publisher's payout, where you can get it) lets you measure the stack directly. Without it you are inferring.
Why it matters: SPO's real prize is not 'fewer paths' for tidiness — it's routing spend through the lowest-take path that preserves the publisher relationship, often recovering 10–20% of media cost. You can't manage a take rate you've never measured, so make path-level effective cost a standing report.
Neighbor spotlight: @SmartlinkOps. They go deep on Smartlinks — the kind of channel you actually keep notifications on for.
Forwarded from Потрачено! Клуб спящих бизнесменов!
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 aff.top — вся индустрия арбитража в одном месте
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
This media is not supported in your browser
VIEW IN TELEGRAM
Алиса AI будет конкурировать с Google AI Studio
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
В Zennoposter добавили ИИ-помощник
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Bid request enrichment: the fields that decide before you do
A bid request is not a neutral fact sheet; it's a partly self-reported document, and several fields shape your bid before your logic runs. Knowing which fields are trustworthy is core craft.
1. Declared fields like viewability prediction, audibility, and content category come from the publisher or SSP and can be optimistic — they describe expected, not realized, outcomes.
2. Some fields are enriched mid-stream by intermediaries (added segments, inferred demographics). Enrichment can add value or add noise you're effectively paying for.
3. Signals like the supply chain object and sellers.json relationship are verifiable; signals like 'predicted viewability 80%' are claims.
The discipline is to separate verifiable fields from claimed ones and to calibrate claimed fields against your own measured outcomes. If a seller's declared viewability is 80% but your post-bid measurement says 55%, you should discount that seller's declared field by the observed gap.
Why it matters: you are bidding on a mix of facts and marketing. Building a per-seller calibration layer — comparing each declared field to what actually happened — turns the bidstream from a document you trust into one you score. That calibration is where sophisticated buyers extract edge that pure price competition can't.
A bid request is not a neutral fact sheet; it's a partly self-reported document, and several fields shape your bid before your logic runs. Knowing which fields are trustworthy is core craft.
1. Declared fields like viewability prediction, audibility, and content category come from the publisher or SSP and can be optimistic — they describe expected, not realized, outcomes.
2. Some fields are enriched mid-stream by intermediaries (added segments, inferred demographics). Enrichment can add value or add noise you're effectively paying for.
3. Signals like the supply chain object and sellers.json relationship are verifiable; signals like 'predicted viewability 80%' are claims.
The discipline is to separate verifiable fields from claimed ones and to calibrate claimed fields against your own measured outcomes. If a seller's declared viewability is 80% but your post-bid measurement says 55%, you should discount that seller's declared field by the observed gap.
Why it matters: you are bidding on a mix of facts and marketing. Building a per-seller calibration layer — comparing each declared field to what actually happened — turns the bidstream from a document you trust into one you score. That calibration is where sophisticated buyers extract edge that pure price competition can't.
This media is not supported in your browser
VIEW IN TELEGRAM
Новую Google reCapcha прошли статичной картинкой
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
DeepSeek представит последнюю версию v4
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
Why frequency caps leak across the open programmatic graph
A frequency cap (limit how many times one user sees your ad) sounds like a counter. In open programmatic it's closer to an estimate, and the leak is structural, not a bug.
1. Capping requires stable identity. When match rate is partial and identifiers fragment across exchanges, the same person can appear as several distinct users to your DSP.
2. Each apparent identity gets its own cap allowance, so a user who resolves to three IDs can see your ad three times the intended limit.
3. Cross-device and in-app environments amplify this; the deterministic link between a phone and a desktop is often missing.
The consequence is overexposure on your heaviest users and wasted impressions that also depress performance through ad fatigue — the opposite of what the cap was meant to prevent.
Mitigation leans on a unified identity layer and, where deterministic IDs are absent, probabilistic stitching with known error rates. But you should treat your cap as a soft target with a leakage percentage, not a hard ceiling.
Why it matters: if you report a 3x cap but your true distribution has a tail of users seeing your ad 8–10 times, your reach and effectiveness numbers are both wrong. Measure realized frequency from log-level impression data against your set cap; the gap is your identity fragmentation, quantified.
A frequency cap (limit how many times one user sees your ad) sounds like a counter. In open programmatic it's closer to an estimate, and the leak is structural, not a bug.
1. Capping requires stable identity. When match rate is partial and identifiers fragment across exchanges, the same person can appear as several distinct users to your DSP.
2. Each apparent identity gets its own cap allowance, so a user who resolves to three IDs can see your ad three times the intended limit.
3. Cross-device and in-app environments amplify this; the deterministic link between a phone and a desktop is often missing.
The consequence is overexposure on your heaviest users and wasted impressions that also depress performance through ad fatigue — the opposite of what the cap was meant to prevent.
Mitigation leans on a unified identity layer and, where deterministic IDs are absent, probabilistic stitching with known error rates. But you should treat your cap as a soft target with a leakage percentage, not a hard ceiling.
Why it matters: if you report a 3x cap but your true distribution has a tail of users seeing your ad 8–10 times, your reach and effectiveness numbers are both wrong. Measure realized frequency from log-level impression data against your set cap; the gap is your identity fragmentation, quantified.