Report aggregate API error and operational counts. #157
Description
There are conditions under which measureConversion() is known to fail; for example:
- In 3.4.1 Operation, step 2: If logic is specified, and the value is anything other than "last-touch"
- In 3.4.1 Operation, step 3: If the private attribution API is not enabled.
- Side channels for measureConversion operation #153 suggests returning a null report if time runs out.
Providing feedback indicating how often these events were happening would be helpful.
Since we're generating histogram contributions anyway, we could reserve a set of histogram buckets specifically for the browser to provide feedback by generating a contribution for the appropriate bucket each time a given event occurred. We might also include counts for non-failure scenarios, like the number of times measureConversion() ran successfully, but matchedImpressions was zero, etc.
This would allow aggregated reports to include both the results of successful attributions and counts by type of instances where measureConversion() did not successfully attribute the conversion. If we decide to include this, it would be of value to also include the total number of calls to measureConversion() (i.e. total conversion reports received) for context.
Two possibilities for implementing this (I'm sure there are others):
- Reserve a range of buckets for error reporting at the beginning or end of the histogramIndex range.
- Reserve all negative index values which would require changing histogramIndex from an unsigned to a signed long.