Targeted acquisition campaigns
This page in a nutshell: This page presents a proposal for a contribution campaign infrastructure modeled after Wiki Loves Monuments, with technical implementation and analytics requirements. It also provides materials for a talk submitted to Wikimania '14 on The missing Wikipedia ads: Designing targeted contribution campaigns. |
About
editI 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:
- generating easy to distribute/embeddable calls for participation
- 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
editAnalytics requirements
editRisks and issues
editSandbox
editRationale
edit- alternative acquisition models
- acquire first / activate later
- acquire targeted segments of users
- 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)
- little structured effort to support bottom-up campaigns
- millions of subject matter experts are out there but they are not actively targeted to contribute to Wikipedia
Task selection
editType of task
editPick tasks that are easy to extract, easy to localize and less subject to friction with content/quality policies.
- Stubs
- Redlinks
Task ranking
editTraffic 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
editBy 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
editThe following are technical requirements to expose tasks and generate campaigns
Task repository
editThis 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- 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
editOther than task widgets, 3rd party integration could be achieved with services reusing or exposing Wikimedia contents
- Twitter cards
- Google Knowledge Panel
- Wikipedia Live Monitor
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
editUse outgoing links in task widgets to generate account creation campaigns:
Campaign logic
edit- point to the account creation landing page
- use a dedicated campaign identifier as a
campaign
parameter - 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
editReturnTo
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:
- number of account creations
- number of activated users
- revert rate per cohort
- activity/survival per cohort
- content contributed per cohort
Affiliation
editUse 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