Update naming and terminology according to the layering effort with Google's Conversion Measurement API #75

johnwilander · 2021-03-09T01:51:04Z

No description provided.

private-click-measurement.bs

hober · 2021-03-09T21:14:29Z

private-click-measurement.bs


 <xmp class="highlight" highlight=html>
-<a adcampaignid="17" addestination="https://destination.example/">
+<a sourceid="17" attributeon="https://destination.example/">


Some thoughts on these new names:

I liked that the previous ones had a common prefix, so you could tell they were related.

sourceid, in particular, seems weird if you don't know anything about PCM. It would be fair for someone to wonder if/assume it's the ID of this element in some source document, which for some reason got moved into this attribute from id="" by some tool.

Similarly, attributeon sounds like it's about HTML attributes.

I'd like @annevk's or @domenic's thoughts on these new attribute names.

My mistake on sourceid. It should be attributionsourceid. That's what's implemented in WebKit.

attributeon has been cringe-worthy all along but the Google folks wanted it to be "attribute-on" so it's called "the attribute-on website":
WICG/attribution-reporting-api#57 (comment)
Referenced in the PCM issue on naming:
#56

We'd be happy to re-engage on those issues if a different naming is more appropriate. My apologies if it came across as though our mind was made up on the matter, that wasn't the intention.

Given the benefits of having a common prefix raised above and using "source" for the click side, attributiondestination may be a better fit (which was the original name on #56). "attributionsite" is another name that solves the above issues and mixes well with prose.

Changing attributeon would likely be a breaking change in WebKit. We've been in beta for five weeks with attributeon.

I like attributiondestination much better than attributeon. Would Google Chrome be willing to change to that?

Yes, we're supportive of the change. I will file a PR against the Conversion Measurement API repo to use "attributiondestination".

cc @csharrison @maudnals

Okay, I think you addressed both of my concerns in 8623b5d. Thanks!

annevk

I think attributiondestination would have been clearer. In particular the word "attribute" already has quite a few meanings and "on" is associated with event handlers. Not sure it's a deal-breaker though.

annevk · 2021-03-10T08:16:53Z

private-click-measurement.bs

 </xmp>

 Formally:

 <pre class="idl">
 partial interface HTMLAnchorElement {
-    [CEReactions] attribute DOMString adCampaignId;
-    [CEReactions] attribute USVString adDestination;
+    [CEReactions] attribute DOMString attributionSourceId;


Why is this not an integer?

Most IDs can contain (almost) arbitrary characters; I assume that's the case here?

No: https://privacycg.github.io/private-click-measurement/#ad-campaign-id

Oh, yeah, then this should definitely be an integer (probably unsigned long to take best advantage of HTML's reflection abilities).

I can’t find where but the reason I believe was layering. Google wants to be able to have far more entropy and might want to use more characters than digits. There was also talk of hierarchical IDs such as “low entropy value:high entropy value” that can either allow developers to have one markup that supports both or allow the browser to use one of the two or both depending on user settings or some privacy measurement.

WebKit has had this as an experimental feature since May 2019 and is five weeks into beta for official release. Changing it will likely be a breaking change for us.

In the Attribution Reporting Explainer, we use an unsigned long for the sourceeventid ( https://github.com/WICG/conversion-measurement-api#registering-attribution-sources-for-anchor-tag-navigations).

(this is an intentionally different attribute that attributionsourceid since it is higher entropy per discussions on #56 )

Sounds like unsigned long then. Hopefully, we won't have too many who've adopted PCM in WebKit browsers by the time we can get this change out.

@johnwilander for most uses of this API it might not even be a breaking change as JavaScript is pretty lenient.

Looks like 8623b5d addresses this concern, yeah?

domenic · 2021-03-10T16:43:26Z

I don't have any particular insights to add here. I did take part in some discussions with @csharrison about https://github.com/WICG/conversion-measurement-api and I recall there being a variety of complex tradeoffs in the naming, e.g. purposefully choosing an "attribute" prefix for "attributeon" that is different from the "attribution" prefix for the others.

…'s type to unsigned long in alignment with Tess's, Anne's, Domenic's, and John's comments.

hober

Looks good to me with the changes in 8623b5d.

johnwilander · 2021-03-18T22:29:29Z

Thanks, all!

For review.

c772ed9

johnwilander requested a review from hober March 9, 2021 01:51

johnwilander changed the title ~~For review.~~ Update naming and terminology according to the layering effort with Google's Conversion Measurement API Mar 9, 2021

hober requested changes Mar 9, 2021

View reviewed changes

Fixed Tess's comments.

72e460a

annevk reviewed Mar 10, 2021

View reviewed changes

Changed attributeOn to attributionDestination and attributionSourceId…

8623b5d

…'s type to unsigned long in alignment with Tess's, Anne's, Domenic's, and John's comments.

johnwilander requested a review from hober March 17, 2021 16:17

hober approved these changes Mar 18, 2021

View reviewed changes

johnwilander merged commit f7e51be into main Mar 18, 2021

johnwilander deleted the updateSpecWithNewNamingAndTerminology branch March 18, 2021 22:29

johnivdel mentioned this pull request Mar 22, 2021

Change "attributeon" naming to "attributiondestination" WICG/attribution-reporting-api#121

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update naming and terminology according to the layering effort with Google's Conversion Measurement API #75

Update naming and terminology according to the layering effort with Google's Conversion Measurement API #75

johnwilander commented Mar 9, 2021

hober Mar 9, 2021 •

edited

johnwilander Mar 9, 2021

johnivdel Mar 9, 2021

johnwilander Mar 9, 2021

johnwilander Mar 12, 2021

johnivdel Mar 15, 2021

hober Mar 18, 2021

annevk left a comment

annevk Mar 10, 2021

domenic Mar 10, 2021

annevk Mar 10, 2021

domenic Mar 10, 2021

johnwilander Mar 10, 2021 •

edited

johnivdel Mar 10, 2021

johnwilander Mar 12, 2021

annevk Mar 13, 2021

hober Mar 18, 2021

domenic commented Mar 10, 2021

hober left a comment

johnwilander commented Mar 18, 2021

Update naming and terminology according to the layering effort with Google's Conversion Measurement API #75

Update naming and terminology according to the layering effort with Google's Conversion Measurement API #75

Conversation

johnwilander commented Mar 9, 2021

hober Mar 9, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johnwilander Mar 10, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Mar 10, 2021

hober left a comment

Choose a reason for hiding this comment

johnwilander commented Mar 18, 2021

hober Mar 9, 2021 •

edited

johnwilander Mar 10, 2021 •

edited