Anonymous editor acquisition/Signup invites v2


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[edit]

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:

  1. On every page, 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.
  2. 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.
  3. 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%).[1]

Proposed user experience[edit]

The following user narratives are meant to help us understand the users who might interact with these interfaces and how they would react.

Julie is a college student. She's supposed to be studying, but she's really watching the latest Game of Thrones episode. Julie can't remember all the characters, and she has her laptop open anyway, so she browses the list of characters on Wikipedia. While reading, she notices that one of the summaries is missing an interesting fact from the previous episode. Julie knows anyone can update Wikipedia, since she heard her teachers talk about it and her friend put a joke in an article once. She goes ahead to click edit, but a popup asks her to sign up first. Julie is used to being asked to sign up for apps and websites, so she decides to create an account.

Mike is a help desk agent at a Fortune 500 company. He's looking up an IT-related issue on Wikipedia, like he sometimes does to while troubleshooting something unfamiliar. This time, he notices an outdated piece of information about a WiFi router model. He goes to click edit, and sees an invitation to sign up. Mike has edited Wikipedia occasionally in the past when notices something wrong, and he knows a lot about IT. However, he doesn't have time to create an account right now, so he just wants to go ahead and make his edit. Mike might have made an account years ago, but he doesn't remember. If he has to spend time thinking about how to proceed, he'll probably just skip editing and go back to work.

Diagram of workflow for pre-edit CTA

Specification: 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. It will also work whether or not VisualEditor is available. If the user clicks edit again after the CTA appears, then the edit button will function as normal.

Version one[edit]

This version is the same as in the previous A/B test.

Screenshot of the CTA triggered on the main Edit button

Version two[edit]

In this version, we are aiming to more strongly emphasize that A) registering is not required B) the user can continue editing immediately.

Screenshot of the CTA triggered on the main Edit button

Rationale and context[edit]

Preliminary results from the previous A/B test showed that we caused a 2-3x increase in new signups among anonymous editors. These users were either as successful at editing as signups in the control group, and in some cases better. However, we also caused an overall drop in productive edits among unregistered users in the pre-edit condition. We have three potential theories about why this was the case, which are not mutually exclusive:

  1. We showed the pre-edit CTA multiple times per user. Showing this repeatedly caused people to get frustrated and refrain from editing.
  2. The pre-edit version may have suggested that editing was required.
  3. Interrupting users in any way causes them to be distracted or annoyed.

Testing with a new version that emphasizes that registering is optional, as well as only showing the CTAs once by setting a cookie, should help us eliminate the first two theories as possibilities.


Like the previous version, this will be built as a guided tour and hosted in the GettingStarted extension.

Testing methodology and data analysis[edit]

In order to compare the two iterations, we will be using the same metrics and analysis from the first A/B test.