Skip to content

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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

martinthomson
Copy link
Member

@martinthomson martinthomson commented Jun 20, 2025

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.

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

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
Copy link
Collaborator

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
Comment on lines 873 to 877
* 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=].
Copy link
Collaborator

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.

Copy link
Member Author

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:

  1. The impression is only visible when the top-level site is in this set.
  2. The impression is only visible when the caller of measureConversion() is in this set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants