scribe: Karen
Wendy: thank you for everyone who has sent agenda items to the list with requests
...On the agenda we have product level TURTLEDOVE
...TURTLEDOVE flow
...gate keeper and proprietary cohorts proposals
<dkwestbr> present_
...and look and other highlights from the collective dashboard
...any other items to add to the agenda?
...any new participants to the call who would like to introduce themselves
<Chapell> +present
Jonash: hello everyone, I am a researcher at RTBhouse
Joey: I lead advertising at WatsonHouse, IBM
Kaz from Yahoo! Japan
Hari: I'm from Yahoo!Japan
Bob Skinner at Ford Direct
https://www.w3.org/groups/bg/web-adv/participants?sortaff=1
Wendy: for one's reference, here is the link of our participants overview page
...we can see some folks have photos in their W3C accounts
...encourage you also to link up your GitHub account so we can coordinate that with the GitHub repository where we do the drafting work
Wendy: We have a busy agenda, so let's get started
https://github.com/jonasz/product_level_turtledove
...product level TURTLEDOVE
Lukasz: Good morning, good evening to everyone
...I represent RTB
...a significant fraction of the web is noticing advertising and ecommerce during COVID
...online revenue helps in tough times
...there are two main channels
...search and retargeting
...we see two key proposals for targeting: TURTLEDOVE and SPARROW
...to maintain current state and adaptation of ecommerce proposals
...it is crucial to introduce the product
...creative ads we describe as a collection of products
Jonasz: Thank you Lukacz for the intro
<piwanczak> https://github.com/jonasz/product_level_turtledove
...the proposal is compatible with TURTLEDOVE and SPARRO
w
...effective retargeting
...we were trying to assess the impact it owuld have on retargeting effectiveness in general and in quality in particular
...useful product recommendations are crucial for retargeting
...ecommerce ads are a collection of products
...usually a grid of items
...a product we think will be useful for you
...TURTLEDOVE introduces a normal difficulty; minimal audience threshold for ad
...to show to the usrs
...this is a problem for recommendation quality
...any solutions so far are not remotely close to our current solutions
...Let me introduce a real world use case to be easier to understand the nature of the problem we are trying to solve
...Let's say you are looking for a pair of headphones
...you have specific situations to use them, such as running, when it rains, and also for your daily commute
...this might be translated to a list of preferences; for example, wireless earbuds; be waterproof to run in rain
...and make use of noise cancelling for your daily commute
...and you might commute music genres that are bass heavy
...that does not sounds like a sophisticated list of requirements
...in an electronics store you will find thousands of headphones
...we would have to create an interest group to which we serve headphone recommendations or ads
...depending upon the ecommerce store, we might create an interest group for truly wireless headphones with noise cancellation
...but not likely we can create an IG to fulfill all your requirements
...we might serve headphones that are wireless or bass heavy
...they are not going to be waterproof, noise cancelling, or in-earbuds
...if you just see bass-heavy, wired, and not noise cancelling, these are not useful for you
...We think that the overarching goal
... of privacy-preserving ads is compatible
...propose minimum threshold at product level
...we think this is the natural way of reasoning ecommerce ads
...coming back to our example
...of thousands of headphones in the electronics estore
...we might find 10-15
...all these on their own might be popular products
...the combination would be rare
...and we could not serve under TURTLEDOVE
...but we could with the product level focus
...Let me stress what happened here
...if we bring the product level focus
...we might go from ads that are not useful to ads that provide great, useful recommendations
...we think this is a crucial change
...this is the major value of our proposal
...one is ease of adoption
...you would be able to use our recommendation system almost as is
...requires a couple of tweaks but nothing fundamental
...also assess impact on core metrics and recommendation quality
...with product level focus we can perform an analysis that is straight forward
...with the min. audience threshold of 30 we could maintain 94-95% of clicks today
...finally let me mention
...as I said, the proposal is compatible with TURTLEDOVE and SPARROW
...could also bring other benefits in quality, native ads, @ and more
<bmilekic> "early research indicates we might be able to retain even ~94.5% of our current click through rate level with product-level audience threshold of 30
...that concludes my summary
...great to hear your thoughts, take questions
...invite you to take a look at our proposal at our GitHub page
...thank you for your attention
Wendy: Thank, you Janesh
Michael: thank you for the description and great data to back up
...I opened up some issues on GitHub
...thank you for answering them
...it seems good to me
https://github.com/jonasz/product_level_turtledove/issues
...show ads without privacy degredation
...only thing to say before we say yes to baseline idea
...other people besides RTBHouse
...I would like to see more people chime in
...to see if there are other varients
...for other people's ad targeting that are different from yours
...to meet needs of as many people as possible
...not having too many comments yet, but it seems great
Wendy: encourage others to queue up
Valentino: In spirit of what Michael asked, we are from NextRoll
...we are on the same page with RTBHouse with the need for product level
...ability to recommend product level
...we propose a slight change in the fetch ad request
...specifically that would enable us to avoid the minimum 30
...run the fetch ad in same context
...since cross site tracking is not possible
...and same site tracking is not being challenged
...you end up with no more or less info by fetching the ad in the first party context effectively
...this was part of the conversation
https://github.com/WICG/turtledove/issues/36
...you seem relatively open to that
...that's it
AramZS: I just want to say
...I appreciate the details and information in this proposal
...this does seem to match with a use case that we would be interested in as well
...some degree of personalization about what types of articles are offered in an ad unit
...thanks for putting it up
...I will check match with our system
<Chapell> +present
Jonasz: for use case Valentino mentioned
...we think the product perspective might make the product level thresholds lower
...or eliminate it all together
...by allowing for more auditability
...an ad itself or the products that comprise the ad
Garrett: Hi there
...thanks for the proposal
...it was interesting
...play devil's advocate
...differences between types of targeting: dynamic or generic
...in academic literature
...which is more effective in which situation
...how value of product pictures shown and whether there was experimental basis to show effectiveness
...the specific product may be less useful in creative
...worth mentioning
...I am pretty pro advertising
...but this is a pretty sensitive topic
...because consumers may or may not be sensitive to targeted ads
...so from a user experience perspective this may be a challenge in keeping users happy
Valentino: just to clarify the question that Garrett asked
...dynamic product creatives perform 2-5 times better than static ones
...22.4 CTR
...and translated through conversion; half or a quarter of the costs through conversion
...this is critical for sites for massive retailers like Rakuten, Amazon, Target, Walmart
...customers only see small percent 1, 2 10%
...a static creative with a random selection
...look like dynamic but they are static
...ends up in a creative that would be clicked a lot less
...this is very easy to validate
<kleber> I think that for @AramZS's use case about content recommendations, you might want to return zero, one, or more-than-one "product"/item in response to a single "product ID". Might need a little generalization of the current design.
...another aspect to clarify
...we support
...the use of product level data inside TURTLEDOVE
...but we are not so hot on the proposal from RTBHouse
<angelina_iabTL> i'd liketo add that with remarketing / dynamic ads - post view traffic and conversions are also significantly higher than standard ads
...it is complex on how it passes data and it does not change the outcome
<AramZS> That's a good point @kleber I'll take a look at addressing that in my comments.
...there would be no more minimum limit for the fetch ad
...true across the board for all ads
...relatively simple change that would remove the group size
...but we are aligned for a solution on product level for ads
AramZS: I think that there was an interesting point made
<angelina_iabTL> as eg. remarketing / dynamic ads - I've seen 40:1 ROI vs. standard ads at 14:1 ROI
...about idea of users' reaction to retargeting that we need to reconsider
...not that I see it as a blocking concern
...as much as dealing with design of TURTLEDOVE in general
...not sure to what extent it makes it visible to users
...might be worth discussing outside of this conversation
...perhaps it has been
...mechanism could be made transparent just to users
...and those mechanisms might help with concerns of where retargeting comes from
...comes from app knowing why they are retargeted
...if we can consider this in the redesign of this product
Wendy: I note Angeline you are adding more data
Jonasz: As long as we stay with minimum @ question to direct to browser folks
...product level might facilitate that
...product level perspective might make it more understandable for users in TURTLEDOVE UI
...that's all I have
Wendy: Hope to see conversation continue on these issues; feel free to bring back to the agenda
Angelina: In addition to the personalization of ads and dynamic ads
...I brought this up a couple months ago
...the ability to track post insertion
...post view impressions
...I've seen several of my previous advertising client examples
...remarketing ads [cannot hear well]
...marketers feel not only track clicks from conversion but also @ from products
...drives people directly
...case of post view impressions
Wendy: Data requirements to capture in the use cases to describe how used
...now, on issue #37
https://github.com/WICG/turtledove/issues/37
Valentino: We wanted clarification
...on issues inside TURTLEDOVE
...our concern is the flow of requests
...throughout the ad negotiation process
...the fetch ad request goes through SSP in encrypted form
...using decryption key
...that is know in a browser location
...and pass to the DSP
...has private key to be decoded
...and reads it
...how fetch ad request ends up to the right party
...our concern with that flow
...two classes of issues; one is additional costs; another is technical limitations
...adds latency
...having two sequential requests to SSP and one to DSP adds a milisecond response time for timeout requirements
..and effectively adds an incremental load on top of the SSPs to manage the publisher and buyer side requests
...we are not an SSP we are a DSP
..but would turn SSP into a single point of failure
...if the SSP or that end point goes down, we cannot add users to a profile in browser
...and @
...request ends them up to SPP
...could bring them down and put minimum amount of cacheing
...cookie matching
...SSP will learn all of the interest groups that people have been added to over time
...at least the SSP gets to learn all the requests due to the get requests
...and we talked about the single point of failure
...issue is going in a positive direction
...make sure certain ads get approved by the publisher
...but the fetch ad being uncorrelated
...for publisher...needs to be known
...fetching of ads needs to be done at time of rendering
...we have explored some alternative ways; some server side protocols
...to approve ads
...fetch ad requests happen on the DSP side and have the browser ask for approval from SSP independently
...we will likely write a proposal on this
...want to understand if others in the room have same concerns with latency and tech issues
Michael: so there has been a lot of discussion in issue #37
...as author of TURTLEDOVE
...I am open to changes to flows
...which serves the browser talk to as long as they respect need for SSP with publishers
...and [missed]
...you mentioned a lot of points
...would be a great topic for a future live phone call with us and the SPARROW under the WICG
...instead of going through nitty gritty here
...you mentioned latency concerns which I don't think should be a problem
...happens out of band
...in advance
...prefetching ads on a future page
...adding hundred milliseconds doesn't really matter
...on subject of not touching SSP at all there is an obvious tradeoff
...browser could ads and not show up if person doesn't visit
...if you fetch ads that do not appear in any auction triggered by the user
...some tradeoff there
...I did not understand worry about SSP to learn something in DSP
...I don't think they learn anything about user in cross-site way; that was part of the design of TURTLEDOVE
<dialtone> they do when the fetch-ads asks for a interest group ads, so they get to learn the interest group in there, which is imho unnecessary
...if you think there is info being learned, I am happy to keep that from being the case
Wendell: Thank you
...I am listening to all this
...heartened by the technical conversation and looking forward to the ad hoc meeting
...this is a wonderful development
...but want to give permission to ourselves to be direct
...and use our time on this call
...and number of people on this call to be very direct
...I will relate how we are thinking about this problem at Verizon Media
...we are going through deep introspection on the viability of our businesses
...as Apple and Google are making changes
...want to make sure we can have concrete business discussions
...they are interesting as a technologist and programmer
...building and waiting for release of these features
...but this word theoretical is a scary word, actually an insult to business people
...company X gives no promise of future promise
...remind ourselves these conversations are theoretical
...we are here because there are two suppliers for our advertising business
...and they have chosen to change the terms
...for our business, but neither has confirmed product features and one has said no interest in these at atll
...one more comment, a positive thing
...someone once said in this or another meeting
...if you try to get funds around Silicon Valley, they will not tell you no
...they will give you an errand
...come back when you have completed this task
..."get me shrubbery" Monty Python joke
...hope we have not overstepped into a speculative range with the engineering
<AramZS> lol
...love to see more practical engineering
<AramZS> re: monty python
...hope this is not an errand
...I like the technical aspects, but want to see more implementations and when they might show up
...thank you
Kris: I just wanted to comment on the flow of SSPs, DSPs, advertisers and publishers
...is not completely flushed out
...a lot of other partners in that flow
...Salesforce has a DMP and ....we deliver....
....offline data we have brought online and use in these targeting situations
...my understanding is for that data to be used, we have to load into the browser
...to load that data into the browser and I am concerned about page loads and latency times
...that is a significant amount of data
...unless browsers will stockpile offline and online data
...I am +1 latency issues and Wendell's comments
...that we do need to get to
...welcome the technical conversations
...and get to testing code to start working on the practical realities
...on what will page loads and latency be like
...thanks
AramZS: I want to make a suggestion
...we are having the technical discussion on aspects of TURTLEDOVE and SPARROW
...idea of how this separate and different space for ad execution would work
...we briefly discussed
...not asking for more in-depth discussion now, but later this week, like to spend extra time on that to address these latency concerns
...the latency we see on publisher side
...is at execution level
...not sure entirely how this weeks
...address this in an ad hoc meeting
...or in future
Wendy: I will note pointers to the link for that call
<kleber> This week's technical discussion is I think going to be on reporting topics -- https://github.com/WICG/sparrow/issues/14
...for those who are interestesd
Andrew_Pascoe: Clarification from Michael on the trade-off with SSPs on the fetch ads request
...for interest groups it happens out of band
...unclear how an SSP would know whether an ad is viable since browser has yet to visit a publishers page
Michael: it's true
...if browser can recognize sites it can show
...networks that show only server to server call-outs make sense to me
Andrew: Do you consider this as additional things to hammer out; browser optimizations; storage requirements, requests
<alextcone> +q
Michael: Browser optimizations don't appear directly in specs in design level we are talking about
...browser vendors make those choices...at a later implementation stage
Brad: queued up to respond to Wendell
...Chrome is well on the way to implementing these things
...trust tokens is in @ and available for origin trials
<alextcone> Queue is closed for this topic, but I am curious if M. Kleber is saying that a browser would make optimizations about transaction participants based on historical data. Did I hear that correctly?
...[missed]
...working in trials and folks can play with
...intent to prototype for FLOC
...and we started the discourse thread to move into WiCG
...for appropriate incubation
...to join conversation on FLOC
<blassey> https://discourse.wicg.io/t/proposal-federated-learning-of-cohorts-floc/4473
...please comment on the discourse thread so we can move into the WICG repo
...and have the CG IPR coverage
...thanks
Wendy: next up
...Tom K had two proposals
<blassey> FLoC I2P: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af929de8-b79c-4018-bcdf-7692da969530%40chromium.org.
Tom: Purpose is to follow up on the previous discussion on how cohorts are created
...far more complexity in eco-system
...talk about functional interactions
https://lists.w3.org/Archives/Public/public-web-adv/2020Jul/0014.html
...make SPARROW more compatible
...and make cohorts
...diametrically opposed
<kleber> @alextcone in the original TURTLEDOVE proposal, I wrote: In particular, the interest-group request could be sent in advance of the browser navigating to the web page. For example, a browser might learn over time which ad networks it regularly encounters, and a few times a day issue any relevant interest-group ad requests to those networks." Doesn't have to work that way, but it is a possibility
...come up with a reasonable mechanism
...turn over to Brad Rodriguez
...proprietary cohorts
...and how @ would have to be governed
https://github.com/MagniteEngineering/ProprietaryCohorts/
BradR: Third party cookies
...are cohorts for purpose of ad targeting
...users get to see more relevant ads
...better way to achieve benefits while respecting user privacy
...an example
...HTML tag or JS API
[missed]
...cookies being sent to provider
...registration ID
...for one request to another on same browser
...minimum domain
...the registration request of core provider
[BradR reviews details from https://github.com/MagniteEngineering/ProprietaryCohorts/ ]
...as response to browser request
...a core ID
...then the publisher or web site uses JS API to retrieve cohort ID after its available
...and use for a number of things: Analytics, targeting and ad measurement
...registration ID provided in cohort
...consistent across all domains
...unique for each cohort provider
...correlate on backend
...set on backend
...based on privacy needs
...request itself
...contains no cookies, caching, or state
...related to proxy to hid user IP address
...ensure minimum number of users exist
...responding cohort ID
...a number of cohort IDs could be limited
...and ensure a minimum size before exposing
...also replace with JS API
...tag chosen if want to integrate with cohort iD
....cohort provider
[talking too fast]
Jeff: I am going to skip ahead a few slides
...behind proposal of gatekeeper
...should be ok for others fo do
https://github.com/MagniteEngineering/Gatekeeper
...a few definitions
...gatekeeper is designated as a service
<scribe> scribenick: wseltzer
Jeff: Gatekeeper defined as a not-for-profit service
... First-party set is collection of websites that agree to share ID, need not be commonly owned
... Business rules: https://github.com/MagniteEngineering/Gatekeeper#business-rules
<dialtone> 1+
https://github.com/MagniteEngineering/Gatekeeper#use-case
<dialtone> not a lot of time left on the call but...
<dialtone> the new aggregate reporting API and sparrow and this proposals all have an external entity that will provide a gatekeeper service or an aggregation service
<dialtone> has anyone detailed who would provide such services?
Wendy: Suggest we pick back up on this topic next week to get questions
...and invite people to look at your GitHub repositories and look there
...some things to think about
...thanks a lot to those who introduced material today
...try to be closer with time management
...we will start up next time with the Magnite proposals
...thank you all
<Jeff> gatekeeper slides: https://docs.google.com/presentation/d/1YVM-yG11hgzpJ2RlHC8_rAN7E0ZWdTMRmDp_hRTGPnM/edit#slide=id.g8d80d6fa2b_0_51