<wseltzer> present=

* Agenda-curation, introductions

<scribe> scribe: Karen

Wendy: any introductions?

Tony Schwartz, from @ Botanicals

CTO of Criteo

* Frequency Capping and Multi-Channel Attribution

s/CTO of Criteo Jean-Baptiste

Russell_Stringham: I have two proposals, brief introduction
... first one is simpler of the two

<wseltzer> https://lists.w3.org/Archives/Public/public-web-adv/20CharlieHarrison0Aug/0005.html

Russell_Stringham: Frequency capping and frequency optimization
... a number of proposals require browsers to keep track of ads
... if browser knows which ads have been viewed
... it is easy for when a new ad is sent, browser can check to see if ad has been seen previously and how many times

<wseltzer> https://github.com/W3C/web-advertising/blob/master/frequency-capping-and-optimization.md

Russell_Stringham: would be easy to pass along a frequency cap
... if too many times displayed, then a different ad would be displayed
... a number of techniques to use
... first one past its cap
... advertiser or ad network could send multiple ads, not over cap
... an extension would allow for frequency optimization
... goal of this is to...
... certain ads are most effective when someone sees if 5-10 times
... get into sweet spot of number of viewings
... may favor showing the same one again vs not showing
... if knowing if previously seen by browser
... know if ad should be prioritized
... but not the minimum number of desired times
... put in a number of ways
... one that goes along with proposal we have been discussing
... in browser bidding function
... the desired min and frequency cap
... along with number of times ad is viewed could be parameters to adjust the bid
... if browsers are going to implement Turtledove, seems that frequency capping and optimization
... Facebook has a proposal regarding
... viewing of ads by browsers by users....can be reported
... that functionality could easily be used here
... that could apply
... to number of times seen ad, but across all linked browsers
... advertisers want you to see not too many times in a single browser
... answer any questions

Wendy: Michael

Michael: thank you for the proposals, Russell
... as you said, my Turtledove proposal has something in there for frequency caps
... Turtledove could support a freq cap supported by browser or with custom JS
... to make it work however you desire

<lukwlodarczyk> I believe we also moved to this use case in https://github.com/WICG/turtledove/issues/44

Michael: agree it's a reasonable part of Turtledove prosoal
... harder for a contextually targeted ad
... ads that are chosen by Turtledove targeting mechanism need to be blind rendered in a certain way so not
... individually reported
... only get aggregate reporting
... that will impose difficulties on ad networks
... had not required ad rendering flow
... contextually targeted ads could be used to re-identify people
... could show people a bunch of some ads
... and use that to figure out who the person is
... if we are willing to take hit for Turtledove or only doing in a blind way
... will be harder to write these ads than using aggregated reporting

Russell: agree
... there is risk if you don't use the aggregate reporting

Michael: let me say one thing
... for contextually targeted ads
... we have talked to some pepoel
... who felt like a site-by-site frequency cap
... does not have a privacy problem
... limits number of times seeing on one site
... but poss of hitting freq cap on any one site
... most people don't visit that many sites in a single day
... might be a global replacement
... if you don't want to incur blind rendering and aggregate reporting

Russell: totally agree with you
... being able to support this functionality and losing the ability to know which ads were rendered

Angelina: I think that
... some considerations need to be made, when running programmatic
... low frequencies to hit right conversion rates
... we sometimes reduce to pretty low across multiple sites
... need to manage across publishers
... there has been campaigns I have run where we want to reduce frequency across multiple sites
... one of optimizations we use to reduce cost per conversion and cost per click costs

Russell: when contextual ad, ad network could specify if immediate feedback or aggregate
... could affect ad chosen v one that's not
... allow freq cap and optimization when that is what the advertiser really wants
... delayed reporting has been discussed previously
... possible to go over ad budgets when there is delayed reporting
... produces problems for advertiser

Angelina: Ability to do sequential messaging; weighted creative; things like that are important for marketers doing A/B split testing
... also attached to this conversation is split testing, customization
... a lot of marketers would like to continue to do this

Russell: i see those as useful enhancements to a proposal like this; see about how to include

Wendy: Thank you
... move to second proopsal

s/proposal

<wseltzer> https://github.com/w3c/web-advertising/blob/master/privacy-preserving-multi-channel-attribution.md

Russell: second one is more complicated; one Adobe uses
... multichannel attribution
... not just ads person viewed, but all the interactions the advertiser had
... could include emails sent
... as well as push notifications
... if they get a chat session on the web site
... all of these types of interactions that contribute to the conversion
... advertiser knows about these, but don't know what user viewed prior to the conversion
... if you don't know what ads were viewed, you cannot understand how interactions play out
... how to figure out how to do budgets
... Adobe customers use this functionality to allocate budgets across the marketing channels
... extend the cross-browser anonymous conversion
... as well as other interactions with advertiser prior to conversion
... and how much those contributed in aggregate
... cannot see for indiv user but can see in aggregate
... just as cross-browser anonymous conversion reporting
... way it works, it shares which ads have been viewed on other browsers
... one of risk if browser is not owned by user, then malicious actor learns about other ads and views
... not have malicious browser view
... share a lot less personal info between the browsers
... when a conversion occurs
... and browser shares the conversion ID and advertiser name and time stamp
... through the mechanism
... that allows the other browsers to see if
... when other browsers see if conversion occurred
... see if that browser displayed other ads
... and sends a conversion report
... to the reporting origin
... where that data can be aggregated as described by the helpers as described by Google
... advertisers can send reports indicating which email campaigns sent and times
... user interactions can be sent to the helpers that calculate the attribution and return the aggregate results back to the advertiser
... to see which ads, email campaigns, which CharlieHarrison
... to overall conversions on their site
... that is basically the proposal
... more complicated, but also valuable
... any quesitons?

charlieharrison: This is a use case I have been thinking about

Charlie: you mentioned mixing data
... with other info
... like emails and push notifications
... you can join with users, first party cookies, whatever ID
... a third class of info
... you might want to join up with ad views and interactions
... is like non-ad interactions you do across sites
... where you don't have user's ID
... like organic traffic links
... is that something you intend to support in your proposal
... if my friend sends me a link through app
... do we want that, or scoping to just direct advertiser impressions, email campaigns?

Russell: advertiser would like as much info for user journey to conversion
... when someone does a Google search and click on ad
... that could be captured in ad info
... click on search results that was not an ad would be nice to know that, too
... shows how SEO contributes to the conversions
... that would be an important aspect
... could include additional channels
... but not have so many that it enables you to re-identify the user

CharlieHarrion: when advertiser is not in control
... challenging to design APIs
... how to configure it
... unless every advertiser designs same way for control levers
... separate point to make
... overall architecture of this proposal
... seems like when we are talking, as a given
... we have this browser synching channel, like the FB proposal
... opportunity to take more advantage of that channel
... trade off with data that the browser is computing before sending to aggregation or ad tech and complexity of protocols
... attribution schemes...assigned based on credits, or linear model
... that seems easy to implement if browser sees that whole user journey
... if we trust browsers to synch data amongst themselves
... would be more private and easier to have browsers compute it before sending off to aggregation servers

[missed]

scribe: but so does sending to browser server have risk
... how much do we shove onto browser vs helpers
... one big caveat
... at end you talk about these ml approaches
... not sure relative priorities of rules based attribution and machine learning attribution
... different tradeoffs doing in helper servers and in the browsers
... both kind of challenging; opens up a whole can of worms
... I think generally this is something we should explore
... seems like some kind of attribution scheme for lots of events
... seems challenging to do in a privacy preserving way
... doing in helpers opens up issues for malicious helpers
... need to be very careful there on what kind of protocol to use
... that is my two cents
... just for data on browsers; if data on browsers at converting time
... anything stored locally like emails, we could add JS interface
... add aux data
... that might be relevant to conversion, way to enhance on-device data

Russell: don't know who user is
... until you check
... and see what push notifications, emails I have sent

can take some time to gather from external systems

scribe: not easy to get data at conversion time
... makes it challenging to get it all into the browser

Charlie: user browser site would be known
... you are saying there are flows where we can only join up what we know about you when you type in email
... and then do join using email address

Russell: yes
... that is a fairly common flow
... you know same person browsing site, but don't know until they check out for sure

Charlie: I see how that makes it harder to send data in synchronous way

Russell: my hope with the helpers
... is that helper code would be open source
... and that would allow
... us to be able to trust what the helpers are doing
... controlled by some sort of different orgs
... poss. non-profit orgs
... supported by advertisers, where the code could be reviewed and validated
... could provide more smarts to helpers themselves

Charlie: flexibility in how we design the helpers
... design we published a couple months ago on the two-helper architecture
... we did not need to trust that all helpers were honest
... there are lot of inherent challenges regarding malicious helpers
... makes things more difficult from computational pov; especially regarding machine learning

Robert, Neustar: a comment and general question

scribe: look at history of attribution
... way you approach attribution makes a difference in how models are incentivized
... question to Chrome team
... do you have a philosophy about attribution
... do you have one, or would we make a framework available where different approaches could be applied to?

Russell: i am proposing a lot of flexibility
... Google's original proposal suggested you could support some of the simpler models

Robert: could make brand advertising look good
... does Google have a philosophy to impose on system, or provide more general data availability

Charlie: I would not say we have a set philosophy
... we have two proposals out with privacy constraints
... I would not consider those the end all be all
... to enumerate what we proposed

<wseltzer> ... support the maximal use cases subject to privacy constraints

Charlie: we do have the event-level conversion API that supports a last click attribution scheme
... where last clicked ad gets weigh of 100 percent where @

<charlieharrison> https://github.com/WICG/conversion-measurement-api/blob/master/AGGREGATE.md#multi-touch-attribution-mta

Charlie: in aggregate API we have a section
... what I described earlier
... a way of when a conversion occurs
... we have a process to look on browser and do any sort of algorithmic weight on that, as long as done in aggregate way
... maybe could be hard coded, linear, last click
... theoretically could be very general
... JS function could allocate weights
... and have any scheme you wanted if it's pre-trained and executed in browser in privacy safe way
... that is the easiest way to think about multi touch attribution
... anything more complex
... is something we are interested in exploring, like on the helpers; but caveat it will be more complex
... on device might be an easier solution
... would not say that we have a philosophy; more on privacy constraint

Robert: we are thinking attribute proposals; to apply a pre-trained model is difficult
... last learning it would have done
... some ability to learn effectiveness on an ongoing basis or we are jumping back to 1997

Russell: end of my proposal suggests the two helpers could share a subset of the data with a third helper applying ML for the advertisers data set
... and be able to understand their appropriate weights
... and compare the various algorithms to see which are most effective

Robert: thanks

Jonrburns: hello everyone
... I represent Shopify
... ask about a podcast...interview with GM of Google ads
... he said, "we'll only phase out third-party cookies if we have tools....[missed]"
... I was hoping to get perspective on what I have heard for a firm timeline for privacy sandbox

<jonrburns> https://www.adexchanger.com/adexchanger-talks/google-ads-gm-jerry-dischler-on-a-cookieless-future-that-happens-when-it-happens/

Jonrburns: hoping someone from Google could comment

Wendy: we have said in past, not to get specific timelines from people on the call
... we are focused on the use cases and proposals and discussions on what we can make work
... don't want to put someone on the spot for product development strategy
... I think if you have specific gaps
... and places where you think it is going to be difficult to do that replacement, let's dig into the web platform to see what else we need to be building

jonrburns: I understand that approach
... this seemed a very divergent message from what we have heard
... I understand if no one is available to comment

Wendy: thanks for that pointer
... Russell, thank you for those proposals. Sounds like you got some good feedback

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

Wendy: Looking at the use cases, matrix, seeing where
... there might be additions, or pointers to add in
... and looking at the use cases
... I wanted to ask
... see that there are some pull requests
... that are waiting for review
... so Ben, as you are initial drafter of use cases document
... do you want people to ask for review or have people merge their own pull requests?

[Ben not on call]

scribe: apologies
... I think that he had suggested previously that people could feel free to merge their own pull requests

* Summer scheduling and vF2F in the fall, TPAC?

scribe: with a little bit of time remaining I would like to raise question of summer scheduling
... should we take a break or meet less frequently as we get into vacation season?
... Like feedback on the mailing list

AramZS: make a suggestion
... Ben doesn't need to approve every pull request
... I know some folks are not as comfortable doing pull requests on GitHub
... maybe give feedback on any pull request; be more collaborative
... and help out anyone who might be less experienced
... before merging yourself, provide feedback
... does that make sense?

Wendy: That sounds good to me
... shows changes and opp to comment on the changes incrementally
... I'd invite people to look at those
... if you are making a pull request and want to tag someone specific for review
... that is a solution
... thanks

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

Wendy: the other scheduling oint

s/point

scribe: in the northern hemisphere Fall, W3C holds its annual Technical Plenary and Advisory Committee (TPAC) meetings
... this year will be virtual
... WGs, IGs, BGs invited to schedule meetings in the span of a week
... with particular focus on cross-group or open participation
... in a F2F meeting, the WGs and other groups meet and invite observers to participate
... we're looking to replicate that experience in the week of 12-16 October.
... Second piece of meeting is a virtual set of break-out sessions where anyone can propose a subject for discussion, put up on a scheduling board
... and we attempt to map to time slots
... without too much conflict and invite anyone from community to participate in those
... We can as a group schedule a working group/business group virtual F2F for a longer period of time if we would like
... and as a group or individually we can propose sessions for the virtual breakout week [26-30 October]
... that's a heads-up for those opportunities
... look towards this period for some stock taking and next steps
... we had talked about a F2F meetup
... but hard to predict when we might do that again
... the virtual F2F where we take a longer period of time and plan out more of an agenda looks attractive
... Should we think about taking a couple of days of multi-hour blocks of time
... and put together an agenda that gives us a bigger picture of the work we have done, what's ahead
... where we see things moving into working groups and further down a standardization pipeline
... if anyone has any immediate feedback would welcome
... or comments or ideas for shaping those meetings
... thank you Kleber for your 'let's do it" comment
... I will share more thoughts on the mailing list

Michael: Aside from yes, we should do TPAC
... let me point out that some of the proposals we have discussed here have moved into incubation in WICG and Privacy CG; those groups will likely have dicussions
... we have been invited to discuss with WICG
... won't be the only opp to dive into proposals that we have discussed ehre

s/here

Wendy: Thank you for reminding me
... it's an opportunity to see other groups working on related material
... or see places where our work might go in the future
... we will work on compiling a schedule
... the W3C events team will compile an overall schedule
... and see which groups are most likely interested in the work here; opp to ask for joint meetings with others we'd like to talk to
... promote cross-group participation
... more to come

Joshua: having that larger group with more time, and inviting the others in incubation groups would also help them get input from a wider group of stakeholders
... I am in favor of wider meeting going across more groups

Wendy: Very good, I will start some work in a GitHub page to start thinking about what an agenda should look like and with whomelse to meet
... we are at the end of our time
... thank you all

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

WARNING: Bad s/// command: s/CTO of Criteo Jean-Baptiste
Succeeded: s/@/Russell_Stringham/
Succeeded: s/allows/has a proposal regarding/
Succeeded: s/@/indivualld reported/
Succeeded: s/rendered/blind rendered/
Succeeded: s/indivualld/individually/
Succeeded: s/frequency for caps/site-by-site frequency cap/
Succeeded: s/site that many times/that many sites/
WARNING: Bad s/// command: s/proposal
Succeeded: s/2/CharlieHarrison/
Succeeded: s/@/charlieharrison/
Succeeded: s/@/CharlieHarrison/
Succeeded: s/pmissed]/can take some time to gather from external systems/
Succeeded: s/based on email/when you type in email/
WARNING: Bad s/// command: s/point
WARNING: Bad s/// command: s/here
Succeeded: s/PING/Privacy CG/
Present: krischapman ionel_ wseltzer shigeki Karen mjv ajknox mlerra seanbedford wbaker___ Diarmuid_Gill hober kleber pedro_alvarado bmilekic imeyers joshua_koran Alan dialtone Chapell pbannist sharkey-cafemedia cpn tomkershaw btsavage ddabbs aschlosser jeff_burkett_gannett cwilso AramZS
Found Scribe: Karen
Inferring ScribeNick: Karen
Agenda: https://lists.w3.org/Archives/Public/public-web-adv/2020Aug/0007.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.)