Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider reducing the ad attribution data budget to 3 bits #28

Closed
johnwilander opened this issue Dec 13, 2019 · 6 comments
Closed

Consider reducing the ad attribution data budget to 3 bits #28

johnwilander opened this issue Dec 13, 2019 · 6 comments
Assignees
Labels
layering Layering additional data and functionality on top of PCM

Comments

@johnwilander
Copy link
Collaborator

johnwilander commented Dec 13, 2019

(And bumping the campaign ID budget up accordingly.)

PCM proposes a 6-bit value encoding the conversion on the click destination side. The Click Through Conversion Measurement Event-Level API proposal has a corresponding 3-bit value called conversion-metadata. Ideally, we’d reconcile this into something simple for developers.

To discuss:

  • Would 3 bits on click destination side work across the board? PCM would obviously be fine with it since it reduces entropy.
  • PCM would probably consider a bump on the click source side to 8 bits if 3 bits were agreed upon on the click destination side. Would that we welcome?
@johnwilander johnwilander added the layering Layering additional data and functionality on top of PCM label Dec 13, 2019
@johnwilander
Copy link
Collaborator Author

Ping @michaelkleber @csharrison.

@benjaminsavage
Copy link

PCM would probably consider a bump on the click source side to 8 bits if 3 bits were agreed upon on the click destination side. Would that we welcome?

The discussion on #11 indicated support for a 4+4+4 split (so potentially 8 and 4). I would welcome that.

In practice, the 64 ad campaigns limit will be more problematic for us than the reduction in the fidelity of the conversion value.

@jinghao
Copy link

jinghao commented Mar 26, 2020

Agreed with @benjaminsavage. Larger domains will have a lot of campaigns, especially the marketplaces like Target or Shopify that have lots of uncoordinated advertisers running their own campaigns. My preference would be 9-3 over 6-6 because that would give us ~500 campaigns per domain and also align the conversion metadata spec with the Chrome proposal.

@hober hober changed the title 3-bit conversion-metadata vs 6-bit ad attribution data Consider reducing the ad attribution data budget to 3 bits Apr 30, 2020
@jinghao
Copy link

jinghao commented Sep 21, 2020

@johnwilander Hi! For planning purposes, it would be helpful to understand where we ended up here. Thanks!

@johnwilander
Copy link
Collaborator Author

I landed 8+4 bits for PCM in WebKit today: https://trac.webkit.org/changeset/270456

That is, 8 bits for the source ID (previously campaign ID) and 4 bits for the trigger data (previously conversion value).

caiolima pushed a commit to caiolima/webkit that referenced this issue Dec 7, 2020
https://bugs.webkit.org/show_bug.cgi?id=219519
<rdar://problem/70470036>

Reviewed by Brent Fulgham.

We've received a lot of feedback saying increased entropy on the click side is more
important than the current 6 bits on the conversion side. Some of that conversation
is captured in privacycg/private-click-measurement#28.

Source/WebCore:

This patch switches from 6+6 bits to 8+4 bits. It also fixes some minor logging
issues.

Existing layout tests and API tests were updated.

* html/HTMLAnchorElement.cpp:
(WebCore::HTMLAnchorElement::parsePrivateClickMeasurement const):
* loader/PrivateClickMeasurement.cpp:
(WebCore::PrivateClickMeasurement::parseAttributionRequest):
    Removed the check that would log "Conversion was not accepted because the URL
    path did not start with ..." on every redirect in PCM Debug Mode. It was wrong
    and annoying.
(WebCore::PrivateClickMeasurement::json const):
    Added a call to isValid(). Other checks made sure this wasn't an issue but I'd
    rather have it in this public function too.
* loader/PrivateClickMeasurement.h:
(WebCore::PrivateClickMeasurement::AttributionTriggerData::isValid const):

Source/WebKit:

This patch switches from 6+6 bits to 8+4 bits. It also makes sure PCM Debug Mode
consistently logs on the LOG level except for real errors.

Existing layout tests and API tests were updated.

* NetworkProcess/PrivateClickMeasurementManager.cpp:
(WebKit::PrivateClickMeasurementManager::storeUnattributed):
(WebKit::PrivateClickMeasurementManager::attribute):
(WebKit::PrivateClickMeasurementManager::fireConversionRequest):

Tools:

This patch switches from 6+6 bits to 8+4 bits.

* TestWebKitAPI/Tests/WebCore/PrivateClickMeasurement.cpp:
(TestWebKitAPI::TEST):

LayoutTests:

This patch switches from 6+6 bits to 8+4 bits.

* http/tests/privateClickMeasurement/anchor-tag-attributes-validation-expected.txt:
* http/tests/privateClickMeasurement/anchor-tag-attributes-validation.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@270456 268f45cc-cd09-0410-ab3c-d52691b4dbfc
ryanhaddad pushed a commit to WebKit/WebKit that referenced this issue Dec 22, 2020
https://bugs.webkit.org/show_bug.cgi?id=219519
<rdar://problem/70470036>

Reviewed by Brent Fulgham.

We've received a lot of feedback saying increased entropy on the click side is more
important than the current 6 bits on the conversion side. Some of that conversation
is captured in privacycg/private-click-measurement#28.

Source/WebCore:

This patch switches from 6+6 bits to 8+4 bits. It also fixes some minor logging
issues.

Existing layout tests and API tests were updated.

* html/HTMLAnchorElement.cpp:
(WebCore::HTMLAnchorElement::parsePrivateClickMeasurement const):
* loader/PrivateClickMeasurement.cpp:
(WebCore::PrivateClickMeasurement::parseAttributionRequest):
    Removed the check that would log "Conversion was not accepted because the URL
    path did not start with ..." on every redirect in PCM Debug Mode. It was wrong
    and annoying.
(WebCore::PrivateClickMeasurement::json const):
    Added a call to isValid(). Other checks made sure this wasn't an issue but I'd
    rather have it in this public function too.
* loader/PrivateClickMeasurement.h:
(WebCore::PrivateClickMeasurement::AttributionTriggerData::isValid const):

Source/WebKit:

This patch switches from 6+6 bits to 8+4 bits. It also makes sure PCM Debug Mode
consistently logs on the LOG level except for real errors.

Existing layout tests and API tests were updated.

* NetworkProcess/PrivateClickMeasurementManager.cpp:
(WebKit::PrivateClickMeasurementManager::storeUnattributed):
(WebKit::PrivateClickMeasurementManager::attribute):
(WebKit::PrivateClickMeasurementManager::fireConversionRequest):

Tools:

This patch switches from 6+6 bits to 8+4 bits.

* TestWebKitAPI/Tests/WebCore/PrivateClickMeasurement.cpp:
(TestWebKitAPI::TEST):

LayoutTests:

This patch switches from 6+6 bits to 8+4 bits.

* http/tests/privateClickMeasurement/anchor-tag-attributes-validation-expected.txt:
* http/tests/privateClickMeasurement/anchor-tag-attributes-validation.html:


Canonical link: https://commits.webkit.org/232134@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@270456 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@johnwilander
Copy link
Collaborator Author

This has now been updated in the spec too: f7e51be

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
layering Layering additional data and functionality on top of PCM
Projects
None yet
Development

No branches or pull requests

3 participants