AdOps

AdOps (advertising operations, usually shortened to “ad ops”) is the work that turns advertising that was sold, or put up for auction, into ads that actually appear, are counted correctly and can be billed. An ad ops team sets up orders, creatives and targeting in an ad server, checks that everything renders and tracks, watches delivery daily, connects the auctions that let outside buyers bid, keeps fraud and unauthorised resellers out, and reconciles counts with the buyer’s before anyone invoices.

The open-source header-bidding project Prebid gives a practical definition of the role: “When we refer to ad ops, we’re talking about the people who login to the ad server software and manage the campaigns and accounts.”^[1] This page uses that operational meaning and extends it to the supply-chain controls the job now depends on.

Written for beginners, publisher and agency ad ops teams, engineers who integrate ad tech, and leaders who own advertising revenue or budgets. Sources were last verified on 2026-10-23.

Digital advertising is sold in two very different ways, and both fail without operations.

• Direct (guaranteed) sales. A salesperson promises, say, 1.5 million impressions on the sports section in November. Someone must turn that into line items with the right targeting, dates, caps and creatives, check that the advertiser’s tags fire, and steer delivery to the goal. A missed promise means a “make-good” (free replacement delivery) or a refund.
• Programmatic (automated) sales. Each impression is auctioned to many buyers in a fraction of a second. Someone must connect the auctions, set floors, map bids into the ad server, and make sure buyers get this publisher’s inventory, not a counterfeit. In 2025 programmatic advertising in the US reached $162.4 billion,^[2] by an IAB/PwC definition that also counts “publisher direct via a proprietary ad platform (i.e. self-serve)”;^[3] in this Atlas’s reading that includes social platforms, so the figure is not a measure of the open web alone.

The money at stake makes the failures visible. A study by the US Association of National Advertisers (ANA), based on log-level data from 21 advertisers, concluded that “Only 36 cents of every dollar that enters a demand-side platform (DSP) effectively reaches the consumer”.^[4] A UK study could not trace 15% of programmatic spend (Scenario 2), and fraud operations such as 3ve sold counterfeit inventory under real publishers’ names (Scenario 1).

Before and after. Without ad ops discipline, creatives break after launch, under-delivery surfaces in the last week, ads.txt lists long-gone partners, and month-end is an argument about numbers. With it, every campaign has a QA record, pacing is checked daily, partners are verifiable, and the controlling count is agreed before launch.

• Not media planning or campaign strategy. Audiences, budgets, channels and messages belong to MarketingOps; AdOps executes and verifies what was planned and sold.
• Not the tag and data infrastructure. Tag managers, server-side tracking and CDPs belong to MarTechOps; AdOps owns which pixel fires on which ad.
• Not privacy law. Whether a lawful basis exists is for PrivacyOps and counsel; AdOps makes sure the user’s recorded choice travels with the ad request and is honoured.
• Not video streaming engineering. Encoding, packaging, ad markers and content delivery for video belong to MediaOps; AdOps covers what fills each ad break and how it is counted (see video and CTV ad operations).
• Not search-engine optimisation. Organic search belongs to SEOps and SEO Operations; paid search is usually run by performance-marketing teams.
• Not “DevOps for ads”. In this Atlas’s reading the suffix comes from the job title “ad operations” (the sense in Prebid’s definition above), not from the DevOps movement, though modern ad ops borrows its habits (version control, automated checks, post-incident reviews).

In this Atlas’s summary (no primary history of the job title was found), ad operations grew out of “trafficking” campaigns into ad servers. The milestones below changed the job and can be dated from primary sources.

Is AdOps an established discipline? Yes, as a job function. IAB lists a Digital Ad Operations Certification that “Demonstrates knowledge and competency in the area of digital ad operations”.^[18] Its 2017 study guide divides the job into executing campaign launch (33% of exam weight), managing live campaigns (38%), supporting ad operations initiatives (19%) and managing incidents (11%).^[19] IAB also ran a Mobile Ad Ops Working Group.^[20] There is no single framework document like ITIL; this page maps the contract templates, specifications and guidelines instead.

Most ad ops problems are disagreements between three records (pacing, fill, make-good and discrepancy are defined in metrics and KPIs):

1. What was promised: the IO, the deal terms, the floor, the brand-safety rules.
2. What was decided: the line items, auctions and ad-server logs that chose an ad for each request.
3. What was counted: impressions, viewable impressions, clicks, invalid traffic and money, as measured by each party.

Trafficking aligns records 1 and 2; measurement standards align record 3 with reality; reconciliation aligns the parties’ versions of record 3 with each other and with record 1; supply-chain transparency (ads.txt, sellers.json, schain) checks that whoever sold in record 2 had the right to.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 14, "rankSpacing": 22, "padding": 8}}}%%
flowchart LR
  MK["MarketingOps: plans, budgets, campaign taxonomy"]
  MT["MarTechOps: tag manager, CDP, consent plumbing"]
  PV["PrivacyOps: lawful basis, consent policy"]
  RV["RevOps: revenue definitions, forecast"]
  A["AdOps: trafficking, auctions, supply-chain trust, reconciliation"]
  MD["MediaOps: video encoding, ad markers, delivery"]
  AN["AnalyticsOps: governed metrics and dashboards"]
  WB["WebOps: page speed and Core Web Vitals"]
  CT["ContentOps: content and pages to monetise"]
  MK --> A
  MT --> A
  PV --> A
  RV <--> A
  MD <--> A
  A --> AN
  A <--> WB
  CT --> A
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class A core
  class MK,MT,PV,RV,MD,AN,WB,CT neutral

The boundary with MarTechOps is the one most often blurred: MarTechOps owns the tag infrastructure; AdOps owns delivery. This is an editorial distinction of this Atlas, not an industry standard; small teams often do both jobs.

No industry body publishes an AdOps manifesto; the charter below is this Atlas’s proposal, distilled from the sources cited.

Mission. Deliver every impression that was sold or auctioned exactly as agreed, count it by an agreed method, sell it only through parties the owner has authorised, and bill it on numbers both sides can trace.

1. The contract is the specification. The IO or deal fixes targets, dates, counting method and tolerances before launch; the 4A’s/IAB template, for example, names which count controls and what happens above a 10% gap.^[31]
2. Count late, count once, count the same way. An impression counts when the ad has loaded and begun to render, not when the server decides to send it.^[8]
3. Every seller is declared and checkable in your ads.txt or app-ads.txt, and every paid hop in the SupplyChain object and its system’s sellers.json.^[26][28]
4. Consent travels with the ad request and is enforced where you control it. Passing a TCF or GPP string lets each partner apply it but blocks no request by itself.^[29][30][32]
5. Every change is reversible and attributable, so “what changed?” has an answer within minutes of a revenue drop.
6. Revenue does not outrank the reader. Ad density, page speed, malicious creatives and intrusive formats are operational risks.^[33]
7. Investigate while it is live, when evidence and options still exist.^[21]

Non-goals. Maximising today’s CPM at the cost of trust; deciding whether a legal basis exists for personalised advertising (that is PrivacyOps); choosing audiences and creative strategy (that is MarketingOps).

The RACI below is a starting template for a publisher (R = responsible, A = accountable, C = consulted, I = informed).

Ad ops runs two lifecycles side by side: per campaign (weeks) and per partner (years).

Partners follow their own cycle: evaluate (terms, data and consent handling, TAG status) → onboard (ads.txt line, adapter, staging test, sellers.json entry checked) → operate (monthly scorecard of bid rate, timeouts, IVT, revenue share) → review quarterly (keep, renegotiate, remove) → offboard (remove adapter, line items and ads.txt line; confirm no further requests). Keep the ads.txt diff and decision record at each step.

A workable cadence for a mid-sized publisher (an Atlas proposal; scale it up or down):

• Daily (15 minutes): pacing outside 95–110%, zero-delivery line items, fill or eCPM jumps, wrapper errors and timeouts.
• Weekly: yield review (floors, deals, bidders, latency); creative incidents; open discrepancies.
• Monthly: billing close; partner scorecards; ads.txt and sellers.json audit (Lab 2).
• Quarterly: supply-path review, contract renewals, maturity self-assessment.

Change control. Priorities, pricing rules, wrapper timeouts and ads.txt can each move site-wide revenue; give each change an approver, a ticket and a rollback step. Google warns that “Incorrectly configured pricing rules can sometimes lead to ad delivery issues, such as low fill rates”.^[34]

Escalation. Tie severity to money and users: Sev 1 for site-wide loss of serving, malicious creatives or consent failure; Sev 2 for a guaranteed campaign that cannot meet its goal or a large revenue drop; Sev 3 for single-line-item faults. Incident mechanics in general are in IncidentOps.

The common open-web pattern for a publisher selling direct and programmatic. App and connected-TV (CTV) stacks swap the page for an SDK or video player but keep the layers.

%%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 16, "rankSpacing": 24, "padding": 8}}}%%
flowchart TB
  CMP["Page: consent platform (TCF or GPP string)"]
  HB["Page: header-bidding wrapper (Prebid.js)"]
  SSP["SSPs and exchanges"]
  DSP["DSPs bidding for buyers"]
  TXT["Public files: ads.txt, sellers.json"]
  TAG["Page: ad-server tag (e.g. GPT)"]
  AS["Publisher ad server: priorities, floors, auction"]
  VER["Verification: viewability, IVT, brand safety"]
  CMP --> HB
  CMP --> TAG
  HB --> SSP
  SSP --> DSP
  DSP -. "checks before bidding" .-> TXT
  HB -- "bids as key-values" --> TAG
  TAG --> AS
  AS -- "winning creative" --> TAG
  TAG --> VER
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class AS,HB core
  class CMP,TAG,SSP,DSP neutral
  class VER,TXT decision

sequenceDiagram
  participant AS as Ad server
  participant P as Page (CMP, Prebid, GPT)
  participant S as SSP or exchange
  participant D as DSP
  P->>P: read consent string
  P->>S: bid request (consent, floor, schain)
  S->>D: OpenRTB request, tmax
  D-->>S: bid price and creative
  S-->>P: bid (rounded later to a price bucket)
  P->>AS: ad request with hb_pb key-values
  AS->>AS: priorities, floors, unified auction
  AS-->>P: winning creative
  P->>P: render, count impression, fire trackers

Three details explain most surprises:

• The ad server still decides. Prebid’s documentation is explicit: “Yes, you still need an ad server,” and “The ad server will still determine the final winner for each ad unit.”^[1] Header bids enter as non-guaranteed line items matching key-values, a use Google’s line-item documentation names.^[22]
• Priorities come before price for guaranteed demand. In Google Ad Manager (as of October 2026), Sponsorship line items have priority 4 and Standard 6, 8 or 10; Network, Bulk, Price priority and Ad Exchange items have 12; House 16; “The lower the number, the higher the priority.”^[22] When dynamic allocation is on, non-guaranteed demand can still compete with guaranteed line items in real time.^[22]
• Win is not bill. In OpenRTB the win notice is “not necessarily indicative of a delivered, viewed, or billable ad”; a separate billing notice fires when the impression becomes billable.^[5] A DSP’s “wins” never match a publisher’s “impressions” exactly.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 14, "rankSpacing": 20, "padding": 8}}}%%
flowchart TB
  IO["IO or deal received"] --> FE{"Spec complete and avails OK?"}
  FE -- "no" --> BACK["Return to sales with gaps"]
  FE -- "yes" --> TR["Traffic line items and creatives"]
  TR --> QA{"QA passes on test page?"}
  QA -- "no" --> FIX["Fix tags, macros, targeting"]
  FIX --> QA
  QA -- "yes" --> GO["Launch; verify first hour"]
  GO --> MON{"Pacing 95-110% and tracking OK?"}
  MON -- "no" --> ACT["Diagnose: targeting, priority, creative, discrepancy"]
  ACT --> MON
  MON -- "yes, flight ends" --> REC{"Gap with buyer within tolerance?"}
  REC -- "no" --> DISP["Reconcile; make-good or adjusted invoice"]
  REC -- "yes" --> INV["Invoice on controlling count"]
  DISP --> INV
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class IO,TR,GO,INV core
  class FE,QA,MON,REC decision
  class BACK,FIX,ACT,DISP risk

Happy path, with owners. Sales submits the IO through the intake form; the trafficker checks it within one business day, builds, QAs and launches; the daily stand-up watches pacing; finance invoices on the controlling count.

Exception paths that deserve a written procedure.

1. Incomplete IO (missing sizes, dates, counting terms): do not traffic “to be safe”; return it with the gaps listed.
2. Creative fails QA (non-secure calls, broken macros, wrong size, heavy file): reject with the evidence; never edit a buyer’s tag without written consent.
3. Under-delivery forecast (the run rate needed exceeds what the targeting can supply): tell the client early with options (broaden targeting, extend dates, raise priority, make-good).
4. Discrepancy above tolerance: follow the worked runbook.
5. Suspected IVT or malvertising: pause the line item or creative first, then investigate (see quality, security, privacy and compliance).

Same three records, different plumbing: MediaOps packages the programme and carries the ad markers; AdOps decides what fills each break and how it is counted.

• VAST and VMAP. VAST is IAB Tech Lab’s “universal XML schema for serving ads to digital video players”;^[35] VMAP lets a content owner that does not control the player define the ad breaks (timing, number, ad types); “What VMAP cannot do is define the ads themselves”.^[36]
• Client-side insertion (CSAI). At a cue the player requests VAST, follows Wrapper responses to an InLine response, plays the ad and fires the trackers itself.^[37]
• Server-side insertion (SSAI, “ad stitching”). A stitching service requests VAST, transcodes new creatives from their mezzanine files and stitches ads into one continuous stream. A creative it has not yet transcoded is skipped (VAST error 407), and it recognises creatives by <UniversalAdId>, so a changed creative needs a new ID. Tracking sent by the server comes from one IP address and can “look similar to invalid traffic”, so stitchers must forward X-Device-IP and X-Device-User-Agent; impression reporting “may vary by implementation”, while the MRC guidelines quoted in VAST favour client-initiated counting.^[37] OpenRTB 2.6 tells buyers which mode applies with imp.ssai (0 unknown, 1 all client-side, 2 assets stitched but trackers client-side, 3 all server-side).^[5]
• Ad pods. OpenRTB 2.6 sells a break as a pod: structured (fixed slots and durations), dynamic (total duration and maximum number of ads known) or hybrid. Key fields: podid, podseq, slotinpod, poddur, maxseq, rqddurs (exact durations, to avoid “dead air” in live TV) and mincpmpersec, a floor per second for the dynamic part. The seller builds the final pod and may use none, some or all of a buyer’s bids.^[5][38]
• Measurement and trust. The Open Measurement SDK gives verification vendors one integration in apps and CTV;^[39] MRC asks SIVT vendors to check spoofed CTV bundle IDs;^[25] app-ads.txt also covers “connected television app stores”,^[40] and the INVENTORYPARTNERDOMAIN variable is “expected to be used primarily for CTV/OTT inventory, where ‘inventory sharing’ is common”.^[41]

Operational checks (an Atlas list): deliver creatives early enough to be transcoded; agree with the verification vendor the ssai mode and headers; set pod floors per second; write into the IO whether impressions count at the stitcher or player.

This part is the centre of the page. Programmatic buying lets software buy from sellers the buyer has never met, through intermediaries the publisher may not know. Deal terms, the public seller files, the SupplyChain object and the consent string make that chain checkable; invalid-traffic filtering catches what they miss.

In OpenRTB, a deal’s at = 3 means its bidfloor “is the agreed upon deal price”, which fits both fixed-price rows.^[5] Definitions follow the IAB/PwC revenue report (preferred deals: “pricing is guaranteed but inventory volume is not”).^[3] The further down the table, the more a buyer depends on the supply-chain files below.

ads.txt (“Authorized Digital Sellers”) is a plain-text file at /ads.txt on a publisher’s root domain in which the publisher lists every advertising system and account that may sell its inventory.^[26] Its mission, in IAB Tech Lab’s words, is to “Increase transparency in the programmatic advertising ecosystem”.^[11] app-ads.txt applies the same idea to apps, “linking app store listings to app developer websites”: the buyer finds the file through the developer URL in the app store listing.^[40]

Each record has three required fields and one optional field:^[26]

# <system domain>, <account ID>, <DIRECT|RESELLER>, <optional cert ID>
ssp-one.example, 1001, DIRECT, abc123
ssp-one.example, 2002, RESELLER
OWNERDOMAIN=news.example
MANAGERDOMAIN=yieldpartner.example
CONTACT=adops@news.example

• DIRECT means the publisher “directly controls the account” on that system; RESELLER means the publisher “has authorized another entity to control the account” and resell its space.^[26]
• The account ID “must contain the same value used in transactions”, typically publisher.id in OpenRTB.^[26]
• OWNERDOMAIN (recommended since version 1.1, finalised July 2022 and listed by IAB Tech Lab as August 2022) names the business that owns the site and should equal the domain that publisher has in sellers.json files. MANAGERDOMAIN (optional) names an exclusive or primary monetisation partner such as a sales house, at most one per country; for impressions the manager sells, the specification expects its domain on the first node of a complete SupplyChain object.^[26][11]
• The file must be served as text/plain. Redirects are followed only within the root domain plus one hop to a third party; consumers should cache for 7 days if no cache headers are set.^[26]
• On a 404, “the advertising system can assume no declarations exist and that no advertising system is unauthorized”, so a missing file authorises everyone; after any other error, crawlers keep the last file they retrieved successfully.^[26]
• A site that authorises nobody publishes a placeholder record rather than an empty file, so crawlers can tell it apart from an error page.^[26]

Why it matters, in one number. Google and White Ops reported that 80.3% of the bid requests the 3ve fraud operation generated in early 2018 came from sellers not listed in the spoofed domain’s ads.txt; with universal enforcement, they wrote, over 80% of 3ve’s inventory “would be completely blocked” (see Scenario 1).^[42]

What ads.txt cannot do. It does not name the account holder (sellers.json does), it does not list every intermediary (the SupplyChain object does), and it cannot stop bot traffic sold through a real, authorised account.

sellers.json is published by an SSP or exchange at /sellers.json on its own domain. For every seller_id it says who is paid and in what capacity:^[27]

• seller_type PUBLISHER: the named entity owns the site or app and is paid directly; INTERMEDIARY: it does not own the inventory or is not paid directly; BOTH: both kinds flow through the account.
• seller_id is “the same ID that appears in an ads.txt file and in the SupplyChain.nodes array sid property”; each ID must map to a single paid entity; is_confidential may hide the name.

The SupplyChain object (often “schain”) travels inside each bid request and lists the entities “involved in the direct flow of payment” for that impression.^[28] The rules are simple:

• The originating seller creates it with complete = 1 and itself as the only node.
• A reseller copies the object, keeps complete as it was, and appends its own node; a reseller that receives no object creates one with complete = 0.
• In a complete chain, the first node is the owner’s system and seller ID, and the last node is the entity sending this request.
• It sits in source.schain in OpenRTB 2.6 and later, source.ext.schain in 2.5.^[28]

Both were finalised on 31 July 2019; IAB Tech Lab tells buyers to keep buying through ads.txt-authorised paths.^[12]

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 14, "rankSpacing": 20, "padding": 8}}}%%
flowchart TB
  BR["Bid request: domain or app, publisher.id, schain"] --> A1{"Seller account listed in the domain's ads.txt?"}
  A1 -- "no" --> X1["Unauthorised: do not bid"]
  A1 -- "yes" --> A2{"schain complete = 1?"}
  A2 -- "no" --> X2["Incomplete chain: lower trust or skip"]
  A2 -- "yes" --> A3{"Every node found in that system's sellers.json?"}
  A3 -- "no" --> X3["Unknown intermediary: skip or investigate"]
  A3 -- "yes" --> A4{"First node = OWNER- or MANAGERDOMAIN?"}
  A4 -- "no" --> X4["Resold or mislabelled: lower priority or review"]
  A4 -- "yes" --> OK["Verifiable path: bid on its merits"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class BR,OK core
  class A1,A2,A3,A4 decision
  class X1,X2,X3,X4 risk

The fourth check combines two rules in ads.txt v1.1. In complete chains the first node “should have sellers.domain that matches the OWNERDOMAIN”; but for “ad opportunities monetized by the manager”, the specification expects the MANAGERDOMAIN to be that of the node representing the originating publisher.^[26] The 1.1 implementation guide turns this into a rule of thumb for the seller’s sellers.json domain: equal to OWNERDOMAIN, the seller is the owner; equal to MANAGERDOMAIN (for that country), the manager; anything else, a reseller. It also leaves the exact interpretation of MANAGERDOMAIN to each buyer.^[41] Buyers apply these checks with different strictness, so publishers should make all four pass for the paths they rely on.

• IAB Europe’s Transparency and Consent Framework (TCF) is “an accountability tool that relies on standardisation to facilitate compliance with certain provisions of the ePrivacy Directive and the GDPR”. Version 2.3 (April 2025) made the “Disclosed Vendors” section mandatory; “TCF participants have until 28 February 2026 to adopt TCF v2.3”.^[29]
• Global Privacy Protocol (GPP), from IAB Tech Lab, carries IAB Europe TCF, IAB Canada TCF, US national and US state strings in one container; an MSPA-alignment update was in public comment until 11 September 2026, so check its final status.^[30] OpenRTB 2.6 carries them in regs.gdpr and regs.gpp.^[5]
• Google’s requirement. AdSense, Ad Manager and AdMob publishers need a Google-certified CMP integrated with the TCF to serve personalised ads in the EEA and UK (from 16 January 2024) and Switzerland (from 31 July 2024); other traffic may get only non-personalised or limited ads. Google “does not check CMPs for full compliance with the TCF or applicable privacy laws”.^[13]
• Header bidding. Prebid splits the job. Its TCF consent management module reads the consent data and passes it to adapters (and is not legal advice).^[43] Enforcement needs the separate, optional TCF control module (tcfControl, in the build), which “Actively restricts” user syncs, ID modules, bidders and other activities according to consent, requiring a legal basis for Purposes 1 and 2 by default.^[32] The consent module’s page names TCF v2.0 and v2.2; check that your CMP and Prebid version handle the v2.3 strings users now send.
• Children. Google does not send requests marked child-directed under the US COPPA law to Open Bidding partners;^[23] check each partner’s handling of the flag.

The legal analysis (lawful basis, notices, retention) belongs to PrivacyOps; the CMP and tag-firing architecture to MarTechOps.

The Media Rating Council (MRC) separates invalid traffic (IVT) into two categories:^[25]

• General invalid traffic (GIVT): “traffic identified through routine means of filtration executed through application of lists or with other standardized parameter checks”, such as known invalid data-centre traffic and declared bots and spiders.
• Sophisticated invalid traffic (SIVT): “more difficult to detect situations that require advanced analytics, multi-point corroboration/coordination, significant human intervention”, including domain and app misrepresentation and domain laundering; an April 2024 MRC memo adds checks of declared against actual property IDs, including CTV bundle IDs.^[25]

Controls by layer:

• Impression. The IAB/MRC display guideline requires counting “as late as possible”: “The ad must be loaded and at minimum begin to render”; “count on decision” at the server is not acceptable, and the ad need not be visible.^[8] Google Ad Manager states that it “counts an impression each time a creative is downloaded and has begun to load”.^[45]
• Viewable display impression. At least 50% of the ad’s pixels on an in-focus browser tab in the viewable space, for at least one continuous second after render; for ads of 242,500 pixels or more (970×250 and larger), 30% of pixels.^[6]
• Viewable video impression. 50% of pixels and 2 continuous seconds of play.^[6]
• Reporting. Disclose viewable, non-viewable and undetermined, and compute measured and viewable rates separately (metrics); MRC warns against calling the viewable share of all impressions the “viewable rate”.^[6] The 2015 guideline is for desktop; MRC’s mobile guidance followed in June 2016.^[7]

1. Compare line items to the IO line by line: dates and time zone, goal and type, rate, targeting, frequency cap, sizes, competitive separation.
2. Preview each creative: right size, secure (HTTPS) calls, correct click-through URL.
3. Confirm every tracker fires once (impression, click, viewability, verification); a click tracker without an impression tracker causes “clicks but no impressions”.^[45]
4. Use the ad server’s matching creative type for third-party ad-server tags (in Google Ad Manager, the Campaign Manager 360 tag type: under 2% discrepancy expected instead of up to 20%).^[21]
5. Record the evidence, launch, and re-check delivery and trackers within the first hour.

Lab 1 computes pacing and the run rate needed. For Standard line items “Delivery pacing is adjusted to meet the defined goal”, Google notes,^[22] but no ad server creates inventory the targeting excludes. When a line item is behind:

1. Check eligibility (status, dates, approved creatives, targeting that matches real inventory) with the Troubleshoot tab and Delivery Inspector.^[46][45]
2. Check competition: higher-priority line items or sponsorships on the same inventory; over-tight frequency caps.
3. Check the creative: a third-party creative that fails to load may count on one side only.
4. Decide with the account manager: widen targeting, extend the flight, raise priority within policy, or plan a make-good.

• Line items. Each price bucket needs a matching line item. Prebid rounds bids down into buckets passed in hb_pb; rounding affects only the ad-server auction, not the price paid. “Dense” needs 425 line items per bidder, “high” 2,001. For custom buckets, set the cap near your 95th-percentile bid, with finer increments where bids cluster.^[47]
• Send all bids or top bid. Sending all bids is Prebid’s default and helps reporting on every bidder; sending only the top bid needs far fewer line items.^[48]
• Timeouts. Prebid calls the auction timeout “a delicate balance”: too short loses bids, too long loses users before the ad call. It suggests a server-side timeout of about 50–75% of the auction timeout and measuring how long consent and identity modules take before bids are sent.^[49] Consent waits count: with actionTimeout set, Prebid waits up to that long for a new user’s choice before the auction starts.^[43]
• Supply chain. If a managed-service provider runs your wrapper and handles payments, it must add its own schain node; since Prebid 10 the schain is treated as first-party data in ortb2.source.ext.schain.^[50]

In Google Ad Manager (as of October 2026), pricing rules centralise floors for non-guaranteed demand, the higher of two overlapping floors applies, floors apply to the publisher’s net after Google’s share, and publishers “can set floors for available demand sources or specific programmatic bidders”.^[34] Change one rule at a time on a slice of inventory and compare revenue per thousand requests, not eCPM alone (see the worked calculation). Expect floor behaviour to change when the US remedies take effect (see advanced topics).

None of these is law; laws apply on their own terms, and frameworks help show compliance without guaranteeing it.^[13]

Automation that pays for itself. Bulk header-bidding line items (Lab 4); scheduled ads.txt and sellers.json checks (Lab 2); daily pacing and discrepancy exceptions (Labs 1 and 3); alerts on jumps in fill, eCPM, timeouts or IVT; wrapper configuration released like code (ReleaseOps).

Guard-rails. Automation that writes to the ad server can change site-wide revenue in one run: require a dry run, a cap on objects changed, an approver for priority and pricing changes, and a tested rollback.

Where language models help, with limits. Drafting a trafficking ticket from an emailed IO (a human checks every field); summarising delivery anomalies; sorting creatives for review. Not approving creatives, changing floors or settling discrepancies without a human. Standards for AI agents that trade inventory are emerging (advanced topics).

For ad ops the reference implementation is a set of operating artefacts plus a little configuration, assuming Google Ad Manager and Prebid.js; the ideas carry to other ad servers.

1. A naming convention that makes reports and bulk changes safe:

Order:      <Advertiser>_<Agency>_<IO number>_<YYYYMM>
Line item:  <IO line>_<Type>_<Format>_<Size>_<Targeting>_<Start YYYYMMDD>
            0420-03_STD_DISPLAY_300x250_SPORTS-UK_20261101
Header bid: HB_<bidder|ALL>_<bucket>      e.g. HB_ALL_02.35
Creative:   <Advertiser>_<Concept>_<Size>_<v#>

2. A trafficking intake form that refuses incomplete orders. Keep it as structured data so a script can check it.

Example status: syntax-checked (YAML), not executed against an ad server.

io_number: "IO-2026-0420"
advertiser: "Example Outdoor Ltd"
agency: "Example Media Agency"
flight: {start: "2026-11-01", end: "2026-11-30", time_zone: "Europe/London"}
lines:
  - line: "0420-03"
    type: standard            # sponsorship | standard | price_priority | pg_deal
    goal_impressions: 1500000
    rate_cpm: 18.00
    sizes: ["300x250", "320x50"]
    targeting: {section: "sports", geo: ["GB"]}
    frequency_cap: {impressions: 3, per: "day"}
measurement:
  controlling_count: "third_party"   # per the IO terms
  third_party_ad_server: "Campaign Manager 360"
  discrepancy_tolerance_pct: 10
  viewability_vendor: "MRC-accredited vendor named in IO"
creative_due: "2026-10-27"
contacts: {sales: "sales@publisher.example", agency: "trafficking@agency.example"}

3. A wrapper configuration reviewed like code. Values are placeholders; the keys follow Prebid’s documented setConfig options (bidderTimeout, priceGranularity, consentManagement, first-party ortb2 data carrying the schain), which are unchanged in the Prebid.js 10 and 11 documentation (11 is the current major release as of October 2026; 10 is maintained as “legacy”).^{[52][43][50][53]} The configuration passes consent; Prebid enforces it only if the build includes tcfControl (for example gulp build --modules=consentManagementTcf,tcfControl,<bidders>).^[32] Prebid 11 also adds a pre-auction wait for viewability measurement (auctionOptions.viewabilityMeasurement); include it in latency tests.^[52]

Example status: syntax-checked with node --check, not executed in a browser (requires a page with Prebid.js and an ad server).

// Prebid.js 10/11 configuration sketch for a wrapper run by a managed-service provider.
// Signal passing only: enforcement needs the tcfControl module in the build.
const pbjs = (globalThis.pbjs = globalThis.pbjs || { que: [] });
pbjs.que.push(() => {
  pbjs.setConfig({
    bidderTimeout: 1000, // measure first; see the timeouts playbook
    priceGranularity: 'dense', // 425 line items per bidder in the ad server
    consentManagement: {
      // timeout: wait for the CMP's first answer. No actionTimeout here: with one
      // (Prebid's example: 10000), the auction waits that long for a new user's choice.
      gdpr: { cmpApi: 'iab', timeout: 500, defaultGdprScope: true },
    },
    ortb2: {
      source: {
        ext: {
          schain: {
            ver: '1.0',
            complete: 1,
            nodes: [{ asi: 'wrapper-provider.example', sid: 'PUB-123', hp: 1 }],
          },
        },
      },
    },
  });
});

4. A one-page QA checklist and a discrepancy log (see Checklists and Templates).

5. A supply-partner register: partner, ads.txt lines, sellers.json seller ID and type, contract owner, TAG status, last review, decision; the source for ads.txt and the quarterly review.

Four labs on synthetic data: Python 3.8 or later and a bash shell, standard library only, no accounts, no cost, no network access. Domains end in .example, which is reserved for documentation. Each lab was executed on 2026-10-23 exactly as printed (Python 3.8.10, Ubuntu Linux); the expected outputs are copied from those runs.

Objective. Calculate pacing, run rates, eCPM, CTR and the two MRC viewability rates for one guaranteed line item. Prerequisites. Python 3.8+. Time. 15 minutes. Risk. None.

1. Create a folder: mkdir -p ~/adops-labs/lab1 && cd ~/adops-labs/lab1
2. Save the script as pacing.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Media math and pacing for one guaranteed line item (standard library only)."""
from datetime import date

GOAL = 1_500_000            # impressions sold on the insertion order
START, END = date(2026, 11, 1), date(2026, 11, 30)
TODAY = date(2026, 11, 13)  # report run in the morning: 12 full days delivered
DELIVERED = 520_000         # impressions counted by the ad server so far
CLICKS = 1_040
REVENUE = 9_360.00          # booked value of the delivered impressions (USD)
VIEWABLE, NON_VIEWABLE, UNDETERMINED = 286_000, 156_000, 78_000

flight_days = (END - START).days + 1
days_done = (TODAY - START).days
expected = GOAL * days_done / flight_days
pacing = DELIVERED / expected
remaining_days = flight_days - days_done
run_rate_needed = (GOAL - DELIVERED) / remaining_days
run_rate_so_far = DELIVERED / days_done

measured = VIEWABLE + NON_VIEWABLE
print(f"Flight {flight_days} days, {days_done} done, {remaining_days} left")
print(f"Expected to date      = {expected:,.0f} impressions")
print(f"Pacing                = {pacing:.1%}  (100% = on schedule)")
print(f"Daily run rate so far = {run_rate_so_far:,.0f}")
print(f"Daily run rate needed = {run_rate_needed:,.0f}")
print(f"eCPM                  = ${REVENUE / DELIVERED * 1000:.2f}")
print(f"CTR                   = {CLICKS / DELIVERED:.2%}")
print(f"Measured rate         = {measured / DELIVERED:.1%}")
print(f"Viewable rate         = {VIEWABLE / measured:.1%}")
print(f"Viewable share of all = {VIEWABLE / DELIVERED:.1%}  (not the viewable rate)")

3. Run python3 pacing.py.

Expected output.

Flight 30 days, 12 done, 18 left
Expected to date      = 600,000 impressions
Pacing                = 86.7%  (100% = on schedule)
Daily run rate so far = 43,333
Daily run rate needed = 54,444
eCPM                  = $18.00
CTR                   = 0.20%
Measured rate         = 85.0%
Viewable rate         = 64.7%
Viewable share of all = 55.0%  (not the viewable rate)

Validation. By hand: 1,500,000 × 12 ÷ 30 = 600,000 expected; 520,000 ÷ 600,000 = 86.7%; (1,500,000 − 520,000) ÷ 18 = 54,444 per day, 26% above the current 43,333. Measured and viewable rates follow MRC’s formulas; reporting 55.0% as “the viewable rate” is the error MRC warns against.^[6] A 26% run-rate increase rarely happens by itself: start the pacing playbook. Troubleshooting. Wrong pacing when run in the evening: decide whether TODAY counts as a delivered day and keep the convention. Teardown. rm -rf ~/adops-labs/lab1

Objective. Find syntax errors in an ads.txt file and relationship mismatches against SSPs’ sellers.json entries. Prerequisites. Python 3.8+, Lab 1 folder conventions. Time. 30 minutes. Risk. None; in real use, fetch only public files and respect each site’s crawl policies.

1. Create the folder and the two input files (an ads.txt and a combined extract of three SSPs’ sellers.json files).

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/adops-labs/lab2 && cd ~/adops-labs/lab2
cat > ads.txt <<'EOF'
# ads.txt for news.example (synthetic lab data)
ssp-one.example, 1001, DIRECT, abc123
ssp-one.example, 2002, RESELLER
ssp-two.example, pub-77, DIRECT
ssp-two.example, pub-77, DIRECT
ssp-three.example, 9, PARTNER
reseller-x.example 55 RESELLER
ssp-four.example, 404, RESELLER
OWNERDOMAIN=news.example
CONTACT=adops@news.example
EOF
cat > sellers.json <<'EOF'
{
  "ssp-one.example": {"sellers": [
    {"seller_id": "1001", "seller_type": "PUBLISHER", "name": "News Example Ltd",
     "domain": "news.example"},
    {"seller_id": "2002", "seller_type": "INTERMEDIARY", "name": "Yield Partner Inc",
     "domain": "yieldpartner.example"}]},
  "ssp-two.example": {"sellers": [
    {"seller_id": "pub-77", "seller_type": "INTERMEDIARY", "name": "Yield Partner Inc",
     "domain": "yieldpartner.example"}]},
  "ssp-four.example": {"sellers": []}
}
EOF

2. Save the checker as check_adstxt.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Lint an ads.txt file and cross-check it against sellers.json extracts (stdlib only)."""
import json
import re

VALID_REL = {"DIRECT", "RESELLER"}
VAR = re.compile(r"^\s*([A-Za-z]+)\s*=\s*(.+?)\s*$")

def parse(path):
    records, variables, problems, seen = [], {}, [], set()
    with open(path, encoding="utf-8") as f:
        for n, raw in enumerate(f, 1):
            line = raw.split("#", 1)[0].strip()
            if not line:
                continue
            m = VAR.match(line)
            if m and "," not in line:
                variables.setdefault(m.group(1).upper(), []).append(m.group(2))
                continue
            fields = [x.strip() for x in line.split(",")]
            if len(fields) < 3:
                problems.append(f"line {n}: expected 3-4 comma-separated fields")
                continue
            domain, account, rel = fields[0].lower(), fields[1], fields[2].upper()
            if rel not in VALID_REL:
                problems.append(f"line {n}: relationship {fields[2]!r} is not "
                                "DIRECT or RESELLER")
                continue
            key = (domain, account, rel)
            if key in seen:
                problems.append(f"line {n}: duplicate record {domain}, {account}, {rel}")
                continue
            seen.add(key)
            records.append((n, domain, account, rel))
    return records, variables, problems

def cross_check(records, owner, sellers_by_system):
    findings = []
    for n, domain, account, rel in records:
        system = sellers_by_system.get(domain)
        if system is None:
            findings.append(f"line {n}: no sellers.json collected for {domain}")
            continue
        seller = next((s for s in system["sellers"] if s["seller_id"] == account), None)
        if seller is None:
            findings.append(f"line {n}: seller_id {account} not in {domain}/sellers.json")
            continue
        stype = seller["seller_type"].upper()
        if rel == "DIRECT" and (stype == "INTERMEDIARY" or seller.get("domain") != owner):
            findings.append(f"line {n}: DIRECT but sellers.json has {stype} "
                            f"{seller.get('domain')}")
        if rel == "RESELLER" and stype == "PUBLISHER":
            findings.append(f"line {n}: RESELLER but sellers.json says PUBLISHER")
    return findings

records, variables, problems = parse("ads.txt")
owner = (variables.get("OWNERDOMAIN") or ["(missing)"])[0].lower()
with open("sellers.json", encoding="utf-8") as f:
    sellers = json.load(f)
print(f"{len(records)} valid records; OWNERDOMAIN={owner}")
for p in problems:
    print("SYNTAX ", p)
for c in cross_check(records, owner, sellers):
    print("CHECK  ", c)

3. Run python3 check_adstxt.py.

Expected output.

4 valid records; OWNERDOMAIN=news.example
SYNTAX  line 5: duplicate record ssp-two.example, pub-77, DIRECT
SYNTAX  line 6: relationship 'PARTNER' is not DIRECT or RESELLER
SYNTAX  line 7: expected 3-4 comma-separated fields
CHECK   line 4: DIRECT but sellers.json has INTERMEDIARY yieldpartner.example
CHECK   line 8: seller_id 404 not in ssp-four.example/sellers.json

Validation. Line 4 matters most: the publisher claims direct control, but the SSP says a yield partner is paid, so the line is probably RESELLER (or the SSP’s record is wrong; ask). Line 8 names an account the SSP does not list. Only DIRECT and RESELLER are defined today (“Other types may be added in the future”), so line 6 is invalid.^[26] The specification does not address duplicate records; they signal unmanaged edits. Extension. In real use, fetch each SSP’s live /sellers.json, cache it and alert on changes. Troubleshooting. JSONDecodeError: re-create the file; a quotation mark was lost. Teardown. rm -rf ~/adops-labs/lab2

Objective. Compare a publisher’s counts with the agency’s third-party counts day by day and apply a 10% tolerance clause in the style of the 4A’s/IAB Standard Terms and Conditions v3.0.^[31] Prerequisites. Python 3.8+. Time. 20 minutes. Risk. None; the script illustrates a clause, and your IO decides.

1. Create the folder and the data.

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/adops-labs/lab3 && cd ~/adops-labs/lab3
cat > delivery.csv <<'EOF'
date,publisher_imps,thirdparty_imps
2026-11-01,51000,47900
2026-11-02,50500,47300
2026-11-03,52000,44100
2026-11-04,49800,41200
2026-11-05,50700,42000
2026-11-06,51200,47600
2026-11-07,50300,46900
EOF

2. Save the script as reconcile.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Discrepancy check in the style of the 4A's/IAB Standard Terms v3.0 (illustrative)."""
import csv

CPM = 12.00          # agreed rate, USD
THRESHOLD = 0.10     # 10% over the invoice period, per the T&Cs pattern
CONTROLLING = "thirdparty_imps"   # assumed: agency's ad server is the controlling count
OTHER = "publisher_imps"

with open("delivery.csv", newline="") as f:
    rows = list(csv.DictReader(f))

for r in rows:
    ctrl, other = int(r[CONTROLLING]), int(r[OTHER])
    gap = (other - ctrl) / other
    flag = "  <-- investigate" if gap > THRESHOLD else ""
    print(f"{r['date']}  pub={other:>6}  3p={ctrl:>6}  gap={gap:6.1%}{flag}")

ctrl_total = sum(int(r[CONTROLLING]) for r in rows)
other_total = sum(int(r[OTHER]) for r in rows)
period_gap = (other_total - ctrl_total) / other_total
print(f"Period: publisher={other_total:,} third-party={ctrl_total:,} "
      f"gap={period_gap:.1%}")
if period_gap > THRESHOLD:
    adjusted = round(ctrl_total * (1 + THRESHOLD))
    print(f"Over {THRESHOLD:.0%}: reconcile first. If unresolved, the agency may")
    print("treat it as under-delivery (make-good) or pay the controlling")
    print("count plus a 10% upward adjustment:")
    print(f"  invoice on {adjusted:,} imps = ${adjusted / 1000 * CPM:,.2f}")
else:
    print(f"Within {THRESHOLD:.0%}: invoice on controlling count "
          f"{ctrl_total:,} imps = ${ctrl_total / 1000 * CPM:,.2f}")

3. Run python3 reconcile.py.

Expected output.

2026-11-01  pub= 51000  3p= 47900  gap=  6.1%
2026-11-02  pub= 50500  3p= 47300  gap=  6.3%
2026-11-03  pub= 52000  3p= 44100  gap= 15.2%  <-- investigate
2026-11-04  pub= 49800  3p= 41200  gap= 17.3%  <-- investigate
2026-11-05  pub= 50700  3p= 42000  gap= 17.2%  <-- investigate
2026-11-06  pub= 51200  3p= 47600  gap=  7.0%
2026-11-07  pub= 50300  3p= 46900  gap=  6.8%
Period: publisher=355,500 third-party=317,000 gap=10.8%
Over 10%: reconcile first. If unresolved, the agency may
treat it as under-delivery (make-good) or pay the controlling
count plus a 10% upward adjustment:
  invoice on 348,700 imps = $4,184.40

Validation. Three consecutive days jump from about 6–7% to 15–17%: something ran only on 3–5 November (a creative, a placement, a tag edit). A detail the template leaves open: the clause compares “the Controlling Measurement and the other measurement” without naming the denominator; the script divides by the publisher’s count (10.8%), while dividing by the controlling count gives 38,500 ÷ 317,000 = 12.1%. Write the formula into your IO. The baseline is a finding too: a steady 6–7% is far above Google’s expectation for the Campaign Manager 360 tag type (QA playbook step 4), so it gets its own ticket (runbook step 8). Troubleshooting. KeyError: keep the CSV column names. Teardown. rm -rf ~/adops-labs/lab3

Objective. Reproduce Prebid’s rounding of bids into price buckets, count the line items a granularity needs, and check SupplyChain objects for structural errors. Prerequisites. Python 3.8+; Labs 2 and 3. Time. 30 minutes. Risk. None.

1. Create the folder: mkdir -p ~/adops-labs/lab4 && cd ~/adops-labs/lab4
2. Save the script as buckets.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Header-bidding price buckets and a SupplyChain (schain) check (stdlib only)."""
from decimal import Decimal, ROUND_FLOOR

# Prebid's documented "dense" preset: (increment, cap) ranges in CPM.
DENSE = [(Decimal("0.01"), Decimal("3.00")), (Decimal("0.05"), Decimal("8.00")),
         (Decimal("0.50"), Decimal("20.00"))]

def bucket(cpm, ranges=DENSE):
    cpm = Decimal(str(cpm))
    top = ranges[-1][1]
    if cpm >= top:
        return top                      # bids above the cap fall to the cap bucket
    for inc, cap in ranges:
        if cpm < cap:
            return (cpm / inc).to_integral_value(rounding=ROUND_FLOOR) * inc
    return top

def line_items(ranges=DENSE):
    total, floor = 0, Decimal("0")
    for inc, cap in ranges:
        total += int((cap - floor) / inc) + (1 if floor == 0 else 0)
        floor = cap
    return total

for bid in [0.237, 2.999, 3.07, 7.99, 12.74, 31.0]:
    print(f"bid {bid:>6} -> hb_pb {bucket(bid)}")
print("line items per bidder (dense):", line_items())

def check_schain(sc, final_seller):
    errs = []
    if sc.get("ver") != "1.0":
        errs.append("ver should be '1.0'")
    nodes = sc.get("nodes") or []
    if not nodes:
        errs.append("nodes is empty")
    for i, n in enumerate(nodes):
        for k in ("asi", "sid", "hp"):
            if k not in n:
                errs.append(f"node {i}: missing {k}")
        if n.get("hp") not in (None, 1):
            errs.append(f"node {i}: hp should always be 1 in v1.0")
    if nodes and (nodes[-1].get("asi"), nodes[-1].get("sid")) != final_seller:
        errs.append("last node is not the system sending this bid request")
    if sc.get("complete") == 1 and len(nodes) > 1:
        errs.append("review: reseller in a complete chain; "
                    "node 0 = owner or manager?")
    return errs or ["ok"]

schain = {"ver": "1.0", "complete": 1, "nodes": [
    {"asi": "ssp-one.example", "sid": "1001", "hp": 1},
    {"asi": "reseller-x.example", "sid": "aaa", "hp": 1}]}
print("good chain:", check_schain(schain, ("reseller-x.example", "aaa")))
schain_bad = {"ver": "1.0", "complete": 0,
              "nodes": [{"asi": "ssp-two.example", "sid": "9"}]}
print("bad chain:", check_schain(schain_bad, ("ssp-two.example", "9")))

3. Run python3 buckets.py.

Expected output.

bid  0.237 -> hb_pb 0.23
bid  2.999 -> hb_pb 2.99
bid   3.07 -> hb_pb 3.05
bid   7.99 -> hb_pb 7.95
bid  12.74 -> hb_pb 12.50
bid   31.0 -> hb_pb 20.00
line items per bidder (dense): 425
good chain: ['review: reseller in a complete chain; node 0 = owner or manager?']
bad chain: ['node 0: missing hp']

Validation. The count of 425 matches Prebid’s published table for “dense” (301 + 100 + 24).^[47] A $12.74 bid enters the ad-server auction as $12.50 and can lose to a $12.51 line item, yet is paid at $12.74 if it wins: Prebid notes that rounding “does not impact the price paid, only the auction on the ad server”.^[47] The bad chain is missing hp, which the specification requires; for version 1.0 it “should always be 1”.^[28] The good chain is flagged because a complete chain with a reseller should start with the owner or its declared manager (the fourth buyer check). Extension. Six bidders with “send all bids” need 6 × 425 = 2,550 line items, against one set of 425 when only the top bid is sent.^[48] Troubleshooting. decimal.InvalidOperation: a bid was passed as text with a currency sign; pass numbers. Teardown. rm -rf ~/adops-labs

Two documented cases (fraud and spend tracing) and two illustrative ones (a header-bidding migration and an app publisher with a sales house); each is labelled.

Problem. 3ve, analysed by Google and White Ops in November 2018, controlled over a million IP addresses, produced more than 10,000 counterfeit domains and, at its peak, between 3 and 12 billion or more bid requests a day.^[42] The takedown involved Google, the FBI and White Ops, and the US Department of Justice unsealed a 13-count indictment against eight people, as reported by The Hacker News.^[54] What ad ops learns. Most of 3ve’s requests failed the ads.txt check (the 80.3% figure above); the authors also recommend scepticism of fraud metrics that look too good, and layered detection.^[42] Trade-off. Strict enforcement also blocks legitimate supply with a stale ads.txt, so keep yours current. Pitfall. Bots laundered through an authorised account pass the check; IVT detection still matters.

Problem. In a 2020 UK study by ISBA, the Association of Online Publishers and PwC, 15% of programmatic spend could not be attributed (the “unknown delta”); only 31 million of 267 million impressions could be matched from DSP to SSP, a 12% match rate. Method and result. The follow-up (January 2023, covering 2022) used log-level data from all vendors: the match rate rose to 58%, the unknown delta fell to 3%, and 65% of spend reached media owners, up from 51%, as reported by VideoWeek.^[55] Lesson for ad ops. Cross-company reconciliation needs shared identifiers and log-level data; without them a gap cannot even be classified as fee, waste or fraud.

Worked calculation (illustrative numbers). A site serves 10,000,000 ad requests in a week; 8,800,000 are filled; revenue is $17,600. Fill rate = 88%; eCPM = $17,600 ÷ 8,800,000 × 1000 = $2.00; revenue per 1,000 requests = $1.76. After a floor increase, 7,000,000 impressions earn $16,100: eCPM rises to $2.30, but revenue per 1,000 requests falls to $1.61, an 8.5% loss on the same traffic. Revenue per request answers the business question; eCPM does not.

%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 12, "rankSpacing": 18, "padding": 8}}}%%
flowchart TB
  R["Ad requests: 10,000,000"] --> F["Filled impressions: 8,800,000 (fill 88%)"]
  F --> V["Valid after IVT filtering"]
  V --> M["Measured for viewability (measured rate)"]
  M --> VW["Viewable impressions (viewable rate)"]
  R -. "unfilled: no eligible ad" .-> U["Unfilled impressions"]
  F -. "invalid traffic removed" .-> I["GIVT and SIVT"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class R,F,V,M,VW core
  class U,I risk

Targets. Set targets from your own baseline and contract terms, not from industry averages: pacing 95–110% at flight end for guaranteed lines (an Atlas suggestion), discrepancy within the IO tolerance, IVT and viewability thresholds as written in buyers’ terms. Vanity metrics. eCPM alone, “impressions served” without IVT filtering, and viewability without the measured rate.

Brand safety and suitability. Buyers set avoidance categories and, as MRC puts it, “different tolerance levels for risk depending on brand suitability”. MRC’s verification supplement separates property-level classification (a whole site or app) from content-level classification (the page, video or post), and requires vendors to disclose when they classify by URL keywords alone, which is not content-level measurement.^[51] For a publisher, a keyword or domain match is therefore a weaker signal than it looks: ask buyers which level their vendor measures before accepting a block, and leave the policy (which categories, which tolerance) to the advertiser’s MarketingOps owners.

Least privilege. Separate ad-server roles for trafficking, yield, administration and reporting; automation credentials reach only the objects they change. Evidence. Keep QA records, discrepancy logs, IOs and invoices as finance rules require, and ads.txt history in version control. Jurisdiction. Legal questions belong to PrivacyOps and LegalOps.

• Intermediary fees. Every hop takes a share. The ANA’s programmatic work centres on made-for-advertising sites and streamlining supply-chain transaction costs;^[4] ad ops helps by removing paths that add no unique demand.
• People. Trafficking scales with IOs and creatives, not impressions; automate bulk work before hiring.
• Line items. Granularity × bidders × formats multiplies objects (Lab 4); check your ad server’s limits first.
• Latency. Each bidder and module delays the ad call; Prebid treats the timeout as a revenue trade-off.^[49]
• Sustainability. Fewer redundant bid requests mean less compute; no source opened here quantifies it (GreenOps).

• Leading indicators: complete IOs at intake; QA first-pass rate; time to traffic; ads.txt check results; discrepancy baselines against vendor expectations.
• Lagging indicators: make-good rate; disputed invoices; revenue per 1,000 requests; IVT rate; incidents by severity.
• Independent checks: MRC-accredited measurement for billing; TAG certification where buyers require it; an annual audit of ad-server access, change logs and ads.txt history.
• Feedback loop: a post-mortem with owned actions for every Sev 1 or Sev 2 incident.^[19]

%%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 14, "rankSpacing": 20, "padding": 8}}}%%
flowchart TB
  T["Alert: pacing below 95% and gap above tolerance"] --> S["Set severity; notify account manager"]
  S --> B{"Same dates, time zone, line items; unfilled excluded?"}
  B -- "no" --> R1["Re-run reports correctly"]
  R1 --> B
  B -- "yes" --> C["Find the change date in daily data"]
  C --> L["Check change log and creatives for that date"]
  L --> FX["Fix: re-traffic creative with correct type and trackers"]
  FX --> P{"Run rate needed achievable?"}
  P -- "yes" --> MON["Monitor daily until gap and pacing recover"]
  P -- "no" --> OPT["Agree option with client: extend, widen, make-good"]
  OPT --> MON
  MON --> PM["Post-mortem: update QA checklist"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class T,R1 risk
  class B,P decision
  class S,C,L,FX,MON,OPT,PM core

1. Triage (first 30 minutes). Severity 2: a guaranteed campaign is at risk and a dispute is forming. Tell the account manager now; investigate while the line item still runs.^[21]
2. Rule out report errors. Same dates and time zone, same line items, unfilled impressions excluded.^[21]
3. Find the change dates. Lab 3 shows a steady 6–7% gap on 1–2 and 6–7 November and 15–17% on 3–5 November. Something ran only on those three days. Do not treat 6–7% as normal: it is a second, older problem (step 8).
4. Check the change log. A second creative version ran from 3 to 5 November. It was trafficked as a generic third-party creative instead of the Campaign Manager 360 tag type (expected gaps: QA playbook step 4). A test page also shows that tag calling another ad server (a passback chain), which increases the expected discrepancy.
5. Fix and verify before it recurs. Traffic the 15 November rotation with the correct creative type and the agency’s current tag; check on a test page that the publisher’s and the agency’s impression trackers each fire once; confirm the next day’s gap falls back to at most the old 6–7%.
6. Recover delivery. Lab 1 needs 54,444 impressions a day against 43,333 so far. If the forecast is short, offer the client a written choice (wider geography, a three-day extension, a make-good); never silently raise the line item above other guaranteed commitments.
7. Settle the money. The three bad days push the week over a 10% tolerance. Share the daily evidence and propose the IO’s remedy (in the 4A’s/IAB template: reconcile, then a make-good or payment on the controlling count plus 10%).^[31]
8. Post-mortem. Root cause: a creative swap without full QA. Actions: creative changes use the launch checklist; the daily report flags step changes in the gap. Follow-up ticket for the 6–7% baseline (step 3): check that creative v1 uses the Campaign Manager 360 tag type, then compare geography, third-party targeting and frequency-cap settings with the agency.

When not to build an ad ops function. When one network serves a minor revenue line well; when you cannot staff daily monitoring (a half-run header-bidding stack can do worse than a simple, well-kept one); or when the business is leaving advertising. Hidden costs: partner contracts, page-performance work, privacy reviews of each bidder, out-of-hours incidents.

Exit criteria from a managed service. Bring work in-house when you can name owners for wrapper releases, ads.txt, consent integration and reconciliation, and when the managed-service fee exceeds the cost of those people plus tooling.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 14, "rankSpacing": 20, "padding": 8}}}%%
flowchart TB
  Q1{"Do you sell your own ad inventory?"}
  Q1 -- "no, we only buy" --> Q5{"Buying outside self-serve platforms at scale?"}
  Q5 -- "no" --> MKT["MarketingOps covers it"]
  Q5 -- "yes" --> BUY["Buy-side ad ops: trafficking, verification, reconciliation"]
  Q1 -- "yes" --> Q2{"Direct sales with guaranteed campaigns?"}
  Q2 -- "yes" --> INH["In-house ad ops and yield team"]
  Q2 -- "no" --> Q3{"More than one or two programmatic partners?"}
  Q3 -- "no" --> OWN["One owner and monthly checks; the network delivers"]
  Q3 -- "yes" --> Q4{"Can you staff daily monitoring and engineering?"}
  Q4 -- "yes" --> INH
  Q4 -- "no" --> MAN["Managed service plus accountable owner"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class Q1,Q2,Q3,Q4,Q5 decision
  class INH,BUY,MAN core
  class OWN,MKT neutral

For the build-or-buy choice inside the “managed service” branch, score each option from 1 to 5 against weighted criteria. The weights below are an Atlas suggestion for a mid-sized publisher; change them to match your situation.

Calculation: in-house = 0.25×5 + 0.20×2 + 0.20×2 + 0.20×5 + 0.15×2 = 3.35; managed = 0.25×3 + 0.20×5 + 0.20×4 + 0.20×3 + 0.15×4 = 3.75. A publisher that weights control and transparency at 35% each would reach the opposite answer; the weights are the decision.

This is the Atlas’s own maturity model, not an industry standard; use it to find the next step.

%%{init: {"flowchart": {"wrappingWidth": 110, "nodeSpacing": 12, "rankSpacing": 18, "padding": 8}}}%%
flowchart TB
  L1["1 Ad hoc"] -- "owner, intake form, QA checklist" --> L2["2 Repeatable"]
  L2 -- "discrepancy log, partner register" --> L3["3 Defined"]
  L3 -- "KPIs with targets, post-mortems" --> L4["4 Measured"]
  L4 -- "guarded automation, experiments" --> L5["5 Optimising"]
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class L1,L2 neutral
  class L3,L4,L5 core

For a publisher moving from level 1 or 2 to level 3. Adapt the order to your biggest pain.

Dependencies: report access, a privacy owner, finance, engineering time. Quick wins: fix ads.txt errors; remove a dead partner; add the measured rate to viewability reports.

Quick start (new owner, first week)

• I can log in to the ad server with my own named account and the right role
• I have the list of every demand partner, its contract owner and its ads.txt line
• /ads.txt (and app-ads.txt for apps) returns 200, text/plain, and includes OWNERDOMAIN
• I know which CMP runs, whether Google certifies it, which TCF/GPP strings it sends, and whether Prebid enforces them
• I can produce yesterday’s impressions, fill, eCPM and revenue per 1,000 requests

Pre-launch QA (every campaign and every creative change): the five steps of the trafficking QA playbook, plus counting terms (controlling count, tolerance, denominator) recorded in the ticket.

Header-bidding release

• Wrapper version and modules recorded; configuration diffed and reviewed
• Price granularity in the wrapper equals the line-item price set
• Timeout tested on a traffic split; consent and identity module wait times measured
• schain configured if a managed service handles payments
• tcfControl in the build if Prebid must enforce consent; rules reviewed with the privacy owner
• Rollback build available and tested

Monthly governance

• ads.txt / app-ads.txt checked against partners’ sellers.json (Lab 2); unknown or mislabelled lines fixed
• Discrepancy log reviewed; open disputes have owners
• IVT, measured rate and viewable rate reviewed by partner and placement
• Ad-server user list reviewed; leavers removed; API keys rotated as policy requires

Incident (revenue drop or malicious ad)

• Severity set; account managers and finance informed
• Last changes listed (pricing rules, priorities, wrapper, ads.txt, CMP, site release)
• For malicious ads: creative paused and evidence captured before investigation
• Post-mortem scheduled with actions and owners

Discrepancy log entry

Campaign / IO:        IO-2026-0420 line 0420-03
Parties and counts:   Publisher ad server vs agency ad server (controlling)
Period:               2026-11-01 to 2026-11-07
Tolerance in IO:      10% (denominator: publisher count)
Daily gap baseline:   6-7% (above the <2% expected for CM360 tags: ticket <id>)
Exception days:       03-05 Nov (15-17%)
Checks done:          dates/time zone, same line items, unfilled excluded, creative type
Root cause:           creative v2 trafficked as generic third-party tag with passback
Action and owner:     re-traffic v3 as CM360 tag type (trafficker), due 2026-11-14
Commercial outcome:   invoice 348,700 (controlling 317,000 + 10%); agreed <date>

Supply-partner review (one per partner per quarter)

Partner:              <SSP or reseller name>     Contract owner: <name>
ads.txt line(s):      <domain, account, DIRECT|RESELLER>
sellers.json entry:   seller_id <id>, domain <...>
                      seller_type <PUBLISHER|INTERMEDIARY|BOTH>
TAG status:           <certified programmes, date checked>
Last 90 days:         revenue share <%>, unique demand <% of its wins not seen via others>
                      bid rate <%>, timeout rate <%>, IVT rate <%>
Data sharing:         user IDs and modules enabled for this partner
Decision:             keep | renegotiate | remove (by <date>)   Approved by: <name>

Post-incident review (one page)

Title / severity:     <what happened>  Sev <1-3>
Impact:               revenue <amount or %>, campaigns affected, users affected
Timeline (UTC):       detected / mitigated / resolved
Root cause:           <technical cause> and <process gap that allowed it>
What went well:       <...>
Actions:              <action> - <owner> - <due date>   (one line each)
Checklist updated:    yes/no, which item

Sell-side versus buy-side: the sell side optimises yield (revenue per request, fill, sell-through), publishes ads.txt and disputes under-delivery; the buy side optimises delivery to plan (reach, viewability, IVT, cost), enforces ads.txt, sellers.json and schain, and disputes invalid or non-viewable impressions. Neighbouring Ops are compared in how AdOps relates to other Ops.

Direct versus programmatic versus header bidding versus server-side

Is AdOps the same as programmatic trading? No. Traders decide what to buy and at what price in a DSP; ad ops sets up and verifies the systems those trades flow through. In small teams one person does both.

Do I need ads.txt if I only use one ad network? Yes. Publish that network’s line exactly as it documents it; buyers’ platforms check the file. A site that authorises nobody should publish the placeholder record.^[26]

Why do our numbers never match the agency’s? Counting points, IVT filters, geography, latency, ad blockers and passbacks differ; Google calls discrepancies “common and expected”.^[21] The 10% tolerance often quoted is a clause in the 4A’s/IAB template, not a standard;^[31] your IO decides.

If Chrome keeps third-party cookies, can we ignore privacy changes? No. Chrome kept user choice over third-party cookies,^[14] but consent requirements such as Google’s own certified-CMP rule for the EEA, UK and Switzerland still apply;^[13] the legal analysis is in PrivacyOps.

Should our header-bidding partner add reseller lines to our ads.txt? Only lines you can trace to a contract and a sellers.json entry, bringing demand you do not reach otherwise. Each line tells buyers the path is yours.

Established capability, still changing:

• Connected TV. Ad pods, server-side insertion and the 2024 VAST CTV addendum are covered in video and CTV ad operations.^[35]
• Privacy signals. GPP keeps adding US state sections;^[30] test signals on every CMP or wrapper upgrade.
• Browser change. On 17 October 2025 Google announced the retirement of Topics, Protected Audience, Attribution Reporting and other Privacy Sandbox technologies, while Chrome keeps third-party cookie choice.^[14] Decommission integrations built for the retired APIs.

Regulatory change with operational consequences:

• The European Commission fined Google €2.95 billion in September 2025 for favouring AdX through DFP and its buying tools (for example, telling AdX the best competing bid in advance) and ordered it to end the self-preferencing.^[15]

• In the United States, a federal court held in April 2025 that Google monopolised open-web digital advertising markets.^[16] On 2 September 2026 the judge rejected a divestiture of AdX and ordered “most of the parties’ proposed behavioral remedies”;^[17] her opinion was unsealed by court order on 16 September,^[56][57] and in early October the parties filed their proposed final judgments in one document, disputed language in brackets. AdExchanger reported “no major disagreements on the core remedies”:^[24]

  • Agreed: AdX connected to Prebid; AdX answering bid requests from rival publisher ad servers on the terms it gives DFP; no reimplementation of first or last look; unified pricing rules, “which prevent publishers from setting different price floors for different buyers”, added to the banned tactics; Google Ads bidding through AdX or Prebid, not directly into DFP; separate DFP and AdX contracts; export of DFP configuration and historical bid data within three months of the order taking effect.
  • Disputed: six or twelve months for the integrations; global effect at once or up to 24 extra months abroad; when publishers get their DFP data; the six-year monitor’s powers.
  • Timing: nothing takes effect until 60 days after the judge signs an order; AdExchanger expects Google to appeal.

  No signed final judgment had been reported by 23 October 2026; the public docket copy lists none.^[56] Check it before changing configurations: integrations, floors and data exports in the dominant publisher ad server will change on its schedule.

Active research and vendor-led change (treat with care):

• AI agents in buying and selling. IAB Tech Lab released an agentic real-time framework (ARTF) for public comment in November 2025 and grouped its agentic work under the name AAMP in March 2026, with an agent registry, as summarised by IAB UK.^[58] These are emerging standards; the operational questions (approval, logging, rollback) are those of any automation that writes to the ad server.
• Attention metrics. MRC issued Attention Measurement Guidelines in November 2025;^[7] treat them as additional signals, not replacements for impressions and viewability in contracts.

Portfolio projects. (1) An ads.txt monitor that alerts on content-type, redirect and seller changes. (2) A discrepancy dashboard that flags step changes and baselines above vendor expectations. (3) A timeout experiment write-up with revenue per session and page-speed results. (4) A partner review of a public ads.txt from public files only.

You should now be able to explain how one impression is decided, counted and billed; check ads.txt, sellers.json and schain; calculate pacing, eCPM, measured and viewable rates; investigate a discrepancy with a runbook; choose an operating model; and evaluate trade-offs such as floors versus fill.

AdOps is old enough to have a certification and young enough to be rewritten by every new auction model, privacy rule and court remedy. What lasts is the core: three records (promised, decided, counted) that must agree, and a supply chain that anyone who pays can check. The specifications are short and public; the discipline is keeping them true every day. Most failures here are not exotic: a stale reseller line, a creative swapped without QA, a floor raised without watching fill, a “normal” discrepancy nobody questioned. And when one network and a well-kept ads.txt are enough, choosing that is good operations, not a lack of ambition.

All sources were opened and checked on 2026-10-23 (evidence ledger: research/adops-ledger.md). Product behaviour and regulatory status change often; re-check them.

Role and market

Supply-chain specifications (IAB Tech Lab)

Measurement and invalid traffic

Google Ad Manager (vendor documentation, as of October 2026)

Header bidding (Prebid.org documentation)

Privacy signals and browsers

Contracts, competition law and emerging standards

Further reading: Basic Prebid.js example, the official minimal integration with Google Publisher Tag.

Changelog. Re-verify Google Ad Manager behaviour, the US remedies judgment and privacy-signal versions by 2027-01-23.

• 2026-10-23, first version (r0): research, evidence ledger, nine diagrams, four labs executed on synthetic data.
• 2026-10-23, r1 revision after independent review: MANAGERDOMAIN added to the buyer’s fourth check and Scenario 4; US remedies updated to the October 2026 proposed final judgment; consent enforcement attributed to Prebid’s tcfControl; runbook treats the 6–7% baseline as a finding; new video and CTV section; brand-safety paragraph; glossary terms; Lab 4 re-run; repetition cut.
• 2026-10-23, post-score polish (reviews/adops-polish.md): unsealing date sourced to the court docket (16 September, ECF 1860; no final judgment); discrepancy restatements cut.