TCF metrics by account and adapter

[muuki88]

Hi,

There are two very useful metrics for monitoring vendorlist:

prebid-server-java/docs/metrics.md

Lines 79 to 80 in 5414d4a

	- `adapter.<bidder-name>.(openrtb2-web|openrtb-app|amp|legacy).tcf.request_blocked` - number of requests made to `<bidder-name>` that were blocked as a result of TCF enforcement for that bidder
	- `adapter.<bidder-name>.(openrtb2-web|openrtb-app|amp|legacy).tcf.analytics_blocked` - number of requests made to `<bidder-name>` that required analytics blocked as a result of TCF enforcement for that bidder

and

prebid-server-java/docs/metrics.md

Lines 117 to 118 in 5414d4a

	- `usersync.<bidder-name>.tcf.blocked` - number of requests received that didn't result in `uid` cookie update for `<bidder-name>` because of lack of user consent for this action according to TCF
	- `usersync.<bidder-name>.tcf.invalid` - number of requests received that are lacking of a valid consent string for `<bidder-name>` in setuid endpoint

However the view is a bit too highlevel to be actionable. We would like to add account to the metrics path as well in order to separate by account and bidder.

This would be activated if verbose is enabled.

Use case

We want to test a new SSP and select a site to rollout this SSP. In order to work the SSP requires to be on the vendorlist in our CMP. With coop-sync enable the TCF blocked metrics show a lot of "blocked" entries, because the SSP is missing on all other site vendorlists.

With a granular view by account we can

• detect missing vendors on account basis
• monitor rollout rates for vendorlist updates
• display a more accurate view of the cookie match rate

[bretg]

From a slack conversation:

Would it be required to have both account and bidder at the same time? That cardinality is pretty large. e.g. 100 accounts * 50 bidders. My preference would be that instead of supporting the full cross-product of 500 combinations, we instead support 150 new metrics: 100 for the account-level metrics and 50 for the bidder-level.

Yes, that would be the case. The question we want to answer is "What account is missing which bidder in the vendorlist".
We do have a lot of publishers managing their vendors themselves.

We discussed in committee establishing a similar set of bidder-level controls over metrics:

• metrics.bidders.default-verbosity - verbosity for bidders not specified in next config entries. Allowed values: none, basic, detailed. Default is basic.
• metrics.bidders.basic-verbosity - a list of bidders for which only basic metrics will be emitted.
• metrics.bidders.detailed-verbosity - a list of bidders for which all metrics will be emitted.

[bretg]

We plan to do a complete metrics review at some point. This will be considered within that overall review.