<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?
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
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
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
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?
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.)[End of scribe.perl diagnostic output]