The Google ad tech remedies ruling routes AdX and DFP through Prebid, so the bid request Prebid Server builds becomes the compliance record.

October 1, 2026 · RTBlint

On September 2, Judge Leonie Brinkema rejected the Justice Department's request to force Google to sell AdX, open-source the DFP final auction logic, or divest the rest of DFP. She accepted most of the behavioral remedies both sides had proposed, as modified by the court. The headline was that Google keeps its stack. The part that lands on engineering teams is different: AdX and DFP have to interoperate with Prebid on terms that are functionally equivalent to how they work with each other, and the evidence for equivalence will be the requests and responses that cross those new connections.

What the court actually ordered

The written opinion, unsealed later in September without redactions, found structural remedies neither realistic nor needed. In their place the court adopted interoperability and data-sharing remedies, anti-discrimination rules, and a monitor with a technical committee. The Final Judgment runs for six years, applies worldwide, and takes effect 60 days after it is entered. The parties were given 30 days from the order to file one jointly proposed judgment, so the operative text is being negotiated now.

Four remedies matter on the wire. Google must build an API from AdX to Prebid covering indirect open-web display inventory. It must build an API and a server-to-server connection from DFP to Prebid Server, so the publisher's auction can run inside Prebid. AdX must submit real-time bids to rival publisher ad servers in the same manner it currently bids into DFP. And AdX winning and losing bid data has to be made available to publishers. First Look and Last Look stay barred, and Unified Pricing Rules have to be deprecated for all indirect transaction types, which means publishers regain the ability to set different floors for different exchanges.

Timing is uneven. Google committed to 12 to 15 months for the DFP to Prebid integration, and the court deferred to Google wherever its estimate was shorter than the plaintiffs'. For AdX bidding into rival ad servers the plaintiffs proposed six months and Google twelve, and the opinion left that number for the parties to settle. A separate case moved on October 1: Judge P. Kevin Castel in New York ruled that USA Today, Daily Mail, and a class of about 5,000 publishers can seek more than $3.2 billion in damages over the same AdX conduct. Neither ruling changes a single field in OpenRTB. Both raise the price of not being able to show what was sent.

The new hop is an OpenRTB request someone will audit

The plaintiffs' proposed judgment, which the court drew on for the Prebid wording, describes the DFP side in three steps. For each impression DFP sends floors, data signals, and publisher first-party data to Prebid Server. Prebid Server sends bid requests to every source of programmatic demand the publisher specified. Prebid Server returns bids and data about the ad candidates to DFP, which keeps the final comparison against the publisher's direct deals.

The middle step is an ordinary OpenRTB 2.x bid request, emitted by Prebid Server from inputs DFP supplied. That is the artifact a monitor, a technical committee, or a publisher's own analyst will compare when the question is whether AdX demand saw the same impression through Prebid that it used to see through DFP. Functionally equivalent is a legal standard. In practice it gets argued with two captures of the same impression side by side, and any field that is missing, mistyped, or translated differently on one side becomes an exhibit.

{
  "id": "req-7f3c",
  "imp": [{
    "id": "1",
    "banner": { "format": [{ "w": 300, "h": 250 }] },
    "bidfloor": 1.20,
    "bidfloorcur": "usd",
    "ext": { "tid": "b9a1-imp-1" }
  }],
  "site": { "domain": "news.example", "page": "https://news.example/a/123" },
  "source": {
    "tid": "b9a1",
    "schain": { "complete": 1, "ver": "1.0", "nodes": [{ "asi": "Publisher.Example", "sid": "123", "hp": 1 }] }
  },
  "regs": { "gpp_sid": [7] },
  "user": { "eids": [{ "source": "uidapi.com", "uids": [{ "id": "A4AAA..." }] }] }
}

Every line in that request would survive a casual glance and every one has a problem a buyer's parser can act on. The floor currency is lowercase, which openrtb.imp.bidfloorcur_format_invalid reports because ISO 4217 codes are uppercase. The GPP section id arrives without a GPP string, which is openrtb.regs.gpp_sid_without_gpp. The supply chain node ASI is not a lowercase domain, which is openrtb.schain.node.asi_not_lowercase. None of these is exotic. They are the ordinary mistakes that appear when one system translates another system's internal state into OpenRTB for the first time, which is exactly what the DFP to Prebid Server bridge will do.

Floors stop being one number

Unified Pricing Rules forced a single floor across AdX and third-party exchanges inside DFP. With UPR deprecated for indirect demand, publishers can price exchanges differently again, and the place those floors travel is imp.bidfloor and imp.bidfloorcur on each outbound request, or pmp.deals[].bidfloor when the impression is in a deal. Per-bidder floors multiply the number of request variants for one impression. They also multiply the chances that one variant carries a floor in the wrong currency, a negative value from a bad rule, or a deal floor that contradicts the open floor.

The court framed equivalence around AdX receiving and returning data on materially identical terms. A floor that DFP set in one currency and Prebid Server forwarded in another, or a deal floor that never made it onto the request, is a measurable difference in terms. Log the floor DFP passed in, the floor Prebid Server sent out per bidder, and the currency on each. If those three columns do not reconcile, the integration is not equivalent, regardless of what the API documentation says.

Data signals are now a discrimination question

The anti-discrimination remedies require Google to use and pass data signals regardless of whether its own tools are involved, and require AdX to pass bids to publisher ad servers and header bidding auctions, including Prebid, without regard to Google ownership. Google argued for, and the court accepted, a clarified list of the signals covered, with carve-outs for privacy policies, governing law, spam, and fraud. Whatever that list says in the final text, the signals it names have concrete homes in a bid request: user.eids for identity, regs and regs.gpp for consent, device and site for context, and source.schain for the path.

An identity entry that reaches one bidder with its source domain and another without it is a signal passed on different terms, and openrtb.eid.field_required catches the missing half. A GPP string that is present on the AdX path and stripped on the Prebid path changes which buyers can bid in regulated states. A supply chain that gains a node on one route and not the other changes how a buyer scores directness. These are the comparisons a technical committee will make, and they are cheaper to make in CI than in a compliance review.

The ruling also lands while browser-side identity is shrinking. Safari 27, which began rolling out on September 14, blocks requests to uidapi.com, ID5, LiveRamp, and Permutive domains, according to a WebKit bug filed by The Trade Desk. Fewer identity entries will originate in Safari pages, so the user.eids array that does arrive carries more weight and deserves stricter validation.

Win and loss data needs a shared vocabulary

Making AdX winning and losing bid data available to publishers is the remedy most likely to change dashboards. OpenRTB already has the plumbing: the loss notice URL lurl on a bid, the ${AUCTION_LOSS} macro, and the community loss reason code list maintained alongside the 2.x spec. Publishers who want to compare AdX outcomes with other demand should normalize on those codes rather than on whatever labels each source invents. A reason 102 (lost to higher bid) means the same thing from every exchange only if every exchange actually sends it.

Responses need the same discipline. A bid returned through Prebid Server without mtype forces the publisher side to guess the creative type, which openrtb.bid.mtype_missing flags. A response with neither seatbid nor nbr gives the analyst nothing to file as a no-bid reason. When the monitor asks why AdX lost a given impression through Prebid, an empty response body does not answer the question.

What to do before the integrations ship

Capture a baseline now: the DFP to AdX path as it runs today, impression by impression, so there is something to compare the Prebid path against later.
Validate the requests Prebid Server emits in CI, not only the ones it receives. The outbound request is the one buyers and auditors see. For the inbound auction call, the prebid-server profile adds the PBS requirements the spec leaves optional, such as bidder params under imp.ext.prebid.bidder or a stored request id.
Log floors per bidder with currency, and reconcile them against the floor the ad server intended. Treat a mismatch as a defect, not a rounding issue.
Diff user.eids, regs, and source.schain between routes for the same impression. A signal present on one route and absent on another is the definition of unequal terms.
Standardize loss reporting on OpenRTB loss reason codes and lurl before the AdX win and loss feed arrives, so the new data lands in an existing schema.
Require mtype on every bid and a reason on every no-bid, so the return leg of the integration is as auditable as the outbound one.

Paste a captured request into the bid request tester, wire the same check into a pipeline with the CI validation guide, and read loss reason codes and nurl vs burl vs lurl for the return leg. For how header bidding and ad server demand already coexist, see Prebid vs Amazon TAM vs Open Bidding. RTBlint is independent and not affiliated with Google, Prebid.org, or any party to either case. It checks whether a request or response matches OpenRTB and AdCOM. It does not decide what the court will consider equivalent.