You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Putting forth an issue which affects third party ad servers/DCO (Dynamic Creative Optimization) vendors like Jivox to achieve the re-marketing use case in the new model.
Context :
Per the protected audience spec (https://github.com/WICG/turtledove/blob/main/FLEDGE.md#11-joining-interest-groups), the DSP whitelisted on the advertiser site (driven via .well-known) will be responsible to register the interest group. Since, the renderUrl is also part of the request payload/json under ads metadata along with other info like interest group name, owner, biddingLogicUrl, trustedBiddingSignals etc., effectively DSP controls this entire flow including binding the creative to IG.
In today's world, the role of DSP is to enable the advertiser to leverage third party ad servers/tags so dynamic ads can be served to targeted audience however with Protected Audience API, advertisers no longer have a direct hook to inject external renderUrl(ads metadata) while registering the interest group with DSP as the owner.
When we reached out to a few testing partners listed at https://github.com/WICG/turtledove/blob/main/fledge-tester-list.md, it appears this use-case isn't being considered at all so we have to be 100% reliant on multiple DSPs and coordinate with them to make desired updates to get the interest group name with the final renderUrl call post the bid is win.
Ideally, if the Protected Audience API itself is able to cater this use-case in the workflow design, it would help all third party ad servers/DCO partners in the ecosystem.
We do have updateInterestGroup as one option but again that is within DSP's purview and will again hinge on all the DSPs implementing the same and exposing an interface for advertisers/third parties enabled by advertisers.
Proposal :
The third party ad serving URL should be able to get IG context primarily interest group name (in the request header?) corresponding to the IG that won the auction.
This will enable DCO vendors to not rely on individual DSPs to map/retrieve IG name for trafficked tags.
Since, the renderUrl is being registered by whitelisted domain, sending the IG name info while hitting the url should not be classified as data leakage (probably redundant from DSP point of view but very much required from 3rd party AdServer perspective)
The text was updated successfully, but these errors were encountered:
I don't think we can make the change you propose. As a privacy protection, the render URL is required to be k-anonymous. But there is no such requirement for Interest Group names — it would be perfectly possible for an advertiser to place each user into an IG whose name was that advertiser's unique customer ID for the user. Revealing that at rendering time would constitute a tracking risk.
I think the right answer here is to perform the "dynamic ad selection" step either at the time the renderURL is placed into the Interest Group, or inside the protected auction when the ad is being chosen.
I do understand that doing it post-auction at render time is more familiar. But with Protected Audience there is simply less information available at rendering time, very deliberately — because anything made available during rendering may escape the browser and may become a tracking mechanism.
@michaelkleber Thanks for the response and feedback on the above.
Agreed that Protected Audience construct is aimed to keep the topics anonymous at the time of ad rendering however wrt "I think the right answer here is to perform the dynamic ad selection step either at the time the renderURL is placed into the Interest Group", advertiser has a challenge to provide a third party(external) renderUrl directly without bringing DSP(owner of IG name and bidding logic) into the picture. Explained in detail here : #924
would you have suggestions around how does Protected Audience API enable the advertiser to inject the renderUrl separately from rest of the IG json viz. owner,biddingLogic, trustedSignals which need to be registered by a DSP in adtech realm.
Hi team,
Putting forth an issue which affects third party ad servers/DCO (Dynamic Creative Optimization) vendors like Jivox to achieve the re-marketing use case in the new model.
Context :
Per the protected audience spec (https://github.com/WICG/turtledove/blob/main/FLEDGE.md#11-joining-interest-groups), the DSP whitelisted on the advertiser site (driven via .well-known) will be responsible to register the interest group. Since, the renderUrl is also part of the request payload/json under
ads metadata
along with other info like interest group name, owner, biddingLogicUrl, trustedBiddingSignals etc., effectively DSP controls this entire flow including binding the creative to IG.In today's world, the role of DSP is to enable the advertiser to leverage third party ad servers/tags so dynamic ads can be served to targeted audience however with Protected Audience API, advertisers no longer have a direct hook to inject external renderUrl(ads metadata) while registering the interest group with DSP as the owner.
When we reached out to a few testing partners listed at https://github.com/WICG/turtledove/blob/main/fledge-tester-list.md, it appears this use-case isn't being considered at all so we have to be 100% reliant on multiple DSPs and coordinate with them to make desired updates to get the interest group name with the final renderUrl call post the bid is win.
Ideally, if the Protected Audience API itself is able to cater this use-case in the workflow design, it would help all third party ad servers/DCO partners in the ecosystem.
We do have
updateInterestGroup
as one option but again that is within DSP's purview and will again hinge on all the DSPs implementing the same and exposing an interface for advertisers/third parties enabled by advertisers.Proposal :
The third party ad serving URL should be able to get IG context primarily interest group name (in the request header?) corresponding to the IG that won the auction.
This will enable DCO vendors to not rely on individual DSPs to map/retrieve IG name for trafficked tags.
Since, the renderUrl is being registered by whitelisted domain, sending the IG name info while hitting the url should not be classified as data leakage (probably redundant from DSP point of view but very much required from 3rd party AdServer perspective)
The text was updated successfully, but these errors were encountered: