Based on @mforns's excellent investigation of (in)accuracy that each sampling rate yields:

This study suggests that 10% of sessions would be an acceptable sampling, but this is based on the initial rollout to group0 and group1 wikis.

Stream configurations enable us to adjust sampling rates rapidly, through the MW config deployments which are much more frequent than code releases. We should start with a conservative rate like 1% (0.01 in the config) when we deploy to all wikis and work from there. By looking at the volume of events/data at that rate we will be able to make a decision about increasing it for some wikis or even making it smaller for others (e.g. 0.1% for enwiki, even).

Also! Since the underlying sampling algorithm uses decimals like 0.5 and 0.25 instead of fractions like "1 in 2" or "1 in 4", we can even arrive at "weird" sampling rates like 17% or 34% by gradually increasing the sampling rate in increments of 0.5% or 1% and seeing how the system handles the resulting changes.

Side note for @Ottomata and @jlinehan: this might be a great opportunity to do a stress test of the system?

The resolution here was was to start with a conservative rate (1%) and go up from there. However, Marcel added a comment that the Analytics Engineering team believes the pipeline could take up to 1/10 of all session tick data:

In T271455#6762361, @mforns wrote:

I discussed with the Analytics team about how much session tick data could our pipeline possibly take, given that high sampling rates result in very low accuracy for our metric.
The conclusion that we arrived is that the pipeline could take up to 1/10 of all session tick data - theoretically without problems - as it is today.
If necessary, we could consider collecting all data un-sampled, but that would probably require some extra work, i.e. scaling EventGate, making sure session tick stream does not starve smaller streams, when importing and processing the data, setting up a specific deletion schedule to avoid keeping TB of data, etc.

Given the above, I believe we should start with 1/10 sampling and adjust as needed.

I still think that we can take 1/10 sampling rate, but nevertheless it would be nice to start at 1/100, just for 1 or 2 days, to be safe... If my projections are *not* correct, this might have the potential to collapse parts of the data collection/processing system. But, as @mpopov said, good news is that we can change the production sampling rate just with a MediaWiki-config change, we don't need to wait for a full MediaWiki deployment train. So, tl;dr, yes 1/10, but let's roll it our progressively.

Thanks for the clarification, @mforns! I'll update the task description with a brief summary.