Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugging enhancement for mobile apps #2518

Open
bretg opened this issue Jan 5, 2023 · 6 comments
Open

Debugging enhancement for mobile apps #2518

bretg opened this issue Jan 5, 2023 · 6 comments
Labels

Comments

@bretg
Copy link
Contributor

bretg commented Jan 5, 2023

Turns out it's hard to debug mobile apps sometimes. Prebid Server could help this process by making it easier to get a bid response in debug scenarios.

This is of course possible already with storedbidresponses and storedauctionresponses, but using them has two disadvantages:

  1. it's only possible to do with a hacked app or a proxy that can intercept the app's request and override it
  2. it requires that a storedresponse to be created in the destination PBS. Some PBS hosts have set these up, but they're not consistent.

Here are a few ideas to improve being able to debug mobile apps in the field:

  1. Assuming it's possible to inject an HTTP header for an app, PBS could support defining a storedresponse there. e.g. "X-Prebid-StoredResponse-Override: 0:sar:12345,1:sbr:bidderA:67890" could be expanded by PBS to the appropriate storedauctionresponse and storedbidresponse. The syntax can be refined if the approach is generally approved. The example suggested here is "IMP#:sar:ID" or "IMP#:sbr:bidder:ID" (sar=storedauctionresponse, sbr=storedbidresponse)
  2. Perhaps more controversial, we could deliver PBS with a simple set of hard-coded stored responses that cover basic banner sizes and a vast response. e.g. pbs-hardcode-banner-320x50.
  3. Instead of requiring a server-configured storedreq/resp, we could define an extension for supplying a desired response. e.g. ext.prebid.echoseatbids which are just added to the resulting seatbid array. e.g.

See #2518 (comment) for where we ended up on this.

@bretg
Copy link
Contributor Author

bretg commented May 11, 2023

Discussed with the mobile committee. #3 above is of most interest to them, and it also happens to be the easiest to implement. Here's the proposed behavior.

For the /auction endpoint only, if ext.prebid.echoseatbid[] is seen on the incoming request:

  1. skip storedrequest/storedresponse processing
  2. skip auctions
  3. modules may be skipped
  4. when formulating the ORTB response, copy the contents of ext.prebid.echoseatbid into seatbid. If echoseatbid is not valid JSON, respond to the requestor with HTTP 404, but otherwise no validations as to the schema or contents.
  5. add the following:
    a. ext.warnings.prebid[{message:"echoseatbids mode: no auction"}]
  6. no seatnonbid
  7. skip analytics

Metrics-wise, it's ok if this shows up as a request, but it doesn't have to. It should emit the following just to keep tabs that the feature is not getting abused:

  • alerts.general
  • send "echoseatbids mode: no auction" to the log stream at N% sampling

No privacy or security concerns come to mind.

@bretg
Copy link
Contributor Author

bretg commented Jun 8, 2023

Discussed in committee. Rather than come up with a new syntax for a feature that's similar to the storedauctionresponse feature, there's a desire to generalize that feature. Here's a proposal:

  1. Support storedauctionresponse at the global level -- ext.prebid.storedauctionresponse. It's currently only supported at the imp-level.
  2. Support a JSON block as a parameter that will be interpreted as the entire seatbid of the response -- currently the storedauctionresponse object must contain an id that points to a stored request.
ext.prebid.storedauctionresponse: {seatbidarr: [ ... contents become the response.seatbid output ... ]}

To keep it simple, the seatbidarr option is only available at the global level. If seatbidarr is specified at the imp level (imp.ext.prebid.storedauctionresponse.seatbidarr) ignore and add a warning "stored response seatbidarr option not supported at the imp level".

Processing:
If the global ext.prebid.storedauctionresponse exists, this means to entirely skip the auction and all modules. It also means that the global storedauctionresponse completely overrides any imp-level storedauctionresponse that may be present.

  1. Just respond with a body containing the $.seatbid set to the value defined in ext.prebid.storedauctionresponse.seatbidarr. If seatbid not defined and id is defined, the system should lookup the value against the storedresponses in the DB/filesystem/HTTP endpoint and use that if available. If no value is available, $.seatbid should be an empty array.
  2. $.id should be set to whatever the incoming request id was set to. If the incoming request doesn't contain id, the response doesn't need to either.
  3. ext.prebid.warnings.prebid.message containing an explanation "no auction. response defined by storedauctionresponse".
  4. Requests to ext.prebid.storedauctionresponse should not go to analytics adapters or any modules.
  5. The priority is support in the /auction endpoint. It's not defined how /amp requests would specify the seatbid object -- if that becomes necessary a separate enhancement will be opened.

@bretg bretg moved this from Needs Requirements to Ready for Dev in Prebid Server Prioritization Jun 21, 2023
@bretg
Copy link
Contributor Author

bretg commented Jun 18, 2024

Sorry, having done this myself with the Charles proxy, I've realized that a per-imp storedauctionresponse would in fact be useful. It would help the debugger if PBS could deal with the caching and adding the seatbid.bid.ext.prebid.{targeting,events} fields. The process is currently:

  1. Capture a bid response (probably the hardest part)
  2. POST manually to /cache to store the VAST and/or Bid
  3. Update the bid response hb_cache_id, hb_uuid, and seatbid.bid.ext.prebid.cache items with the new UUIDs
  4. Set the proxy to override the PBS response with the captured and updated response
  5. Debug for a few minutes
  6. Repeat steps 2-5 once PBC cached items hit their time-to-live

So I'd like to explore expanding this feature to support dealing with the cache stuff. ORTB seatbid is an array of seatbid objects. It's actually a different slice of the underlying data than is present in the incoming request: the request is an array where each entry is an adunit, while the seatbid is an array of arrays, where each entry is from a single bidder and may contain multiple bids that map in strange ways back to the original imp[] using the impid field.

To make this distinction clear, I'm going to propose a change to the syntax here - the global attribute should be ext.prebid.storedauctionresponse.seatbidarr to indicate that the value is expected to be an array that entirely replaces the output seatbid array.

In contrast, the imp-level attribute would be seatbidobj to indicate that the value should be an object that's added to the output seatbid array.

imp[].ext.prebid.storedauctionresponse: {"seatbidobj": { ... contents of this object are appended to the response.seatbid array ... }}
  1. The global ext.prebid.storedauctionresponse.seatbidarr takes precedence. (same warning as noted in previous comment)
  2. The value of seatbidobj in the imp context is just one array entry. i.e. if there are multiple imps with imp[].ext.prebid.storedauctionresponse, then each would contribute an object to the ORTB seatbid array. This differs from the global ext.prebid.storedauctionresponse.seatbidarr where the value is an array that forms the entirety of the output seatbid.
  3. It should be possible to allow some impression objects to contain imp[].ext.prebid.storedauctionresponse.seatbidobj while other entries in the array contain imp[].ext.prebid.storedauctionresponse.id.
  4. However, if both storedauctionresponse.seatbidobj AND storedauctionresponse.id are present in a single imp object, the seatbidobj takes precedence.
  5. If PBS sees seatbidobj, there should be no auction or analytics for this imp. We know the result.
  6. Modules may be skipped. But if its better from a code path perspective to call the modules, it's ok to do so.

I'm kicking this back to "Needs requirements" to get a second opinion on the proposed syntax change.

@bretg bretg moved this from Ready for Dev to Needs Requirements in Prebid Server Prioritization Jun 18, 2024
@bretg
Copy link
Contributor Author

bretg commented Jul 31, 2024

The global part of this done with PBS-Java 3.7

@bretg bretg moved this from Needs Requirements to Community Review in Prebid Server Prioritization Sep 23, 2024
@bretg
Copy link
Contributor Author

bretg commented Sep 25, 2024

Reviewed by PBS committee. Will discuss with Mobile committee

@bretg bretg moved this from Community Review to Ready for Dev in Prebid Server Prioritization Oct 8, 2024
@bretg
Copy link
Contributor Author

bretg commented Jan 17, 2025

Support for defining the contents of the desired response is done in PBS-Java 3.13. See https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#impression-stored-auction-response-json

@bretg bretg added the PBS-Go label Jan 17, 2025
@bretg bretg changed the title Debugging enhancements for mobile apps Debugging enhancement for mobile apps Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Ready for Dev
Development

No branches or pull requests

1 participant