Jan 9 2020
Furthermore @gabriel-wmde @kai.nissen there is new tracking parameter that needs to be exported: banner-close-events of mobile banners. This is needed because on mobile banners viewports of banner-close-events tracked were not tracked. so we rely on the data of the other pattern that tracks banner-close-events to calculate the banner-close-rate. I've changed the task description accordingly.
Jan 3 2020
Dec 19 2019
Nov 27 2019
everything fine, thanks. can be closed!
Nov 26 2019
@chrp it became clear that viewport measurements on wikipedia.de are not implemented, yet (that's the corresponding ticket: T235635). therefore that ticket can be closed. for the export of wp.de test #2 the task description depends on whether respective tracking features are implemented until or during the test.
Nov 25 2019
Nov 21 2019
@chrp wikipedia.de is a special case. The tracking of viewport data is realized not with EventLogging but with Matomo. Therefor I would not merge the wikipedia.de exports to other tickets (sorry, should have mentioned before).
Nov 20 2019
@gabriel-wmde In your screenshot you can see that there are more donations than visitors. Even if the difference is not big that is not supposed to happen. Also, in ctrl you can see that there are quite a few more visits than donations - as it is supposed to be. Moreover like @tmletzko is showing the same applies to the current test on mobile (which tests the same thing)
Nov 18 2019
Nov 14 2019
Some further remarks:
@Tim_WMDE Your question about the different banner sizes indicates that you really well internalized our banner test specifiactions! *thumbs-up* But in this specific case the differences in banner height are intentionally there - it's what the advantage of the responsive banner is: being smaller in small viewports, being bigger on bigger viewports. hence, it's whats being tested. so, there shall not be any invisible placeholders in any banner to adjust for equal height.
Nov 13 2019
@gabriel-wmde Here is still the export of backend data missing. Could you please do that export? Thanks! (and beware the different time span)
Nov 11 2019
@Tim_WMDE another small thing: could you please delete in ctrl the text break after "... in Deutschland gefragt:" at the breaktpoint of 1500px (as it is in var)?
Nov 8 2019
@gabriel-wmde The adjustment of the text size in var is correct now but the form breakpoint is wrong. As I wrote in var the form shall be positioned on the right until 900px. But maybe my description of the changed breakpoints was misleading. Could you please change that?
@gabriel-wmde hi, after talking to Till and Jan: Could you please make further following changes to var:
Nov 6 2019
Nov 1 2019
Oct 30 2019
So now, after some days it is possible to see the erroneous pattern: If you look at the data from oct 29th-30th you can see that in var there are more donations than visits, hence there is a portion of visits not being tracked correctly. In ctrl that problem doesn't occur which is not surprising because there is no direct redirect to payment providers.
Oct 29 2019
Ok, thanks for the info @gabriel-wmde
Oct 28 2019
@gabriel-wmde You can see the effect of the bug if you compare the number of donations and visitors of in a test group.
Oct 17 2019
@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.
Oct 10 2019
@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?
Oct 9 2019
And test links with the correct skin:
hi @gabriel-wmde thanks! Some remarks:
Oct 8 2019
Regarding the banners for this test:
Oct 1 2019
Sep 30 2019
@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!