I agree that filterData is vague, but we probably want something vague enough that it can be easily extended in the future, e.g. if we want to support types other than integers. For example, I could imagine this ultimately being more similar to ARA's filter_data, which is a dictionary of keys-to-list-of-values.

@apasel422, sorry that you missed the meeting yesterday, but not surprised given the hour. In that, I suggested that the best extensibility strategy was to add new fields, rather than try to mutate existing ones.

With that in mind, an integer value that we call something really simple might be better. Keep filterData in reserve and just call this something that matches its name.

Bikeshed time:

• key or id. "key" in the sense of "a word used to gain admittance or to gain access to information". It's simple, we can expand to say "impression key" or "impression id" if we want more words and less ambiguity in text. It's not ideal though because it implies uniqueness to some people. It's not like it can't be unique, but it probably works better if the same value is attached to a bunch of impressions.
• anchor. In the sense of "an important quality or feature on which a particular thing depends or is based".
• mark. In the sense of "brand" and close enough in intent that it might fit without being overly confusing.

The suggestion box is open.

I suggested that the best extensibility strategy was to add new fields, rather than try to mutate existing ones.

That's valid, though of course it means we need to determine what happens when multiple fields are present (which can be as simple as throwing).

• key or id. "key" in the sense of "a word used to gain admittance or to gain access to information". It's simple, we can expand to say "impression key" or "impression id" if we want more words and less ambiguity in text. It's not ideal though because it implies uniqueness to some people. It's not like it can't be unique, but it probably works better if the same value is attached to a bunch of impressions.

I think we should try to avoid key and id exactly for the uniqueness implication. In ARA we have seen a lot of confusion around fields with similar names.

anchor
mark

These are certainly vague enough, but if we do add fields in the future for other types, what do we think the naming relationship will be?

Flagging for discussion: this seems like it might need some wider input. It's very much a bikeshed, but the editors don't have a great set of choices here and maybe someone can help us.

Another option is tag, which doesn't imply uniqueness, though is perhaps more associated with strings than integers.

As described, it's a very simple filtering mechanism, only ads and conversions with the same value for "filterData" can match for attribution purposes.

How about "matchValue"? It is about identifying a subset of values with a matching value.

Another option is tag, which doesn't imply uniqueness, though is perhaps more associated with strings than integers.

I'd be careful with "tag" which is commonly used within AdTech and could lead to confusion.

Discussed by a small group of mostly-very-tired individuals 2025-05-13: tentative conclusion is to take Brian's suggestion of matchValue for now. Anyone who wants something better can propose that as an improvement, but we'd like to lay this one to rest.