TERN - Step 1: Feedback

TL;DR: TERN assumes that DSPs should bid directly into the browser, which is a change from how ad-tech generally functions today and results in more complexity. I believe that bids should be funneled through an SSP acting on the publisher's behalf, which is less disruptive while accomplishing the privacy goals of TurtleDove/TERN.

Long version Of the several challenges I see here, the biggest is an assumption that advertisers are primarily the ones setting interest group information. I think the utility of interest groups is maximized when they are a tool that can be used by anyone. In fact, I suspect that both publishers and marketers will be the ones to create IGs and that DSPs and SSPs will only be a conduit by which those are transmitted and transacted upon. Keeping the IG API separate from the ad fetching API yields a more flexible and simple system.

a. Faster delivery of ads

We combine writing interest groups along with the web bundles for ads. This means that, in principle, ads can be delivered nearly immediately after browsing away from the site.

True, but it assumes the second condition of:

b. Elimination of minimum interest group sizes

Since the browser is on the advertiser's site, its set of interest groups already can be known in full to the advertiser through first-party cookies, and thus there is no reduction in privacy.

This requires that the advertiser is also writing a cookie when it is storing IGs and said another way: there's no reduction in privacy because it can't be reduced below none. I think this is against the spirit of TD, though it does raise the issue of what to do when the party setting IGs is also a first party and could store that information elsewhere. In fact, I think this is probably a good argument for maintaining minimum interest group sizes.

c. Reduced networking

There's no particular need for the browser to make follow-up calls when it's already on the advertiser's site. This should reduce the amount of background network calls the browser will need to make.

This assumes that an IG bid would end up being eligible soon after stored. If the bid times out prior to the next fetch, then it was actually excess/wasted networking. Not sure this is a strong win.

It also leads to the complexity noted elsewhere in here when a bid isn't funneled to a publisher through an SSP.

d. Writing multiple interest groups

Rather than writing one interest group at a time, we can write multiple.

This is a fair point, though calling an API multiple times isn't the end of the world.

e. Multiple ad formats This seems valuable, though I think it should be done at the IG ad request time rather than through the IG API.

f. Ad categories and g. SSP tokens If IG bids require web bundles, then the SSP's job of doing categorization and ad quality just became MUCH easier because the ad content is static. This is great news and it also improves the experience of the publisher and protects the end user. As I noted in #76 I don't think we should attempt to change the existing ad-tech flow if it isn't directly related to improving user privacy (not because ad-tech is perfect- far from it). If the IG Bid Request goes to the SSP (like the contextual bid request) then the same machinery that works for ad quality and categorization will continue to work. It also remains consistent between contextual requests and IG requests. In this case, the DSPs would choose which SSPs they want to share their IGs with and then bid through the SSPs accordingly. No tokens/etc needed.

j. DSPs control bidding

Many DSPs prefer to control their own bidding logic;

I think every party in ad-tech would like more control over the bidding logic. Unfortunately, we are all constrained to having control at some layer and then ceding control to others at a higher layer. DSPs control the auction that they hold among all the demand they represent. SSPs control the auction that they hold among all the DSPs they represent. Publishers control the auction they hold among all the SSPs they represent (using Prebid.js most of the time). And Google controls the auction they hold among all of us (via OB, AdX, and line items activated by Prebid.js). As the publishers agent, SSPs should receive the contextual and IG ad requests, enforce ad quality/etc across them, and make the in-page choice of what bid to represent. They also need to consume the aggregate reporting data in order to present the publisher with a consistent set or reports on who bought their inventory.

This section feels a bit like a DSP land grab. An SSP could argue that fairness and transparency would be enhanced if a DSP simply registered all of their bids with an SSP at once rather than responding with one-of-many on any given ad request (with bid value manipulated who knows how in the process). But the DSP has a role in representing and optimizing for their buyers, which an SSP does not. And vice versa.

k. Preserving third-party tag functionality

it's important for auditing and providing some choice on the market for advertisers who may want to use analytics tools that are separate from the SSP and DSP responsible for showing impressions.

On the one hand, I couldn't agree more. Publishers and Marketers like to have third-party verification of what the selling/buying tools are telling them. On the other hand, in the new TD/TERN world, what those tools do will be restricted (I think) so the utility won't be as high. The browser is basically playing the role of enforcer at this point. Would a javascript running in a Fenced Frame be able to determine if it was viewable?

Perhaps by default the event for an Interest Group based bid would be aggregated and shared with all parties that have access to the interest group themselves, with an API like the one described available to extend access to Publisher or Marketer partners that need the information.

Apologies for the long issue. My goal is to respond to the proposal with an SSPs point-of-view, and in some cases play Devil's Advocate a bit.

@JoelPM I have a couple of comments:

This requires that the advertiser is also writing a cookie when it is storing IGs and said another way: there's no reduction in privacy because it can't be reduced below none. I think this is against the spirit of TD, though it does raise the issue of what to do when the party setting IGs is also a first party and could store that information elsewhere. In fact, I think this is probably a good argument for maintaining minimum interest group sizes.

This is a misunderstanding. First-party cookies are not changing. It is third-party cookies that are changing. This roughly means that the operators of a website I can still know about who is using their website and how. What is being disallowed is that site then getting to know things about their users browsing behavior elsewhere on the internet ("cross-site tracking"). The former type of data collection is not very controversial, while the later is often considered privacy violating though it powers much of ad-tech. The point is of this section is that while the person is browsing the advertiser's site, which can already know about that persons interaction with the site because of first party cookies, DSPs may as well be allowed to write interest groups of any size. This does not enable any of the privacy violating cross-site tracking that the privacy sandbox seeks to avoid.

I think the utility of interest groups is maximized when they are a tool that can be used by anyone. In fact, I suspect that both publishers and marketers will be the ones to create IGs and that DSPs and SSPs will only be a conduit by which those are transmitted and transacted upon.

I think this is already the case. For example, a publisher can also advertise so there is nothing to stop them from using the browser APIs that put people in interest groups. Similarly, I see no reason a company cannot play some of the roles of a "DSP" and some of an "SSP" at different times as it makes sense for that company.

I think every party in ad-tech would like more control over the bidding logic. Unfortunately, we are all constrained to having control at some layer and then ceding control to others at a higher layer. DSPs control the auction that they hold among all the demand they represent. SSPs control the auction that they hold among all the DSPs they represent. Publishers control the auction they hold among all the SSPs they represent (using Prebid.js most of the time). And Google controls the auction they hold among all of us (via OB, AdX, and line items activated by Prebid.js)... This section feels a bit like a DSP land grab.

I think you are confusing auction logic with bidding logic. Bidding logic is something that the DSPs control today. This is because the bids into the series of auctions you describe above are generated by DSPs on behalf of the advertisers represented by DSPs. TERN is not intended to be a land grab, but to preserve the ad-tech ecosystem we see today, quirks and all.

I believe that bids should be funneled through an SSP acting on the publisher's behalf, which is less disruptive while accomplishing the privacy goals of TurtleDove/TERN.

TERN explicitly allows the publisher (presumably via an SSP) to provide the auction logic. In other words, TERN essentially does allow bids to be funneled to an SSP acting on the publisher's behalf.

@mbowiewilson thanks for the feedback. Attempting to reply more-or-less in-line:

This is a misunderstanding. First-party cookies are not changing. It is third-party cookies that are changing. This roughly means that the operators of a website I can still know about who is using their website and how.

Yup, I get that 1st party cookies are unaffected (for now). What TERN pointed out, and then I highlighted, is that a first party can set IGs and also store the corresponding information in a cookie (or local storage). My interpretation of the spirit of TD is that IG information should not be associated with a user identifier, which means this behavior is a violation of the spirit even if it's not a technical violation of how the web works or will work.

a publisher can also advertise so there is nothing to stop them from using the browser APIs that put people in interest groups

Even when not advertising a publisher or third party may wish to put people in interest groups and then monetize those interest groups. I still maintain that the IG storing API and the IG ad request should be kept separate because you only benefit a very small use case by combining them.

I think you are confusing auction logic with bidding logic.

The term transition was intentional, but I see how that can confuse the issue. I agree that in a pure system a bid placed by a buyer would participate unaltered in a single global auction against other unaltered bids. And I can also understand why a buyer would desire that. Unfortunately, with the heavily tiered system that has evolved in ad-tech, bids get placed into an auction, the winner of which is then turned into a bid into the next auction. A bid is just an economic arrangement between two parties on how they will transact, so the control of the logic extends only between the two parties that have the agreement. The DSP may have originated the creative that a bid was associated with (and controlled the logic that dictated the value it was assigned in that transaction/auction), but I don't think it has a right to decide how that creative gets valued to parties further up the stream (so long as the terms of the original agreement/auction are maintained). If I agree to sell you a yellow Corolla for no less than $1500 and you then agree to sell it to Michael Kleber for $2000, that's your business, even though I would perhaps have wanted to sell Michael a green Civic for $1900 if I'd known he was in the market for an old but reliable compact car. I interpreted TERN to be asking for the ability to control value (the bid price/logic) in a transaction that it wasn't a first party in, but perhaps I misinterpreted the wording in that section.

Since we're on the topic, I'll raise this:

For sophisticated DSPs, the primary benefit of SSPs is the management of publisher networks, not collecting user signals or providing bidding algorithms. A discussion on this topic occurs in TURTLEDOVE Issue #37 - Clarification on Entities.

I think for any DSP, the primary benefit of an SSP is the supply of inventory ("the management of publisher networks" is a part of that). The auction logic/bidding algorithms exist to help the publishers fairly monetize their inventory since as TERN points out the DSPs don't need help "collecting user signals" (part of the reason we're having this conversation as an industry) and the comment also highlights the information asymmetry that exists between publishers and marketers which is why they (publishers) end up having as many people as possible compete for their inventory (albeit in a highly inefficient way).

At any rate, I appreciate the dialogue. No doubt I've gotten something wrong but hopefully we can start shaping one of these proposals into something that more people will get behind and we can make some progress. And if I'm taking myself or these proposals too seriously, let me know. :-)

First, I'll throw in my hat with the discussion you're having with Matt, and then I'll address the rest of the points in the original issue.

Yup, I get that 1st party cookies are unaffected (for now). What TERN pointed out, and then I highlighted, is that a first party can set IGs and also store the corresponding information in a cookie (or local storage). My interpretation of the spirit of TD is that IG information should not be associated with a user identifier, which means this behavior is a violation of the spirit even if it's not a technical violation of how the web works or will work.

Local storage isn't even required. When the pixel gets fired, the DSP can simply store the URLs the first-party cookie has visited in logs to build a profile. Since first-party cookie identifiers are unique per domain, we don't view this as privacy-violating, at least under the scope of what TURTLEDOVE/TERN are trying to accomplish, which is more about collecting broad, web-wide browsing behavior. Even then, such first-party tracking is regulated by such legislation as GDPR and CCPA.

Even when not advertising a publisher or third party may wish to put people in interest groups and then monetize those interest groups. I still maintain that the IG storing API and the IG ad request should be kept separate because you only benefit a very small use case by combining them.

Two points.

1) TERN allows for publishers to monetize their own IGs. I don't know why a publisher would want to use an IG as opposed to a first-party cookie mechanism, which seems simpler. However, in TERN, the publisher can take the IGs that it has for a given browser and pass them through to SSPs in the metadata object of the contextual request, as in Section 3a. Of course, this payload can be encrypted so that only DSPs that have paid for access are able to decrypt them.

2) On the NextRoll side, we're quite adamant that keeping the IG storing API and the IG ad request separate is extremely detrimental to the ad tech ecosystem as a whole, both for publishers and DSPs. This is for a few reasons: a) the graph presented in Section 1a, b) avoiding the steep dropoff in that graph while keeping things separate opens up timing attacks anyway, c) granular interest groups are useful for ad selection and product recommendation, and d) there's no gain in privacy by keeping them separate. We don't consider a potential drop of 40% of publisher revenues a very small use case. Also, smaller advertisers may have difficulty hitting minimum interest group sizes. While each of these advertisers is a small use case, merchant platforms such as Shopify, Yelp, Rakuten, Amazon, etc. are very large use cases when taken together.

That being said, we're open to other solutions, but we strongly believe that the problems raised need to be resolved to maintain a healthy ecosystem.

And I can also understand why a buyer would desire that. Unfortunately, with the heavily tiered system that has evolved in ad-tech, bids get placed into an auction, the winner of which is then turned into a bid into the next auction. A bid is just an economic arrangement between two parties on how they will transact, so the control of the logic extends only between the two parties that have the agreement. The DSP may have originated the creative that a bid was associated with (and controlled the logic that dictated the value it was assigned in that transaction/auction), but I don't think it has a right to decide how that creative gets valued to parties further up the stream (so long as the terms of the original agreement/auction are maintained).

When we talk about DSPs controlling their own bids, we mean controlling their bids at the tier in which they're participating. I'd say that we strongly feel that DSPs should never get charged more than what they bid, but any modifications of the bid in further tiers can be handled by the auction logic that is available to publishers and SSPs as described in Section 6a.

I think for any DSP, the primary benefit of an SSP is the supply of inventory ("the management of publisher networks" is a part of that).

The TERN document generally uses the terms "DSP" and "SSP" as roles not really companies. I think I still maintain that TURTLEDOVE/TERN drastically reduce the friction of a DSP company integrating with a set of publishers, and so I don't think the supply of inventory is much of a benefit anymore.

I believe that bids should be funneled through an SSP acting on the publisher's behalf, which is less disruptive while accomplishing the privacy goals of TurtleDove/TERN.

I hope I already addressed this in this post.

I think the utility of interest groups is maximized when they are a tool that can be used by anyone.

As stated, "DSP" and "SSP" are more roles. Yes, TERN allows for any interest to leverage the IG functionality.

I suspect that both publishers and marketers will be the ones to create IGs and that DSPs and SSPs will only be a conduit by which those are transmitted and transacted upon.

I'm not 100% positive, but I am very confident that many DSPs have a vested interest in generating IGs. For example, at NextRoll, we automatically set up segmentation for our clients, including segments generated by machine learning. Also, our clients specify the IGs they want to target, and we're responsible for implementing them. DSPs really should be a significant, non-trivial source of IGs.

In fact, I think this is probably a good argument for maintaining minimum interest group sizes.

I addressed this above.

This assumes that an IG bid would end up being eligible soon after stored. If the bid times out prior to the next fetch, then it was actually excess/wasted networking. Not sure this is a strong win.

The graph in Section 1a demonstrates that this is a strong win.

It also leads to the complexity noted elsewhere in here when a bid isn't funneled to a publisher through an SSP.

As stated, the bid gets funneled through the SSP's auction logic.

e. Multiple ad formats This seems valuable, though I think it should be done at the IG ad request time rather than through the IG API.

In TERN, it's done in both. The IG ad request is simply a less powerful version of using the IG API on-site.

If the IG Bid Request goes to the SSP (like the contextual bid request) then the same machinery that works for ad quality and categorization will continue to work.

This seems like it violates privacy. If the browser is repeatedly calling the same SSP with its different set of interest groups, then the SSP can construct a detailed profile of the user. I don't believe the interest groups should be escaping the browser. Actually, now that I think about it, that may also be a privacy hole with the separate IG ad request in both TURTLEDOVE and TERN.

I think every party in ad-tech would like more control over the bidding logic.

Hopefully I addressed this above.

On the one hand, I couldn't agree more. Publishers and Marketers like to have third-party verification of what the selling/buying tools are telling them. On the other hand, in the new TD/TERN world, what those tools do will be restricted (I think) so the utility won't be as high. The browser is basically playing the role of enforcer at this point. Would a javascript running in a Fenced Frame be able to determine if it was viewable?

Totally agree that things look they're shaping up into reduced functionality. Reporting is out of scope for TERN. I'm hoping we have a satisfactory resolution to it.

Andrew, thanks for the thoughtful reply.

I would very much prefer that the unix philosophy apply here and that an IG API be small and focused only on managing Interest Groups. My hope is that Interest Groups find utility outside of ad-tech (article recommender on a news site anyone? or maybe music recommendations in Spotify?). That being said, I understand what you're saying about the need for the ability to store bids very closely to the time of IG registration. Coupling IG management and bidding explicitly doesn't feel right to me, but maybe there's another option that achieves our shared goal of maintaining a healthy ecosystem.

I don't know why a publisher would want to use an IG as opposed to a first-party cookie mechanism, which seems simpler.

Because a 1P cookie only works on their site, where an IG could be used for audience extension or other similar use cases.

in TERN, the publisher can take the IGs that it has for a given browser and pass them through to SSPs in the metadata object of the contextual request

My understanding is that IGs only ever leave the browser via an IG ad request (which is how the browser enforces the privacy of the IGs). If that's the case, the pub would need to store their IGs in the cookie (as Matt noted earlier). I'd love to hear @michaelkleber's take on this, as I didn't think this type of behavior would be seen as okay by Chrome. I thought a contextual request was always meant to be ENTIRELY devoid of any IG information to prevent timing attacks of any sort.

On the NextRoll side, we're quite adamant that keeping the IG storing API and the IG ad request separate is extremely detrimental to the ad tech ecosystem as a whole, both for publishers and DSPs

As noted above I now understand why you're pushing for this, though I still strongly prefer an alternate solution that achieves the goal.

When we talk about DSPs controlling their own bids, we mean controlling their bids at the tier in which they're participating.

Got it, and I agree with this principle. I think the difference is related to the next comment:

I think I still maintain that TURTLEDOVE/TERN drastically reduce the friction of a DSP company integrating with a set of publishers, and so I don't think the supply of inventory is much of a benefit anymore.

This is one of our key difference points. I don't believe TURTLEDOVE addressed this at all. I believe TERN introduced the reduction of friction in the way it filled in the blanks where TD was ambiguous. This is my biggest issue with TERN. It's also why I said I felt like parts of it were a land grab.

The TERN document generally uses the terms "DSP" and "SSP" as roles not really companies.

I don't know if that's okay. I often think of ad-tech as being similar to real estate. As a home buyer, I want an agent who is focused on my needs and is vetting properties in line with my goals. As a home seller, I would want an agent representing my interests. Both sellers and buyers are working with someone who is incentivized to protect their interests. When one entity is doing both roles you lose this protection. Ad-tech complexities aside, I think this principle holds and is a valid argument for having the separation of roles into companies.

This seems like it violates privacy. If the browser is repeatedly calling the same SSP with its different set of interest groups, then the SSP can construct a detailed profile of the user.

What will the SSP be using to develop this detailed profile of the user? It won't be a cookie or similar identifier (we can argue about IP, but that is addressed by Privacy Sandbox as well). I don't think this is actually a privacy concern - particularly if only IG ad requests contain IG info (as I believe is the intent of TD).

To summarize, I think our biggest differences are philosophical: 1) the separation of APIs, 2) the availability of IGs outside of IG Ad Requests, and 3) the role of SSPs and DSPs and how TERN assumes things that I don't think TD does.

Thanks again for the good conversation, it helps me understand the different POVs and figure out where we align and don't.

I would very much prefer that the unix philosophy apply here and that an IG API be small and focused only on managing Interest Groups. My hope is that Interest Groups find utility outside of ad-tech (article recommender on a news site anyone? or maybe music recommendations in Spotify?).

Yeah, I'm generally in favor of the unix philosophy, but we're operating in a scenario where breaking apart the API into a bunch of separate chunks results in a lot more network calls, which can really drastically affect the user experience. The amount of network calls and their associated latency is one of the major reasons people use ad blockers, or publishers don't want to integrate with too many partners in header bidding.

I'm certainly open to additional use cases for IGs. Note that TERN doesn't actually require the submission of any ad data (let alone bid data) when writing the IGs. This is explicitly called out in the spec. Perhaps we could rename the writeAdvertisementData function to sound more generic.

Coupling IG management and bidding explicitly doesn't feel right to me, but maybe there's another option that achieves our shared goal of maintaining a healthy ecosystem.

Yup, we're open to other options if they achieve similar results.

Because a 1P cookie only works on their site, where an IG could be used for audience extension or other similar use cases.

I'm a bit confused by this. TURTLEDOVE (and TERN) both assume that an IG is namespaced to the first-party context. Could you elaborate a bit more about what you mean here?

My understanding is that IGs only ever leave the browser via an IG ad request (which is how the browser enforces the privacy of the IGs). If that's the case, the pub would need to store their IGs in the cookie (as Matt noted earlier).

Yeah, that's correct.

I'd love to hear @michaelkleber's take on this, as I didn't think this type of behavior would be seen as okay by Chrome. I thought a contextual request was always meant to be ENTIRELY devoid of any IG information to prevent timing attacks of any sort.

Well, in the TERN case, these are publisher IGs, not advertiser IGs that could be used in the contextual request. There's no real additional leakage of identifying information. In theory, the publisher could even send over their own first-party ID for the user through in this payload, but that's not particularly useful as it can't be paired with the first-party IDs that advertisers have. Heck, a publisher could even send over the email address of a logged in user. This seems unacceptable on the surface, but it's not really. The publisher could completely skirt the browser and in a backend server-to-server call reveal the timestamp, email address, and URL that one of their users generated on their site, and the SSP or DSP can then do a simple timing attack join to tie it with the contextual request anyway. There's no technical means of preventing this, but is covered by legislation like GDPR and CCPA. This is why I say there's no additional leakage in TERN.

This is one of our key difference points. I don't believe TURTLEDOVE addressed this at all. I believe TERN introduced the reduction of friction in the way it filled in the blanks where TD was ambiguous. This is my biggest issue with TERN. It's also why I said I felt like parts of it were a land grab.

I think it was under the surface in TURTLEDOVE. This was a large part of the discussion in https://github.com/WICG/turtledove/issues/37 . The way TURTLEDOVE intends to communicate with SSPs makes it easy for a DSP to start to take on the role of an SSP... if they're willing to put in the effort to do all the publisher management. I do agree that TERN makes this more concrete; this is why I wrote TERN to begin with.

We definitely feel strongly that there's not much point in putting the SSP in the middle of an IG request. The DSP isn't going to want to leak their segments to the SSP, so they're likely to encrypt everything. At that point, the SSP just becomes a forwarder; I don't see the benefit of doubling the traffic of IG requests on the internet.

I don't know if that's okay. I often think of ad-tech as being similar to real estate. As a home buyer, I want an agent who is focused on my needs and is vetting properties in line with my goals. As a home seller, I would want an agent representing my interests. Both sellers and buyers are working with someone who is incentivized to protect their interests. When one entity is doing both roles you lose this protection. Ad-tech complexities aside, I think this principle holds and is a valid argument for having the separation of roles into companies.

Well... TERN explicitly has a goal of trying to keep the ad tech ecosystem as similar as possible through the transition. Even today you have Google's AdX, but they also offer services for advertisers to buy directly through them instead of a separate DSP. Facebook is another example of a DSP/SSP combination. I don't disagree that separation of concerns can result in better market efficiencies, but that separation just doesn't exist today.

What will the SSP be using to develop this detailed profile of the user? It won't be a cookie or similar identifier (we can argue about IP, but that is addressed by Privacy Sandbox as well). I don't think this is actually a privacy concern - particularly if only IG ad requests contain IG info (as I believe is the intent of TD).

If the browser is calling the SSP directly, it's not just the DSPs' payloads that they'll have access to. For example, there's IP address (unless Willful IP Blindness becomes a thing). There's potentially a lot an SSP can do to build detailed profiles off of the other information in the packets (like header information) than just the IG payload.

Thank you @JoelPM for thoughtful perspective; I have a few follow ups.

I believe that bids should be funneled through an SSP acting on the publisher's behalf, which is less disruptive while accomplishing the privacy goals of TurtleDove/TERN.

I think it’s important for SSPs to continue to be able to bring the value that publishers expect and need, with functionality such as ad quality checks, brand safety blocks and publisher business-driven rules, aggregate demand and serve as a reliable clearing house in a transparent auction, etc. There are different technical ways to provide that functionality, and different notions of what funneling bids may refer to.

If IG bids require web bundles, then the SSP's job of doing categorization and ad quality just became MUCH easier because the ad content is static. This is great news and it also improves the experience of the publisher and protects the end user. As I noted in #76 I don't think we should attempt to change the existing ad-tech flow if it isn't directly related to improving user privacy (not because ad-tech is perfect- far from it). If the IG Bid Request goes to the SSP (like the contextual bid request) then the same machinery that works for ad quality and categorization will continue to work.

How would this flow look in practice? If an IG ad request needs to go to an SSP first, and that IG request is configured (by adding a user to an interest group) or initiated directly by the DSP’s tag on the advertiser’s tag, would that not require to send ad requests to each SSP (double-digit numbers are not unusual) that a given DSP (who helped create an interest group) works with at that point? Could that have some negative impact on the user experience and browser resource consumption?

It also remains consistent between contextual requests and IG requests. In this case, the DSPs would choose which SSPs they want to share their IGs with and then bid through the SSPs accordingly.

At the same time, if an ad web bundle is static, does an SSP need to inspect the web bundle for every single interest group response with the same ad?

No tokens/etc needed.

Some exchanges (such as Google, Xandr) already implement some form of the creative review API integration, which could generate something akin to tokens suggested in TERN that a DSP could propagate via the interest group response, even if the interest group request does not get sent to an SSP. For example, the token generated by an SSP could contain ad classification metadata, an expiration timestamp and be cryptographically signed by an SSP.

I wonder what other DSPs and SSPs think about the practicality and the convenience of such design involving the use of an exchange creative review API with TURTLEDOVE for interest group ads.

As the publishers agent, SSPs should receive the contextual and IG ad requests, enforce ad quality/etc across them, and make the in-page choice of what bid to represent.

Can the SSPs in-page choice of what bid to represent be addressed by suggestions in #70 and #72? If an SSP supports a creative review API, is there functionality that you believe would benefit from an SSP receiving an individual IG ad request from a browser?

They also need to consume the aggregate reporting data in order to present the publisher with a consistent set or reports on who bought their inventory.

I agree that SSPs / publisher ad networks in TURTLEDOVE need a mechanism to report on the interest group ads that get shown that may need to have a distinct entry point from the reporting mechanism for DSPs / advertiser ad networks.

WICG / turtledove

TERN - Step 1: Feedback #78