Using event logging from banners might not work correctly. Events seem to be logged at a very low rate, if at all. We dropped the enum definition for banner action in the schema (see schema diff) to fix mobile banner expansion tracking, but this seems to have worsened the situation.
For desktop-de-18, we introduced a mini banner. Logging expansion and close events of that produced some data. Manually testing with a banner that sets the logging rate to 100% seems to also be working.
Logged events of Schema:WMDEBannerEvents in 2019 grouped by banner action and schema revision
| banneraction | Rev. 18437830 | Rev. 19608660 |
|---|---|---|
| application-of-funds-shown | 103744 | 42752 |
| banner-closed | 57025 | 6 |
| mobile-mini-banner-expanded | 19 | 0 |
| mini-banner-closed¹ | 0 | 40087 |
| mini-banner-expanded¹ | 0 | 135 |
¹) data collected only during desktop-de-18
The number of logged events including viewport size data differs from the logged events of closed banners, while it should actually be the same.
0: jdbc:hive2://an-coord1001.eqiad.wmnet:1000> select count(*) from wmdebannersizeissue where event.bannerName like "vtc%" and year = 2019; _c0 511989 1 row selected (112.252 seconds)
0: jdbc:hive2://an-coord1001.eqiad.wmnet:1000> select count(*) from wmdebannerevents where event.bannerAction = "banner-closed" and year = 2019; _c0 57031 1 row selected (78.22 seconds)
Acceptance Criteria
- All events are manually triggered in banners while the Logstash is being monitored for possible errors that keep events from actually being logged.
- We know what events are affected and what errors are produced when triggering the event.
Notes
Examples of banners from last year: