Optimized Price Discovery (OPD)

Optimized Price Discovery (OPD) adjusts the price reported on winning bids to improve margin while preserving win rates. LiteSwitch uses machine-learning models to choose a price-reduction factor for each winning bid, transforming the inbound price (in_ba), the price after any applicable client fee into an optimized outbound price (out_ba) that is reported onward.

In ingress proxy mode, OPD operates on the response path: after the downstream endpoint returns a bid response, LiteSwitch can rewrite the reported price on each winning bid before returning the response to the original caller.

Note

OPD in ingress proxy mode is configured and enabled by LiteSwitch per integration, and is not active by default. Confirm availability with LiteSwitch support before relying on it for a deployment.

Price Modification

LiteSwitch can apply OPD price modification in two ways.

Natively during bidding

In ingress proxy mode, OPD modifies the price inline. On the bid response path it recalculates each winning bid’s price and expands the ${LSW_OPD_CONTEXT} macro before the response is returned upstream. The new price is the original price multiplied by a model-selected factor, chosen to meet the configured objective (for example, maximizing platform revenue) while keeping the price at or above the bid floor.

Use the macros below in the response fields (adm, nurl, burl, lurl) you want LiteSwitch to populate:

Macro

Replacement

${LSW_OPD_CONTEXT}

Encoded OPD context for the winning bid

${LSW_OPD_IN_BID_PRICE}

Original (inbound) bid price

${LSW_OPD_OUT_BID_PRICE}

Optimized (outbound) price after OPD

${LSW_OPD_MODE}

OPD optimization mode

LiteSwitch processes a winning bid only when the lsw_opd=${LSW_OPD_CONTEXT} pattern is present in adm, nurl, or burl.

For example, a winning bid that arrives priced at 2.50 is returned with the optimized price, and the context macro is expanded in nurl:

price: 2.50  →  4.50
nurl:  ...&lsw_opd=${LSW_OPD_CONTEXT}  →  ...&lsw_opd=x75AChAQpaoj_CzxGlQlCBvtX6JWMEUde4MER3RVgUOEO_UcZQ

Standalone price-modification handler

If you need price modification but not the inline proxy, LiteSwitch exposes the same optimization as a standalone handler you can call directly - similar to sidecar mode. Your platform sends the winning bid(s) to the handler and receives the modified price back, without LiteSwitch sitting in the bid request path.

  • Endpoint: POST /opd/<ssp>_yesbid

  • Request: the OpenRTB seatbid payload for the winning bid(s). Each bid carries its demand identifier (dsp_id) and demand-side price (price_dsp); Supplier-internal bid and impression IDs are required when the integration uses internal-ID mode.

  • Response: for each bid, LiteSwitch returns the modified price and the OPD context:

{ "id": "bid-98765", "modified_price": 4.5, "lsw_opd": "x75AChAQpaoj_CzxGlQlCBvtX6JWMEUde4MER3RVgUOEO_UcZQ" }

OPD must be enabled for the integration; otherwise the handler responds with HTTP 403 (OPD not enabled). This option is useful when LiteSwitch does not need to be inline in the bid request flow.

Sending Win and Impression Notifications

OPD learns from impression (win) notifications, so your platform must forward them to LiteSwitch. The simplest approach is to forward them server-side from your win-notification service.

You do not need to build the LiteSwitch context yourself. When OPD processes a winning bid, it expands ${LSW_OPD_CONTEXT} inside the response field you chose (for example nurl) and modifies the reported price. Your win-notification URL then carries the encoded context, which you pass back to LiteSwitch.

For example, a nurl you submit as:

https://win.example.com/win?bidid=bid-98765&price=${AUCTION_PRICE}&lsw_opd=${LSW_OPD_CONTEXT}

is returned upstream with the context expanded and the price optimized:

https://win.example.com/win?bidid=bid-98765&price=${AUCTION_PRICE}&lsw_opd=x75AChAQpaoj_CzxGlQlCBvtX6JWMEUde4MER3RVgUOEO_UcZQ

Note

${AUCTION_PRICE} is expanded by the upstream supplier; LiteSwitch does not touch it.

When the win fires, your service forwards an impression notification to the LiteSwitch impression handler:

GET /opd/imp?bid_id=bid-98765&price=${AUCTION_PRICE}&lsw_opd=x75AChAQpaoj_CzxGlQlCBvtX6JWMEUde4MER3RVgUOEO_UcZQ

Note

lsw_opd is optional in maximize-revenue mode - LiteSwitch can match impressions using the bid id values it already logged. Passing it is strongly recommended: it improves discrepancy matching, unlocks real-time impression metrics broken down by context (publisher, domain, and so on), and is required for any OPD mode that performs margin balancing.

Impression Handler

The OPD impression notification shown above uses these parameters:

Parameter

Required

Description

bid_id

Yes

Identifier of the winning bid (matches the bid id in the response)

price

Yes

Cleared price (the supplier-expanded ${AUCTION_PRICE})

lsw_opd

Recommended

Encoded OPD context expanded from ${LSW_OPD_CONTEXT}

When lsw_opd is omitted, LiteSwitch attributes the impression using the bid id it already logged. The same handler also serves ingress impression reporting, where the demand-side price (price_dsp) may be included when your integration prices on the demand side.

What OPD Skips

OPD does not modify a bid when:

  • the bid is part of a fixed-price deal

  • the inventory is audio content (can be enabled upon request)

  • the required macros are missing from the response

  • OPD is disabled or its configuration is invalid for the integration

OPD Integration FAQ

Q: Does each proxy node train its own model, or is the model shared? A: OPD uses a single model per optimization mode. With a single mode (maximize platform revenue), one model is shared across all nodes.

Q: Do impression notifications have to reach the same node that handled the bid? A: No. Notifications can be sent to any node. For accurate real-time monitoring, send them within the same region as the bids.

Q: What does a minimal OPD (ingress proxy) integration require? A: Three components:

  1. Cluster control — autoscaling and load balancing for the LiteSwitch container pool.

  2. Bidding support — send bid requests through the proxy and return the bid responses.

  3. Impression notifications — forward win/impression calls to the LiteSwitch impression handler.

Troubleshooting

Note

This section only contains OPD specific causes

OPD prices are not applied

Check:

  • OPD is enabled for the integration (confirm with LiteSwitch support)

  • the winning bid includes the lsw_opd=${LSW_OPD_CONTEXT} macro pattern in adm, `nurl`, or burl

  • the OPD macros are present in the response fields you expect LiteSwitch to populate

  • the bid is not a fixed-price deal or audio content