• Home
• About
• Chrome Setup
• Glossary

Post View Conversions on Contextual Wins

Test Home

Overview

Here we go over a solution that will help us maintain the current functionality we have for post-view conversions, during the "intermediate sandbox" stage.

Prereqs

If you are unfamiliar with post view conversions or the difference between contextual and private wins, start here.

Also make sure you have your chrome setup for PS testing.

Problem

With 3PCD we no longer have a consistent identifier to use across sites in the same browser. ARA provides some of the functionality we need, but does not provide a solution that gives us an immediate, event level, and un-noised signal, which is needed for CPA billing.

Goal

The goal for a solution is to be able to join one or more AuctionTargets, in this case the impression that a user saw, to a ConversionTrigger, i.e. a purchase, immediately, at event level granularity, and without noise. We also must not link any identifiers, assuming the AuctionTarget and ConversionTrigger are in different sites.

Solution Overview

This solution relies on:

• BYOS KV feature which exists until >= Q3 2025
• Fledge Auction Framework coalescing all IG trustedBiddingSignal requests into a single call

The steps at a high level are:

1. Register an IG with the relevant auction information on win.
2. Register an IG with the relevant conversion information on conversion.
3. "Activate" the IGs from the first two steps by running an auction which includes only those two.
4. The auction results in a single call to the IGs KV service with the relevant auction and conversion information, which can then be joined as normal with the original auction information.

Test

Overview

See domain structure to understand the domains used here.

Steps

Let's walk through the test. As you go through the steps and click the links, they will open in new tabs. The new tabs will give their own descriptions of what they are doing and display test results as makes sense.

1. Setup: First we Clear the DSP data Pipeline, which will result in a redirect to the imp and pixel log viewer, which should show no entries for impressions or pixels, so we start with a clean pipeline (no tricks!).
2. Publisher Page - Contextual Auction: Next we hit the publishers content and begin with the contextual auction. Code on page starts by creating a client_request_id to unify any auctions occurring on the page, contextual or private. Each contextual auction will create it's own auction_id. These will be our join keys for the AuctionTarget and ConversionTrigger.
   
   In this case the publishers 1PD and contextual signals are so good that the winning bid of the contextual auction bids high enough that the private auction won't be run. The BidResponse includes the winning creative, the auction ID, and a pixel that the winning line item is tracking to. (Note, that this test applies equally to a case where the private auction is run but the contextual bid wins anyway).
You can see the client side JS running this step here, look for "step 2 begins here".


3. Publisher Page - Rendering: Publisher code on page then:
   1. Renders creative in a normal iframe (remember this is a contextual win, not a private win so no opaque if/ff needed).
   2. Sends impression render tracker to the DSP data pipeline, which you can see (here).
   3. AND drops an Interest Group that contains the auction ID and pixel ID (other meta-data as well but ignore that for now), which we will connect on the advertiser page via pixel ID when the "pixel drops".
   4. For the purpose of this test, we will also store IGs for "other pixels", to show that the appropriate filtering to a single pixel IG is not merely the result of only 2 IGs being registered.
   Again you can verify that the "state of the pipeline" has the corresponding imp tracker log but no pixel logs.
   You can see the client side JS running this step, including AuctionTarget IG creation here, look for "step 3 begins here".
   
   
4. Advertiser Page - Conversion Time: We then visit the advertisers site and click the "buy and pay money" button for the advertised product. That button is attached to a pixel, that just so happens to be the one attached to the winning creative from step 1. The code on page then does two things in order:
   1. Drop an interest group with the pixelID (and other useful metadata).
   2. Run an auction that invites the 2 IGs for this pixel we've mentioned so far (the impression based one from the publisher site and the pixel based one from the advertiser site).
   3. That auction with those 2 IGs results in a call to the DSP KV server with information from those two IGs, which forwards that log to the DSP data pipeline. We can see them together here, which could then be used for transaction resolution.
   You can see the client side JS running this step, including ConversionTrigger IG creation and ConversionTrigger "Auction" here.
   
   
5. Tear Down/Clean Up: Finally we leave the "ConversionTrigger" IG to preserve our browser side resources, and keep things clean in general.
   You can see the client side JS running this step in the last line here.
   
   

Results

You can see expected results here.

Scope and Limitations

Scope

• As indicated ^ this solution will only apply for a contextual win. A private win will require more footwork due to the rendering inside of an iframe with an opaque src or Fenced Frame, making information passing a bit more difficult. See here for details.
• It can work for cases where the SSP and DSP are not the same entity, although the demo and protocol for making that happen will need some thought.
• The demo is set up for a single tag page but the approachwill work for multi tag pages, i.e. a case where we wanted to do this for multiple auctions on a page. Some additional footwork may be needed in that case, to be explored. Also be aware that multi tag support remains logistically challenged by fledge design.

Limitations

See here for details on limitations of this solution.

Further Details/Ideas to Consider

See here.