Thu, Oct 17
@Tim_WMDE Not to change banner behaviour (yet) is correct. But I'am stumbling (and maybe not understanding correctly) about to track the viewports of wikipedia.de visits in general (and unrelated to a actual display of a banner). To track if a banner size issue would have occured and at which viewport width this happens (as Till writes, a "potential banner size issue") the actual banner (height) would needed to be taken into account (calculating the difference of max. banner height and actual banner height). Therefor I wonder what you mean by viewport tracking even if no banners are present.
Thu, Oct 10
@tonina looks good! Thanks and sorry again for the short notice! Just to understand the banner functionality - was there any code that needed to be updated so that the tracking via EventLogging (viewport tracking items, especially the newly introduced tracking of viewports of banner submits) works? Or is this not part of the banner code?
Wed, Oct 9
And test links with the correct skin:
hi @gabriel-wmde thanks! Some remarks:
Tue, Oct 8
Regarding the banners for this test:
Tue, Oct 1
Mon, Sep 30
@gabriel-wmde What we actually need are the viewport sizes of the banner impressions. And the viewport sizes of intances of banner-size-issues (which are not implemented yet, of course). From both data we can understand how big a banner can get in certain viewport areas and how many impressions (aka users) are in certain viewport size areas. This then is the base of a definition of clusters for a responsive banner. At least we used that approach on de.org.
Sep 13 2019
Sep 4 2019
@Tim_WMDE if that helps: there was another test on mobile (test 7) in 2018 which should include that feature. that test was in 12/2018.
Sep 3 2019
@Tim_WMDE just for the reasoning:
- impressions of different banner tests on the same day (one ends, one starts) are not possible to seperate without tracked banner names
- moreover there are use cases where it is important to separate impression data of ctrl and var banners for the analysis
Sep 2 2019
@Jan_Dittrich In banner tests users won't usually see laika-payment because they are directed to laika-personal-data and old analysis of 10h16 indicate that only a very smalll percentage of people change sum, interval or payment provider after they came to the landing page. So, I would use the submit oder conversion rate of laika-personal-data to measure the performance of the skin.
It would be different if it is for instance an emailing test where users are direced to the first page of the form. This way your calculation should seems sensible. But I'am not sure if the submit button on 10h16_payment actually works because at the moment there are zero submits since the beginning of the test.
Aug 30 2019
@Tonina_Zhelyazkova_WMDE yes, august 8th till 22th is correct!