does it make sense to have some of this code in a submodule, which might end up being extremely compact on initial commit, but would provide the convenient logical abstraction that a user would pick the PAAPI submodule associated with their choice of TLS?

I think so yes. A pub makes 2 decisions.

1. I want to run PAAPI with prebid
2. I want to do it myself (pub sub module) or I want GPT to do it for me

this calls gam if paapi doesn't fill, correct? But PAAPI will always fill if we give it the best contextual bid from prebid as its best alternative? Is the below code basically saying 'Let's compete Prebid vs PAAPI, and if neither provide any ad call gam?'

I don't think we can give it the best contextual bid. Some bidders may decide to provide "extra" bids for it, but those don't necessarily contain all, or even the same, contextual bids, and Prebid can't control them.

That's auctionSignals.prebid.bidfloor no ? I don't know if all buyers take it into account, so it may still not fill even if everyone bid all the time and above the floor.

Anyway, I assume that deleting the <div> is what makes GAM skip that slot if it was filled by PAAPI. Is there a better way to disable the slot more explicitly and perhaps less permanent ? It's fine either way as a test page but I imagine it won't work if I wanted to periodically refresh the ads.

Yes, this is not a great way to render. I am not sure yet what the render API will look like:

• when using GAM, the use case I'm hearing is to run fledge only after GAM picks the Prebid contextual winner (to keep adx demand in GAM). In practice this would mean returning the URN back to the rendering logic running in the GAM creative (PUC or equivalent). The publisher would not call any rendering API but somehow enable this behavior.
• when not using GAM, the publisher calls renderAd(document, adId). We could do something similar and only "pretend" to render adId, rendering the fledge ad instead in a nested frame, if the publisher enabled the same behavior as above. Or we could provide separate runPaapi/renderPaapi APIs.
• I'm not sure there will be a use case for what's demoed here, only run gam if fledge has no winner. Pubs would probably prefer to let GAM run fledge and get better demand.

reference comparison to floor (or top prebid bid)

  var sellerSignals = auctionConfig.sellerSignals;
  var floor = sellerSignals.floor || 0;
  var modifiedBid = bid * 0.95;

  // temporary reporting: https://github.com/WICG/turtledove/blob/main/Proposed_First_FLEDGE_OT_Details.md#reporting
  const reportingBrowserSignals = {...browserSignals, bid, modifiedBid}
  const macros = '&winningBid=${winningBid}&winningBidCurrency=${winningBidCurrency}&topLevelWinningBid=${topLevelWinningBid}&topLevelWinningBidCurrency=${topLevelWinningBidCurrency}';
  globalThis.forDebuggingOnly?.reportAdAuctionLoss(
    buildReportURL('bid-loss', auctionConfig, reportingBrowserSignals) + macros);
  globalThis.forDebuggingOnly?.reportAdAuctionWin(
    buildReportURL('bid-win',  auctionConfig, reportingBrowserSignals) + macros);

  return {
    ad: null,
    desirability: (modifiedBid > floor && (browserSignals.bidCurrency == '???' || auctionConfig.sellerCurrency == browserSignals.bidCurrency)) ? modifiedBid : 0,
    allowComponentAuction: true,
    bid: modifiedBid
  };
}

citing my source ```https://privacysandbox.openx.net/fledge/decision-logic-component.js````

could we demonstrate calling a url in sellerSingals

eg

const reportingURL =
(sellerSignals.reportingURL || 'https://privacysandbox-reporting.openx.net/fledgeReporting')
+ '?'
+ Object.entries(params)
.filter(([k,v]) => v)
.map(([k,v]) => ${k}=${encodeURIComponent(v)})
.join('&');

return reportingURL;
}

Objects logged from worklets cannot be expanded after the worklet finished.
I usually do JSON.stringify() while skipping perBuyerSignals from the logged auctionConfig (too large). Is there a better way ?

should leave this out for component, I do not think it has any effect

Can make it fully local with

navigator.joinAdInterestGroup({
  name: 'prebid-test',
  owner: window.location.origin,
  biddingLogicURL: (new URL('buyer.js', window.location)).toString(),
  ads: [{
    renderURL: (new URL('ad.html', window.location)).toString(),
  }],
  adComponents: []
}, 600);

and a short buyer js

My intention was to make this as real-world as possible but I couldn't get any adapter that would both work and agree to be in here. Mocking openx' response was a compromise, hopefully temporary.

I was not sure if the demo needed to be self-contained. If so, the buyer can be local too, at a small cost of being slightly confusing to share a domain with seller. It's fine either way.

Mocking the openx adapter response is also fine - I was not aware this is possible so thanks for showing me how to do it :)

That's auctionSignals.prebid.bidfloor no ? I don't know if all buyers take it into account, so it may still not fill even if everyone bid all the time and above the floor.

Anyway, I assume that deleting the <div> is what makes GAM skip that slot if it was filled by PAAPI. Is there a better way to disable the slot more explicitly and perhaps less permanent ? It's fine either way as a test page but I imagine it won't work if I wanted to periodically refresh the ads.

reportResult should still be defined even if it does not do anything, to avoid

Worklet error: https://127.0.0.1:9999/integrationExamples/gpt/top-level-paapi/decisionLogic.js reportResult is not a function.

Could be something like this

function reportResult(auctionConfig, browserSignals) {
  log('reportResult', { auctionConfig, browserSignals });
  sendReportTo(`${auctionConfig.seller}/report/win?${Object.entries(browserSignals).map(([k, v]) => `${k}=${encodeURIComponent(v)}`).join('&')}`);
  return {}
}

that would replace it with an error about the report call failing :) I am already worried about people copying this demo into production so I'd rather avoid it; the plan is to work with @patmmccann to publish an actual reference implementation separately

Is this about the event url showing up as an error in the Network tab ? It's still useful to look at parameters, but if unwanted can comment out sendReportTo or make it conditional on something like sellerSignals.reportURL