Targeted acquisition campaigns

About edit

I wish Wikipedia could turn itself inside out. I want to able to read, contribute and donate to Wikipedia on every single website I visit that reuses its contents. I want to know how I can donate my time or money to Wikipedia before I even visit it.

— Luca M.

Rationale edit

  • Where can I find a list of stubs about living female scientists on the Spanish Wikipedia?
  • What are the most visited articles in military history with POV templates older than a year?
  • I need a list of health-related articles lacking high-quality images?
  • How do I find about notable historical events near my city with no dedicated article in my native language?

Gaps and biases in the coverage, quality or cross-language availability of Wikipedia contents represent an outstanding opportunity to onboard potential new contributors, particularly subject-matter experts. Over time, a number of initiatives have been launched to try and reach out to expert contributors and users from diverse backgrounds and demographies to fill these gaps. With one notable exception (Wiki Loves Monuments), these outreach initiatives and campaigns targeted at communities and users who are currently underrepresented in Wikimedia projects have received limited attention in terms of technology and analytics support. Yet, outreach campaigns like Wiki Loves Monument have proved consistently effective in onboarding first-time contributors and driving participation from existing community members (albeit for limited amounts of time). Limited technology support means that these campaigns are in general hard to scale and there are significant barriers for organizing new campaigns at the push of a button. Lack of dedicated analytics support means that it's hard to determine the impact of these campaigns in a consistent and measurable way and make a case – backed by hard data – to partner organizations, movements and institutions about the importance of adopting or sponsoring these initiatives. This proposal describe a possible model to generalize Wiki Loves Monuments campaigns, allowing anyone (community members, chapters, partner institutions and organizations or interested members of the public) to programmatically create and run targeted contribution campaigns on specific topic areas, by:

  1. generating easy to distribute/embeddable calls for participation
  2. leveraging existing analytics tools designed by the Wikimedia Foundation (Wikimetrics, EventLogging, Account creation campaign logging) to evaluate the impact of these campaigns and identify the most successful ones.

Implementation requirements edit

Analytics requirements edit

Risks and issues edit

Sandbox edit

Rationale edit

  1. alternative acquisition models
    1. acquire first / activate later
    2. acquire targeted segments of users
  2. acquire first might be suboptimal
  • we might be trying to acquire/activate the wrong people
  • the majority of new registered users are not interested in editing
  • we have little actionable data on what motivates a user to register an account (other than account creation meta-data or data hat could be obtained via post-registration surveys)
  1. little structured effort to support bottom-up campaigns
  2. millions of subject matter experts are out there but they are not actively targeted to contribute to Wikipedia

Task selection edit

Type of task edit

Pick tasks that are easy to extract, easy to localize and less subject to friction with content/quality policies.

  1. Stubs
  2. Redlinks

Task ranking edit

Traffic data https://en.wikipedia.org/wiki/User:West.andrew.g/Popular_pages https://en.wikipedia.org/wiki/User:West.andrew.g/Popular_redlinks

In-degree https://en.wikipedia.org/wiki/Wikipedia:Most_wanted_articles

(we don't have search data that could be processed to rank tasks yet)

Topic extraction edit

By far the easiest way to categorize these articles by topic is by looking at their WikiProject affiliation. This gets more complicated with redlinks, although the primary topic of a redlink can be inferred by categorizing referring articles

Risks edit

  • Arguably highly visited articles do not suffer from notability issues
  • How to mitigate COI edits

Exposing Tasks edit

 
Add here diagram of campaign logic

The following are technical requirements to expose tasks and generate campaigns

Task repository edit

This proposal assumes that the atomic unit of a task is a Wikipedia article and the properties that describe it. Sub-article tasks (section level tasks, media-related tasks) fall outside the scope of this proposal. A generic task repository is a store of article metadata that can be used for filtering and extracting relevant tasks

  • Page_title
  • Page_id (if available
  • Task category: {stub, redlink}
  • Traffic score
  • Authority score based on incoming links
  • Topic

Other possible metadata to consider

  • Geocoordinates, for nearby filtering
  • Cross-wiki coverage
  • Latency (e.g. combine the age of the article or the age of a cleanup template with traffic and authority scores to determine the priority of the task
  • Other type categories from cleanup templates

Task widgets edit

 
Add here mockups of task widgets
static
Build simple embeddable ad widgets with a static article topic or set of topics.
dynamic
Allow people to subscribe and retrieve a random article or a list of articles matching the topic
context-sensitive
Allow people to retrieve a context-sensitive widget that automatically serves the most relevant topic for the page it's embedded in.
Projects such as Dexter already allow entity/topic extraction from text snippets matching Wikipedia entries.

3rd party integration edit

 
Add here mockup of Twitter card integration

Other than task widgets, 3rd party integration could be achieved with services reusing or exposing Wikimedia contents

A task repository could also be used to populate a stand-alone web service adding more functionality than the basic task widgets described above.

Campaigns edit

Use outgoing links in task widgets to generate account creation campaigns:

Campaign logic edit

  1. point to the account creation landing page
  2. use a dedicated campaign identifier as a campaign parameter
  3. use the original article as the returnto parameter, for automatic redirect upon registration

E.g. https://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Environmental+resources+management&type=signup&campaign=xyz

Alternative campaign workflows edit

  • ReturnTo queries could point to landing pages in the WP namespace other than single articles
  • Guiders served upon successful account registration could be configured to disable some elements if a campaign parameter is present
  • A modified version of the campaign extension could be used to display a one-off notice on the landing page instead of having the widget directly point to the account registration page

Campaign analytics edit

  • The campaign ID could be suffixed with the corresponding WikiProject name (which was used for extracting the topic) or other metadata to simplify analytics
  • Basic stats on users acquired via these projects will be automatically generated via Wikimetrics:
  1. number of account creations
  2. number of activated users
  3. revert rate per cohort
  4. activity/survival per cohort
  5. content contributed per cohort

Affiliation edit

Use notifications to:

  • sustain continued participation via GettingStarted
  • alert WikiProject members of active new users
  • invite new users to join relevant Wikiprojects

Possible partnerships edit

  • Blogs / forums from expert communities / communities of practice
  • Chapters
  • Scholarly publishers
  • GLAM