Targeted Advertising
This data used to target ads often starts off as personal data when it is collected from a consumer. The data may then be converted into anonymized data by replacing personal details (such as name and contact information) with anonymous identifiers, which may then be shared between different ad tech and data suppliers.

Sample sequence of data flows

In a simplified example involving one automated auction operated by the SSP, the following ad targeting and ad verification data flows may take place.
  1. 1.
    Before an auction takes place, the advertiser may provide their first-party data to their data management platform for use in targeting ads.
  2. 2.
    Third party data providers might also be contributing third-party data to the advertisers' and publishers' data management platforms to help with targeting ads on both the buy-side and the sell-side.
  3. 3.
    When a consumer visits the publisher's website, a bid request is sent from the website to the publisher's supply-side services.
  4. 4.
    The SSP then contacts their data management platform (if using one) to match the IDs and data in the bid request to data in the publisher's database. This will inform its decision on how to price the ad impression.
  5. 5.
    Once the SSP sets a price floor, it then sends a bid request to the DSPs to seek their bids for the ad impression.
  6. 6.
    DSPs contact their own data management platforms to look up the user ID and other data against their own databases, this time to decide how much to bid on behalf of the advertiser for the ad impression.
  7. 7.
    DSPs send their bid response to the SSP, placing its bid in the real-time auction.
  8. 8.
    The SSP runs a real-time bidding auction.
  9. 9.
    The SSP then communicates the bid outcome to the DSPs and the publisher ad server, who then pass it on to the advertiser and publisher.
  10. 10.
    The advertiser who won the auction sends the ad to the publisher website.
  11. 11.
    The website sends data on ad delivery and performance to the ad verification and attribution provider (e.g., how long the user looked at the ad or how long it was visible on the page for, whether the user clicked on the ad).
  12. 12.
    The advertiser sends through any additional data on attribution that it has collected on its end (e.g. whether the user actually bought an item).
  13. 13.
    The ad verification and attribution provider then uses this information to measure the performance of the ad campaign and reports this information to the advertiser.

Cookie syncing

For ad targeting to work well, consumers must be able to be consistently and accurately identified throughout the ad tech supply chain. This generally would involve a single consumer being identified by both SSPs and DSPs as being that same single consumer. However, this can be difficult given the number of different ad tech providers involved.
For example, a consumer may be browsing on an advertiser's website and the advertiser wishes to re-target that consumer. The consumer continues to browse the web and visits a publisher website where an ad opportunity is presented. Assuming the advertiser's DSP and the publisher's SSP are owned by different companies, each one would have been assigned a different unique identifier (commonly a "cookie") to the same consumer. As such, there is no ability for the DSP and the SSP to know that this is the same consumer and strike up a deal for the ad being re-targeted to the consumer. In this scenario, a data sharing process (known as cookie syncing) would assist the DSP and SSP in identifying this consumer in the same way.
In a basic sense, cookie syncing involves a number of ad tech providers agreeing to share their unique identifiers with one another. Using matching techniques, a consumer identified as Consumer A in one DSP, and Consumer B in one SSP, could then be identified as Consumer 1, or any other name.
The disadvantages of this technique are that it is not accurate all the time, and additional time is spent completing the cookie matching process during each transaction. If a DSP takes too long to return a bid to the SSP due to time spent cookie syncing, that DSP may time-out and would not be able to submit a bid in time on behalf of the advertiser for that ad space.
From Clearcode:
Here’s a step-by-step overview of how it works:
  • A user visits a website that contains an ad.
  • The DSP receives the ad request.
  • The DSP sends back the request and creates a third-party cookie.
  • The ad exchange redirects (http redirect) the ad request to the pixel URL on the DMP’s side, passing the user ID in the URL parameter. The DMP reads its own cookie, or creates a new cookie, and then saves the user ID passed from the DSP along with its own user ID in the cookie-matching table.
  • If the sync is bidirectional, the DMP makes the redirect back to the DSP, passing its own ID in the URL parameter. The DSP receives this request, reads its own cookie, and stores the DMP ID along with its own ID in the cookie-matching table.
  • Now, both the DSP and DMP have each other’s’ user IDs in each other’s databases.
Last modified 7mo ago