> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/investigate-an-auction-or-deal-result.md).

# Investigate an auction or deal result

Investigate a connected demand result, create a safe trace, and escalate only the evidence a partner needs.

Use this task when a connected demand result does not match what you expected. The Podigee Audio Video Ad Server keeps the request, the provider result, and the final decision separate so you can find the cause without changing live delivery.

This task covers an auction or provider result. It also covers a committed Marketplace deal whose external state does not agree with Podigee. It does not change a Campaign, resend a live ad, or create a manual revenue record.

## What you can investigate

The decision can show one of these outcomes:

| Result                  | Meaning                                                         |
| ----------------------- | --------------------------------------------------------------- |
| Ad selected             | Podigee selected an eligible ad for the request.                |
| No ad selected          | No source produced a usable ad, or a rule removed every source. |
| House ad selected       | The configured house Flight supplied the fallback.              |
| Original content played | The request used clean content because no ad was eligible.      |

For a connected demand source, the reason can include **No marketplace buyer placed a bid** or **The marketplace did not answer in time**. Other reasons can come from targeting, price, rights, media, schedule, frequency, privacy, or capacity rules. Read the reason on the exact decision before you contact the provider.

## Find the exact delivery decision

1. Open **Monetization > Evidence & Money**.
2. Open **Live ad delivery**, then select **Recent ad decisions**.
3. Search by the short decision reference, Campaign, Creative, episode, or request time.
4. Filter **Result**, **Delivery method**, or **Privacy** when the list contains many requests.
5. Open **View decision** for the request you need to explain.

![The current One Podigee Recent ad decisions page shows one Podcast audio result after filtering by its short decision reference.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-a1654ab452ed46718e4b5981217703e7eac7ba93%2Fdoc-monetization-064-exact-decision.png?alt=media)

*Use the request time and delivery method to separate this request from other listener requests.*

Do not use a provider timestamp alone. Match the request time, delivery method, Podcast, Episode, Ad break, and short decision reference. A provider can receive a request that Podigee later rejects, or a listener can retry the same presentation.

## Read the decision before the provider trace

The decision details page shows:

* the selected result or fallback;
* the customer-readable reason;
* the Campaign and Creative, when one was selected;
* the Podcast, Episode, Ad break, and privacy mode;
* the qualified value, when the measurement window is complete;
* the shortened decision and delivery release references;
* one row for each ad slot in the decision.

![The current One Podigee Ad decision details page connects the selected Campaign and Creative to the podcast, episode, ad break, privacy mode, qualified value, and exact delivery references.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-a6a46bc4f1c8230e01ac95b529b06c49a9b3d5f9%2Fdoc-monetization-064-decision-evidence.png?alt=media)

*Copy the complete value only when another operator or Podigee Support needs it.*

The decision is read only. Opening it, copying a reference, or reviewing its slots does not change delivery or billing.

## Inspect demand evidence safely

On the exact decision, open **Investigate this decision** and choose **Inspect demand evidence**. This starts an asynchronous inspection of retained, redacted provider evidence.

The inspection does not:

* send another auction request;
* serve another ad;
* reserve inventory;
* change the demand policy;
* change a Campaign or Flight;
* create a delivery or revenue record.

When the inspection is ready, return to the same decision. The investigation status is shown with the decision's other diagnostic records. The result can identify a bid, no-bid, timeout, response rejection, or an authority or policy failure.

Use the following order when you read the result:

1. **Request**: confirm the delivery method, media kind, market, privacy mode, and request time.
2. **Provider**: confirm the provider, protocol, operation, and provider version.
3. **Response**: identify bid, no-bid, timeout, malformed response, or rejected response.
4. **Validation**: check media, tracker, price, rights, and policy results.
5. **Decision**: confirm the selected source, next source, or safe fallback.
6. **Measurement**: confirm whether the listener or viewer event qualified any value.

A bid is not a selected ad. A selected ad is not qualified revenue until the measurement contract accepts the required event.

## Compare common provider results

### No bid

The provider received a valid request and did not offer an ad. Check the provider's targeting, market, budget, and supply rules. If another eligible source exists, Podigee can try that source according to the active demand order.

### Timeout

The provider did not answer within the configured response limit. Check the provider's status, region, and connection evidence. A timeout must not block the whole listener request. Podigee can continue to the next source or the configured fallback.

### Response rejected

The provider answered, but the response did not pass the Flight or delivery rules. Common causes include unsupported media, an invalid tracker, a price below the policy boundary, missing rights, or an unapproved brand or category. Repair the source or Flight instead of creating a manual fill.

### Selected but not qualified

The provider result won the decision, but the listener or viewer has not yet met the measurement rule. Wait for the qualification window. Do not count the provider bid or the decision as qualified revenue.

## Investigate a committed deal synchronization

Use the Marketplace path when the problem is a committed deal, buyer, or external deal identity:

1. Open **Monetization > Marketplace**.
2. Find **Committed deals** or the synchronization notice for the deal.
3. Select **Review** for the deal that needs attention.
4. Compare the Podigee deal number, buyer, provider, budget, currency, and current state.
5. Compare the external identity and the latest synchronization result.

The synchronization state can be **Pending**, **Confirmed**, **Ambiguous**, or **Conflict**. A confirmed state is not shown in the attention list. An ambiguous or conflict state needs review before the deal can be treated as synchronized.

Use **Reconcile** when the latest external result is available and the records can be compared. Use **Retry** when the provider did not complete the previous attempt or the conflict needs a new request. Both actions create a durable operation. They do not silently rewrite the committed deal.

Keep the deal non-serving when the external identity, terms, buyer, or supply version is unclear. Resolve the mismatch first, then confirm the next synchronization result.

## Create a redacted support package

Create a support package only after **Replay recorded decision** or **Inspect demand evidence** is ready. The package contains the minimum redacted trace for the authorized recipient and expires after its stated period.

Before you create it, confirm:

* the exact decision reference;
* the provider and protocol;
* the request time and delivery method;
* the customer-readable reason;
* the failed or unexpected validation step;
* the recipient who needs the trace;
* the allowed expiry period.

Do not copy a full endpoint, credential, listener identifier, or raw provider payload into a chat, ticket, or email. Use the **Create support package** action so the access boundary and expiry are recorded with the trace.

## If the records disagree

Check these items in order:

1. Confirm that you opened the correct Podcast, Episode, Ad break, and request time.
2. Compare the decision result with the provider result, not only the Campaign status.
3. Check the active demand policy and its response limit.
4. Check the provider version and certification state at the request time.
5. Check whether the response failed media, tracker, price, rights, or safety validation.
6. Check whether the measurement window is still open.
7. Check **Monetization > Operations** for a provider or delivery incident.
8. Create the redacted support package only when a partner or Podigee Support needs it.

Do not replay a live request to make the numbers match. The recorded replay is for diagnosis and does not create a new commercial effect.

## Expected result

You can explain the exact provider result, the Podigee decision, the fallback or selected ad, and the measurement state without changing live delivery. If a partner must investigate, the redacted trace contains enough evidence to reproduce the question without exposing credentials or raw listener data.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/investigate-an-auction-or-deal-result.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.