<scribe> Scribe: Karen Myers

Wendy: As we get started, I hope everyone had a good week of TPAC breakouts
... if we get a chance at the end of our agenda, we can get some reports from there
... and also thanks for recalling that we had queued up PARROT just before TPAC discussions and had not put that on agenda
... so I re-introduced that here today to present for discussion
... we had Andrew Pascoe's introduction of MURRE
... and follow that with any other reports that people want to share from TPAC virtual F2F discussions, or breakouts or other meetings you were able to attend
... and think we should bring for discussion here or take note of
... any other business that we should include?
... Do we have any introductions [of new participants]

Basile: Someone needs to mute

<GarrettJohnson> Can the meeting default to muting participants again?

Agenda-curation, introductions

Wendy: Is there anyone who wants to give an introduction?

Anthony Molinaro: I work at OpenX Technologies

scribe: been in web advertising space for 25 years

Wendy: Thanks, Welcome

Don Marti: Hi, I'm with CafeMedia and was formerly with Mozilla and @

Kevin Sales: I am attending on Mike Smith's behalf today

Remi: I am with @, we use AI as a service
... interested in understanding the future of advertising

Welcome Remi

Chris Starr: from @

scribe: do inventory operations

Wendy: Glad to see some more people joining the group
... you should see on our [Github] repository home page
... a listing of the proposals that have come to the group for discussion
... we recently started to send out an introductory email message when you join the group
... I will resend to the list so that everyone gets that intro email
... we are on irc.w3.org, in the channel #web-adv
... Great, let's get right back into our discussions
... Brad, thank you for introducing PARROT

PARRROT

Wendy: would you like to share what that proposal is

Brad: Thank you, Wendy for putting this back on the agenda and for Michael [Kleber] for getting it back on the agenda
... I wanted to introduce everyone to a proposal that we wrote at Magnite in conjunction with Prebid

[@@@]

scribe: acronym is PARROT

<wseltzer> https://github.com/prebid/identity-gatekeeper/blob/master/proposals/PARRROT.md

scribe: purpose is to call out some concerns with the way the auction in the Turtledove proposal
... which seems more like a black box
... wanted to call out a concern
... this proposal could address those concerns
... auction within TD is basically a black box, presumably controlled by the browser itself
... probably open source but not customizable on a per publisher basis
... many publishers have concerns
... domains...create a buyer box, buying models, pacing, if a deal is involved in impression

<pedro_alvarado> !present

scribe: targeting, potential discounts, custom parameters

<wseltzer> https://github.com/prebid/identity-gatekeeper/blob/master/proposals/PARRROT.md#introduction

scribe: we could name more arbitrary things within a given auction
... we want to propose a mechanism by which the publisher can control the auction while protecting privacy that aligns with goals of TD
... proposal outlines a strawman interface between publisher, developer of the page, and the browser

<wseltzer> https://github.com/prebid/identity-gatekeeper/blob/master/proposals/PARRROT.md#proposed-workflow

scribe: starting with an overview that many publishers are running a header
... we envision this header could be extended to TD and PARROT
... where initial auction runs with header
... and code
... and return data relevant to TD auction
... Let me take a step back
... the header bidding idea
... not everyone may be familiar with header bidding
... Publishers will include JS that runs with payloads; requests to SSPs
... and to proprietary ad server, to get info about what ads might qualify for a given impression
... that data is compared, possibly passed to third party, and winner is chosen
... and page is loaded...
... taking into account that header JS
... often controlled by open source, as in prebid
... could be leveraged and extended so publishers does not have to do a lot of work
... outcome of that header solution could produce a TD style secondary auction
... header solution determines if a TD style auciton needs to be run
... based on parameters the publisher needs to control
... other campaign needs to run
... we would not need to call TD solution
... if header bidding solution determines that a TD style or interest group based
... those decisions could be passed to a varient of a fenced frame
... only variation is you can pass in darta in a structured way
... into URL or web bundle
... and what gets rendered in that frame
... fence frame proposal provides information
... interacting with TD APIs
... and possibly indicate how they are viewed

<wseltzer> https://github.com/shivanigithub/fenced-frame/

scribe: Fenced frame loads in additional JS controlled by publisher, whether @ bundle or source
... contextual requests made
... at that point that JS loaded potentially could be a web bundle
... and have access to TD APIs, or make independent request
... independent request would be done beforehand
... so in TD some sort of cached bids

<wseltzer> https://github.com/prebid/identity-gatekeeper/blob/master/proposals/PARRROT.md#diagrams

scribe: like TERN-style with that information provided
... then potentially dovekey store could be accessed
... or other proposals
... after all of that magic, the JS is provided
... with data for IG
... IG places bids and makes decision based on info that the publisher controls
... via JS that they can verify
... winner chosen based on data input
... winning ad rendered in a sub fenced frame
... within a larger fenced frame that would have controls
... to show the ad in a private way
... one key aspect of this
... in order to prevent data leakage
... and the sub fenced frame, or URL or web bundle
... would need to be one provided either in initial IG request
... or within the contextual request so they are generated before any mixing of data
... specific URL would be valid for serving an ad
... to keep data out...
... any privacy preserving reporting APIs would be available
... certain outstanding issue on how we would effectively report
... for finance purposes the winner of an auction
... Proposal has some diagrams to walk through

<brodriguez> https://github.com/prebid/identity-gatekeeper/blob/master/proposals/PARRROT.md

scribe: I dropped into irc here
... if you have any questions
... feel free to reach out to me: brad@magnite.com

Wendy: Thank you, Brad

<brodriguez> brad@magnite.com

Wendy: glad to see the links match

Ben: two questions
... first one, can you explain exactly what the problem is that you are solving with this proposal
... I heard vague, browser runs auction is bad, someone else runs auction is good
... I did not hear a clear problem statement
... regarding TD running auction in a browser
... is there a clearer problem statement?

Brad: Both the publisher or browser writing JS
... don't mean to say anything running in browser is bad
... but publishers not being able to adapt to their professional business needs and to adapt
... puts them at a disadvantage to what they have today
... in theory you could construct an auction that is priced based and the proper winner is chosen
... often times the priced used to win the auction is not the price the buyer would pay
... that is not intuitive
... something like a discount
... auction might be a dollar but buyer pays 50 cents
... discount applied afterwards
... that is one example
... of how a certain business case might compete with a one-option style to rule them all

Ben: Why does this need a web standard?
... can this be done with your own JS?
... can't we do everything by running your own JS
... I don't care about which auction wins...I'm ok with that; why can't you do that? Why do we need a standard?

Brad: allows for an IG auction to take place where publisher retains control

Ben: you want to the publisher to run their direct sold with the awareness of IG info
... and have lower bid win...

Tom_Kershaw: High price often loses the auction
... it is poss to come up with method to not invoke fenced frame
... or browser
... cannot always assume high bid always wins
... we are fine with a web standard
... help various bid mechanisms to communicate with each other

GangWang: Thanks, Brad for the presentation
... I would like to ask some clarification questions to understand proposal
... for each ad slot
... under this proposal
... how many ad requests will browser send out
... per ad block
... second is in this general proposal, which entity is in charge of paying the publisher and advertising
... and how does it ensure the auction is real?

<tomkershaw> purpose of the proposal is to allow for cases where high price does not win, to allow publisher to select winner based on whatever parameters it chooses

Ben: I think in our proposal, standard header bidding auction
... publishers make a number of requests

<tomkershaw> and for rational cooridination between the various auctions that take place

Ben: I'll throw out five
... but there is no limit

<tomkershaw> ie direct, td, prebid, etc

Ben: it does not have to be related to number of ad slots on the page
... all could be handled within a single request or single provided
... could be provided to multiple fenced frame
... every ad would need to get its own slot
... winner would be chosen
... but every single ad slot would not have to win
... would know that logic and know the one that wins
... second question
... how to determine or who determines the price?

GangWang: which entity pays the publisher at end, and how do they know the final clearing price?

Ben: in this scenario, the controller of the logic or fenced frame...would be the one to bill the advertising and pay the publisher
... how they ensure the right price is won, there are some issues in TD
... on how to effectively report on data
... not prepared to speak to current state of the art there
... I think that is still an outstanding question. Perhaps Michael could speak to that

Michael: Hi, sure
... that is not what I was going to speak on

<kleber> (Note: Some other discussion about this idea happened in https://github.com/WICG/turtledove/issues/59)

Michael: two other things to talk about first
... although there has been some discussion on issue 59
... take a look at that
... I have two fundamental things
... first, I want to clarify something about the original TD
... in original TD proposal, how I proposed auction working
... every ad can run some code
... intention of that code is to produce some number
... where the higher number ad should win over a lower number ad
... never my intention that number associated with each ad had to be the bid, clearing price or cost of ad
... how money changes hands is up to the contractual business relationships; that is your job, not my job
... goal of TD was for some bunch of code in the brower
... agree early code did not separate out code from SSPs and DSPs
... produces some number, that is ranking of that ad
... and ad ranked highest is one that should win
... then use the various reporting APIs and winner of auction expresses how much money changes hands.
... I wanted to understand if you think that fundamental model need to change?
... is that model still ok
... if I clarify that the number is not a price being paid
... or does there need to be a JS that looks at all the ads that finally picks the winner
... where ad A is ranked higher than ad B, then ad C comes in, and should it override
... if you need that capability
... that's the thing to answer Ben's question that is not covered by the original TD intent
... that would require new JS that does not just pick the highest ranked ad

Ben: Knowledge of the winning price of other ads
... would be important in a second price auction
... not determine who wins but determines price of winning ad

Michael: that is fine; we can ad more info to reporting
... and that winning ad report more information, including value of other ads
... that is a different question from what ad shows up on the page

Brad: [missed]
... whatever function runs right before and after
... and if availalble on both sides, you could hack around
... a limiting factor that does not provide a lot of value
... I think this is simpler mechanism
... where browser doesn't need to take that on
... parties participating don't need to work around it to take the business needs
... Tom, do you have use cases where we need to know losing ads where we need to pick winning ad

Tom: I think most of these use cases are covered under Michael's description
... where ranking is used for decision making purposes
... I cannot think of any discrepancies off the top of my head

Michael: That's great
... I think it means I can support the use cases you are talking about
... a second I want to say
... it seems like the one additional thing you are asking for
... is sort of you want there to be multiple auctions
... run by multiple, different people
... you want an auction where an SSPs controls participants in auction
... and a different auction where publishers control participants

<pbannist> One use case relevant in this case is video advertising and dealing with VAST errors. If a given advertiser's video ads cause VAST errors 20% of the time, we would want to reduce the effective "rank" number by 20% of that ad based on who the advertiser and/or campaign was. That might be possible with the basic TD ranking system, but given dozens of potential bids for a specific ad, and many different vast error rates, and the fact that nothi[CUT]

Michael: each one of those seems to be the last person who wants to run the ranking JS

<pbannist> browser knows what the ad is, it might require custom JS to adjust the ranks correctly?

Michael: I think the feature request compared to TD
... you want to run a TD style auction that uses some amount of ad demand
... and then another auction after that
... and the winner is a participant in the next auction

Tom: That does not sound right to me at all
... today, it does run that way; there are multiple auctions that are disconnected
... shake up and winner is chosen
... like to see a single auction where rules defined by publisher in a single way
... allow for a case where there would be multiple discrete auction
... my preference is to create a single, discrete auction

Brad: From my perspective, maybe why it sounded that way
... as Tom pointed out, there are multiple auctions today
... having four clearer reasons
... first auction in header would have access to data
... and do things not in the TD fenced frame
... industry will squeeze as much juice as possible under that scenario
... price triggers that
... provide a stepping stone to adopt
... if TD is super successful and we can get everything we need out of TD in long run, you might see a drop in requests in that auction
... that would be a huge success for TD if it is performing way better
... if first auctions never win
... I don't think that two is magic number; get what you can get in one scenario and out of another

Michael: Fundamental problem in issue 59 with there being only one auction
... seems to me as infrastructure only provider
... seems there are two kinds of protections the browser needs to offer
... from what I have heard from people this eyar
... one is person running auction needs control over who runs auction
... someone who is buying needs control over who runs auction they are buying into
... those seem like reasonable design requirements
... case where ther is only one auction and controlled by different party on different web sites, I don't know how to reconcil
... even if buying through DSP; who runs the auctions they need to participate in

<wseltzer> Issue 59

Michael: issue 59 would be a good place to continue this discussion

Brad: seems to me that TD and PARROT do not follow that
... I will follow up on that issue

Wendy: I have closed the queue to keep some time
... thanks, Tom, for adding comments into irc

Viraj: I am the one who opened issue 59 to give high level intention
... the first part of what Michael said
... starts with simple case of who gets to participate in the auction
... that is...we went through the framed source; who partners with them
... I wanted to get clarification...in case of header bidding you would need something more
... I think as participants said, header bidding is side effect
... works in publisher ad network
... might not be @
... ability for non-partnering partners
... non-partnering ad networks to participate in a bidding process
... that is number one goal for issue 59
... quickly goes into how the auction is run
... slight ambiguity
... one model you do the auctions separately
... most important part
... whenever you do auction for one single ad slot
... do we get to wire all the contextual info from the SSPs, they could be wired together to get the bidding information
... that was my intention

Brad: the request is that a buyer, an advertiser or DSP
... would participate in an auction...where they don't have a pre-existing relationship

Viraj: typically an iframe
... where domain listed
... publisher accesses @
... final auction happens
... >TD hints that the IG would participate
... based on that domain name
... my point is we might need to open it
... that is issue of 59
... quickly goes into the auction dynamics
... that is the later part
... if we align them correctly, could make them one or two options
... we would like to have each IG, each ad networks' IG, should get the contextual response at run time
... two, non-partnering ad networks should be able to participate...for an ad slot

Brad: this is an interesting use case
... not sure how this would work
... how I envision PARROT
... in order to participate, SSP...would need to collaborate with the publisher to participate in that auction
... you would not get an arbitrary third party
... question about billing in TD
... could arrange for collecting payments for third party or publisher
... in case of publisher or SSP, they would need to know who to reach out to
... there needs to be a chain of parties that has billing information
... and not @ check in future

Viraj: in general, it is similar to header bidding
... look at issue 59 is similar to standard setup of header bidding
... regular header

Tom: Brad, check out issue 59

Basile: need to be quick
... I want to call out
... when Michael you said it could be the ranking
... good if we could have a map with interaction of multiple types of functions
... which doesn't come with contextual
... two worlds competing
... question, how in auction you make these worlds compete
... In Sparrow we tried
... interesting to have something similar
... what is allowed to go out in the inbrowser auction
... how it prefers contextuals
... than in TD auction
... how does the bidding work
... maybe I missed a small document to explain this
... it would help...if adding to the confusion
... maybe just to call for clarifications on what would be possible and how it interacts with other auctions?

Brad: with PARROT or TD?

Basile: with TD, some clarifications

Michael: ok, good feedback, I will clarify that

Wendy: Thank you for that discussion
... we now have link to PARROT repository
... some discussion of those issues in TD in WICG
... look forward to hearing more from those conversations as they progress
... Andrew, why don't we start with the introduction of MURRE, and return at a following meeting

MURRE

Andrew: I think it would be best to postpone until next meeting
... it is basically a mechanism to get granular data for ML applications
... latter half of document
... relatively simple, but I will save that for next week
... if you have questions, you can open an issue or email me at andrew@nextroll.com

Wendy: Get a link there

<apascoe> https://github.com/AdRoll/privacy/blob/main/MURRE.md

Wendy: thanks for sharing that
... maybe get some discussion going before the next meeting

TPAC follow-up, any breakout or other group reports?

Wendy: with the last nine minutes or so
... I want to thank everyone who participated in our TPAC virtual F2F and for the range of discussion afterwards and the breakout sessions
... I sent the minutes of those discussions
... a lot of great discussion; minutes contain links to the presentations
... thank you to all who participated in the discussions, presentations, scribing, and contributing to lively conversations
... I wonder if people have feedback on items to take forward from those discussions
... or reports from other discussions you may have participated in

charlieharrison: I think that at our...
... related to the TPAC conversation we had on conversion measurement we had on WiCG
... attendees from web adv group

<kleber> Charlie's GitHub Issue: https://github.com/WICG/conversion-measurement-api/issues/80

charlieharrison: want to advertise there is a Github issue
... linking here
... thanks, Michael
... Feel free to take a look at that issue
... maybe we organize something once every two weeks just related to that measurement proposal

Wendy: Thanks; great initiave
... at any point when you want to move a proposal to some additional synchronous discussion

<btsavage> I appreciate that the times listed are in GMT =)

Wendy: the web incubator CG has

<btsavage> but I expect all ya'll will be surprised by British summer time

Wendy: and privacy CG can do ad hoc calls
... great way to dig in further

<btsavage> which is one hour off of USA time

Basile: just a small thing

<btsavage> a week of the year or so

Basile: there was a discussion about certification of servers
... I had impression some interest in discussing it
... we are preparing a document explaining in detail the role of the Sparrow gatekeeper
... and how it can be audited
... potentially this could be another meeting
... to discuss it
... we think it's important to know there is a trusted server
... we are working on this now
... in future we hope to have some news

Wendy: excellent, we look forward to seeing that paper and discussing here or pointing to another slot where the discussion may continue
... anyone else?

AOB

Wendy: Any other business?

Dave: I was going to
... I'm working on registering for the origin trial on Chrome
... forgive me if this is in the documentation somewhere
... but since right people are on the call
... where can I find the testing strategy?
... Questionnaire for origin trial...not clear to me
... for a percentage of traffic for the domain
... not clear to me how the testing is being done

Charlie: I think our documentation could use some work
... not sure if you saw the blog post we posted on @
... on how to use the conversion measurement API

<charlieharrison> https://web.dev/conversion-measurement/

Charlie: we are also working on a follow up blog post going into the nuts and bolts

Dave: I will read it; but I want to register to participate
... I don't understand the questions that are there
... and not misinterpret how our conversions are going down

Charlie: not affect your site
... once you register, you will get an origin trial token; then insert into the DOM

<mjv> https://web.dev/origin-trials/

Charlie: enable API to test on those clients
... that is how the flow works
... should not affect existing code on the page

Dave: thanks

Wendy: Glad we can offer some tech support
... thank you all for your participation
... we will have MURRE back on the agenda next week
... and other agenda items as people suggest them

<wseltzer> [adjourned]

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)

Succeeded: s/@:/Remi:/
Succeeded: s/prebid/open source, as in prebid/
Succeeded: s/fence frame/fenced frame/
Succeeded: s/cash/cached/
Succeeded: s/turnstyle/TERN-style/
Succeeded: s/@/data leakage/
Succeeded: s/@/Tom_Kershaw/
Succeeded: s/these things/help various bid mechanisms to/
Succeeded: s/Ben/Brad/
Succeeded: s/condition/relationship/
Succeeded: s/wrong @/ranking/
Succeeded: s/@:/Brad:/
Succeeded: s/contributed/audited/
Succeeded: i/Any other business/Topic: AOB
Present: Karen ErikAnderson brodriguez ionel_EDAA jeff_burkett_gannett br-rtbhouse wseltzer wbaker dialtone pbannist tomkershaw btsavage lukwlodarczyk Mike_Pisula_Xaxis arnoldrw jrosewell bleparmentier kleber mjv seanbedford blassey mserrate jonasz Dinesh-PubMatic lbasdevant joshua_koran imeyers bmay charlieharrison eriktaubeneck ajknox pl_mrcy dkwestbr gendler hober
No ScribeNick specified.  Guessing ScribeNick: Karen
Found Scribe: Karen Myers
Agenda: https://lists.w3.org/Archives/Public/public-web-adv/2020Nov/0007.html

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.)