-
Notifications
You must be signed in to change notification settings - Fork 7
Define intermediary interactions with the API #208
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
base: main
Are you sure you want to change the base?
Conversation
This doesn't look like a lot, but there's a whole bunch here. 1. There is a discussion of the rule of intermediaries in the API. This is pretty brief for now, but we can expand it over time. 2. There is a longer discussion about what it means to construct a histogram. There's a new concept here that is introduced, of histogram definition. This allows me to explain that the semantics of each of the histogram indices used by impressions that are selected by the same `measureConversion()` call need to be consistent. This section describes the set of tools that the API provides for ensuring that this is possible. 3. Those tools are then defined. The various `intermediarySites` options are renamed. I've named these `impressionCallers` (on the conversion site) and `conversionCallers` (on the impression side; this is new). This reflects the fact that these will select either a top-level site (impression site or conversion site respectively) OR an intermediary site on that side. I'm not wed to this name, but it's the best I could come up with on short notice. 4. `impressionCallers` allows `measureConversion()` to only select impressions saved by specific intermediaries OR impression sites. We discussed this defaulting to just the intermediary site when the API is invoked by an intermediary, but I decided not to do this. This is logically simpler and I think that intemediaries are more likely to be technically competent enough to get this part right, especially with the new explanation. 5. `conversionCallers` is a new restriction, with new attributes for saved impressions. This exists to avoid accidental bleed over of impressions, as we discussed at the recent meeting.
api.bs
Outdated
both [=impression sites=] and [=intermediary sites=], | ||
that might have called the <a method for=Attribution>saveImpression()</a> API. | ||
If specified, | ||
only [=impressions=] recorded by scripts originating from one of the listed sites |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can avoid the recorded by scripts
phrasing, given the presence of the HTTP API for Save-Impression
.
api.bs
Outdated
* Use of an [=impression=] for [=conversion=] can be restricted | ||
to a [=impression/Conversion Sites|set of conversion sites=]. | ||
|
||
* Use of an [=impression=] for [=conversion=] can be restricted | ||
to use by a [=impression/Conversion Callers|set of sites=]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a distinction between restricted to a
and restricted to use by a
here? If not, let's use the same phrasing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying (and failing) to distinguish between the two concepts:
- The impression is only visible when the top-level site is in this set.
- The impression is only visible when the caller of
measureConversion()
is in this set.
Co-authored-by: Andrew Paseltiner <apaseltiner@google.com>
This doesn't look like a lot, but there's a whole bunch here.
There is a discussion of the rule of intermediaries in the API. This is pretty brief for now, but we can expand it over time.
There is a longer discussion about what it means to construct a histogram. There's a new concept here that is introduced, of histogram definition. This allows me to explain that the semantics of each of the histogram indices used by impressions that are selected by the same
measureConversion()
call need to be consistent. This section describes the set of tools that the API provides for ensuring that this is possible.Those tools are then defined. The various
intermediarySites
options are renamed. I've named theseimpressionCallers
(on the conversion site) andconversionCallers
(on the impression side; this is new). This reflects the fact that these will select either a top-level site (impression site or conversion site respectively) OR an intermediary site on that side. I'm not wed to this name, but it's the best I could come up with on short notice.impressionCallers
allowsmeasureConversion()
to only select impressions saved by specific intermediaries OR impression sites. We discussed this defaulting to just the intermediary site when the API is invoked by an intermediary, but I decided not to do this. This is logically simpler and I think that intemediaries are more likely to be technically competent enough to get this part right, especially with the new explanation.conversionCallers
is a new restriction, with new attributes for saved impressions. This exists to avoid accidental bleed over of impressions, as we discussed at the recent meeting.This does not implement the delegation API proposed in #34. That's a bigger lift that can come afterwards.
Closes #55.
Closes #102.
Preview | Diff