Meeting minutes
<wseltzer> https://
<dmarti> +present
Wendy: welcome
Wendy: As people join, take a look at the agenda
… please mute if you are not speaking
… thank you
… we asked for an update on private click measurement
… and John Wilander is going to speaker to that
… and on dashboard, other topics; any other business?
… to put on today's discussion or raise for a future conversation
… remember to please join the irc channel and "present+" to add yourself to record
Agenda-curation, introductions
Wendy: and "q+" to ask a question
… Is there anyone new to the group who would like to introduce themselves?
PCM - webkit
Wendy: So let's go right to our first agendum
<wseltzer> https://
Wendy: John, thank you for joining us
… See you published a blog post on introducing private click measurement
John: Thank you so much
… John Wilander from Apple WebKit here
… we published that blog post with first Beta with iOS14.5
… I believe MacOS is 11.3
… which also have PCM, private click measurement
… can I share screen?
[shares screen]
… this started in May 2019
… mentioned under "proposed standard"
… called privacy preserving ad-click attribution
… in interest of clarity we changed to private click measurement
… not a direct reference to ads
… desire from W3C TAG
… that we don't use advertising terms and lingo in these proposed standards unless there is a real technical tie to advertising
… PCM is not restricted to measuring ad clicks...any click can be measured with it
… you might note that in tech things like attributes and tech labels
… they don't mention ads in terms like conversion
… It is on by default in beta and in Safari preview
… allows for privacy preserving measurement across ad sites
… you can tap and ad and go to a web site with the same kind of triggering function
… iOS app is not a proposed web standard
… in Privacy CG, where this lives
… in Github
… proposal had six bits
… you could encode your ad campaign, run 64 parallel campaigns per site
… and six on the conversion side
… distinguish 64 conversion events down a sales funnel
… the more bits of entropy you have, the more closely it gets to a tracking vector
… that's why it's limited to be privacy
… in Privacy CG
… advertisers and adtech folks said in this trade-off
… it's more important to run more parallel ad campaigns
… so two bits were moved
… to the click side, the source side of this
… so now 256 parallel ad campaigns can be run and measured on web
… and conversion side reduced to four bits
… so 16 conversions
… One of major feedbacks we got
… is there needs to be fraud prevention, which comes in many forms
… all fraud will not be solved, obviously
… having capability to send trust from click side and also conversion side
… and have it part of attribution report
… for example the ad network thought it was a real organic click
… or as merchant I thought it was a real click
… this has been discussed
… it will use blinded signatures
… have cryptographic signed proof going into this
… not in beta today, will come in later phase
… Also see here
… on click side
… you can see how things have changed in terms of naming
… what was ad campaign ID is now attribution source
… attribute on was @
… this is also from TAG
… they wanted us and Google to harmonize these things as far as possible
… so Google's conversion measurement and private click measurement APIs will have as few differences as possible
… intention is Google will use the same names for these
… and potentially adding same name for their 64 bit identifier
… Also wanted to mention here
… get down to report format
… this is what report format looks like
… part of the standards conversation in Privacy CG
… original May 2019 encoded this in URL; had path components signally attribution report
… now an http post with @ structure
… we can use same report format for future measuring
… maybe for through attribution
… saw with linked format
… and have attribution trigger data, what people refer to as conversion value or conversion ID
… and add a version label to this
… as we evolve this, adding tokens I mentioned
… so server can know something has changed
… I need to interpret this data in a different way
… and stay on top of this standard
… here is a picture how this works for apps
… links don't natively exist in apps, but app makes call to URL to make navigation happen
… I think that's it
… if you find any bugs, please file them and test them
… that is our chance to change
… you can file and open source bug
… and see how issue is tracked and handled
… future enhancements we are tracking in PrivacyCG repository
… the fraud-prevention tokens I mentioned
… and relies on tracking pixels
… to make adoption easy
… existing tracking events uses pixels
… trigger same for PCM
… like to get to a modern JS API to trigger
… and that will allow merchant to be in more control
… or just convert for a subject
… those are ones I'm measuring for this conversion
… depending on which tracking pixels you are firing; will be cleaner with JS API
… remove tracking pixel requests all togehter
… content blocking won't affect this; you are calling an API
… instead
… We have said we want to send these attribution reports to advertisers, too
… currently sent to source
… report doesn't rely on opaque data
… source ID can be understood by click source and destination
… support requests in nested iFrames
… I thinks that's it
… there is a FAQ section, but open up for questions here
<wseltzer> https://
<charlieharrison> our PR with the naming changes is here:
<charlieharrison> https://
Ben: hey, John
… start by saying thank you for listening to feedback on fraud prevention from the industry
… thanks for working on that
… love for the Chrome team to have a similar conversion fraud mechanism as well
… and for listening to industry on moving the bits around
… and for supporting the use case for app to web
… and will call out also
… the iView overlay
… that allows iOS to stand behind those
… click-stuffing is large source of conversion fraud
… currently proposed API seems to have a good prevention against click stuffing
John: you are right, we have a user gesture check
… in the web-to-web and web-to-app case
Ben: this is future of adv
… doesn't make clean distinction between web and apps
… my requests for future
… plug for Github issue I raised
<btsavage> https://
Ben: which we also brought up in Privacy CG
… a lot of people don't have own independent web sites; use a hosting provider to make bus available to Internet
… if they pay for domain and pay for hosting, they could use this API
… but currently they cannot
… we can measure clicks from ETSY, but not for their specific shop
… give them this same calibre of measurement
… Second thing is this webview problem
… had a great talk at conversion measurement weekly with Charlie, Criteo and others
… Google were conceptualizing as an @ experience and I was thinking an App experience
… maybe think 3x3
[missed]
… Interest in measuring conversion that happened on web sites
… quite a few publishers
… Aram is on the call
… I image WashPost shows ads and would like to have some form of measurement
… Prioritize in this 9-cell grid; what is prioritization
… good to have two of those cells
… leave it there
<AramZS> Yup hi!
Wendy: Thanks, do you want to respond?
John: we do cover WebView in the FAQ
… to see what we wrote on the topic
… we also mentioned request to support Safari ViewController
… and Android has something similar
… more on an in-app experience; maybe grid will be more of a four by four
Kris: thanks for taking questions
… I come at this from a non-adv use case
… trying to track clicks in email campaigns
<AramZS> And yes, we do have a big interest in webviews working consistently with the browser.
Kris: wondering about
… that well-known URL you are using for pixels to send requests back
… any restrictions?
… I don't want that stuff to go to gmail
… prefer it go to either the brand or something like that
… second part was that source site aspect
… would you consider it gmail if opened in a web client or something else
… Has there been consideration for email clients?
… not everything is in web browser
… wondering what you thought about that?
John: That has not been brought up
… we covered web-to-app and app-to-web
… there needs to be tap signal, source ID
… link to take user to; then you are on a web site
… there would have to be a way for either email clients to adopt some tech
… and feed web browser with this meta data when I know that a tap or click is for something to be measured
… maybe the click format itself
… but then that takes us to place that may open up to fraud
… want that gate
… and make sure it's a deliberate thing
… source application, social media or email client
… this is a destination that the site wants to measure
… I'm absolutely open to talk about how to measure for email
Kris: I would prefer to have folks sending it collect it, rather than email client
… that standardization aspect
… sometimes mobile, email, or web
… easier to have it be standardized
… and substitute in a URL or location for it
… I will raise the issue and we can talk about it more
… thanks, John
Marcel: In the triggering event
… it seems the advertiser needs to add publisher pixel on conversion page
… when in the open market, adv can place his ad anywhere
… doesn't know where publisher is going to present his ad, how is that supported in PCM?
John: there is no blanket way of doing it
… that has been discussed in terms of modern JS API
… doesn't exist yet
… we drafted it in earyly explainer of this feature
… call API with a wild card
… asterisk - convert for all things I want
… done through all these pixel requests
… redirect makes it possible to tell browser this is triggering event; needs to be same-site
… and go to well known location
… and be in control if I want to do this
… otherwise someone else can make request and flush pending reports
… consume stored ad clicks
… thinking of it...
… interesting question
… this whole tracking pixel thing is meant to support existing stuff
… told early on that adv and merchants
… are often slow to adopt new tech
… may not have developers, not that interested in leading edge of web tech
… we heard people raise issue that this could take years to roll out
… if dependent upon a JS API
… only way to get this private click measurement working
… that's why we worked to figure out a way to take existing implementations and repurpose this
… not that tracking pixels are great
… I would prefer not to keep polishing the pixels
… we would like to get to modern way with JS API as quickly as possible
… what you are describing may need to wait until we have that API
Wendy: I queued up
… lots of conversation going on in the Privacy CG
… thanks for your acknowledgement of it there
… and thanks for you and the Google teams engaging with TAG
… looking to harmonize the proposals and work
… pointing toward pathways to a potential web standards
… where implementers who want to see greater implementation can partiicpate
… and express their interest in things that converge
… in feature sets available across the web
… and to prepare that for something that could be put into a working gorup
s/group
… this business group is good place to discuss common requirements
… and then to go into the implementation discussion
… with questions of how can we harmonize those, how can we bring those back to a single standard
… and W3C stands ready to shape that in a working group at the right time
Charlie: Question for you and some of members here about the legacy pixel triggering
… one of my concerns with removing this in the long-term
… concerned this JS
… even if run on adv domain
… or adtech provided script
… a lot of advertisers aren't savvy enough to run own measurement solutions
… concerned that some adv may be wary to run third-party JS vs triggering a third-party piexl
… especially on sites like financial institutions that have sensitive info
… in some ways, pixel has better characteristics than JS
John: Absolutely; looking at issues in github
… no fan of third-party scripts running on web sites
… we had proposal that spec should allow browser to restrict to true first party scripts
… not distinguish if came from first or third party
… could see this coming in browser engines in future
… being discussed for security reasons; diff privileges for diff scripts
… could restrict...not sure if we went into policy discussoin
[missed]
… tracking pixels have other negative things; going to block this; not with intent to block privacy measurement
… but blocking third-party things
… one concern I heard and share to some extent
… also a network request, unnecessary
… could fail or be slow, consume poer
s/power
… fewer network requests to endpoints is better
… will be a long time to sunset tracking pixels to fire the triggering event
… since sites are slow to adopt
… that could be a reason for slowly taking it away
… I would rather get to JS API for other reasons
Charlie: If we move to JS, do so in way that is compatible with adv needs
… work on permissions
… make sure JS based conversion measurement will not block out big financial institutions from measurement
John: We tried our best to not make this more complex than need to be
… if we move this part of the web to a better place
… it needs to be as easy as possible
… will it be harder to adopt? we need to make it super simple
… and support more complex cases for those who want it
Angelina: As someone who has dealt with 250 adv to place pixels
… especially financial services and insurance
… most do not allow JS; only HTML code allowed
… typically tech team is not living in our world
… asking them to place pixels takes 3-6 months to deploy
… have to go through whole bunch of compliance questions; declare they are not doing certain things with pixels
… for just one plxel being placed on the site
John: those are good pieces of feedback
… going back to financial institutions not adding pixels
… hot-loading JS over domain, not giving power
… I worked for a major bank and know you don't want to do that
… could also be in-line JS
… could be trigger event, wild card @; will store all ad clicks
… could add pixel and look better
… web site would not make third-party requests
Angelina: I agree, but it will take a lot of education to get them to understand the use cases
… the educational gap is pretty huge
… I ran analytics inside MorganStanley and it took six months for them to understand the standard pixel and what it does
… will take time
… I do recommend
… looking at Google tag manager; good idea to collaborate with them to deploy in easier way
… benefits of server to server on back end make it easier to control rather than place JS on the site
John: Makes me think that not only a JS API but a same-site pixel API
… don't have to make third-party request, they call their own server and convert stored clicks
Angelina: how do non-domain holders (affiliates) work?
John: I think we mention it in this blog post, also in github repository in Privacy CG
… For this to be privacy preserving, reports should go to first parties involved
… click source and adv web site
… if we support sending reports to third-parties on either side or both
… that cannot be gained by user devices; and not to bucketize
… boost number of bits
… by setting up specifically
… North America west, east coast; entropy to report
… we discussed recently; I filed issue around that
… poss restrict to single third party for web site
… outside your org
… so it will be feteched
… and serve up a custom report
<wseltzer> https://
John: and only send to registerable domain
… so sub-domains are not set up
… existing feature only uses two first parties involved in the click
Kris: I was responding to Charlie's call for feedback
… say two things on that
… regarding JS, it is not supported in all of the environments that are involved in this click attribution
… one case is email
… IoT
… and how that works
… one client is using a toothbrush connected
… to activity that goes onto activity in web site; they do use pixels in that situation
… feedback wise we have to be careful to only go to JS only
<kleber> NOW I WANT A JAVASCRIPT-ENABLED TOOTHBRUSH!!!
Kris: also had clients form Salesforce
… not like everyone is wild about having pixels firing everywhere
<jrosewell> kris_chapman: agree with your comment about avoiding requirement on JavaScript.
Kris: but also a lot of concern about JS firing due to page load times
<AramZS> lol
Kris: it will have some issues with 40 or more firing
… smaller players will be pushed out
<AramZS> Wait the toothbrush can't use Javascript but it can load an image?
Kris: larger players will have an easier time getting JS onto sites to get that data
… feedback mechanisms
John: Thank you
<eriktaubeneck> I wonder if that toothbrush can run Doom...
Ben: John, you mentioned there is that one field for attribution type for click
… which can be extended to @
<jrosewell> kleber: JavaScript toothbrushes have promise.
Ben: did you look at proposal from FB for ads no ads measurement
… to measure the true value
… not using some heuristic
… possibly use that field
<Jordan> use the toothbrush too much and you get bluetooth
Ben: would require a one-bit
<AramZS> I sorta want an open source IoT toothbrush technical specification now.
Ben: not need 8 bits; just need one
… ads, no ads...
John: getting triggering event regardless, at time of conversion, no knowledge of pending clicks in browser
… part of sales funnel, browser will see them
… in that case, send an empty report or a one-report signal and no stored ad clicks that led to that conversion
Ben: you construct two randomly constructed groups; one to show ads, one to not show ads
… this is a click for attribution; or this is an opportunity
… some see ad, some don't; you tell browser both
… someone who did, someone who did not see ad
… same way PCM lets you get aggregate count for 256 buckets; you only need 2 buckets
… one for those who saw ads, one for those who did not
… trustworhty spot
… show ads to people who were going to buy or not
… what is diff between ads or no ads
… same mechanism, same modern JS
… to measure ads/no ads
John: I see what you are saying; a very restricted view through attribution
Ben: yes, the view no ad group saw no ad
… impression start, impression stop
… browser cannot determine if viewable
… send a signal that is not able to be verified
John: I would think no ads doesn't require a call
… not showing shoe ads
… absence of a positive signal would be interpreted as a negative signal
Ben: no, you would have mis-matched groups
… let's say you are running ad campaign
John: It's a deliberate decision
<LonPilot> A/B testing?
John: now I get why you want the signal
<angelina_iab> great point BEN
Ben: Why you want this balanced
John: 50 see ad, 50 don't see it
… sounds like...please file it
… sounds like a whole new feature, not PCM, but tied to it
<GarrettJohnson> Thanks, Ben. Experimentation use case is really important.
John: sounds like a new feature; please file it
Ben: Click would be a mis-nomer here
Wendy: thank you
… anyone else?
… Thank you very much for that presentation, John, and the blog post
… Issues are being filed in the Privacy CG and sometimes comes up on Privacy CG calls
Brian: I am not deeply familiar with the proposal
… based on what Ben said
… does it make sense for whoever is creating pixel to allow them to determine how to allocate the bits
John: we did consider a dynamic allocation scheme
… four bits signed to either side for example
… we did not go with that because we did not hear a lot of requests
… would have added to complexity for implementers and browsers
Wendy: I think we are at the tend of that topic; thank you very much
John: Please test out the feature and file issues if you find them
Dashboard highlights? https://w3c.github.io/web-advertising/dashboard/
Wendy: in our remaining six minutes, does anyone have items from the dashboard they would like to propose?
… Or to call our attention to items to discuss at a future meeting?
Ben: we were talking about click-stuffing and click-fraud
… maybe go deeper into that topic
… and invite people from fraud space to talk here?
@: yes
Aram: yes
Valention: yes, from NextRoll
Wendy: Thanks, Ben
… if you want to start an issue to gather other ideas, feel free
… and feel free that we discuss it on one of these calls
… sounds like a relevant subject
… or at another side meeting
<pedro_alvarado> yes
Ben: I'll follow up on email list
Wendy: Terrific
… generally, if there are additional experts or folks to bring in to discuss a particular subject, you are welcome to recommend that to us
… we benefit from hearing insights from those studying particular topics
… that's great
… we'll keep looking for agenda requests
… I don't think we have anything specifically queued up for next week's meeting
… Let's see if other proposals that have been percolating come forward
… with that, we'll see you next Tuesday, 16 Feb
<wseltzer> [adjourned]
Wendy: and Kris, we may need info on that IoT toothbrush!