Change Details

Set `wgWMEReadingDepthSamplingRate` to 0.1 Background: The [[https://meta.wikimedia.org/wiki/Schema:ReadingDepth |ReadingDepth]] schema is currently sampled at 0.001 (0.1% of sessions), to which it was [[https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/340095/ | decreased last year]] down from the originally planned 0.05% because of load issues with the old MariaDB EventLogging infrastructure. Since then, the new Hadoop EL environment has become available, which doesn't have these rate constraints. And last week, Analytics Engineering already blacklisted ReadingDepth from MariaDB for us ( T203596#4577520 ) because we are about to increase the event rate via a separate sample that will send ReadingDepth events as part of the Page Issues A/B test (T200792, sampled at 20% of sessions). This task is about increasing the default sample too. We are about to launch a separate research project where @Groceryheist will need to use this data for questions where 0.1% will be too low (e.g. how dwell time depends on content). == Acceptance criteria [X] Let analytics know this is happening before the deploy. [] Monitor ReadingDepth event traffic post-deploy and that it matches expectations. [] Check with analytics post-deploy [] Analyse any errors that are introduced in the EventLogging pipeline relating to this change (use stat1004 and kafkacat - T196904 has some good pointers). [X] Check error rate is not increased. If it is, understand the root cause and fix.

Set `wgWMEReadingDepthSamplingRate` to 0.1 Background: The [[https://meta.wikimedia.org/wiki/Schema:ReadingDepth |ReadingDepth]] schema is currently sampled at 0.001 (0.1% of sessions), to which it was [[https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/340095/ | decreased last year]] down from the originally planned 0.05% because of load issues with the old MariaDB EventLogging infrastructure. Since then, the new Hadoop EL environment has become available, which doesn't have these rate constraints. And last week, Analytics Engineering already blacklisted ReadingDepth from MariaDB for us ( T203596#4577520 ) because we are about to increase the event rate via a separate sample that will send ReadingDepth events as part of the Page Issues A/B test (T200792, sampled at 20% of sessions). This task is about increasing the default sample too. We are about to launch a separate research project where @Groceryheist will need to use this data for questions where 0.1% will be too low (e.g. how dwell time depends on content). == Acceptance criteria [X] Let analytics know this is happening before the deploy. [] Monitor ReadingDepth event traffic post-deploy and that it matches expectations. [X] Check with analytics post-deploy [] Analyse any errors that are introduced in the EventLogging pipeline relating to this change (use stat1004 and kafkacat - T196904 has some good pointers). [X] Check error rate is not increased. If it is, understand the root cause and fix.

Set `wgWMEReadingDepthSamplingRate` to 0.1 Background: The [[https://meta.wikimedia.org/wiki/Schema:ReadingDepth |ReadingDepth]] schema is currently sampled at 0.001 (0.1% of sessions), to which it was [[https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/340095/ | decreased last year]] down from the originally planned 0.05% because of load issues with the old MariaDB EventLogging infrastructure. Since then, the new Hadoop EL environment has become available, which doesn't have these rate constraints. And last week, Analytics Engineering already blacklisted ReadingDepth from MariaDB for us ( T203596#4577520 ) because we are about to increase the event rate via a separate sample that will send ReadingDepth events as part of the Page Issues A/B test (T200792, sampled at 20% of sessions). This task is about increasing the default sample too. We are about to launch a separate research project where @Groceryheist will need to use this data for questions where 0.1% will be too low (e.g. how dwell time depends on content). == Acceptance criteria [X] Let analytics know this is happening before the deploy. [] Monitor ReadingDepth event traffic post-deploy and that it matches expectations. [X] Check with analytics post-deploy [] Analyse any errors that are introduced in the EventLogging pipeline relating to this change (use stat1004 and kafkacat - T196904 has some good pointers). [X] Check error rate is not increased. If it is, understand the root cause and fix.