Anonymous editor acquisition/Signup invites
This document describes proposed workflows for inviting anonymous editors to sign up for an account. This is currently part of the GettingStarted extension.
Current user experience
Currently, there are very few explicit invitations made to anonymous editors to sign up for an account. Not including help page documentation and other content that a reader would need to actively seek out, we know of only a few widespread calls to sign up for an account on Wikipedia:
- On every page view, links to "create account" or "log in" are present. These are persistent and highly visible, but do not make it clear why a user would want an account.
- On the login page, there is a call to register if you do not already have an account. This makes up a surprisingly large chunk of registrations on some wikis.
- On many Wikipedias, there is a notice delivered on the edit mode (in VisualEditor and wikitext editor) which directs you to log in or sign up for an account. It also typically informs the user about exposing their IP as an anonymous editor, and in English it links to a page documenting the benefits of signing up. This one notice makes up a significant number of registrations on the largest Wikipedias (between 9-15%).
Proposed desktop user experience
These two options will be tested against a control.
If we think it is advantageous for users to log in or sign up, then we need to ask users to do so. Passive "create account" links (in the personal toolbar or in static MediaWiki messages mid-edit) are not ideal as calls-to-action. We also know that, using methods like tooltip-based guided tours, actively asking users to complete an action and showing them how works for increasing completion rates within a funnel. This effect comes not just from actively asking users to do things, but through asking them to complete actions that align with a clear mental model about what they're being asked to do and why.
For Option 1 in particular, we believe that this may increase registrations by essentially requiring the user to make a choice to stay anonymous or sign up/log in if they wish to proceed with editing. While this choice causes an increase in the steps pre-edit and cognitively in general, it may actually cause less frustration than the current user experience, because it does not require the user to load the edit page and then abandon their edit if they want to log in. While this is an interruption, users on the modern web are very used to being asked to authenticate to take certain actions, like contributing content.
For Option 2, we believe that this interface change would increase the number of anonymous editors who register, because it targets users who successfully saved an edit anonymously and thus are likely to be high-value acquisitions. This workflow is also less of an interruption or barrier to editing anonymously. The disadvantage of this workflow is that it could potentially annoy anonymous editors by showing them multiple calls to register. It may also increase confusion over why they would be asked to register after editing instead of before, if we are suggesting that it is better for users, since they usually see signup invitations prior to performing an action.
One of the risks we run in either option is that we will significantly increase the number of registrations, but that users acquired will not be driven to contribute as much as the signups we already acquire via more passive calls to register. If this occurs, then the alternative is to increase acquisitions by improving CTAs or creating new ones that are not direct suggestions to register, but which are instead more closely tied with improving content. For both options (but particularly option 1) there is a risk that the dialog will cause friction that reduces productivity; for example, someone seeing the pre-edit CTA may neither signup nor edit.
Option 1: Pre-edit CTA
When an user that is not logged in clicks "Edit" or "Edit source", they will be presented with a guider that provides them two options: a primary button to go to account creation, and a secondary button to continue to the appropriate edit mode as an anonymous user. This would work the same for section editing, and regardless of how the wiki editing interfaces are configured, e.g. regardless of whether VisualEditor is enabled for anonymous editors or not. Explanatory text should be provided that warns the user that they will have their IP address saved in a page's revision history. If the user clicks edit again after the CTA appears, then the edit button will function as normal.
Option 2: Post-edit CTA
In this workflow, the user is given a call-to-action only after saving an edit anonymously. This guider would point directly to the "create account" link on the site. It provides explanation as to why we encourage prolific or repeat editors to sign up, giving the user a reason for registering and context. If they dismiss the CTA and continue to edit anonymously, the user should not be presented with the CTA multiple times.
Proposed mobile user experience
Anonymous editing does not currently exist on mobile web for Wikipedia. This first experimental take on this is planned for the redesign for iOS and Android that is being undertaken by the Wikimedia Apps team. Later, the mobile web team will begin testing similar workflows. Learn more at Mobile wikitext editing#Anonymous editing.
To be filled in.
Both the iOS and Android apps support anonymous editing. For the initial release, the workflow does not prompt anonymous users to sign up. Mockups of the workflow are available at File:Mobile editing workflow MVP, 6th June.png.
Originally, a call to action to sign in and save previously existed in the app. User testing showed that the call to action was completely ineffective for anonymous editor acquisition; new users would simply press "Save anonymously" without reading any of the accompanying text. The call to action was therefore removed as it was not accomplishing its intended goal of acquiring anonymous editors and was just bloating out the number of steps required to save edits.
However, the team recognised that we still needed to attempt to acquire anonymous editors, so an onboarding experience was designed for the MVP. Mockups of this are available at File:Mobile onboarding workflow, 6th June.png.
- Data from campaign tracking
- Our third A/B test of the onboarding process tested an experience with guiders vs. one without
- Research:Anonymous editor acquisition/Volume and impact