---
title: "My PMP deal is not delivering"
description: "A deal-specific decision tree for a private marketplace deal that transacts poorly — confirm the seat, the country rows, the deal ID, the deal floor, competing demand and creative scan, in the order the ad server checks them."
type: "troubleshooting"
audience: [network-manager, admin]
keywords: [PMP, private deal, deal not delivering, no bids, buyer seat, wseat, deal ID, deal floor, private auction, invalid deal, creative scan]
ui_path: "Account → Advertisers → advertiser → campaign → RTB PMP deals"
---

Fetch the complete documentation index at: https://epom.com/ad-server/docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version.

# My PMP deal is not delivering

A buyer says a private marketplace deal wins nothing — or far less than agreed. A deal
adds one more filter on top of everything that gates ordinary programmatic demand, and
that filter has moving parts on the buyer's side (the **seat** and **deal ID** their DSP
returns) that you don't control. Work through the checks below **in order** — they run from the
most frequent cause to the rarest, which is not exactly the order the ad server applies them in,
so the first one that fails is usually the answer.

Before you start, rule out the ordinary causes: a deal only delivers where the campaign it
lives on would deliver anyway. If the campaign's OpenRTB banners aren't reaching the auction
at all, the deal never gets a chance. Run [My ad is not serving](https://epom.com/ad-server/docs/troubleshooting/ad-not-serving.md) first
if **Requests** are zero for the partner — this page assumes bid requests are going out and
the deal specifically is the problem.

## Who this is for

Network managers running programmatic PMP deals. The **RTB PMP deals** card on a campaign needs
the *RTB PMP Deals* permission, which no stock role holds — your network administrator grants it in **Admin →
Users & access → User roles & permissions**. Two of the checks below, DSP partners analytics and
creative-scan verdicts, live in the admin area (Admin → Demand partners (DSP)); a role that holds
*DSP Partners Analytics* or *DSP Creative Scan* also sees them at **Account → RTB**, but neither
permission is on for any non-administrator role until an administrator grants it — so loop in your
network administrator for those.

## The one thing that makes a deal measurable

If you can't tell whether the deal is delivering, fix this first: **one campaign per deal**.
Reports have no per-deal dimension, so several deals on one campaign blend into a single set
of numbers and you can't separate them. When a campaign carries exactly one deal, that
campaign's impressions, revenue and eCPM *are* the deal's — see
[Sell premium inventory through PMP private deals](https://epom.com/ad-server/docs/use-cases/pmp-private-deals.md).
Everything below assumes you can read the deal's delivery this way.

## Check 1 — is the buyer’s seat still the one you entered?

This is first because it changes most often. A bid that carries the right deal ID but comes
from a **different seat** than the **Buyer ID** on the deal row is rejected as an invalid
deal bid — the seat must appear in the deal's buyer-seat list (`wseat`) or the whole seat-bid
is dropped.

- Re-confirm the seat ID with the buyer. DSPs rotate or split seats far more often than they
  change deal IDs; a deal that "suddenly went quiet" is usually a seat that moved.
- Fix it on **Account → Advertisers → advertiser → campaign → RTB PMP deals** → edit the row's
  **Buyer ID**.
- The deal ID and the seat are matched **together**: a bid whose deal ID belongs to a row with a
  different seat is dropped as an invalid deal even when **Private auction** is off.

> **Corner case:** the ad server logs the mismatch. When your network administrator has a troubleshooting log
> task covering the request (**Admin → Audit & diagnostics → Troubleshooting log tasks**), the
> record reads *"Invalid seatbid for private PMP request with buyerId(wseat)=… and dealId=…"*
> (private auction) or *"Request doesn't have imp with pmp dealID=… and seatID=…"* — ask your
> network administrator to pull it for the placement and time window; it names the seat the buyer actually
> sent versus the one you configured.

## Check 2 — do the deal’s Country rows cover the traffic?

Country matching on a deal is **exact**, and this interacts badly with **Private auction**.

- A deal row is attached to a bid request only when the request's country matches that row
  (or the row is **Global** / `*`). Traffic in a country with no matching row carries no deal.
- With **Private auction on**, an impression that ends up with *no eligible deal* is an
  invalid private request — the platform sends **no bid request at all** for it. So a
  private, country-scoped deal is silently dark everywhere outside its listed countries.

Compare the deal's Country rows against where the buyer expects volume. If the buyer reports
missing geos, this is the most common cause.

> **Corner case — unresolved geo:** when the visitor's country can't be resolved (VPNs,
> internal IPs, geo-lookup gaps), country-scoped rows are **not** attached — only a **Global**
> row keeps the deal in play on that traffic. If the deal must always ride along, add a Global
> row (see the geo corner cases in
> [ad-not-serving Check 6](https://epom.com/ad-server/docs/troubleshooting/ad-not-serving.md#check-6--targeting-too-narrow)).

## Check 3 — does the deal ID match what the DSP returns?

The deal ID is a string both sides reference, and it must match **exactly**. On a private
auction, a bid whose `dealId` is empty, or doesn't match any deal on the impression, is
dropped and the runner-up (if any) takes over.

- Copy the deal ID from the buyer's DSP verbatim into the row — watch for trailing spaces,
  case, and lookalike characters.
- Ask the buyer to confirm their DSP is *sending the deal ID back in the bid*, not just
  targeting it. A DSP that bids into the deal but omits the deal ID on the response looks
  identical to "no bid" on your side.

> **Corner case:** in a troubleshooting log task, a wrong or absent deal ID on a private auction is
> logged as *"Invalid bid for private PMP request with dealId …"*. That message means the bid
> arrived but was rejected — different from the partner never bidding, which shows as zero
> bids in DSP partners analytics.

## Check 4 — is the deal floor priced where the buyer actually bids?

A valid deal bid **skips your open-auction floors** and is judged against the **deal floor**
instead — the deal terms are the contract, in both directions:

- A deal floor set **above** what the buyer is willing to bid means every deal bid falls
  short and loses. If the buyer says "I'm bidding $X but winning nothing", compare $X against
  the row's **Bid floor**.
- A deal floor **below** your normal placement/site floors will still clear — the deal floor
  overrides them. That's intended, but it means a deal you priced too low can quietly
  underdeliver *revenue* while looking like it "delivers".

A bid below the floor is dropped, and a troubleshooting log task records it as *"Bid price (…)
less than pmp bid floor …"*. Adjust the row's Bid floor to match the negotiated price, then
re-check delivery.

## Check 5 — is other demand outbidding the deal?

Unless the campaign is deal-only, the deal competes with everything else:

- With **Private auction off**, deal bids and open-auction bids from the same partner — and
  any direct campaigns on the same placement — compete on price/priority. A higher-paying
  direct campaign or a stronger open bid simply wins the slot.
- To make the campaign deal-only, turn **Private auction on** so only deal bids are accepted on
  it, and use campaign **priority** and linking to steer the slots the deal should fill. Epom has
  no guaranteed-delivery deal type — a deal is an auction, so none of this reserves volume (see
  [PMP deal types compared](https://epom.com/ad-server/docs/guides/advertising/pmp-deal-types-compared.md)).

Verify with a report grouped by the deal's campaign: if impressions exist but are lower than
promised, the deal is being outbid, not filtered.

## Check 6 — is the creative being blocked by scan?

On networks that scan DSP creatives, a creative that is **Blocked** is dropped from the auction
before it can win, and the runner-up serves instead. A deal whose
buyer keeps sending one flagged creative will look like it never delivers.

- Verdicts are on **Admin → Demand partners (DSP) → DSP creative scan**, and at **Account → RTB →
  DSP creative scan** for a role that holds *DSP Creative Scan*. Ask your network administrator to check the
  buyer's creative(s) for this partner.
- A **Passed** creative delivers; a **Blocked** one won't until the buyer swaps it. See
  [creative policy protection](https://epom.com/ad-server/docs/use-cases/creative-policy-protection.md) and
  [ad-not-serving Check 10](https://epom.com/ad-server/docs/troubleshooting/ad-not-serving.md#check-10--programmatic-demand-with-no-bids).

## Check 7 — the ordinary ad-serving gates still apply

A deal doesn't bypass the rest of the platform. If checks 1–6 pass and delivery is still
short, the deal's campaign is subject to the same filters as any campaign:

- Everything in the demand chain (banner → campaign → advertiser) and supply chain
  (placement → zone → site) must be **on** and linked.
- The campaign's own **targeting, capping and limits** are the deal's delivery controls —
  a tight frequency cap or a reached limit throttles the deal too.
- The partner-level **Max QPS** and timeouts throttle bid requests before deals are even
  evaluated.

Run the full [My ad is not serving](https://epom.com/ad-server/docs/troubleshooting/ad-not-serving.md) ladder against the deal's campaign
to catch these.

## When you escalate

Give your network administrator: the **deal ID** and **Buyer ID (seat)** as configured, the **campaign
ID**, the **countries** where volume is missing, the **time window**, and what **DSP partners
analytics** shows for the partner (Requests / Bids / Wins). If a troubleshooting log task covers
the traffic, the *"Invalid bid…"* / *"Invalid seatbid…"* / *"…less than pmp bid floor…"* lines
pinpoint whether bids are arriving and being rejected versus never arriving at all.

## Related

- [Sell premium inventory through PMP private deals](https://epom.com/ad-server/docs/use-cases/pmp-private-deals.md)
- [My ad is not serving](https://epom.com/ad-server/docs/troubleshooting/ad-not-serving.md)
- [Plug programmatic DSP demand](https://epom.com/ad-server/docs/use-cases/programmatic-dsp-demand.md)
- [Configure DSP partners](https://epom.com/ad-server/docs/guides/admin/dsp-partners.md)
- [Troubleshooting overview](https://epom.com/ad-server/docs/troubleshooting.md)