Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interest group ownership construct missing for Third Party Ad servers whitelisted by Advertiser #924

Open
singht-jivox opened this issue Nov 21, 2023 · 4 comments

Comments

@singht-jivox
Copy link
Contributor

Current workflow (prior to privacy sandbox) :

Third-party ad serving is an approach where Advertisers utilise services of a third party vendor to generate ad tags (which can serve dynamic creatives) and share across those ad tags to DSP (tag trafficking). DSP stores and serves an ad tag (tag = snippet of HTML) in place of the ad. The tag is sent to the client, which then executes the HTML and retrieves the actual ad from a third-party.
Essentially, the bidding entity (DSP) is different from the creative serving entity(3rd party ad server) while advertiser utilizes them both.

New workflow (post privacy sandbox)

In the new workflow (retargeting via Protected Audience API), ownership of Interest Group is indirectly always granted to DSP (thanks to the reliance of Advertisers on DSP for bidding logic). The call to registerInterestGroup has both the placeholder for creative (renderUrl as substitute for 3rd party ad tag) and bidding components (interest group name,owner,biddingLogicUrl) in the same payload so there's no way for an advertiser to specify the renderUrl separately.

Gaps :

  • An advertiser cannot serve dynamic creatives from third party ad servers/urls in this case and has to rely on static creatives uploaded on DSP platform.
  • The current API assumes that the DSP owns the protected audience. If the advertiser uses more than one DSP, then each DSP will need to create and maintain these protected audiences.
  • Having the advertiser own the protected audience also allows better control of sequencing across DSPs. This has some useful downstream benefits too, in terms of comparing performance when multiple DSPs are involved at an advertiser.
  • In addition, consent is provided by the browser user only to the advertiser and not to the DSP or the ad server directly. Hence, it makes better privacy sense to allow the advertiser to own it and have them control access via appropriate white lists.

Proposal :

  • For third party ad servers to continue to function post GPS update, IG ownership construct needs to be revisited so that the creative url can also be externally provided by the advertiser.
  • The binding of renderUrl for an Interest Group should stay with advertiser(or/and whitelisted entities) aka the true owner and be decoupled from other bits required to participate in the auction viz. bidding logic etc where DSP(whitelisted by advertiser) is always the sole owner.
@michaelkleber
Copy link
Collaborator

I don't think I understand the division of responsibilities that you're trying to achieve here, and I'm having trouble even asking the right clarifying questions. Would you consider coming to one of our weekly video calls for an interactive discussion to help clarify the problem? Logistic details in #88.

To be concrete, here is a proposal that I'm sure doesn't meet your needs, but I don't know why it doesn't: The DSP performs its bidding job and uses a rendering URL of the form https://dco-vendor-like-jivox.com/advertiser_id=123&campaign_id=456. Now bidding is controlled by the DSP and rendering by the third party. The advertiser can interact with either party to change how the ad campaign's bidding or rendering work.

I look forward to better understanding your goals.

@AmitGuptaCodeLab
Copy link

Hi @michaelkleber - I believe there are bunch of clarifications requested here on the end-to-end workflow:

  1. Outlining the players involved:
  • Advertiser (shopper.com) who is the brand looking to host ad for the products listed on website.
  • DSPs (dsp1.com | dsp2.com) who are the primary DSPs engaged by shopper.com to serve their ads.
  • Publisher (sports-news.com) who hosts the placements|ad slots where ad will get rendered post on-device auction.
  • ThirdPartyAd-Server + DCO vendor (dco.com) who is responsible for serving the retargeted dynamic creative based on protected audience or interest group captured.
  1. Workflow:
  • A user comes on advertiser site(shopper.com) and adds one of the listed product to the cart.

  • On that user action, advertiser registers the interest group (IG) against the added product to the user browser. Let's call it "listed-product-ig" ("name" in IG JSON).

  • Query 1: During the interest group registration process, assumption is owner of the interest group is "shopper.com" and not "DSP-1" or "DSP-2", is that correct? If it is not, then how can same interest group be served by multiple DSPs?

  • Query 2: Advertiser might or might not have renderURL or the creative tag at the time of registration of IG. Could be that "shopper.com" is still trying to figure out the campaign strategy, etc. In such case, how does delayed updation of "renderURL" in the interest group works? Assuming that there is some way to perform this update.

  • Query3: Advertiser has whitelisted DSPs (DSP-1 and DSP-2). I think the workflow is clear when a DSP is the owner of interest-group. In that case, IG gets registered by the advertiser with DSP as the owner. With auctionConfig defined by publisher ("sports-news.com") listing DSP-1 as the buyer, DSP-1 will participate in bidding for placement|ad-slot (on-device auction) and will pick one of the creatives from DSP-1 with the highest rank (based on dimensions, priority signals, etc). Winning bid contains creative (renderURL) as well. Is there a way to pass IG information in renderURL? Does it always have to be 1x1 relation between renderURL and IG? How does DSP-2 participate here for bidding on the same interest group?

  • Query 4: Establishing corollary to the current workflow, where tags|creatives|renderURLs (with the data passbacks) gets generated by ThirdPartyAd-Server (dco.com) and are given to Advertiser (shopper.com) for trafficking on the DSP1.com with the selected audience. In the privacy sandbox construct, Tags|renderURL|Creatives (one and same thing) gets generated by dco.com and gets pushed to Advertiser (shopper.com) who then either manage renderURL specification itself or hire tech partner to do the same. Is it expected from shopper.com to update JS hosted on their website for IG registration with any new tags generated for them OR shopper.com still has some way to work with DSP-1 to publish the creatives post selecting the targeted audience?

  • Query 5: As a ThirdPartyAd-Server (dco.com), we are looking for a way to leverage interest group information to display more relevant ads to the end-user maintaining the privacy restrictions listed in the spec. Will be useful in the case where same creative|ad-tag is registered as renderURL for multiple interest groups and the decision to show the relevant creative variation is delayed till the render time, if dco.com receives interest-group information with renderURL. We believe contextual retargeting will continue to work for some more time even after Q3-2024.

@shankar-jivox
Copy link

shankar-jivox commented Dec 6, 2023

@michaelkleber - Adding a few more clarifications to what @AmitGuptaCodeLab has detailed as the DCO use case.

  1. Advertiser (shopper.com) is running ads for their products they sell and is ideally the owner of the proitected audience.
  2. The problem that we are trying to get addressed in the workflow is that the advertiser is expected to have a campaign strategy, bid strategy, creative strategy, and related constructs in place when registering an IG. But an IG, by definition, is just a group of browser / device instances with certain behaviors on the advettiser site, that the advertiser would like to target for ads. How that group gets used in campaigns could come later. Usually IGs (aka retargeting audiences) are a slow moving data set, while campaign and creatives are more volatile.

Your proposal is coming close to what we would like to see. We would need one of the following:

  1. A parameter trhat tells us the interest group that the dsp is bidding on - https://dco-vendor-like-jivox.com/advertiser_id=123&campaign_id=456&**signal=interest-groups**
  2. Interest groips are available in the http header for us to look into before deciding on the creative to serve.
    Either of the above options would need the advertiser as the owner of the IG to whitelist the domaon dco-vendor-like-jivox.com

@TheTamFamily
Copy link

Combining with this issue - privacysandbox/privacy-sandbox-dev-support#201

The problem in a nutsell, can be summarised as:

User A and user B goes to Advertiser TopShoes website. Both users will be placed in the same interest group named "shoes". However user A will see "boots" and user B will see "trainers" as the image. The same ad creative is able to render the different images and since there cannot be any logic within the ad creative how is it possible to show "boots" to user A and "trainers" to user B?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants