Finally finished analyzing the @apple webkit proposal "Privacy Preserving Ad Click Attribution For the Web" from @johnwilander @ https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/ // I'm pretty excited about this proposal (while also slightly confused) / thread w/ my thoughts & questions:

My questions / conclusions:
1.) What about placement / impression optimization? How much actual money will publishers lose from not being able to optimize their placements based on immediate click-data? (minimal/acceptable I'd hope)

2.) 64 campaigns per XX days // hours? I got caught up in the math but I think the core concept is that at-scale, this entropy makes it impossible to really track people 1:1 // but super rural folks who visit your non-popular site at 2 am every day & click ads..maybe identifiable

3.) All the errors that can be thrown from a conversion that doesn't follow their REGEX needs a really big chart with more details. I couldn't figure out how Google Safe Frame was going to work on a publisher site - the debugging w/ 3rd parties is going to be pretty tough...

4.) Apple's statement that this plan, "Dramatically limits the entropy of data" is basically them saying, "we're okay if a random one-off person could be tracked, but this plan destroys tracking *at scale* and reduces ability to parse more than some limited amount of data flow.

5.) The on-device click sandbox is likely built w/ the same dark metadata they dropped in their Hardware Abstraction Layer (HAL - "i'm sorry i can't do that') - apple's on-device metadata filtering for Siri is processed & it's where they build pseudonymous user intent segments.

6.) Apple's "adDestination and adCampaignID" as basically UTM 2.0 with privacy scrubbers -- we all know that source/medium/campaign (and custom params) are what make it possible to identify anyone and everyone. Apple whittled those UTM params down to 2 params for privacy at scale

7.) 2 URL params - at what *low volume or scale* does this entropy break? The flaw with logic like this is that if you have a shitty campaign on a shitty website, with no conversions etc, you can easily still track 1:1. So "entropy at scale" needs lwo end clarity.

8.) Apple IPT 2.0 is blocking JS/cookies + largely breaking tracking. This proposal is Apple FIXING the cookie tracking but not by just turning it back on. It's apple saying that a 7-day window max tracking window + any conversion tracking must be done safely and privately.

8.) Apple created loopholes for 1st party ads… but they are confusing. They created loopholes for FB/Amazon and folks running native 1st party ads, but I don’t exactly understand how their architecture stops publishers from building interstitial pages per advertiser w/ redirects

9.) screen reading software could give publishers data about ad slots that users clicked on — using tech to see where a mouse was moments before the session unexpectedly dropped - that could be assumed to be a safari ad click on banner. This can be maybe* done with CSS not js...

10.) Safari is mostly stripping referrer / referrer header cookies — and then holding/tweaking those details in a private HAL repo on browser, and then pushes it back through a redirect and finally re-reveals the original referrer to complete the feedback loop on goal completion

11.) How many landing pages can an ad campaign have? One would assume that you could create thousands of landing pages unique per user or some other combo. I understand the limit of 64 campaigns, but what stops you from creating 100 landing page Urls for each campaign?

12.) The Javascript API sounds like a chromeless head window basically just pushing data from one server to server connection into a sandbox for pixels to fire and capture data. I’ve built something like this on a project … but it was complex! feels like 2040 job security

13.) Once an ad click has been consumed, it can NOT be re-consumed — which prevents double counting clicks and click-replay // IMO This concept needs to be deployed via HTML5 timestamps in video to create conversions based on encrypted HTML strings being injected into video feeds

14.)The well-known locations were used to make it easy for browser blockers and pi hole and other DNS blackholes … I think… it’s a consistent structure instead of millions of random Urls to block // Regex to the rescue!

15.) I think the thesis of Apple’s work was in one of the bullets, “The browser should offer a way to turn ad click attribution on and off.”
Personally i love that line and 10000% agree -- it's such a tough thing to accomplish but sandboxing the click data is f-ing brilliant imo

16.) The Ad Click Attribution Debug Mode shortens the processing delay to only 1 minute — and developers can test this locally. It’s very different than some types of conversion processing but even Google analytics goals had delays. It’s new, but it’s not necessarily any worse...

17.) I don’t understand, “Ad click attribution is only supported in the main frame” — this seems like it punishes Google safe frames and iframe banners like that… I’m confused by that open ended statement and how that works in practice..tbd!

18.) The syslog error messages worry me — I wish there was an “Error Replay” bc at least 1 of the errors can occur if the domain has a broken SSL. So if a site’s SSL goes down, 100% of the advertising click attribution requests will break with errors and apparently never replay.

19.) Apple’s filter to reject a URL protocol that has any query string/fragment/etc is going to be confusing for some developers to implement — a lot of servers have redirects setup that pass URL params for any Urls. Something here is going to break in production I think - TBD!

20.) Apple’s “conversion priority” + the fact they only send 1 conversion event means no more “glamor goals” like page views — orgs w/ fast funnels (layers of retargeting ads) will need to look at other data to understand if someone is shown X, Y, Z ads over less than 3 days.

21.) There is suddenly a new industry to help people map + plan binary-based schema -- that makes me very happy // There is a business model here — a big one— every business will have private schema and there *will* be best practices for how to craft 64-bit conversion events

I'll probably organize and file some of these pieces of feedback over at their github issues page @ https://github.com/WICG/ad-click-attribution/issues/ // The W3C proposal/feedback process @ https://wicg.github.io/ad-click-attribution/index.html // To the future of the internet! Fuzz away!