Open thegreatfatzby opened 5 months ago
Thanks @thegreatfatzby. Sorry about the delay.
BrowserSignals
in ProtectedAuctionInput is what browser sends from device.
Note: Since the browserSignal is not constructed on browser but in B&A, we had to name the arg sellerReportingMetadata for reportResult and buyerReportingMetadata for reportWin respectively; bidMetadata for scoreAd(), deviceSignals for generateBid()
Reporting: The constants are defined here for reporting. You may also refer to event level reporting explainer.
scoreAd():
generatebid()
In general, B&A doesn't have parity with on-device yet. E.g. Dataversion and so on would be available by Jan 2025 (when Chrome - B&A API ramps to 100% and B&A is available for scale testing) as documented in the roadmap.
Been digging around the protos to try to understand Protected App Signals a bit better, but noticed something in Protected Audience relevant protos.
Looking at the Browser signals protobuf here, I'm seeing a subset of the fields that are available on device in the call to generateBid.
The on device list includes
topWindowHostname, seller, topLevelSeller, requestedSize, joinCount, recency, bidCount, prevWinsMs, wasmHelper, dataVersion, adComponentsLimit, multiBidLimit
, whereas the BA PB forjoin_count, bid_count, recency, prev_wins
, withpublisher_name
indicated in other messages as being for the signals (although I'm not clear what that maps to).Are the docs just behind here, or is the current thinking that the BA version of generateBid will have less signals available? In that case I'd also be curious how generateBid would invoke the WASM helper if the WebAssembly.module isn't passed in (I understand the module can't be in the request to BA itself).