Skip to main content
A campaign should be trying to achieve something, and you should be able to tell whether it did. A goal-seeking campaign states its goal in a form sellers can price against, keeps what each seller committed to, carries that commitment onto the booked media buy, and judges delivery against it. Take a buyer who says “find dog lovers in Slovenia and get them to my online store, €5,000”. Store traffic is how they will know it worked. Their agent turns that into a goal statement: clicks, at €3 or less per click, counted by the seller’s ad server, from a seller willing to guarantee the price. Sellers answer on those terms. One guarantees €3 per click and forecasts 1,700 clicks; one can only aim for €4.50; one does not sell on clicks and passes. The agent books the first. At the end of the flight the campaign reports 1,740 clicks at €2.90, which beat the target. This page explains each part of that loop. The field shapes live on the campaign and media buy guides; the request flow is in the buyer workflows.

​
The goal statement

A goal has four parts. You should be able to read all four in one line: clicks, at €3 or less, counted by the seller’s ad server, guaranteed. The first goal in the list is the primary goal. Sellers see the whole ranked list; commitments and delivery verdicts are judged against the primary goal.

​
Stating a cost or return target

A cost per result (“clicks at €3 or less”) and a return on ad spend (“4 back for every 1 spent”) are not stated on a goal in V3. They are the campaign’s bidding policy, in AdCP 3.2’s own shape, and apply to the primary goal:
  • bidding: { cost_per: { amount, strength } }: the average cost per primary goal result, in the campaign currency. cap keeps the average at or below the amount and accepts less delivery when necessary. target aims at the amount while balancing volume and spend.
  • bidding: { roas: { value, strength } }: the return per unit of spend. floor prefers less delivery to knowingly going below the return. target aims at the return. The primary goal must be an event goal whose every event source names its valueField.
strength is required, and a campaign carries one of the two, never both. A primary goal that already has a rate or “as much as possible” target cannot also take a policy. A goal holds one target, so the save is refused and asks you to keep one. Neither strength is a guarantee per result. What a seller commits to is in its answer to your goal (see what a seller can promise). bidding: null clears the policy. Reading campaigns with V3 get or search returns each campaign’s bidding, including a target set through V2, with a missing strength read as cap for a cost and target for a return. save_campaign refuses a cost_per or per_ad_spend target on any goal, and the refusal names bidding. In V2, performanceConfig.optimizationGoals[].target still takes those targets with an optional strength. A campaign written either way reads back the same: in V2 the policy shows as the primary goal’s target. A V2 campaign can carry a cost or return target on a goal other than the primary one, which V3 cannot state. V3 leaves that target alone when a save sends the same goal back unchanged. When a save removes or changes that goal, the target is removed and the response names it.

​
Who counts the result

Every goal is counted by exactly one party. Choosing a goal chooses who counts it, and each choice needs something different from you. Sellers never see your event source id, tracker configuration, or the names of your custom events. An event goal reaches a seller as its event type (for example purchase) and value field only.

​
Vendor-measured goals

Vendor-measured goals are in a pilot. Saving a new one from an account outside the pilot is refused with FEATURE_NOT_ENABLED. A vendor-measured goal a campaign already carries is kept when you edit the campaign. A vendor-measured goal names the vendor and the vendor’s own metric, the way AdCP keys it:
  • vendor is the domain that hosts the vendor’s brand.json, plus brand_id when that domain hosts several brands.
  • metric_id is the id the vendor publishes for the metric.
  • target is optional. A threshold_rate is a minimum rate per impression. On V3 a cost target goes in bidding, as for every goal.
V2 stores the same goal in camelCase: vendor.brandId and metricId. As for every V2 goal, its target can also be a cost_per with an optional strength; that is where a V3 bidding cost target reads back in V2. Sellers receive the goal in AdCP’s shape when their product declares that vendor and metric both in vendor_metric_optimization and in reporting_capabilities.vendor_metrics. The goal goes with a matching committed_metrics entry, because AdCP has a seller refuse a vendor goal unless it commits to reporting the metric. Every other seller sees the goal only in the brief’s goals section and does not have to report it. The execute response’s optimization_goals_dropped warning names each product that was not given the goal, and why. Goal progress judges a vendor-measured goal on the vendor’s values that sellers report in delivery, under the goal’s vendor and metric id. Nothing else stands in for them: not the seller’s own counts, and not an estimate.
  • A threshold_rate target is judged on the vendor’s value per measured impression. AdCP defines a rate target on a vendor metric as a minimum value per impression, so each reported value is weighted by the impressions the vendor measured (measurable_impressions). A report that covers a wider window, such as the flight so far, and says how many impressions it measured replaces the daily reports inside it, so no impression is counted twice. Two reports whose windows overlap without one containing the other are not judged (metric_unsupported), because the impressions they share would count twice. Like any rate, the verdict needs at least 1,000 measured impressions. A value that does not say how many impressions it measured is not counted, because AdCP treats missing coverage as unknown, not as full coverage.
  • A cost target is not judged (metric_unsupported). The vendor defines the metric’s unit, so a reported value cannot be told apart as a total or an average, and a cost per unit cannot be worked out from it.
  • No target: progress names the vendor and how many impressions it measured, with no number to judge.
  • No values yet: the goal reads as not reported (metric_not_reported), and missingMetrics names it as <vendor domain>:<metric id>.
The read’s basis is vendor_attested. It names the vendor and metric, the impressions the vendor measured, and coverage: the share of delivered impressions the vendor measured.

​
Where the vendor and metric names come from

A goal’s vendor and metric_id are identifiers, so a read that carries them also carries the names a person reads, beside the identifiers. Goal progress, the campaign seller scorecard, a seller’s scores and a seller’s Media Buys page show “Integral Ad Science · Brand safety rate” and keep integralads.com:brand_safety_rate alongside it. The identifiers stay the codes you send and match on. The names are display only and never an input. AdCP says where each one lives, and the platform reads it there: The platform reads the vendor’s catalog from the AAO registry, which crawls each measurement agent, so reading a goal never calls the vendor. When a name is missing or not yet fetched, the read shows the identifier in its place: the vendor’s domain, and the metric id written as words. The same goal can read by domain once and by name on the next read, because a name is looked up the first time it is needed and kept for hours; a read never waits more than a moment for it. A vendor that publishes no brand.json name, or no measurement agent, reads by its domain with no kind.

​
Your own measurement takes precedence

When your measurement source declares the goal’s vendor and maps the vendor’s metric to one of its outcome types, goal progress judges the goal on your measurement records instead of the values sellers report. Your records count for a campaign, media buy or package only when they name it.
  • A threshold_rate target is judged on the outcomes your records count divided by the impressions delivered on the days those records cover. For example, 1,500 store visits in a week the buy delivered 70,000 impressions is 0.021 visits per impression. Days your records do not cover do not count, so a measurement that arrives weeks late is not set against impressions it never measured. Like any rate, the verdict needs at least 1,000 delivered impressions.
  • Which records count: a media buy counts its own records, or, when it has none, its package records. A campaign counts its campaign-wide records when it has them, and otherwise adds up its buys’ records. A campaign-wide record is never split across buys.
  • Overlapping records: a record whose window covers another record’s window for the same geo replaces it. Two records for the same geo whose windows share days without one containing the other are not judged (metric_unsupported), because those days would count twice.
  • A cost target is still not judged (metric_unsupported).
The read’s basis is then advertiser_measured. It names the vendor and metric and the impressions the rate divides by. When your records do not name the campaign or media buy, goal progress falls back to the values sellers report. Sellers never see your records or which measurement source produced them.

​
Telling the seller how it is doing

A seller often cannot see the vendor’s numbers, so it cannot tell how its buy is doing on a vendor-measured goal. When your records name a seller’s media buy, the platform can send that seller a score on your behalf: an AdCP provide_performance_feedback assertion. This is in a separate pilot. Nothing is sent from an account outside it, even one in the vendor-measured goals pilot.
  • The score is performance_index: the rate your records show for that buy divided by the goal’s threshold_rate target, with baseline: "campaign_target". 1.0 means the buy meets the target, 0.5 half of it, and 2.0 twice it. There is no upper limit. The rate is the one goal progress shows for the buy, so it needs the same 1,000 delivered impressions. A score covers the latest unbroken run of days your records measure: if a week is missing, the score starts after the gap, so the days it claims are exactly the days it counts.
  • What the seller receives: the score, the vendor and metric id, the days your records cover (measurement_period) and feedback_source: "third_party_measurement". The seller never receives your outcome counts, the impressions behind the rate, your measurement source or your records.
  • When it is sent: an hourly check sends a new score when your records change the score or the days it covers. A revision names the score it replaces in supersedes_feedback_id. A score the seller already accepted is not sent again, and one it refused is not retried.
  • Who receives one: only the single seller behind the media buy. That is either a seller agent that supports AdCP 3.2 and declares that it accepts performance feedback, or a storefront this platform hosts, which always accepts it. A buy split across sellers, a campaign-wide record and a cost target are never scored. A cost score would be built on your cost, which includes the platform fee.
  • On a hosted storefront: the storefront keeps the score, and its seller sees it on the buy’s goal as buyer_reported, with a verdict from the score (1 or more is on track, 1.1 or more beats the target, less than 1 is behind) and no rate. Without a score the seller sees the goal as not reported. See A goal a measurement vendor counts.

​
What sellers see

When you request proposals, every solicited seller receives the same brief. Alongside the flight, geography, channels, formats and audience requirements, the brief carries a goals section: for each goal, its kind, metric or event type, target, priority and attribution window. A seller reads a line such as “clicks, target cost 3.00 or less per click in the buy currency, counted by the seller’s delivery metrics” and prices against it. A seller that receives the canonical AdCP 3.2 request_proposals call can also receive the primary goal in structured form, as criteria.outcome_target. It gets one only when it declares media_buy.outcome_target and its features.bidding_policy accepts a media-buy cost_per cap. The target names the goal’s metric and its cost per result as cost_per with an amount, the buy currency and strength: cap. It carries no volume. The primary goal qualifies when it has a cost target and is a delivery metric the outcome target can name (clicks, views, completed views without a view duration, engagements, follows, saves, profile visits or reach) with no attribution window. Every other goal travels in the brief only. The seller answers the cost it can plan to in its proposal’s terms (see best effort). The campaign budget stays withheld. The platform never turns a cost target into a volume for sellers (budget divided by cost per click), because that would hand every seller the budget. Sellers quote a price and forecast a volume; you decide how much of the budget to place with each.

​
Which goals a seller’s packages carry

The brief tells every seller about every goal. The media buy is stricter: each package sent to a seller carries only the optimization goals that the package’s product says it can optimize. AdCP products declare this in metric_optimization (metrics the seller measures, and the target kinds it accepts), conversion_tracking (conversion-event goals), vendor_metric_optimization (a measurement vendor’s metric) and max_optimization_goals (how many goals one package accepts). Some sellers reject a whole package that carries a goal they did not declare, so sending that goal would stop the buy rather than being ignored.
  • A goal the product does not declare (its kind, metric, target kind, reach unit, view duration, viewability standard or vendor metric) is left off that product’s package.
  • When the product accepts fewer goals than you set, the highest-priority goals are sent: priority 1 first, then the order you listed them.
  • A product that declares no optimization capability at all receives no goals: AdCP ties support for each goal kind to its declaration, so a product with none can optimize to none. The seller still sees every goal in the brief, and you can still buy the product; it just isn’t asked to optimize.
Goals left off a package are reported when the campaign executes. The execute response carries an optimization_goals_dropped warning for each affected media buy, naming the product, the goal and why it was not sent. The campaign keeps the goal, and other products that declare it still receive it.

​
How a package carries a cost or return target

AdCP 3.2 moves a cost or return target off the goal and into the package’s bidding policy, bound to the package’s primary goal. A seller receives that shape when it declares, in features.bidding_policy.package.fixed, the mode (cost_per or roas) and the strength the target needs. The package’s primary goal then has no target, and the package carries bidding.cost_per (an amount and a strength) or bidding.roas (a value and a strength). The amount is the target you set. A cost target with no strength is sent as cap: the seller keeps the average cost at or below the amount and delivers less if it has to. A return target with no strength is sent as target. Every other seller receives the target on the goal, as before. A package also keeps the target on the goal when it carries a bid price, or when a goal other than its primary goal has a cost or return target, because AdCP does not allow the two shapes on one package and the policy can express only the primary goal’s target.

​
Seeing it before you book

You do not have to wait for execute to find out. The same declaration, read with the same rule, tells you before booking which goals a product cannot optimize to:
  • Each proposal’s goal answers and each proposal-less product returned by request_proposals carry a goalCoverage: whether the product can optimize to your primary goal, and each goal it cannot optimize to, by priority, with the reason code.
  • Auto-select carries the same coverage on every product it selects.
A product that declares no optimization capability, or whose declaration does not match the AdCP schema, shows every goal as one it cannot optimize to, the same goals execute would leave off its package.

​
Expected performance against your goal

When your primary goal is on viewability or video completion and has a target, goalCoverage.expected also says what the product’s inventory is expected to deliver, read from the ranges in the seller’s forecast. For example, “expected 78%-88% viewable vs your 70%”. The verdict is likely when even the low end meets the required rate, possible when only the expected or high end does, and unlikely when the high end misses. Rates run from 0 to 1. There is no expectation when the goal has no target, the seller’s forecast has no range for the rate, or a cost goal has no CPM price in your campaign’s currency to judge it at (a CPM in another currency is never compared with your target). A viewable_rate expectation requires the goal and forecast to name the same standard (mrc or groupm). Missing, mismatched or mixed forecast standards produce no expectation. views counts content views and receives no viewability expectation. Click goals never get one: click-through rates differ too much between advertisers and creatives for a seller’s history to predict yours. The forecast describes the inventory before the seller optimizes toward your goal, so treat the verdict as a conservative read. A seller whose products cannot optimize to your goal still receives the brief, and you can still book them. Auto-select prefers products that can: it puts every product that can optimize to your primary goal ahead of every product that cannot. Among the products that can, it puts likely first, then possible, then products with no expectation, then unlikely, and keeps its usual order (historical score, or lowest CPM) within each group. A product that cannot optimize to the goal is chosen only once the budget reaches past every product that can. It is booked without the goals it cannot take, and its commitment is report_only unless its price is on the outcome itself.

​
What a seller can promise

AdCP is explicit about liability: a seller’s bid target is “not a per-result guarantee”. The guarantee, when there is one, is the price: a seller guarantees your goal only by pricing it. A seller that sells a fixed price per click is on the hook for that price, so you cannot pay more than it per click. A seller that sells impressions and promises to aim for €3 per click is trying. The platform reads each proposal’s commercial terms and labels every allocation with one of three commitment kinds. Three things follow. A seller’s prose (“we are confident in strong click-through performance”) never changes the kind; only terms do. A proposal is only as committed as its least committed part: if one allocation is guaranteed and another is report_only, the proposal’s commitment is report_only. And the kind says only whether the seller priced your goal. Whether that price meets your target is a separate fact, meetsAskedTarget: a guaranteed €3.50 per click against a €3 ask is still a guarantee, at a higher price. Volume and quality are separate facts too, and neither changes the kind. A product sold as guaranteed delivery says how many impressions the seller holds for you, and performance standards with a makegood policy say what the seller makes good if measured quality falls short. Read them beside the kind, in the answer’s delivery type and measurement terms and the proposal’s estimated volume. Proposals and booked buys stored before this reading read guaranteed only for a fixed outcome price on a guaranteed product or with a makegood policy. Those records are restated in a one-time pass after this change ships, so until that pass has run an older proposal or buy can still show its earlier label. Once it has, a fixed price on the outcome you asked for reads guaranteed on proposals and buys, except that an older answer to an event goal that also carries seller optimisation goals keeps its earlier label, because the stored answer does not show which event the price covered. Seller-history snapshots the co-op already published are not rewritten; the next snapshot uses this reading.

​
How proposals answer on the goal’s terms

Each quoted proposal carries one goal answer per allocation and a proposal-level commitment. The answer names the pricing model and fixed price, the delivery type, the measurement terms, the goal you asked for, the target the seller’s terms actually commit or aim at, and the resulting commitment kind. The proposal-level summary gives the weakest kind, the worst answered cost, and whether every allocation meets your asked target. That lets your agent compare sellers on the goal’s terms rather than on price alone: a guaranteed €3 per click and a best-effort €2.50 per click are different offers, and the second is not cheaper. Field by field, see Read what a seller committed to. A seller that returned no structured answer is labelled as such. The platform does not guess a commitment from how well the prose aligns with the brief.

​
Comparing proposals in the Campaigns view

Open a campaign in the Campaigns view and, once sellers have answered it, a Proposals section lists each proposal beside the others. Each row shows:
  • The seller and the proposal’s name, with whether it is quoted, booked, expired or withdrawn. A quoted proposal also shows how long the seller’s quote stays valid.
  • The answer to your goal. Meets your goal when the seller’s terms commit or aim at your target or better. Can do a different target when they commit to something else, with that target shown beside the one you asked for. No target for your goal when the seller’s terms are not tied to the goal. No goal answer when the proposal came back without a structured answer. The view never guesses an answer from the seller’s wording.
  • The commitment. Guaranteed, best effort or report only, as defined above. A proposal with several products shows the weakest commitment across them.
  • The price and budget. A proposal with one product shows its price per click, view or thousand impressions. A proposal with several products shows how many it holds. The budget is the seller’s own guidance.
  • The seller’s record on this goal, for accounts in the seller record pilot. Beside each proposal that answers a goal, the seller’s record on that same goal, with guaranteed and best effort shown apart because they mean different things. A rate always sits beside the buys behind it: “9 of 10 judged buys hit the target”, with how far from target the median landed. An account that joined the seller-history co-op sees the pooled record with its counts rounded, or “fewer than 40 judged buys” for a small one. Any other account sees its own buys with the seller. A seller with no completed buy on the goal reads “No history on this goal yet”. A proposal with no goal answer has no goal to read a record against, so it shows none. Accounts outside the pilot see no record column at all, and nothing in its place.
The view lists proposals in the order the platform returns them, newest first. It does not rank them. Three things come from the platform and are shown as it sends them:
  • A recommendation. When one quoted proposal meets your goal on a commitment, a line above the table names it: “Northstar Media guarantees your goal at $2.80”, or, when only a best-effort answer meets it, says best effort, never a guarantee. That proposal is marked Recommended and its Book is the primary action. The platform recommends a proposal only when it is quoted, can be booked, and its seller met your target with a guarantee or a best-effort answer. The strongest commitment wins, then the lowest answered cost, then the earlier quote. With none that qualifies, there is no recommendation.
  • The seller’s own forecast volume, under the price, when the seller’s forecast states one plainly, for example “Seller forecast: about 1,700 clicks, range 1,200 to 2,100”. Only a forecast point priced at the proposal’s budget counts; a point with no budget is the seller’s total available inventory, not what this proposal delivers. Nothing is worked out from the price, and a forecast that does not say shows nothing.
  • The seller’s record on this goal, as described above, now for event goals as well as metric goals, because the platform matches each proposal to its goal.
The view does not show the sellers that did not answer. Compare on the answer and the commitment before the price: a guaranteed price and a best-effort target are different offers. Book appears on each quoted proposal when you can edit the campaign. It asks you to confirm, and then creates a draft media buy from the proposal’s own terms and budget, the same as accepting the proposal through your agent. The buy stays a draft until you take it live. A proposal that has expired, was withdrawn or is already booked cannot be booked, and the view says which.

​
What the booked buy carries

Accepting a proposal books media buys, and each buy carries a goal commitment: the goal you asked, the target the seller answered, the commitment kind, the per-product answers, and the proposal version they came from. A buy created without a proposal (a social adapter such as Spotify, Meta, TikTok or Snap, a wholesale product, or a directed selection) still gets a commitment from its own terms: a fixed price on the outcome you asked for reads guaranteed even if you stated no goal. The commitment kind otherwise follows the same price-or-target rule proposals do — it does not become best_effort just because the product covers your goal. When a product’s own optimization declaration covers your goal, its per-product answer carries a note that the product applies the goal by its own design, not a price or target you negotiated, so a report_only or best_effort reading next to that note is not the seller ignoring your goal — it is the product pursuing it without pricing or targeting it. Many of these products declare exactly one metric with no configurable target — the product’s objective is simply fixed, and booking it books that objective, whatever you asked. The commitment is fixed at booking, and a buy’s own per-product answers never change after that. Only two things give a buy a different reading: appending a new product to it picks up the campaign’s goals as they stand at that moment for the newly appended line only, and accepting an update proposal books a new row with the commitment that proposal’s own terms answer. An in-place edit that touches no product — a budget change, a name, a flight date — keeps the row’s existing commitment exactly as booked, because nothing about what the seller promised changed. So adding or changing your campaign’s goal after a buy already exists does not reach that buy on its own: see the next section for how to tell which buys are affected.

​
When a goal change won’t reach an existing buy

Saving a changed optimizationGoals, and previewing a campaign launch (desiredPhase: "active" without confirming), both check every existing media buy in the campaign against the goal you are about to save or already have, and name the ones it won’t reach, with why:
  • Its product doesn’t declare support for the goal, now or ever, unless the product itself changes. Rebooking or refreshing the buy will not help.
  • Its product is fixed to a different single objective — a genuine conflict, for example a clicks goal next to a “Brand awareness – Reach” buy, where the product’s one fixed metric contradicts what you are asking for.
  • The buy was already booked before this goal existed or changed. Its product would cover the new goal, but the buy’s stored commitment predates it and nothing resends the goal to an already-booked line on its own — append a new product to the buy, or book a new one, to pick it up.
These are warnings, not refusals: saving the goal or launching the campaign still proceeds, and the affected buys keep delivering on their existing commitment.

​
Judging delivery

A campaign with a goal reports two different things, and they answer two different questions. Pacing answers “is the money moving on schedule?”. It compares delivered spend with how much of the flight has run — not with the budget alone, because a buy three days into a thirty-day flight that has spent a tenth of its budget is exactly on pace, while a buy on its last day that has spent the same tenth is nine tenths undelivered. Goal progress answers “is the campaign achieving what it set out to?”. It compares the number the goal is counted on (clicks, completed views, viewable rate, leads) against the asked target and the seller’s commitment. The two are reported side by side, because “spend 200 a day at 80% viewable” is two answers, not one: a buy can be on pace and missing its quality bar, or hitting its quality bar and underspending. Both read on Get reporting metrics. In the Campaigns view, open a campaign to see its goal bar beside pacing, and again on each media buy. The bar shows what you asked, what the seller committed to, what has been delivered, and whether the result is on track, behind, or beat target. A campaign or media buy with no goal and no seller commitment shows no bar. The view reads goal progress for a campaign’s first 100 media buys; for a campaign with more, buys beyond the first 100 show no bar there. Get reporting metrics carries goal progress on every media buy block it returns. Goal progress is judged on these rules:
  • Achieved, not estimated. The achieved cost per unit, rate, or volume is computed from the same delivery metric the goal names. A missing metric is reported as unavailable, never as zero.
  • No verdict without evidence. A verdict of on track, behind, or beat is given only when there are enough observations for the metric to mean something. On day one, or when the seller has not yet reported the metric, the campaign says why there is no verdict yet instead of guessing. A rate is judged on how large the population it divided by was, not on its own count, so a low rate over a large, well-measured population is still a real verdict.
  • Basis. Every number says who counted it: the seller, a measurement vendor (with its coverage), or your own event source (with its attribution method and window). A seller’s click count and your pixel’s click count are both real and can legitimately differ.
  • Freshness. Every number says how final it is: the period it covers, the measurement window, whether a later window supersedes it, and which metrics the seller committed to report but has not yet.
Viewability goals use matching counts. A viewable_rate goal is judged from stored viewable and measurable impression counts reported in AdCP’s viewability object. An MRC goal accepts reports with standard: "mrc" or no declared standard. A GroupM goal accepts only standard: "groupm" reports. Counts under different standards are never combined. Progress is withheld when counts come from different counters or reporting windows overlap without one containing the other. A rate verdict still needs at least 1,000 measurable impressions.A viewable_rate goal without a standard remains readable but is not scored. When matching counts are unavailable, the goal reports metric_not_reported, with viewability in missingMetrics. The views metric counts content views, the quantity CPV pricing bills on.A measurement-vendor or event-source basis is still planned. Every number today is counted by the seller, and says so.

​
The seller’s record

Once a buy with a commitment completes, the platform keeps what was asked, what was answered, what was delivered, and whether the seller beat, met or missed its commitment. It rolls these up per seller, per goal objective (for example clicks, or an event type such as purchase) and per commitment kind, because a kept guarantee and a beaten best effort are different facts. The record covers completed buys whose delivery was last reported in the past 180 days, judged the same way as the goal progress you see on your own buys. For accounts that use product scoring, it also informs how automatic selection ranks products. Whose buys the record is built from depends on whether your account joined the seller-history co-op. An account that did not join reads its own completed buys with each seller, and automatic selection ranks with the same. A member reads the co-op’s published pooled history of the seller instead, and automatic selection ranks with that. Each cell of the record reads: In a member’s pooled record, buys and judged are rounded to the nearest 5 when it is built from 40 or more judged buys, so no count is exact, and a smaller record shows a size band and a coarse hit rate instead. The read says which one you are looking at in commitmentRecordSource: coop for the published pooled history, own for your own buys. Buyers read it on the seller, in the pilot. Ask for it with include: ["commitmentRecord"] on search or get with kind: "seller". Without the include, a seller read is unchanged. A buyer that is not a co-op member reads its own buys with the seller, with no minimum, because they are its own. A member reads the co-op’s published pooled history, and a cell is shown only when at least 3 distinct operators and at least 5 judged buys stand behind it, with no operator supplying more than half of them. A seller can have no cell to show yet; that is not the same as a seller that missed. The record never names a buyer, a campaign or a media buy, and never says how many buyers or operators stand behind a cell. An account outside the pilot that asks for it is refused with FEATURE_NOT_ENABLED; it is never handed an empty record that could be mistaken for “no record”. What a member shares and gets, and how leaving works, is on the seller-history co-op. Sellers see their own record. A seller asks for the same include on its own seller read and sees every cell for its own Storefront, without the floor above. Each input is the seller’s own evidence: its answers to goals disclosed to it, judged on the delivery it reported. It still names no buyer, campaign or media buy. A seller that can see its record can question it.
Pilot. Sellers can read their own record now. Buyer access is limited to accounts in the pilot, and widens after sellers have been told what buyers see.

​
Scoring the sellers in a campaign

The campaign seller scorecard answers “how did each seller do in this campaign?” It scores every seller you bought from in the campaign on four things, each judged on its own: Each score carries the seller’s rank among the campaign’s sellers on that score alone, and who counted it: the seller, a measurement vendor, or your own event source. There is no blended score. “Costs more but performs better” is two answers, and one number would hide exactly that trade-off. A score with no data reads as not reported, never as zero. It has no rank and never drags a seller down. A score over too little delivery to compare is shown but not ranked, under the same minimums goal progress uses.

​
What the quality score holds

The quality score is served to agents on V3, on the campaign sellerScorecard include and the seller scores include, and shown in the Campaigns view. The V2 Get campaign seller scorecard read keeps quality not reported, so a V2 field keeps its type. Quality is the viewable rate: viewable impressions over the impressions the counter could measure, never over all impressions. The seller reports the counts in its delivery report, and a measurement vendor may count them instead; the score says which. It adds the counts across the seller’s buys in the campaign, so it is a rate over the whole campaign rather than an average of rates. A seller whose buys were counted by different counters has no quality score, because counts from different counters cannot be added. The score carries:
  • viewableRate, with the viewableImpressions and measurableImpressions behind it.
  • coverage, the measurable impressions over the impressions the seller delivered. A rate over a small share of the delivery says so here.
  • standard and verdict, when you set a viewability standard (for example MRC at 70%) on every package behind the rate. standard is your standard in the same shape you sent it, and verdict is met or missed. One package that missed the standard makes the verdict missed. When your packages carry different viewability standards, or a package behind the rate has none, there is no standard and no verdict, because the rate would include delivery the standard was not set for. When none could be judged for lack of measured impressions, there is a standard and no verdict. The rate still shows.
A seller’s quality ranks highest rate first, and only against sellers whose rate was counted the same way: the same counter, under the same viewability standard (MRC or GroupM), over enough measured impressions to compare. When the campaign’s sellers were counted differently, no seller gets a quality rank and the reason is not_comparable; each still shows its own rate.

​
Invalid traffic and brand safety: name the vendor metric

AdCP’s performance standard names the verification vendor but not which of the vendor’s metrics holds the value, and a vendor can report several (more than one invalid traffic rate, say). So Interchange does not guess: an ivt or brand_safety standard reads as not reported until you name the metric. Name it on the standard you set on the package with V3 save_media_buy, in ext.apostra.metric_id, with the vendor it belongs to. The V2 media buy tools do not carry ext:
metric_id is the identifier from the vendor’s own metric list. It is an extension, named as one: a proposal to carry the metric on the AdCP standard itself is with AdCP, and ext.apostra.metric_id goes away once AdCP ships the equivalent. Interchange uses it only to judge delivery and never sends it to the seller; the seller is sent AdCP’s own fields. Interchange then judges the vendor’s value for that metric against your threshold, the way AdCP defines it: invalid traffic is a ceiling (the rate must not exceed it) and brand safety is a floor. The quality score carries each as its own part, beside the viewable rate:
  • invalidTraffic and brandSafety: the vendor’s rate (weighted by the impressions it measured), measurableImpressions, your standard (with the ext that named the metric), the verdict (met or missed; one package that missed makes it missed) and countedBy, the vendor.
A part is present only when every package of the seller’s buys carries the same standard and the vendor reported a usable value for each. Otherwise it is null, never a guess: a package with no standard, standards that differ, a vendor that reported nothing for the metric you named, or too few measured impressions all leave it out. A seller that reported no viewability still shows its vendor parts, and viewableRate is then null. Only the viewable rate is ranked and totalled. A seller reading its own scores sees the vendor’s rate for the metric you named, as invalidTraffic and brandSafety with the rate, the impressions measured and who counted it. It never sees your threshold, your verdict or the metric id. The scorecard uses only your own media buys in the campaign, never other buyers’ results. Over the API, read it with Get campaign seller scorecard. Agents on V3 read it with the campaign include: get with kind: "campaign", the campaign’s id and include: ["sellerScorecard"]. That read scores the campaign’s whole reported life and takes no dates, and it is a Buyer Account read: a Seller Account cannot request it, and a campaign search does not offer it. It carries at most 50 sellers, most spend first, and sellersOmitted counts any beyond that. Ranks are computed over every seller before the cut, so a seller’s rank does not depend on the bound. The text answer names each seller beside its Storefront id and gives each score’s value and rank, or the reason it has no rank. When the reporting store is missing days, it says so: spend is then understated, so delivery and price read as not reported for every seller. In the Campaigns view, open a live campaign to see the seller scorecard below its media buys:
  • Four scores lists each seller with its delivery, price, performance and quality. Each score shows its value, the seller’s rank on that score alone (1 is best), or the reason it has no rank, and who counted it. There is no overall column.
  • Quality against price puts each seller’s quality score and price side by side, each with its own rank. The two are never divided into a ratio or combined into one number, so a seller that costs more and delivers better quality reads as exactly that. This view appears as a second tab once any seller in the campaign has a quality score; until then only the four scores show. A quality cell shows the viewable rate, your standard with whether it was met, and how much of the delivery was measured.
The view lists ten sellers a page, in the order the scorecard returns them, and says how many sellers with the least spend the read left out. A draft campaign shows no scorecard, and neither does an account that does not have the scorecard.

​
Your history with one seller

The same scores answer “how has this seller done for me?” across your campaigns. Agents on V3 read them on the seller: get with kind: "seller", the seller’s id and include: ["scores"]. The scores come back on the seller object as scores, beside the rest of the seller read.
  • One entry per campaign. Each campaign you ran with the seller is an entry in campaigns, most recent delivery first, with at most 25 listed. campaignsOmitted counts the rest, so you can tell a complete history from a cut one. Each entry carries the campaign’s campaignId and campaignName, lastDeliveredOn, the seller’s mediaBuyIds in it, and its delivery, price, performance and quality scores. Each score carries the seller’s rank among that campaign’s sellers, and it matches what the campaign’s own scorecard shows for the seller. A campaign whose buys with the seller have reported no delivery yet is listed last, with every score not reported.
  • Totals for what means the same thing everywhere. totals counts the campaigns where the seller delivered on pace, behind or ahead, and those with no pace verdict, over every campaign, including any not listed. Quality is totalled too: totals.quality counts the campaigns where the seller met or missed your viewability standard, those with a rate and no verdict (notJudged) and those with no rate (notReported), and adds the viewable and measurable impressions into one viewability rate when one counter counted every campaign (otherwise it is null). Price and performance are never totalled, because each campaign prices and judges them in its own goal’s unit; a total would blend cost per click with cost per visit.
  • A campaign that cannot be scored is named, not dropped silently. When a media buy in a campaign reported spend that cannot be put in a single currency, no spend figure for that campaign would be correct. That campaign is listed in unavailableCampaigns with the reason, which names the media buys at fault, and totals.campaignsExcluded says how many campaigns the totals leave out. Your other campaigns with the seller are still scored.
These are your own buys only. A seller search does not offer the include, so a listing never carries a seller’s history. A seller’s record across many buyers is the separate commitmentRecord include described in The seller’s record.
Who can read it. The scorecard and the seller’s scores are on for buyers on the standard buyer profile and for buyers in the V3 beta. A buyer without them who requests the V3 campaign sellerScorecard include or the seller scores include receives a FEATURE_NOT_ENABLED error, never an empty scorecard or empty scores.

​
A seller’s own scores

A seller asks “how am I doing for each of my buyers?” A Seller Account reads its answer on its own seller read: get with kind: "seller" and include: ["scores"], with no id, because a Seller Account’s seller read is always its own Storefront. The scores come back on the seller object as scores.
  • One entry per buyer and campaign. entries holds one entry for each buyer campaign the seller has buys in, most recent delivery first, with at most 25 listed. entriesOmitted counts the rest. Each entry names the buyer (its customer id and name, as the seller’s media buy reads name it), the seller’s own mediaBuyIds for that campaign, lastDeliveredOn, the currency of the requests the seller was sent, and the four scores. An entry never names the buyer’s campaign. Grouping does tell the seller which of its buys belong to the same campaign.
  • Built only from what the seller holds or was sent. Delivery is the seller’s own delivery reports against the budget on the request it was sent and an even pace across each buy’s flight. Performance is the goal judgement the seller already sees on each buy (see The buyer’s goal), over its own delivery. For a goal a measurement vendor counts, it is the score the buyer’s side sent, when the entry is a single buy: a score covers one buy, and scores for different buys cannot be added. Quality is the seller’s own viewability counts, as viewable and measurable impressions and their rate.
  • Price is the seller’s own net price. It is the seller’s own net spend per unit of the goal it was sent, or per thousand impressions when it holds no goal delivery can price. A seller never sees your fee-inclusive price, a ratio built from it, a rank, or another seller’s figures. Your price includes the platform fee, and a seller that knows what it charged could work the fee out from it.
  • Each score says who counted it: the seller, a measurement vendor, your own event source, or buyer when it is a score your side sent. A score with no data reads as not reported, never as zero. Money in more than one currency within an entry is not added, so delivery and price read as not reported.
  • Only buys placed through the platform. A buy from a buyer that reached the seller from outside the platform has no campaign here, so it is not scored.
Every Seller Account can read its own scores, as it can read its own commitmentRecord. If they cannot be loaded, the seller read still returns, and unavailableIncludes says why. Demo Storefronts show a generated record. A Demo Storefront has no buyers and no completed buys, so a Seller Account whose Storefront holds an active demo lease reads a generated commitmentRecord and scores on its own seller read, so a seller demo can show history. The read carries synthetic with the demo notice: the figures are fixed for the day, are not real history, and are unsuitable for commercial decisions. They are never stored, never pooled into the co-op and never shown to a buyer. A real Storefront, and a demo whose lease has ended, read their real record.

​
If you do not state a goal

A goal is optional. Without one, sellers price against the brief alone: the brief they receive carries no goals section. Each proposal still carries goal answers and a commitment kind read off its terms, but they answer no goal of yours. The asked goal and meetsAskedTarget are empty, and the kind only says whether the seller priced on an outcome at all (a fixed price per click still reads guaranteed). Compare such offers on price, forecast and fit to the brief. You can add a goal later. Sellers answer the goals in the brief they received, so a proposal round requested before the goal existed does not answer it; request a new round for sellers to answer on the goal’s terms.

​
Three questions to ask before you book

How will you know it worked? Name the number and the target. If the answer is “more sales”, the goal is a purchase event and the target is a cost per purchase or a return on ad spend. If the answer is “people saw it”, the goal is reach or completed views. Who counts it? A metric goal is counted by the seller, so the seller can guarantee it. An event goal is counted by your event source, so you need one set up, and the seller can only aim for it unless it can read your events. A vendor-measured goal is counted by the vendor. Is the seller liable? For the price, when the commitment kind is guaranteed: a fixed price on the outcome you asked for. It does not promise volume or quality, so read the delivery type and estimated volume too. A best-effort target, however confident the prose, leaves the risk with you. Read the commitment, not the pitch.