To get an idea of what parameters are being sent by clients I ran this hive query:

select count(1) cnt, pkey
from ApiAction LATERAL VIEW explode(map_keys(params)) pTable AS pkey
where year=2016
  and month=4
  and day=1
group by pkey
order by cnt desc
limit 500
;

@Anomie, @Qgil, @EBernhardson, @Addshore: can you help me come up with an initial whitelist of interesting parameters to count in the action_param_hourly table? (Or alternately convince me that a blacklist is a better approach and help create that list.)

I think a whitelist is going to be the safer approach, unless you're not actually capturing the values.

As for which values to capture... To know what modules were requested, you need action and format (for ApiMain); prop, list, and meta (for action=query); submodule (for action=flow); and generator (for anything using ApiPageSet). Beyond that, I don't really know what sorts of uses the data will be put to to be able to try to say which fields would be needed. I'm personally more likely to either need weirdly specific stuff or to just use api-feature-usage to track the things that I'm interested in.

In T132283#2194878, @Anomie wrote:

I think a whitelist is going to be the safer approach, unless you're not actually capturing the values.

The intent of the action_param_hourly is to count (action, parameter, value, wiki) tuples. We don't really want to count parameters where the value has a very high carnality (e.g. title or revid). Having looked a bit at the data I'm pretty sure that a whitelist is what we want.

As for which values to capture... To know what modules were requested, you need action and format (for ApiMain); prop, list, and meta (for action=query); submodule (for action=flow); and generator (for anything using ApiPageSet). Beyond that, I don't really know what sorts of uses the data will be put to to be able to try to say which fields would be needed. I'm personally more likely to either need weirdly specific stuff or to just use api-feature-usage to track the things that I'm interested in.

The original request that led to designing this tables was for a report "Ranking of most requested actions/parameters, on a monthly basis + all time (DevRel, to help identifying usage of our APIs and check against our documentation, APIs we should promote...)" (T116065). I dug through my emails and found a discussion with @Spage and @Qgil from October 2015 where we settled on basically the same list that @Anomie is suggesting minus the format parameter. I think format is interesting for discussions of deprecating little used formats (e.g. T118538: Reduce the usage of API format=php), but generally it's not highly useful for a long lived dashboard.

For the initial ETL scripts I'm now thinking we should record summary counts for:

The prop, list and meta parameters we should split the value on | and count each component value separately (i.e. "prop=foo|bar|baz" would count as 3 events).

Once we have this ETL pipeline working, additional parameters can be added if and when someone realizes that they want them for a dashboard.

I can't immediately think of anything for Wikidata here