required daily data:
banner impressions
nice to have:
registrations
required daily data:
banner impressions
nice to have:
registrations
Please implement the following user tracking schema for this campaign (these data should end up in ServerSideAccountCreation_5487345 for campaign tracking)
(1) ?campaign=wmde_abc2017_bt1 - banner for Specific Task 1;
(2) ?campaign=wmde_abc2017_bt2 - banner for Specific Task 2;
(3) ?campaign=wmde_abc2017_bt3 - banner for Specific Task 3;
(4) ?campaign=wmde_abc2017_gib_lp - banner for the General Invitation which leads to the Landing Page upon click;
(5) ?campaign=wmde_abc2017_gib_rg - banner for the General Invitation which leads directly to Registration upon click.
Banner (4) and (5) are visually identical. Of course I don't mind exactly what ?campaign= values are used - until we're able to tell which value refers to what.
The banner diet should be adjusted as planned (I guess this is done on Central Notice): 25% for each of the Specific Task banners, and 12.5% per each of the General Invitation banners. @Verena @Stefan_Schneider_WMDE
This organization of user tracking will enable us to have a proper campaign dataset to perform serious campaign analytics and figure out exactly the effects of each campaign element upon the defined campaign goals (see slides 11 - 13 in the KickOff new editor autumn edition presentation).
Once this user tracking scheme is implemented, please re-assign this task to me. @Addshore
I've already asked that question at our kick-off, but want to be sure, that it's possible: The tracking of the pageviews will be possible also through the campaign tags, right? So that we have specific data on how many people have seen the landingpage seperated by the specific banner they came from.
Let me summarize the whole tracking schema for the Autumn Banner Campaign 2017 for us and ask @Addshore for a review and confirmation/correction:
The page views, banner impressions, and banner clicks are maintained in a separate dataset and reported upon daily.
The tracking of banner clicks, landing pages, registrations, guided tours and edits per user is combined into another dataset (namely: the User Journey Dataset) that is also updated daily.
Yes.
When looking ONLY at page views we can also use the pageview api (1 day behind) or the pageview tables in hadoop.
When using webrequest directly for page view there are extra things that need to be taken into account such as spider vs user etc. But there is an is_pageview flag that should help here.
- Banner impressions: tracked from webrequest table by (a) uri_host , (b) uri_path (beacon in this case), and (c) campaign tag; already tested and delivers the same data as Pivot. I need the beacon uri_path for this
Yes.
Could also use Pivot, as they give the same numbers.
Pivot would be more efficient.
- Banner clicks: similar to (2) and adding something like action = bannerClick. I need the beacon uri_path for this
Yes.
Although lets avoid using action= (that does stuff in mediawiki)
In previous runs I think we have used &wmdesource=bannerclick or something similar.
- Registrations: tracked in log.ServerSideAccountCreation_5487345; the event_campaign field will match some of the campaign tag values as described in this ticket (namely: (1) wmde_abc2017_bt1, wmde_abc2017_bt2, wmde_abc2017_bt3, wmde_abc2017_gib_lp, or wmde_abc2017_gib_rg ).
Yes.
- Guided Tours: all registered users are presented with a Guided Tour; whether a registered user completes a Guided Tour or not is tracked in Schema:GuidedTourExited (revision: 8690566). @Addshore: Did you set the MW parameter for Guided Tour tracking to TRUE?
See T174949#3583341, I can not do this.
- Edits: from the dewiki.user SQL table.
Yes.
@Addshore Thanks!
Yes. Could also use Pivot, as they give the same numbers. Pivot would be more efficient.
It would be more efficient, but it would also be less consistent. Using Hadoop we have all the code comfortably placed in one single R script that runs from some statbox daily. Using Pivot means running around different data sources and thus preventing full reproducibility. OR we can use Druid directly - via JSON calls to its API; that would be more efficient than Hadoop in this case.
Exactly, that's what I had on my mind but couldn't remember exactly the wmdesource tag that was used.
See T174949#3583341, I can not do this.
Ok, but can @DerHexer do it?
Thank you for clarifying all the details.
I have a question to point 1.
Does pageview api OR the webrequest table show the pageviews seperated by different banners? In other words: Is it possible to have a list like:
Banner 1 = X pageviews
Banner 2 = X pageviews
...
The pageview API will ONLY show the total page views to a page.
Using the webrequest table it is possible to see the pageviews for each type of banner / campaign tag separately.
Using the webrequest table it is possible to see the pageviews for each type of banner / campaign tag separately.
Awesome!
Why would anyone need to search for banners in the page views?
Page Views from Banner_1 = Num.Clicks(Banner_1)
etc.
@Stefan_Schneider_WMDE @Verena
What definition of a Guided Tour completion do we want to use:
(A) The user did not exit the Guided Tour explicitly.
(B) The user did not exit the Guided Tour explicitly AND did not hide the guider before step X (please define step X if you decide to go for this definition).
Also, please let me know what is the name of the Guided Tour that will be used in the Autumn Banner Campaign. Thanks.
For the guided tours it would be great to have two numbers:
The name of the guided tour stated in the code is "name: 'einfuhrung'".
And if you also need the tag to start the guided tour it's the following: "?tour=einfuhrung"
It is the same guided tour we used in the last campaigns.
Hi, by the following:
"1. Number of people who started the guided tour / completed the first step"
do you mean:
(A) People who started the guided tour, completed the first step, and then exited, OR
(B) People who started the guided tour, completed the first step, and then did whatever including giving up after N steps, completing the tour..?
Thanks.