Multi-touch conversion Attribution
- Overview
- Scope
- Demo
Overview
Description
Marketing attribution is a method used by advertisers to determine the contribution of marketing tactics and subsequent ad interactions to sales or conversions.
There are various types of attribution models, including first-touch and last-touch attribution, which are single-touch attribution models. Single-touch attribution models assign 100% of the conversion credit to a single touchpoint in the customer journey. In first-touch attribution, the credit is assigned to the first touchpoint. While in last-touch attribution, the credit is assigned to the last touchpoint before the conversion. Attribution can also be shared across multiple touchpoints in the customer journey, where credit is distributed among the different touchpoints. This is called multi-touch attribution.
Privacy Sandbox APIs
Related parties
- Publishers
- Advertiser
- DSP
Scope
Goals
In this demo, we assume that the AdTech wants to calculate multi-touch attribution based on nodes (separate aggregate contributions for each impression touch point). Which means that on a per conversion basis, the AdTech (DSP) is capturing the purchase amount and a credit fraction for the publisher (e.g. $100: 50% to "publisher 1", 25% to "publisher 2" and 25% to "publisher 3"). With this information, AdTech can optimize their campaign by bidding more frequently and/or with a higher amount for a specific publisher in the future.
To keep this example simple, during the conversion, we will divide the purchase amount (budget) equally between all sites that displayed this ad/campaign. However, you can also use a similar implementation if you want to calculate it based on path. In this Multi-Touch Attribution article, you can learn more about these two different strategies and decide which one is the best for you.
This demo uses the Shared Storage and Private Aggregation APIs, as they enable the data capture and aggregated measurement of multiple touchpoints on a single browser.
Key Exclusions
To focus on the measurement aspect of the multi-touch attribution use-case, we will be simplifying the setup by rendering an ad directly without integrating the delivery via the Protected Audience API.
The custom logic for multi-attribution touch calculates the budget based on nodes but the user can change it to use path or any other strategy based on their needs.
System Design
-
User sees an ad on "news site" → Adtech stores context from the ad view in Shared Storage along with other dimensions for the user including the impression timestamp.
-
User sees another ad on "travel site" → Adtech stores context from the ad view in Shared Storage as earlier.
-
User converts by making a purchase on the "shop site" → Adtech can reference the context stored in Shared Storage to generate a custom attribution report using the Private Aggregation API.
- In this demo, the AdTech chooses to represent the impression touch points as singular nodes and each node will be represented in the 128-bit aggregation key (aka bucket) along with a campaignId and a Publisher ID.
- So, the AdTech can reference the impression context in Shared Storage to distribute credit across the impressions. For example, 50% to the most recent impression and 50% divided equally for all other impressions.
-
AdTech batches the received aggregatable reports and processes them with the Aggregation Service which returns a summary report.
User Journey #1
Demo
Prerequisites
- Chrome > v129 (Open chrome://version to look up your current version)
- Clear your browsing history before you run one of the demo scenario below (Open chrome://settings/clearBrowserData to delete your browsing history)
User Journey #1
-
Navigate to news site (Publisher 1) and observe the ad served on the news site
-
Navigate to the soccer site (Publisher 2) and observe the ad served on the soccer site
-
Navigate to shop site (Advertiser), select a shoe, add to cart and click on the checkout button
-
Navigate to DSP service report visualization page
- On this page you can see the aggregatable report sent by the browser to the DSP. In a production environment, the aggregatable report is encrypted by the browser and sent to the DSP. There, they will be batched and sent to the Aggregation Service where they will be aggregated and noised to preserve privacy. However for development and testing purposes, you can also send an unencrypted version called debug report. This is what you are seeing now.
- The report shows aggregation data in 1 dimension : purchase amount divided between each publisher in each campaign.
Implementation details
<script src="https://privacy-sandbox-demos-dsp.dev/js/mta-conversion-tag.js" ></script>