Consider allowing conversions to specify a set of integers to match filter data

[apasel422]

Following from #58 (comment), it might be useful to allow conversions to provide a set of values to match against filter data, rather than just one. If the given set is empty, all impressions match. (There is no reason to call measureConversion if you intend to match zero impressions.) Otherwise, an impression matches if the set contains its filter data.

This effectively allows any predicate to be implemented, assuming that the full set of impression-side filter data is remembered by the caller of measureConversion, making any subsequent improvements here mostly a form of compression, rather than new behavior.

This also maps nicely to the HTTP API via an inner list, if conversions can ever be registered using HTTP. We would permit responses like:

Save-Conversion: ..., filter-data=12

Save-Conversion: ..., filter-data=(12 13)

with the filter-data key's absence defaulting to (), meaning match anything.

[martinthomson]

I'm inclined not to allow this. If a site wants to register two impressions as alternatives, that would achieve the goal, provided that the set of wossnames (#24!) is small.

However, if we want to get into more complex matching logic that is more efficient for this sort of stuff, we can define additional matching attributes on impressions and corresponding matching rules. I'd prefer to keep this one as simple as possible.

[csharrison]

In the last meeting a few people (I think @AramZS and @ohpauleez among others?) spoke up suggesting we implement more complex matching. I agree we can land a "minimum viable" thing in parallel but we can quibble on what is "viable". My preference would be for the functionality @apasel422 suggests here rather than the single integer filtering.

Maybe we can discuss two separate points:

1. Are people OK with an MVP filtering implementation that doesn't satisfy all requirements?
2. If yes, what is the minimum viable functionality it needs?

[bmayd]

If a site wants to register two impressions as alternatives, that would achieve the goal, provided that the set of wossnames (#24!) is small.

I'm uneasy with the notion of creating duplicate records for an impression, seems like it would be result in much greater complexity and end up being much harder to police than allowing single impression records to contain arrays of match values.

[martinthomson]

Discussed 2025-05-13: General view is that we don't need the complication for matchValues (see #24). Those can be a single value for saveImpression() and a list for measureConversion().

We do agree that having a better view of where we are planning to head longer term is sensible. That's something we'd like to discuss more on another issue.

[apasel422]

If the given set is empty, all impressions match. (There is no reason to call measureConversion if you intend to match zero impressions.) Otherwise, an impression matches if the set contains its filter data.

@martinthomson To clarify, we're in agreement that we can update the spec with this behavior? If so, I'll file a PR.

And if there's concern about defaulting to the empty list, we could always make matchValues required (but still permit the empty, meaning match any).

[martinthomson]

Yep, I'd appreciate that.

[ohpauleez]

Thanks all