Interaction with URL decoration

[nchrys]

Simplifying a bit, under the current setup (third party cookies being already blocked) post-click attribution would work this way :

1. The user (uvw) clicks on an ad by advertiser.com on the publisher site www.publisher.com
2. He is redirected to the URL www.retailer.com/product_id?click_id=abc&advertiser=advertiser.com
3. First party JavaScript (retailer.com and/or advertiser.com) has access to the URL decoration and can log the click (abc) with the local web id (lwib = xyz) stored in the first-party cookie of retailer.com.
4. The user (xyz) converts on retailer.com (conversion_id = 123)
5. retailer.com and/or advertiser.com can attribute 123 to abc (and thus to advertiser.com).

If I understand correctly, this process would still be valid under this proposal (and also TurtleDove and other privacy sandbox related proposals).

Thus, what is the incentive for the advertiser and publisher to use the "event-level API"?

[abebis]

I tried to discuss about that in the PCM (WebKit's proposal) repository.
privacycg/private-click-measurement#31 (comment)
This was clearly off-topic though, thanks for creating a specific issue.

Some talk about restricting link decoration here:
https://twitter.com/johnwilander/status/1227709639665606659?s=20
Haven't heard anything from Chrome devs about this though.

I guess click ids (unique per user) are not acceptable and known parameters are/will probably be blocked. ad/campaign id may be fine, but it's hard for browsers to make the distinction between click ids and campaign ids.

[csharrison]

Hey folks,
This API proposal is purely additive to the platform, and isn't the place to discuss things like restricting link annotation. This API should certainly be usable without relying on such techniques though.