• Home
• About
• Chrome Setup
• Glossary

Overview

Let's go through a demo of Bidding and Auction features in a Private Auction, in particular looking at the ability for advertisers to bid using their own data...

• Tied to an identity they had access to at the time of the user visit to their site...
• ...Even when the auction is not on their site...
• ...For potentially multiple IDs of different types, including not just device provided IDs like a CHIP or IFA, but a cross-device/channel ID such as an Industry ID like LiveRamp.

Jump to the test if you like.

Demo

Prereqs

As always visit the Chrome Setup for instructions on making this works for you.

Goals

The main thing we want to demonstrate here is the ability, even in Vanilla Fledge, for information from multiple sites to participate in an auction on an unrelated site despite the lack of browser provided link. While Fledge does not replace 3PC with either identity or data, it does give the means to activate identity and/or data in a Private Auction held on device.

Test Setup

We have a few ad tech entities we'll work with here:

• PST DSP: a DSP who works with advertisers to activate their buys. They have tech on page to integrate both with Privacy Sandbox tech and their server side data pipelines and stores, where they store targeting data.
• PST SSP: for the purposes of this test a pretty simple SSP that runs private auctions.
• RampedUp is an independent Identity Provider trying to create a privacy respecting but cross site identity and data solution that isn't entirely dependent on a walled garden. Publishers and Advertisers can integrate their authenticated users identifiers with RampedUp, and RampedUp will provide a privacy safe ID that can be used in auctions on other sites. (Note that I'm trying to get actual LiveRamp working here, for now I'm doing my best to simulate both the per-ad-tech encoding and deterministic matching).

As well as a few brands we'll interact with:

• Sports Advertiser, a newer Sports business that doesn't have any authenticated user relationships yet but is trying to get into the sports e-commerce game. They currently only have a website, available here. Maybe they'll build an app when they get more funding.
  
  Sports Advertiser manages their buys using PST DSP.
• Literature Advertiser is an established books business that has authenticated relationships with consumers that they want to leverage. They have both a website, available here, and an e-reader app that can be installed on phones and tablets. For the purposes of this demo we won't make an app, but we can simulate cross-device by opening a link in a different browser (we'll use FireFox, choose your own).
  
  Like Sports Advertiser, they have contracted with PST DSP as a buy side technology provider, but unlike Sports Advertiser they also have contracted with the Open Internet Identity Provider RampedUp, in order to be able to bid on impressions using their own data from different devices and channels, including inference algorithms they run offline and then batch upload data to PST-DSP (note that this demo doesn't do this part but its the same pattern as the cross-device RampedUp onboarding we show).
• News Publisher is a news site that gets lots of views and is trying to fund its journalism. It decides to use PST-SSP as it's technology platform for placing ads on it's site.

A couple of additional notes:

• In this demo we do not demonstate any RampedUpID translation, i.e. use the Literature Advertiser's RampUpID to map to another partner advertisers data, or even our own. The demo here shows how PII-based IDs, such as LR, UID2, StableID, etc, can be used in a Private Auction in a simple way. A further demo can show translation, although presence is the pre-req.
• All storage keys for this test, server or client side, are prefixed with VANILLABAAB_, no need to pay much attention to that.

Steps Overview

The overall idea is that we'll enter some Sports and Literature preferences while on page with the two brands, preferences which we won't have direct access to when we visit our News site; despite not having a direct browser supported link like a 3PC, or even a graph based link via some PII or probabalistic match, we will still see an ad on the News Site based on those preferences.

Steps

0. Clear State: first click here to setup a clean test. The handler will open new tabs that execute various cleaning functions, listed below and available for the paranoid/curious/unwilling-to-allow-pop-ups-from-this-site (right side of browser bar likely will give you the option to allow all, I'll try not to abuse your trust):
   1. Clears any data previously attached in the PST DSP Data Store for this demo.
   2. Clears client side state, including Local/Session Storage, Cookies, IndexedDb, and IGs, stored for: PST Sports Brand, PST Literature Brand, PST News Publisher, PST DSP, and PST SSP.
   View code:

   • Clearing links
   • DSP Pipeline Clearing endpoints and service code.
   • Local storage clearing (same for each domain)
1. Sports Brand, Preferences: First we visit Sports Advertiser, a sports related site. We are presented with a choice of our favorite sport. When we make our selection:
   1. Code from pst-advertiser-sports.com will be used to validate and store that value locally for future use (i.e. repopulating the form).
   2. Then code from PST DSP will be used to onboard your sport preference for use in advertising targeting by:
      1. Grabbing the VANILLABAAB_PARTITIONED_CHIP partitioned for the pst-advertiser-sports.com partition using the get-chip endpoint.
      2. Creating an entry for the sports preference attached to that ID in the DSP's data store.
      3. Creating an Interest Group:
         1. Owned by pst-dsp.com but with a name scoped to pst-advertiser-sports.
         2. VANILLABAAB_PARTITIONED_CHIP in the trustedBiddingSignalsKeys.
         3. A bidding function that will return the appropriate sport image if the auction it is participating in indicates some preference for sports.
   View Code:

   • Sports Brand code from 1a.
   • PST DSP client side and server side code from 1b.
   • PST DSP bidding function, and kv/update endpoints, from 1biii.
2. Literature Brand, Chrome Web Site Login: next we visit Literature Advertiser's Login Page where we login using our "username". The "login" code is owned by the Literature Advertiser, and once the "login" is complete it leverages code loaded from RampedUp (here represented by pst-identity-provider.com) to create the RampedUp Envelope and IDby:
   1. Matching the email to a RampedUpID.
   2. Encoding that ID as a RampedUp Envelope.
   3. Storing both the Envelope and ID in Local Storage for later use in the Sports Advertiser's website.
   4. Leverage PST DSPs RampedUp integration to onboard the user for later targeting in Private Auctions.
   View Code:

   • Literature Brand login.
   • PST DSP client side and server side code from 2d.
   • PST DSP bidding function, and kv/update endpoints, from 2d.
   • RampedUp JS API from 2a, 2b, and 2c.
3. Literature Brand, E-Reader Preferences, Chrome...BROKEN: Now we go to visit the E-Reader in Chrome but since it's designed for mobile it doesn't work, sad! Instead we'll have to use the E-Reader in our "mobile app".
4. Literature Brand, E-Reader Preferences, "Mobile App": So now lets login to the E-Reader "Mobile App" by opening Firefox and logging in at `https://ereader.pst-advertiser-literature.com/vanilla/basic-auction-and-bidding/ereader/login.html`, followed by visiting the preferences page at `https://ereader.pst-advertiser-literature.com/vanilla/basic-auction-and-bidding/ereader/book-preferences.html` so the E-Reader can know what books we like. When we make our selection
   1. Literature Brand E-Reader code will validate and store that value locally for future use (i.e. repopulating the form).
   2. Then the Literature E-Reader will use PST DSP's integration with RampedUp to onboard your book preference across devices and channels:
      1. Grabbing the RampedUpID from local storage using the RampedUp JS APIs.
      2. Creating an entry for the sports preference attached to that ID in the DSP's data store.
      3. That's it! Note no additional IG is, or even can be created, as we're in FF - the IG from our login on the Literature Brand's site from the previous step is enough.
   View Code:

   • Literature Brand preference code from 4a.
   • PST DSP client side and server side code from 4bii.
   • RampedUp JS API from 4bi.
5. News Publisher: Now we will visit our News Publishers site where we will visit pages that indicate different interest based on their context:
   1. Need move auction code to ssp file, lives in pub atm
   2. First we visit a sports related page. News Publisher encodes information in the Auction Config indicating that this is a sports related page, which inform the bidding functions of any advertisers participating in the auction. In this case Sports Advertiser bids very high because of the page context, and shows an ad specific to the preference you entered in step 1.
   3. Next we visit an article about a new book. News Publisher encodes information in the Auction Config indicating that this is a books related page. This informs the bidding functions of any advertisers participating in the auction, and so Literature Advertiser bids enough to win; we again see an ad related to preferences entered on another site, despite the lack of a linking identifier in News Publisher's space.
   View Code:

   • News Publisher sports article from 5a and books article from 5b, that kicks off the auction with the appropriate content category.
   • PST SSP auction running code.