CHIP
Syncing

Background Ideas

Let's explore some background ideas to motivate this.

Private Auction and Identity Syncing

In the current 3PC world we sync cookies between different ad techs to support interoperability between different players within an ad request. This helps a publisher reach more demand by allowing for a single identity from the publishers ad tech to be mapped to the identities for the same user in other DSPs, enabling those DSPs to bid in the auction using their data without sharing it fully with the SSP or other DSPs.

In the partitioned world we're entering, in theory we don't need cookie syncs to enable an ad tech to participate in the the private auction, as the IGs of all ad tech's are stored on the browser and can be invited to the private auction. This is a significant win in a sense, as if you hold the auction environment constant and ignore the loss of functionality, you can invite any DSP to the auction and they can use their own data without having to do cookie syncs. On its own, this is a significant win, as it can save a lot of traffic and storage, as well as complexity.

However we cannot ignore the issues and challenges, including:

• Duplicating code or logic from our normal server auction environments to the private environment, for both buy and sell side logic.
• The challenges with operating in the new private environment.
• The lack of flexibility with IG bidding, scoring, and reporting.

It would be quite ideal if we could avoid cookie syncing but, at least during the PS Transition Period, be able to avoid or mitigate some of the issues.

BYOS KV Hole

An interesting option available till >= July 2025 is to leverage the BYOS KV hole. The KV feature can allow arbitrary, non-re-identifying logic, to be executed on top of all of the IGs invited to the auction. In theory all IGs could be funneled to the same KV endpoint, which combined with the BidRequest IG pattern discussed here, would allow a pretty good approximation of an ORTB auction as it exists today.

Trying to Mix the Two

So, why not try to do both! Let's walk through a vanilla implementation of PAAPI for two DSPs and an SSP:

DSPs and SSP Setup

1. pst-dsp registers IGs using:
   • owner: https://igs.pst-dsp.com.
   • trustedBiddingSignalsUrl: https://igs.pst-dsp.com/buyer-kv
   • trustedBiddingSignalsKeys: the CHIP ID from the joining site, which can be used to look up segments or other user data.
   • biddingScriptUrl: https://igs.pst-dsp.com/bidding.js
2. pst-dsp-two registers IGs using:
   • owner: https://igs.pst-dsp-two.com.
   • trustedBiddingSignalsUrl: https://igs.pst-dsp-two.com/buyer-kv
   • trustedBiddingSignalsKeys: the CHIP ID from the joining site, which can be used to look up segments or other user data.
   • biddingScriptUrl: https://igs.pst-dsp-two.com/bidding.js
3. When interacting with a user on an advertiser or publisher site, the DSPs send the relevant signals (segments, let's say) to their data stores keyed on the CHIP.
4. pst-ssp runs its private auction:
   • invitedBuyers: [https://igs.pst-dsp.com, https://igs.pst-dsp-two.com]

Private Auction

1. pst-ssp calls navigator.runAdAuction() with the two DSPs invited.
2. The Chromium code finds all the IGs for pst-dsp and pst-dsp-two and then:
   1. Sends a request to https://igs.pst-dsp.com/buyer-kv?names=all_pstdsp_ig_names&keys=all_pstdsp_chips_from_its_sites.
   2. Sends a request to https://igs.pst-dsp-two.com/buyer-kv?names=all_pstdsptwo_ig_names&keys=all_pstdsptwo_chips_from_its_sites.
   Due to Chromium's coalescing of IGs into a single KV call, PST DSP and PST DSP Two each get all of their IGs in the call, which in turn due to the structure of the IGs from 1 and 2 above, and the CHIP based onboarding, results in a call to their KV server with all their CHIPs.
3. Inisde the BYOS KV code for /buyer-kv, the DSP can try to run it's bidding logic, and return values back to the generateBid function that can be passed through as the renderUrl and bid, based on it's current bidding logic.
4. The pst-ssp scoreAd function can now do a fairly simple scoring.

So what's the problem? This doesn't get you quite what you want:

1. The KV server call doesn't include the auctionSignals, so the bidding process can't really run in full.
2. The sellers logic doesn't really benefit from this, making it harder to respect publisher settings around ad quality, yield management, forex, etc.