MobileFuse SDK bidding

MobileFuse SDK bidding requests a MobileFuse bid for an app that runs the MobileFuse SDK. The request carries an SDK token, and the bid returns a rendering token that the SDK uses to show the ad.

Direction and version

A mediation or auction server sends a request with the MobileFuse SDK token to MobileFuse, and MobileFuse returns a bid carrying a rendering token for the SDK.

OpenRTB 2.x JSON, checked against the 2.6 field catalog. Both tokens are opaque strings that are never decoded.

The RTBlint profile mobilefuse-sdk checks requests and responses against the published contract.

Rules beyond the OpenRTB spec

  • The SDK token goes in user.data[0].segment[0].signal, the first segment of the first data entry. It must be a non-empty string of at most 4000 bytes.
  • The first impression needs imp.tagid. Later impressions are ignored and do not need a placement tag.
  • Each returned bid needs a non-empty string rendering token in bid.ext.signaldata.
  • An SDK bid may omit adm, because the SDK renders from the token.
  • at, when sent, must be 1. tmax must be at least 100 milliseconds, and badv may list at most 50 domains.
  • Bid responses are in USD.
  • Unlike app supply, SDK requests are not required to carry app.bundle, device.ua, or a device IP address.

Documented extensions

PathMeaning
bid.ext.signaldataOpaque rendering token the SDK uses to display the ad.
bid.ext.mfMobileFuse render, cache, and SDK click event strings.
device.ext.attsApp Tracking Transparency status, 0 to 3.
user.ext.hemsHashed email objects with hem and hem_type.
regs.ext.gppGPP string in its legacy location.

What the validator checks for this profile

Validate against this contract

Open the tester with the MobileFuse SDK bidding profile, or run:

rtblint validate --profile mobilefuse-sdk request.json

Similar integrations