<wseltzer> present=

<wseltzer> NextRoll), https://github.com/AdRoll/TERN

<wseltzer> https://w3c.github.io/web-advertising/dashboard/

<scribe> Scribe: Karen

Wendy: Welcome, folks
... Webex interface is updated; maybe it will help to improve the connection qualities

<bleparmentier> presnt+

Wendy: not sure if this is the best tech to use for our meetings

<AramZS> whoa upgraded webex UI

Wendy: Gallery view by default! :)
... Lots of people joining the meeting now
... Let's look at our agenda

Agenda-curation, introductions

Wendy: then we have a proposal
... around TERN
... more bird names
... and any dashboard highlights to bring to our attention
... TPAC planning questions and thoughts
... Any additional agenda?

<bleparmentier> +1 to Kris

Wendy: I saw Kris with a suggestion for a future meeting
... we invite Google Ads folks to discuss DoveKey
... RTB experimental branch
... If our Google colleagues on the call could look into that
... or if they think it's appropriate to bring those colleagues to WICG discussions

Michael: we have told those folks that we would like them to come to this group
... have not heard, but hope next week's meeting possibly and will let you know

Wendy: Any other agenda items?

<kris_chapman> thanks, Michael!

Wendy: any introductions? Anyone new to the call to say hello

TERN: Turtledove Enhancements with Reduced Networking (from

<dialtone> present=

Wendy: We have TERN

<wbaker_> presnt+

Wendy: Valention or Andrew, would you like to present that?

s/Valentino

<wseltzer> https://github.com/AdRoll/TERN

Andrew: Best to read the proposal
... if you have not read, it is long
... there is a reason it is long; apologies for that
... At NextRoll we decided to incorporate feedback from Github issues and other issues
... to enhance Turtledove
... I kind of approached it
... aware there are a lot of ideas in the air
... and not nec agreement on what problems are and designing a solution around that
... Took my kernel of a problem

<wseltzer> https://github.com/AdRoll/TERN#operating-principles

Andrew: we want advertising to work in world where third parties are not able to track a web browsers behavior on the web in general
... the rest
... that is in the proposal
... is designed to maintain as much Adtech functionality that exists in ecosystem today that I thought I could
... did not cover all the use cases
... can modify and add additional things
... It basically works liek Turtledove
... has a much larger JSON object
... that works on browser at pixel time

<lukwlodarczyk_> +q

Andrew: includes IGs and ads we want to show to that user
... thought it was a good idea
... smaller advertisers who want to advertise rare products can still function

<wseltzer> https://github.com/AdRoll/TERN#1-on-the-advertisers-site

Andrew: still an IG request; preserved for updating ads, or something on sale
... or something not available
... and they want to target an IG later
... that would still be subject to privacy protecting mechanism
... Mechanism for creative review, SSPs can get involved
... DSPs declare what their content is
... that can be used for brand safety on publishers side
... mechanisms for that in this proposal
... with this writing of the ad bundles
... allows for a faster delivery time of ads
... through our own analyses we found ads are more valuable when delivered based on recent activity, and drops off steeply
... 60% of bid prices on average
... good way to support pub revenue
... also some clarification stuff that did not seem obvious in TD
... writing in multiple ad formats
... don't know what will be on pub site later
... We also more clearly defined roles of SSPs and DSPs
... and SSP can function as a DSP
... bidding logic is applied to DSPs
... SSPs responsible for maintaining publisher relationships
... we thought that was a more natural continuation of what we see in the market today
... Attempt to support some notion of third party ad tags
... a bunch of players in market have tags for additional marketing of impression signals
... impression beacons are out
... but we can capture some of it by providing names spaces for the metrics
... reported to the aggregate reporting API
... a piece that adjusts the aggregate reporting API
... these third partiies would receive own reports on tag they care about for their clients
... some of other feedback was stuff from RTB House
... product level and outcome-based Turtledove
... we took the JSON Objects almost verbatim
... User signals
... instead we named that object private data
... we see that as a clear mechanism for DSPs to include more fine grained @ signals
... conversion rate for user
... and things for ad campaign
... conversion rates for ads, campaign, all of which would get past the bidding JS
... and a final things what we added
... notion that browser itself is responsible to send signals that DSPs could leverage
... how many times a user has seen this ad
... something filed by Adobe
... thought that needed to be covered

<bleparmentier> Big +1 on second price

Andrew: also specified the auction mechanism

<bleparmentier> Argument are great

Andrew: determine prices; aware this might be confidential

<wseltzer> https://github.com/AdRoll/TERN#6-the-auction

Andrew: industry has moved away from second to first auctions
... potentially having first priced auctions in browser
... might be possible ot game things in privacy violating way
... having first prices to ID users
... another is that
... there are these game theory concerns in highly specific first price auctions
... desire to bid hire than the highest price, but lower than what you are willing to pay for it

<arnaud_blanchard> agree with the first price auction in browser being a problematics

Andrew: second price auctions would remove the gaming
... simplifies logic for DSPs
... figure out what bid price is
... I added an FAQ to describe how some common use cases would be accommodated
... We are hoping to expand that FAQ
... and feedback or questions, let us know and let us know if we can resolve that
... Got some even internally at NextRoll
... that's it for me
... Valentino?

Valentino: you covered it very well

Wendy: Thank you Andrew and Valention

<lukwlodarczyk_> need to refresh

Michael: thanks
... first of all, thank you very much for TERN
... I think it does a great job for proposing a final state for proposing open questions in TD design space
... a few things I would like to call out with a strong thumbs up
... you did a great job clearing up what the ownership is of the SSP vs the DSP
... product level and outcome based are things that should be incorporated into a final solution
... I think that the original TD was agnostic
... to what the pricing logic in the auction was
... both first and second price auctions should be possible depending on how party running auction decides to do things
... supportive of tech that will enable adtech community do what they want
... let them experiement and decide on own how the auction bidding ought to work
... note that this comes down on one side
... that is still the biggest open questions
... TD v Sparrow question of whether auction takes place in browser or a server side component to it
... there is a section of TERN that focuses on that
... and why you did not focus on a Sparrow gatekeeper solutions
... I think that does a good job addressing concerns with Sparrow
... TD dovekey is an attempt to address a lot fo the very same questions about Sparrow that the TERN proposal does
... thinking about dovekey maybe we end up with something we like better than Sparrow
... Overall, I think this is a good vision for what one possible end state could be
... but not all decisions are ones that would carry over to a Sparrow or Dovekey solution
... we will want to compare and contrast next

Wendy: thanks

Andrew: if I may respond
... that feedback is fair
... we put a lot of eggs in the basket on the turtledove side
... I still need to review dovekey in greater detail
... appeared as I was wrapping this proposal up
... I will review this week

<bleparmentier> +1 on SSP

Andrew: I am surprised that you mentioned SSPs controlling how an auction gets run
... I was under impression that browsers would be conducting this
... if desire is SSPs to have control over auction, that should be further specified

Michael: yes, to respond back
... I totally understand you have not looked at dovekey yet
... and I have not read everything in the TERN proposal, so I expect more discussion in the future
... In terms of control over the auction
... the original TD did not disentangle job of SSP and DSP
... for first v second price auction does not affect which ad gets rendered on users screen
... ad will get renedered either way
... what differs is at reporting time
... where the how much this adveriser is supposed to pay in a second price auction is the function of more stuff than just the highest bid price

<dinesh-pubmatic> +1 on clarifying who conducts the auction - is it the browser or the SSP

Michael: to run a second price auction, what info is available at reporting time, gets sent through the aggregated reporting system
... and reporting code is second highest bid, it is possible to have a system like TD to run a second price auction

Andrew: thought it would have access to all the bids
... and price paid would be the second price paid through the browser
... not submitted for computation later

Michael: where browser could make APIs powerful enough to support first or second price auctions and person running auction could do either one
... allows for experimentation; adtech can decide what it wants

Andrew: primary diff between first and second price is....largest differentiator is what constitutes a good bid in those scenarios
... having read up on all this stuff years ago when I joined adtech industry
... the BCG mechanism has nicer economic properties and that is what I am concerned about

Michael: And I support people in adtech being able to make that decision

Wendy: we cannot hear you
... let me know in irc if we can help

<andrzej_surkont> lukwlodarczyk has some problems with mic

bleparmentier: I think that I don't see how what you are proposing really works
... in the turtledove presence
... then you have some issues of timing
... that will occur
... I don't see how it will work, the browser will own everything if the auction is in the browser everything in the auction in the browser
... maybe we need to apply....
... I don't understand how this fits here
... another good question not well answered
... how do we do auctions around TD to be contextual
... in the deals on all these things, not well explained how they are interacting
... I should soon publish something to explain more about Sparrow
... I just wanted to pile on what was said
... a second price auction has a lot of good properties if you don't know the win rate
... we won't know this info in TD
... so I +1 that second price is a good idea
... but it's important to clarify how the auction really runs in TD
... for me it is definitely inside the browser
... but DSPs on the side
... case with TD

<lukwlodarczyk_> Guys as my mic is not willing to work with me today please find few words from RTB House below:

bleparmentier: I just wanted to add to this discussion, I am in favor of second price

Wendy: thanks, Lucasz

Andrew: nothing more to add

<lukwlodarczyk_> Andrew and Valentino we would like to thank you for your presentation and happy to see a new proposal on potential end state and consensus

Wendy: give a moment for text to come through

<lukwlodarczyk_> As RTB House - We need to admit that we are still digesting content delivered in TERN proposal.

<lukwlodarczyk_> If anything will need some clearance in our opinion, definitely we will bring relevant issues in the repository.

Michael: Let me say I completely agree we need to make completely clearer the relationship between DSPs, SSPs and how the final auction solution works

Wendy: thank you

<lukwlodarczyk_> We are glad to see that the TERN proposal was inspired and supports core use cases described in Product Level and Output Based Extensions for turtledove presented by RTB House on previous calls.

<lukwlodarczyk_> We are really curious to hear detailed feedback from the browsers and community on how they find TERN proposal from a policy and overall mechanics point of view.

[Wendy reads new text added]

<lukwlodarczyk_> It will be interesting to hear also more details and feedback on the dovekey proposal.

Wendy: thank you

<lukwlodarczyk_> thank you Wendy!

Wendy: I've seen some discussion in the mailing list
... that you are bringing this to WICG
... the web platform incubator CG
... sounds like a good place to host the joint discussions on TD, Sparrow, TERN and associated clarifications
... anticipate that Github issues over there would be a good place for follow up conversation
... and was mentioned there is some discussion that

<kleber> TERN in the TURTLEDOVE repo: https://github.com/WICG/turtledove/blob/master/TERN.md

Wendy: the WICG is hosting at TPAC call session
... so all of that will share
... information on that
... and of course folks are welcome to join the WICG

Andrew: Can I add one quick thing?
... when we emailed the group we sent to repo under @ org
... and it got merged under WICG repo
... please do so there

Wendy: That you for that pointer, and thanks Michael for that link in ric

s/irc

scribe: we already have a place for issues in the Turtledove repo
... thanks for that introduction

Andrew: thank you

Wendy: anyone else with a comment or question here?
... I will note a feature that I found interesting here
... was also the stakeholder feedback section that you offered at the top
... noting first that NextRoll's interest in this document
... and I think that is a nice feature to consider as we've heard the question asked
... who wants to see this work proceed, who is interested in implementing
... as that question arises when we look to see how things might progress from incubation into standards track work
... we will want to gather more of that expression of interest
... and interest in testing and experimentation, use; all helpful to gauge when and where we might be ready to move things forward
... thanks for that from a standards process perspective

Dashboard highlights?

Wendy: With that I wonder if anyone has items from other issues on the dashboard that they would like to raise for conversation?

TPAC planning ahead, issues and agenda

Wendy: Hearing none...good conversations continue to happen in Github, so let those continue
... anything else people would like to share in thinking about our upcoming TPAC meetings?

<wseltzer> https://github.com/w3c/web-advertising/blob/master/meetings/TPAC2020.md

Wendy: we have been building a list of suggested items
... I have heard from a few people
... there with additional interest in inviting participants to speak on those topics

<bleparmentier> A litlle late

Wendy: I see James, Aram and

James: I raised three suggestions for TPAC
... a couple people have commented on; how do we go about setting those up?
... do I need to do something, can W3C team member help?
... can you advise please what to do next?

Wendy: Sure, we have two opportunities for sessions and discussions
... One is the virtual F2F of Improving Web Adv on 21-22 October
... the second is the week of breakout sessions (26-30 October) and we have a wiki that any participant can add suggestions
... those are open to the entire community
... and scheduled as a "choose one" during the scheduled time each day
... Aware there were some challenges gaining access to that wiki

<wseltzer> https://www.w3.org/wiki/TPAC/2020/SessionIdeas

Wendy: that should be corrected so everyone in this group should be able to add the TPAC planning wiki
... just added link

James: perfect, I will do that for these sessions
... generally, they fall into this group
... definitions of first and third parties
... another is view of TCF and IAB Europe to explain how policy and procedure can address these problems
... third is party sets and brands
... will take these forward on TPAC wiki as breakout sessions

Wendy: that sounds great
... anyone can propose sessions there
... will be some scheduling coordination to try to build up a program to build up a program and attend a sequence of events
... other procedural question is if you are inviting
... people who are not yet otherwise participating to participate in those
... Team can work with you to help get those people invited

James: thank you very much

Aram: I want to note that
... I think everyone on this group in publishing may already know about Slack channel
... Myself and Robin Berjon from NYT are putting together a breakout session
... let me know of your interest; we will be talking about it on that channel

Wendy: Sorry to introduce yet another channel
... We do have a W3C Community Slack

<wseltzer> w3ccommunity.slack.com

Wendy: if you need an invitation there, you can reach out to one of us on the Team and we can help you to join that conversation, toio

<Zakim> bleparmentier, you wanted to comment on issues?

Bleparmentier: sorry to be late
... wanted to ask a question on an issue
... a question we asked on FLOC
... very important question about link decoration post lead
... on FLOC, because it was big enough did not all the restrictions
... problem of privacy

<wseltzer> https://github.com/jkarlin/floc/issues/31

Bleparmentier: a huge part of measurement is done through @ sources, one of backbones
... you close issue saying that everything will need to rely on the measurement proposal we are discussing
... will you remove this item
... will you try to blcok this link decoration
... will this break Google analytics
... used by a huge part of the advertising world
... it applies even in the programmatic world
... a question to Michael

Michael: so the issue that you opened originally, number 28
... that I...this is not to be an issue about FLOC
... point of FLOC is clusters created by browsers tend to be large and not sensitive enough so it's ok to join FLCO up with other contextual signals
... and page views, ok to use FLOC in that way
... that was why I figured that was a sufficient answer to number 28
... link decoration is certainly a legit question
... everything about navigation around the web
... not just specifically about FLOC or advertising
... I think all the various browsers have indicated that there is going to be some discussion of link decoration in the future
... have not seen a clear answer, roadmap or defnite statement yet about what future will look like

Ble: for us FLOC is contextual.
... confirmation that we will still be able to use standard way of measurement

Michael: i am not saying anything about link decoration; no answer about it
... our intention for Floc is it can be treated the same as other contextual signals
... using first party data from publisher, @. can be on same footing
... various conversion measurement proposals out there
... and being discussed
... those measurement proposals intended to cover ad measurement use cases across all the ways that ads can be targeted
... contextual, first party, TD style...whatever the future is
... if you feel that the current measurement solutions don't address your needs for all targeting ads, please provide that info to make conversion measurement proposals better

Ble: we have been doing that
... one thing that is very important
... on Sparrow, we understood a need for noise
... in terms of privacy
... this section
... because this could be used for targeting and cross site tracking
... this proposal has specific
... for solutions that we are still
... @ in some type of cross site tracking
... here what I understand
... doing advertising on the web we will have to migrate to this new measurement proposal
... they ahve a lot of issues
... I understand why they are needed on top of the web even if I think they are too strong
... no reason to try to add noise
... issue is different; no risk in contextual world
... because by definition it is contextual, no info about the user
... big difference for me
... everybody will need to migrate
... even full contextual will have to migrate to a new stack
... will be noise
... forced quality
... reduce accuracy
... I think this is very important for everybody to know
... pull people who are not in adtech; all agency people need to know this
... affects the way they work
... this would be a big change from my POV
... leads to other issues
... want to work on best proposal possible
... constraints still from principle that publisher should not learn @
... a different @ could be used

Wendy: Thanks
... it sounds as though at least one question might be if the issue is not specific to FLOC, raise it in the Web Adv repository

<bleparmentier> Yes wendy, I agree that I mi9ght have misposted it

Wendy: or against the aggregate reporting proposals so it gets the right attention
... as with other use case discussions

<bleparmentier> I still think it is very important

Wendy: is the tech solution of link decoration something that is needed to solve the use cases that you are proposing
... Are there other solutions, and elaborate against some fo the work that the Privacy IG is looking at in terms of privacy thread model
... and see what concerns there might be for privacy
... thanks for starting that discussion and find right place for it

Aram: As a publisher
... I don't find the change from link decoration to some of the other reporting proposals are objectionable
... I don't think it's going to be quite the cataclysm you might think
... worth looking at those proposals
... there is already some limitation of link decoration in ITP
... ITP changes
... bring in some data
... addressing link decoration and cookies as a privacy issue
... that is not just linked decoration, but how it is combined with other features
... bring in that data

<joshua_koran> Agreed with Basile that agencies and marketers need to better understand the discussions occurring here.

<joshua_koran> But disagree that they will shift how they work, since the largest 1st parties will still provide addressable advertising, with frequency capping and optimization. Thus, they will likely just shift advertising to those pubs.

Aram: take a look at it

Charlie: I want to respond to the point why we want APIs for contextual ads
... reason is in TD case, is joining sensitive advertiser info to the publishers
... publisher would learn the users IG
... one example of a sensitive join
... if publisher is only serving contextual ads
... allow a join between user and publisher
... publishers and advertiser still learn info about the user
... and user may be tracked more than they might like
... all conversion measurement explicitly involves this cross site linking, both advertiser and publisher side
... contextual ads are not devoid of all user info
... plenty of times when publisher sends contextual ads; remarketing ads; they still know users name, email
... makes it dangerous to link that up with info on conversion
... wanted to voice this was a motivation when building the measurement APIs

<bleparmentier> Thank you

Charlie: we think it applies to all conversions, not just Turtledove

Wendy: Thank you for some good conversations

<wseltzer> [adjourned]

Wendy: we will speak with you next week

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

WARNING: Bad s/// command: s/Valentino
Succeeded: s/JSON/JSON object/
Succeeded: s/and/an/
Succeeded: s/SSPs/Mechanism for creative review, SSPs/
Succeeded: s/delivered..../more valuable when delivered based on recent activity, /
Succeeded: s/@ tags/ad tags/
Succeeded: s/level/level and outcome-based/
Succeeded: s/files/filed/
Succeeded: s/first/highly specific first/
Succeeded: s/I don't see that you...will do/I don't see how it will work, the browser will own everything if the auction is in the browser/
WARNING: Bad s/// command: s/irc
Succeeded: s/lead @/link decoration/
Succeeded: s/piracy/privacy/
Succeeded: s/@ decoration/link decoration/
Succeeded: s/applies...not even/applies even in the/
Succeeded: s/is.../is contextual/
Succeeded: s/@/targeting/
Succeeded: s/@/contextual/
Succeeded: s/@/ITP/
Succeeded: s/linked/link/
Succeeded: s/joining/joining sensitive/
Present: dialtone_ lbasdevant wseltzer Karen_ arnoldrw kris_chapman ErikAnderson ionel AramZS mgendler sharkey-cafemedia bleparmentier mlerra blassey pl_mrcy br-rtbhouse jrosewell kleber Mike_Pisula_Xaxis pbannist hober marguin joshua_koran dinesh-pubmatic dialtone DiarmuidG wbaker_ Alan mjv arnaud_blanchard pedro_alvarado cpn Chetna_Bindra
No ScribeNick specified.  Guessing ScribeNick: Karen_
Found Scribe: Karen
Agenda: https://lists.w3.org/Archives/Public/public-web-adv/2020Sep/0019.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)