Overview

Here we show the ability to onboard data for a previously recognized user of a site we have a relationship with (presumably 1st party relationship for these purposes but not necessarily), without tying the data to any identity other than the original authenticated one.

Jump straight to the test.

Prereqs

Have your chrome setup for PS testing.

Goal

With the progressing reduction of cross partition identifiers, one activity that becomes much harder is data onboarding, either directly targetable data or data used for inference. Being able to maintain some degree of onboarding without re-identifying users across context, for either the til 2026 period or after, would provide a useful glide path as we figure out more fundamental changes to the eco-system.

Solution Overview

At a high level we demo the ability to onboard non identifiable data from varied contexts to a previously recognized "anchor/account/stable ID" without using the users identity in that context. The solution involves a persistent event_log, an onboarding function that can be invoked generically on any page for event onboarding, and visits to three sites, one in which the user is recognized as "authenticated", the other two in which the user is not, but there is tech on those pages that we either directly own, or have a common supplier of.

Test

Overview

For the purpose of this demo we'll use our domains as follows:

• privacy-sandbox-testing-one.com will be the site the user has a relationship with. This is where we'll "authenticate".
• pst-advertiser.com and pst-publisher.com will be the sites that we go and visit afterwords for some special product and special offer, where we'd like to onboard data.
• pst-dsp.com will be the common tech provider. Onboarding.js is loaded from its domain.
• Here we assume a strongly coupled relationship between privacy-sandbox-testing-one.com and pst-dsp.com, as this simplifes a number of things conceptually, as the "tech provider" is in effect hardcoding the "authentication domain". Since this matches some cases, it's a fine place to start; more interesting ideas can be explored.
• We use onboarding.pst-dsp.com so as to separate these IGs from any IGs pst-dsp is keeping for other purposes.

Steps

At a high level, we'll authenticate on our main site (the one , visit some other unrelated sites, and then see onboarded data related to activity on those other unrelated sites but tied to the authenticated ID on the first site.

Let's proceed:

1. First we clear and then view the event_log table to start from a clean state, no tricks!
2. We then visit the login page of our identifying site where we "authenticate". The authentication drops an Interest Group, that will live on the browser for up to 30 days, and which we can recognize as an "onboarding" IG. To keep it separate from our data IGs and not eat into our limits there, we'll use a different subdomain as owner, in addition to the type filtering. In particular, we'll include the ID in the trustedBiddingSignalsKeys, which in this case will be a random "account ID" we create on "login".
   You can see the client side login and IG dropping code for this step in the PST DSP onboarder library and then the PST One login code here.
3. We then visit the unrelated advertiser site for some special product. We drop an IG in the same owner, let that finish, and then run an auction which triggers the call to the buyer KV service with the info. Note that the account ID generated in step 2 is not included on the link to the advertiser page, so we are not passing the ID around; the information is stored in the browsers IG storage and then activated via the auction.
   You can see the code that joins the IG and activates the data for onboarding here
4. We then visit some other publisher's special offer page, which is different but will call the same onboarding code.
   Same as step 4, can see the code that joins the IG and activates the data for onboarding here
5. The server then records the event, and we visit the event log page to verify the activity was recorded for further analysis.

Results

You can see expected results here.

Scope and Limitations

Scope

As alluded to this specific solution is hardwired for a case where the tech provider and the authentication provider and data onboarder share a strongly coupled relationship. The ideas here can support a more loosely coupled relationship in which things would be more configureable, which we can look to demo in another page.

Limitations

The time limit is 30 days after the user's last visit. This is the "simple" version, in which we do not make an attempt to decide whether it's worth sending the request in. Further demos will work on that.

The primary long term limitation is that this solution will no longer work when the BYOS KV features is removed from Fledge, no sooner than Q3 2025.