Sketch in last-touch attribution #11
Conversation
api.bs
Outdated
| To <dfn ignore>fill a histogram using last-touch attribution</dfn>, | ||
| given |options|: |
There was a problem hiding this comment.
This method of writing code is super, super annoying. This is far from being ready, but it has the bones that I think we need.
| 1. For each |week| starting from the current week | ||
| to the oldest week supported by the [=user agent=]: |
There was a problem hiding this comment.
We should define somewhere what a week is. Presumably UTC, but need to choose Sunday or Monday.
| 1. Set |impression| to the value in |impressions| | ||
| with the most recent |impression|.timestamp. | ||
| <!-- TODO define a type for stored impressions --> |
There was a problem hiding this comment.
We can make the keys in https://private-attribution.github.io/api/#impression-store-contents linkable, at the cost of the simpledef markup getting even uglier. I tested <dfn lt=stored-timestamp>Timestamp</dfn> before removing it because it was so ugly. Do you have a different kind of definition in mind? Maybe change it to a <dl>?
In the case of major clock adjustments, it is possible that the store could have impressions in the future. Is it worth discussing this case?
There was a problem hiding this comment.
The links we can work out later.
The local machine won't have any issue with that sort of time skew. I hope. (Modulo time adjustments....)
| Last touch attribution does not select any impression | ||
| that was saved during a week | ||
| that does not have sufficient [=privacy budget=]. |
There was a problem hiding this comment.
I had been assuming we could report partial conversion value if there is insufficient but non-zero privacy budget. Since the privacy budget is likely to be chosen by the browser (and may vary between browsers and over time), the conversion site doesn't necessarily know the available budget.
There was a problem hiding this comment.
I have a preference for avoiding that sort of thing, at least until we have discussed it. It might be worth opening an issue to track that though.
More API updates
Co-authored-by: Andy Leiserson <aleiserson@mozilla.com>
2 participants
No description provided.