appascoe
commented
3 years ago I think some clarifications are in order. Let me know if you think it makes sense to issue a PR so the description in TERN is a bit clearer.
First, I disagree that a contextual request is the right answer for this situation. I'm suggesting that a user is on the Yelp page for the pizza shop and then browses away from Yelp to other sites. That is, the user has expressed some interest, and the shop is interested in enticing the user back to convert (classic retargeting). If the user browses away to a publisher that is not about pizza, then a contextual request is not sufficient: there isn't any particular reason to believe a raw contextual request coming from nytimes.com should be responded to with an ad for a small pizza joint.
The other miscommunication is the use of word "time-sensitive." It seems to me like you're referring to ad flights, whereas the TERN doc is trying to communicate an issue with TURTLEDOVE, which suggests waiting 4 hours before issuing an interest group request to receive a set of ad web bundles. In the case of having looked at a pizza shop's page, 4 hours may be too long to advertise back to the user; they may have already ordered from somewhere else. As for ad flights, TERN has a simple mechanism to support this, described below. TURTLEDOVE is more ambiguous.
As for creative review, we have a PR out that overhauls it: https://github.com/WICG/turtledove/pull/74 . This is not particularly different from how creative review operates today, other than a browser signing check. I think it's a bit of a misnomer to suggest that DSPs are placing bids directly in the browser (though that is certainly possible). TERN takes the position that contextual information is necessary to bidding healthily. As such, when ads are written, there's more of a partial prediction that is written along with the advertisement data, which is later combined with another partial prediction that would run through the SSP. In a very real way, TERN still solicits bids through SSPs.
Yes, TERN explicitly rejects the OBTD use of a third-party server to track ghost wins. It's not about the size of the IG up front, but it does specify:
If the number of unique users who saw the ad is higher than k, publicly declare the creative as validated.
In some ways, this is worse. There's a minimum size per creative than per IG. As explained in TERN, it's important for us to minimize the delay between being on the advertiser's site and being able to deliver a creative as much as possible.
Let's discuss how to do ad flights in TERN. I will probably add this as part of the FAQ.
When writing the advertisement data object (as described in Section 1), the DSP can use the privateData object to specify fields:
privateData = { 'start-time': t0, 'end-time': t1 }Then, in the generate_bid function described in Section 5, logic can be implemented thusly:
function generate_bid(adSignals, publisherSignals, browserSignals) {
t = browserSignals.currentTime // maybe this could be grabbed elsewhere, not super important
t0 = adSignals.privateData['start-time']
t1 = adSignals.privateData['end-time']
if t < t0 or t1 < t:
return 0
// proceed with other bidding logic past this point
}This will ensure that the ad will not be displayed outside of its intended flight.
I'm not sure the best way to engage in this kind of discourse, but I will attempt to do it through issues. @appascoe feel free to let me know if there's a better way.
This section seems to conflate several things that I don't think are related: time-sensitive campaigns, creative review, and OBTD.
While I understand the intent of this example is to illustrate a certain problem, I think it probably illustrates that a contextual ad request is the right answer for this situation (the context is yelp / pizza - no IG needed to communicate intent; also no delay in showing the ad).
I think a fair question to ask would be "can TurtleDove serve time-sensitive campaigns? Under what conditions?"
As far as creative review goes, it seems like complexity is being added here in order to allow the DSP to place bids directly in the browser. If, instead, the browser solicits bids directly from the SSP (as it does today), then the creative review process doesn't have to change. I think TERN/TD have a better shot of succeeding if they keep the changes minimal and focus on preserving privacy rather than how ad-tech functions as a whole. Either way, I don't think this is related to time-sensitive campaigns.
Finally, my understanding of OB TD was that it required a third-party server to track the number of attempted wins ("ghost wins") rather than the size of the IG up front. This seems like another layer of complexity (and infrastructure) that is harder to reason about. It also doesn't relate to time-sensitive campaigns or creative review, near as I can tell.
I would vote to strike this section entirely and replace it with something that explores how TD can serve time-sensitive campaigns or the limitations on doing so.