Extension:EventLogging/Campaigns

Summary
When a user follows a URL to a page that has ?campaign=someName in it, if someName is a valid campaign identifier then this...
 * 1) this logs a campaign event
 * 2) stores the campaign identifier in their session cookie, so that if they sign up, edit, or take another action within the session, then it's logged

Use cases

 * A. Why is someone creating an account?
 * There are lots of paths into creating an account but we can't tell which is effective.


 * B. Invitation to participate in a project, e.g. PhilippinesOutreach
 * We have a promotion that goes to on-wiki page(s) (not necessarily the Create account form). We'd like to know how many people followed it, and associate any account creations with the campaign.


 * C. Present special material during and after account creation and/or login.
 * If we know someone created an account or logged in to participate in the PhilippinesOutreach, then we can do better than present them the default GettingStarted page, we can give them special messaging.

Sketch of design
implemented an earlier version of this as an addition to extension EventLogging, with lots of TODOs.

On any wiki page request, client-side JS
 * Notices URL parameter ?campaign=someName (apsiw, PhilippinesOutreach2013, fromredlink, fromtutorial, etc.)
 * Logs this a simple event according to the Campaigns schema:
 * campaign someName (campaign's an enum, so must match).
 * user session token (if anonymous) or userId (if logged-in)
 * the namespace and title of the page.
 * (Analytics code could process this to apply usertagging)
 * If the campaign event validated, then store the campaign someName in a mediaWiki.campaign session cookie.

When a user creates an account, the existing ServerSideAccountCreation event will log the mediaWiki.campaign cookie, along with token and new userId, so we can directly relate account creations to the most recent campaign the user clicked.

Open issues
Do we heed the user's "Exclude me from experiments" preference?
 * Yes. Note that it's moot for new users, since they haven't expressed a preference.
 * No, Ori comments "the 'vector-noexperiments' preference has been stretched into a generic 'do not track' preference in the past, but no once accepts it as adequate for that purpose."

Discussion
Names for the project, for the query string, for the cookie
 * For now RoCA (Return of Campaign Awareness), ?campaign, and mediaWiki.campaign. We considered and discarded ?c=foo, ?camp=foo and scamp™.

Why always set a session cookie?
 * It's the easiest way to associate a campaign that lands users on some wiki page with later account creation, and this is the most common and important use case.

Why client-side JS? we could log this on the server.
 * client-side already has code to set user session token. Also bots and people who don't want it to be known that they participated in a campaign have some overlap with people who disable JS.

Is enumerating all the currently valid campaign values in the Schema a good idea?
 * + stops people fabricating Rickroll links that set campaign cookie to troll values
 * + forces people to think about the campaigns they want in advance
 * + lets us invalidate campaigns
 * + [View history] provides a history of campaigns
 * + Adds a campaign gatekeeper, WMF staff can't just add ?campaign=SFMeetupHackers to their URLs.
 * - updating the schema rev in PHP will be constant busy-work
 * any group who cares can add an automated workflow
 * - a lot(?) of churn in the schema, there will be a new Schema table each time.

What about multiple campaigns?
 * If the user follows one link with ?campaign in it and then clicks another link with ?campaign, the second replaces the first in the session cookie; only the most recent is associated with the account creation. This is OK since the thing that encouraged account creation is the "closest" campaign, but it means we can't abuse ?campaign to track all the ways users arrive at the Create account form. We could enhance the cookie to store multiple campaigns, but YAGNI.

Question: should we log campaign cookie contents in case there's already something in it and we overwrite?
 * No, nobody has time to puzzle out this crap!

Question: do we overload this to handle userbucketing for A/B tests?
 * No, we have mw.user.bucket for that.

Question: should the camp cookie be prefixed with "mediaWiki" or the wgDbName (enwiki.camp, dewiki.camp)?
 * Just mediaWiki.campaign

Idea: put this in a general-purpose session cookie with other session info.
 * YAGNI for now.

Issue: If someone lands on login with a campaign and instead creates an account, or vice-versa, might want to pass the campaign in the link to the other form.

Question: do we enable this for mobile?
 * Sure, why not?

Use cases vs. sketch
A. External calls to action that link directly to account creation work great, they just append ?campaign=fundraiserCTA5.

We could append ?campaign=redlink, ?campaign=WikipediaTutorial, etc. to each of the internal links to signup. However, since the campaign session cookie only tracks one campaign, this would overwrite any campaign that brought the user to some page on the site (see Use case B).
 * Maybe the link by which users arrive at the Create account form should be separate from campaign. Each of the links to create an account has a via={searchRedLink,WikipediaTutorial, topNavLink, etc.) query string parameter, and account creation stores this in a hidden field that ServerSideAccountCreation later logs.

B. Add ?campaign=PhilippinesOutreach to the links to the target pages, and anyone who follows them will be logged. For any users that create an account during the session, their m:Schema:ServerSideAccountCreation event will log the campaign.

C. Umm, we can offer a custom on-wiki message and/or modify GettingStarted to present something different based on campaign session cookie. Steven Walling cautions that reshaping experience based on campaign by redirecting the user and manipulating pages has NOT worked well in the past (see Account Creation Improvement Project).