Growth/Personalizovaný první den/Strukturované úkoly/Přidání odkazu

Skupina:	Growth
Začal:	2020-04-06
Členové týmu:	Gergő Tisza (software engineer), Benoît Evellin (community relations specialist), Elena Tonkovidova (QA engineer), Kosta Harlan (software engineer), Morten Warncke-Wang (data analyst), Rita Ho (senior user experience designer), Max Binder (coach)
Historie změn:	#T252822
Vedoucí:	Roan Kattouw
Vedení:	Marcella Florence (engineering), Marshall Miller (product)
Aktualizace:	Most updates posted here.

This page is a translated version of the page Growth/Personalized first day/Structured tasks/Add a link and the translation is 100% complete.

Řešeno přes Phabricator
Úkol T252822

Tato stránka popisuje práci týmu Growth na strukturovaném úkolu "přidat odkaz", což je typ strukturovaného úkolu, který tým Growth nabízí prostřednictvím domovské stránky pro nováčky. Tato stránka obsahuje nejdůležitější informace, otevřené otázky a rozhodnutí. Více novinek týkající se práce týmu Growth najdete na všeobecné stránce s aktualizacemi. Závažné a větší aktuality budou pak vloženy i sem.

Od srpna 2021 je první iterace tohoto úkolu nasazena u poloviny všech nově vytvořených účtů na Wikipediích v arabštině, češtině, vietnamštině, bengálštině, polštině, francouzštině, ruštině, rumunštině, maďarštině a perštině. Analyzovali jsme data z prvních dvou týdnů nasazení této funkce a zjistili jsme, že mnoho z těchto úprav provádějí nováčci a že mají nízkou míru vrácení změn. Poznatky z této analýzy nás vedly k vylepšení této funkce a výsledky nás povzbuzují k rozšíření nasazení této funkce na více wiki stránek.

V těchto interaktivních prototypech můžete vidět, co stavíme. Všimněte si, že protože se jedná o prototypy, ne všechna tlačítka fungují:

Členové týmu prezentovali na Wikimanii 2021 podklady, algoritmus, implementaci a výsledky této práce. Podívejte se na video zde a slajdy zde.

Vyzkoušejte funkci!

Současný stav

7. ledna 2020 – první vyhodnocení proveditelnosti algoritmu doporučování odkazů
24. února 2020 – vyhodnocení vylepšeného algoritmu pro doporučování odkazů
11. května 2020 – diskuse komunity o strukturovaných úkolech a doporučení propojení
29. května 2020 – počáteční náčrty
27. srpna 2020 – začíná backendové inženýrství
7. září 2020 – první kolo uživatelského testování mobilních designů
8. září 2020 – výzva ke společné diskusi o nejnovějších návrzích
19. října 2020 – druhé kolo uživatelského testování mobilních designů
21. října 2020 – první kolo uživatelského testování designu stolních počítačů
29. října 2020 – začíná frontendové inženýrství
2. listopadu 2020 – druhé kolo uživatelského testování návrhů desktopů
10. listopadu 2020 – výzva k zpětné vazbě k návrhům od arabských, vietnamských a českých komunit
19. dubna 2021 – přidány sekce o terminologii a měření
10. května 2021 – funkce je testována v produkčním prostředí na našich čtyřech pilotních wiki.
27. května 2021 – nasazeno u poloviny nově příchozích na arabské, vietnamské, české a bengálské Wikipedii
21. července 2021 – nasazeno u poloviny nováčků na polských, ruských, francouzských, rumunských, maďarských a perských Wikipediích.
23. července 2021 – zveřejněná analýza z prvních dvou týdnů zavedení funkce.
15. srpna 2021 – prezentace na Wikimanii o podkladech, implementaci, algoritmu a výsledcích.
20. května 2022 – dokončení 2. iterace funkce, která zahrnuje vylepšení založená na zpětné vazbě od komunity a analýze dat (seznam vylepšení viz Přidat odkaz "Iterace 2".
19. června 2022 – zveřejněna analýza experimentu "přidat odkaz"
20. srpna 2022 – zahájení práce na řešení zpětné vazby od sledování ohledně strukturovaných úkolů (T315732)
2. září 2022 – zveřejněna Analýza typu úpravy úkolu pro nováčky
31. prosince 2023 – téměř všechny Wikipedie nyní tento úkol nabízejí nováčkům. Výjimkou je tucet malých wiki, kde není dostatek článků k aktivaci algoritmu, a anglické a německé Wikipedii.
11. července 2025 – publikování Anglická Wikipedie "přidat odkaz" Analýza experimentu
23. října 2025 – Share English Wikipedia "add a link" constructive activation metrics
Další – nasazení na všechny wikiny a spolupráce s hlídači na zlepšení jejich zkušeností s úpravami odkazů.

Shrnutí

Strukturované úkoly mají za cíl rozdělit editační úkoly do postupných pracovních postupů, které jsou smysluplné pro nováčky a fungují i na mobilních zařízeních. Tým Growth věří, že zavedení těchto nových druhů editačních postupů umožní více novým lidem zapojit se do Wikipedie, z nichž někteří se naučí provádět rozsáhlejší úpravy a zapojit se do svých komunit. Poté, co jsme diskusovali s komunitami myšlenku strukturovaných úkolů, jsme se rozhodli vytvořit první strukturovaný úkol: "přidat odkaz". Tento úkol použije algoritmus k označení slov nebo frází, které by mohly být dobrými wikilinky, a nováčci mohou návrhy přijmout nebo odmítnout. V rámci tohoto projektu chceme získat poznatky o těchto otázkách:

Jsou strukturované úkoly poutavé pro nováčky?
Uspějí nováčci se strukturovanými úkoly na mobilních zařízeních?
Generují cenné úpravy?
Vedou některé nováčky k větší angažovanosti?

Po dokončení Analýzy experimentu s "Přidáním odkazu" můžeme dojít k závěru, že strukturovaný úkol "přidání odkazu" zlepšuje výsledky pro nováčky jak oproti kontrolní skupině, která neměla přístup k funkcím Growth, tak i oproti skupině, která měla nestrukturované úkoly přidání odkazů, zejména pokud jde o konstruktivní (nevrácené) úpravy. Nejdůležitější body jsou:

Nováčci, kteří měli k dispozici Přidávání obrázků, se aktivují s větší pravděpodobností (tj. provedou první editaci v hlavním jmenném prostoru).
Tito nováčci se na Wikipedii rovněž s vyšší pravděpodobností udrží (tj. že se některý další den vrátí a uloží další editaci).
Tato funkce také zvyšuje objem úprav (tj. počet konstruktivních úprav provedených během prvních několika týdnů) a zároveň zlepšuje kvalitu úprav (tj. pravděpodobnost, že úpravy nováčka budou vráceny zpět).

Proč wikilinks?

Níže uvedený text je výňatkem ze stránky strukturovaných úkolů a vysvětluje, proč jsme se rozhodli vytvořit "přidat odkaz" jako první strukturovaný úkol.

Tým Growth chce v současné době (květen 2020) upřednostnit pracovní postup "přidat odkaz" před ostatními uvedenými v tabulce výše. Ačkoli se jiné pracovní postupy, jako například "copyedit", zdají být hodnotnější, existuje řada důvodů, proč bychom chtěli začít nejprve s "přidáním odkazu":

V blízké budoucnosti je nejdůležitější věcí, kterou bychom chtěli udělat jako první, dokázat koncept, že "strukturované úkoly" mohou fungovat. Proto bychom chtěli vytvořit tu nejjednodušší, abychom ji mohli nasadit uživatelům a získat z ní nové zkušenosti, aniž bychom museli do první verze investovat příliš mnoho. Pokud první verze půjde dobře, budeme mít důvěru investovat do typů úkolů, které je obtížnější sestavit.

"Přidat odkaz" se nám zdá být nejjednodušší k vytvoření, protože již existuje algoritmus vytvořený výzkumným týmem WMF, který se zdá být v navrhování wikiodkazů dobrý (viz sekce Algoritmy).

Přidání wikiodkazu obvykle nevyžaduje, aby nováček psal cokoli vlastního, což podle nás obzvláště usnadní návrh a tvorbu – a nováčkovi i jeho provedení.

Přidání wikilinku se zdá být úpravou s nízkým rizikem. Jinými slovy, obsah článku nemůže být tak ohrožen nesprávným přidáním odkazů, jako by mohl být nesprávným přidáním referencí nebo obrázků.

Vývoj

Tato sekce obsahuje naše současné vývojové myšlení. Chcete-li se podívat na kompletní sadu úvah o návrhu pro strukturovaný úkol "přidat odkaz", podívejte se na tuto prezentaci, která obsahuje podklady, uživatelské příběhy a počáteční koncepty designu.

Naše návrhy se vyvíjely prostřednictvím několika kol uživatelských testů a opakování. K prosinci 2020 jsme se dohodli na návrzích, které pro první verzi této funkce vypracujeme. Můžete je vidět v těchto ovlivňujících prototypech. Všimněte si, že protože se jedná o prototypy, ne všechna tlačítka fungují:

Srovnávací přehled

Když navrhujeme nějakou funkci, zkoumáme podobné funkce v jiných softwarových platformách mimo svět Wikimedie. Zde jsou některé hlavní body srovnávacích recenzí provedených v rámci přípravy na funkci navrhovaných úprav v systému Android, které zůstávají relevantní pro náš projekt.

Typy úkolů se dělí na pět hlavních typů: Vytváření, Hodnocení, Překlad, Ověřování obsahu vytvořeného ostatními (lidmi nebo strojem) a Oprava obsahu vytvořeného ostatními.
Vizuální design a rozvržení – motivační funkce (statistiky, žebříčky atd.) a onboarding jsou často vizuálně velmi bohaté ve srovnání s jednoduchými formuláři pro vyplňování krátkých úprav. Potěšující animace často kompenzují nedostatek skutečné odměny.
Pobídky – většina produktů nabízela nehmotné pobídky seskupené do: ocenění a hodnocení (odznaky) za dosažení stanovených milníků, osobní hrdosti a uspokojení (statistiky) nebo odemykání funkcí (přístupová práva).
Motivace uživatelů – ti s altruističtější motivací (např. pomoc druhým s učením) budou s větší pravděpodobností motivováni nehmotnými pobídkami než ti s motivací ze sobeckého zájmu (např. kariérní/finanční výhody).
Personalizace/Přizpůsobení bylo nějakým způsobem použito ve většině recenzovaných aplikací. Nejčastějším přizpůsobením byly průzkumy během vytváření účtu nebo před úkolem a geolokalizace použitá pro personalizaci na základě systému.
Vedení – téměř všechny recenzované produkty měly alespoň základní pokyny před dokončením úkolu, nejčastěji úvodní 'prohlídky'. Kontextová nápověda byla poskytována také ve formě instruktážních textů, popisků, podrobných postupů a také ve formě mechanismů zpětné vazby (kladení otázek, odesílání zpětné vazby).

Initial wireframes

After organizing our thoughts and doing background research, the first visuals in the design process are "wireframes". Jejich účelem je jednoduše experimentovat a ukázat některé nápady, o kterých si myslíme, že by mohly dobře fungovat ve strukturovaném pracovním postupu. Úplný kontext k těmto wireframeům naleznete v prezentaci s návrhem.

Poskytnutí podrobnějšího vysvětlení při prvním použití pracovního postupu nováčkem než při dalších pokusech
Vysvětlení, proč se úkol vyplatí vykonat
Výuka konceptů pomocí kontrolních seznamů
Umožnění uživatelům nesouhlasit s algoritmy a generovat přitom užitečná data
Povzbuzování nováčka k přechodu na důležitější úkoly a k učení se více
Poskytování příležitostí k osvojení si výkonnějších nástrojů pro úpravy
Zábrany proti nekvalitním příspěvkům
Odměňování dobré práce

Mobilní makety: srpen 2020

Translate this section

Náš tým probral wireframy z předchozí části. Zvažovali jsme, co by bylo nejlepší pro nově příchozí, s přihlédnutím k preferencím vyjádřeným členy komunity a s ohledem na technická omezení. V srpnu 2020 jsme podnikli další krok a vytvořili makety, které měly detailněji ukázat, jak by daný prvek mohl vypadat. Tyto makety (nebo podobné verze) budou použity v týmových diskusích, diskusích komunity a uživatelských testech. Jednou z nejdůležitějších věcí, nad kterými jsme u těchto maket přemýšleli, je obava, kterou jsme od členů komunity opakovaně slyšeli během diskuse: Strukturované úkoly mohou být dobrým způsobem, jak seznámit nováčky s editací, ale také chceme zajistit, aby si v případě zájmu mohli najít a používat tradiční editační rozhraní.

Máme makety pro dva různé vývojové koncepty. Nejde nutně o to, vybrat si jeden nebo druhý vývojový koncept. Tyto dva koncepty mají spíše demonstrovat odlišné přístupy. Naše finální návrhy mohou obsahovat to nejlepší z obou konceptů:

Koncept A: Úprava strukturovaného úkolu probíhá ve vizuálním editoru. Uživatel si může prohlédnout celý článek a přepnout z "režimu doporučení" do režimu zdrojového kódu nebo vizuálního editoru. Méně zaměřené na přidávání odkazů, ale snazší přístup k vizuálním a zdrojovým editorům.
Koncept B': Úprava strukturovaného úkolu probíhá ve vlastní nové oblasti. Uživateli se zobrazí pouze odstavec článku, který vyžaduje jeho pozornost, a v případě potřeby může článek upravit. Méně rušivých elementů z přidávání odkazů, ale vzdálenější přístup k vizuálnímu editoru a editoru zdrojového kódu.

Vezměte prosím na vědomí, že tato sada maket se zaměřuje na uživatelský tok a zážitek, nikoli na slova a jazyk. Náš tým projde procesem, aby určil nejlepší způsob, jak napsat slova v daném prvku, a vysvětlil uživateli, zda by měl být odkaz přidán.

Static mockups

Pro zobrazení těchto designových konceptů doporučujeme prohlédnout si celou sadu snímků níže.

Interactive prototypes

You can also try out the "interactive prototypes" that we're using for live user tests. These prototypes, for Concept A and for Concept B, show what it might feel like to use "add a link" on mobile. They work on desktop browsers and Android devices, but not iPhones. Note that not everything is clickable -- only the parts of the design that are important for the workflow.

Základní otázky

V rámci diskuse o těchto návrzích náš tým doufá, že získá odpovědi na řadu zásadních otázek:

Měla by úprava probíhat v článku (více kontextu)? Nebo ve vyhrazeném prostředí pro tento typ úprav (více zaměření, ale větší přechod k použití editoru)?
Co když chce někdo upravit cíl odkazu nebo text? Měli bychom tomu zabránit, nebo ho nechat používat standardní editor? Je tohle příležitost naučit ho pracovat s vizuálním editorem?
Víme, že je pro nás nezbytné podporovat nováčky při objevování tradičních editačních nástrojů. Ale kdy to uděláme? Uděláme to během strukturovaného úkolu s připomenutím, že uživatel může přejít do editoru? Nebo pravidelně při dosažení milníků dokončení, například po dokončení určitého počtu strukturovaných úkolů?
Je v tomto případě "bot" správný termín? Jaké jsou další možnosti? "Algoritmus", "Počítač", "Auto-", "Stroj" atd.? Co by mohlo lépe vyjádřit, že strojová doporučení jsou omylná a jak důležitý je lidský zásah?

Mobile user testing: September 2020

Background

During the week of September 7, 2020, we used usertesting.com to conduct 10 tests of the mobile interactive prototypes, 5 tests each of Concepts A and B, all in English. By comparing how users interact with the two different approaches at this early stage, we wanted to better understand whether one or the other is better at providing users with good understanding and ability to successfully complete structured tasks, and to set them up for other kinds of editing afterward. Specific questions we wanted to answer were:

Do users understand how they are improving an article by adding wikilinks?
Do users seem like they will want to cruise through a feed of link edits?
Do users understand that they're being given algorithmic suggestions?
Do users make better considerations on machine-suggested links when they have the full context of the article (like in Concept A)?
Do users complete tasks more confidently and quickly in a focused UI (like in Concept B)?
Do users feel like they can progress to other, non-structured tasks?

Key findings

The users generally were able to exhibit good judgment for adding links. They understood that AI is fallible and that they have to think critically about the suggestions.
While general understanding of what the task would be ("adding links") was low at first, they understood it well once they actually started doing the task. Understanding in Concept B was marginally lower.
Concept B was not better at providing focus. The isolation of excerpts in many cases was mistaken for the whole article. There were also many misunderstandings in Concept B about whether the user would be seeing more suggestions for the same term, for the same article, or for different articles.
Concept A better conveyed expectations on task length than Concept B. But the additional context of a whole article did not appear to be the primary factor of why.
As participants proceed through several tasks, they become more focused on the specific link text and destination, and less on the article context. This seemed like it could lead to users making weak decisions, and this is a design challenge. This was true for both Concepts A and B.
Almost every user intuitively knew they could exit from the suggestions and edit the article themselves by tapping the edit pencil.
All users liked the option to view their edits once they finished, either to verify or admire them.
“AI” was well understood as a concept and term. People knew the link suggestions came from AI, and generally preferred that term over other suggestions. This does not mean that the term will translate well to other languages.
Copy and onboarding needs to be succinct and accessible in multiple points. Reading our instructions is important, but users tended not to read closely. This is a design challenge.

Outcome

We want to build Concept A for mobile, but absorbing some of the best parts of Concept B's design. These are the reasons why:
- User tests did not show advantages to Concept B.
- Concept A gives more exposure to rest of editing experience.
- Concept A will be more easily adapted to an “entry point in reading experience”: in addition to users being able to find tasks in a feed on their homepage, perhaps we could let them check to see if suggestions are available on articles as they read them.
- Concept A was generally preferred by community members who commented on the designs, with the reason being that it seemed like it would help users understand how editing works in a broader sense.
We still need to design and test for desktop.

Ideas

The team had these ideas from watching the user tests:

Should we consider a “sandbox” version of the feature that lets users do a dry run through an article for which we know the “right” and “wrong” answers, and can then teach them along the way?
Where and when should we put the clear door toward other kinds of editing? Should we have an explicit moment at the end of the flow that actively invites them copyedit or do another level task?
It’s hard to explain the rules of adding a link before they try the task, because they don't have context. How might we show them the task a little bit, before they read the rules?
Perhaps we could onboard the users in stages? First they learn a few of the rules, then they do some links, then we teach them a few more pointers, then they do more links?
Should users have a cooling-off period after doing lots of suggestions really fast, where we wait for patrollers to catch up, so we can see if the user has been reverted?

Desktop mockups: October 2020

After designing, testing, and deciding on Concept A for mobile users, we moved on to thinking about desktop users. We again have the same question around Concepts A and B. The links below open interactive prototypes of each, which we are using for user testing.

Concept A: the structured task takes place at the article, in the editor, using some of the existing visual editor components. This gives users greater exposure to the editing context and may make it more likely that they explore other kinds of editing tasks.
Concept B: the structured task takes place on the newcomer homepage, essentially embedding the compact mobile experience into the page. Because the user doesn't have to leave the page, this may encourage them to complete more edits. They could also see their impact statistics increase as they edit.

We are user testing these designs during the week of October 23. See below for mockups showing the main interaction in each concept.

Mockup of Concept A
Mockup of Concept B

Outcome

The results of the desktop user tests led us to decide on Concept A for desktop for many of the same reasons we chose Concept A for mobile. The convenience and speed of Concept B did not outweigh the opportunity for Concept A to expose newcomers to more of the editing experience.

Terminology

"Add a link" is a feature in which human users interact with an algorithm. As such, it is important that user have a strong understanding that suggestions come from an algorithm and that they should be regarded with skepticism. In other words, we want the users to understand that their role is to evaluate the algorithm's suggestion and not to trust it to much. Terminology (i.e. the words we use to describe the algorithm) play an important role in building that understanding.

At first, we planned to use the terms "artificial intelligence" and "AI" to refer to the algorithm, but we eventually decided to use the term "machine". This may be a practice that gets adopted more broadly as multiple teams build more structured tasks that are backed by algorithms. Below is how we thought about this decision.

Background

As we build experiences that incorporate augmentation, we are thinking about the terminology to use when referring to suggestions that come from automated systems. If possible, we want to make a smart choice at the outset, to minimize changes and confusion later. For instance, we are looking at sentences in the feature like these:

"Suggested links are machine-generated, and can be incorrect."
"Links are recommended by machine, and you will decide whether to add them to the article."

Objectives

We want the terms we use to satisfy these objectives.

Transparency: users should understand where recommendations come from, and we should be being honest with them.
Human-in-the-loop: users should understand that their contributions improve recommendations in the future.
Usability: copy should help users complete the tasks, not confuse or burden them with too much information.
Consistency: we should use the same copy as much as possible to lower cognitive load.

Terms we considered

Term	Strengths	Weaknesses
AI	Well understood in some cultures. Users naturally understand that it can fail.	May not accurately describe all the various augmentation we use. Users may think methods are more sophisticated or opaque than they are. Can be challenging to translate.
Machine	Moderately understood. Wide applicability.	Some users may not understand what we mean / term seems archaic. Unclear how much to trust it.
Computer	Moderately understood. Wide applicability.	Sounds archaic
Algorithm	Well understood. Wide applicability.	Unclear how much to trust it. Different meaning in ML context.
Automated	Total applicability.	So broad that it may not convey much meaning to users.

Methods and findings

User testing: the Growth team tested "add a link" in English using the terms "artificial intelligence" and "AI". We found that users understood the term well and that English-speaking users understood that they should regard the output of AI with skepticism.
Experts: we spoke to WMF experts in the fields of artificial intelligence and machine learning. They explained that the link recommendation is not truly "AI", in the way that the term is used in the industry today. They explained that by using that term, we may be over-inflating our work and giving users a false sense of the intelligence of the algorithm. Experts preferred the term "machine", as it would accurately describe the link recommendation algorithm as well as be broad enough to describe almost any other kind of algorithm we might use for structured tasks.
Multi-lingual community members: we spoke to about seven multilingual colleagues and ambassadors about the terms that would make the most sense in their languages. Not all languages have a short acronym for "AI"; many have long translations. The consensus was that "machine" made good sense in most languages and would be easy to translate.

Result

We are going to use the term "machine" to refer to the link recommendation algorithm, e.g. "Suggested links are machine-generated". See screenshots below to see one of the places where the terminology changed based on this decision.

Onboarding screen using the term "AI"
Onboarding screen using the term "machine"

Measurement

Hypotheses

The “add a link” workflow structures the process of adding wikilinks to a Wikipedia article, and assists the user with artificial intelligence to point out the clearest opportunities for adding links. Our hypothesis with the “add a link” workflow is that such a structured editing experience will lower the barrier to entry and thereby engage more newcomers, and more kinds of newcomers than an unstructured experience. We further hypothesize that newcomers with the workflow will complete more edits in their first session, and be more likely to return to complete more.

Below are the specific hypotheses we seek to validate. These govern the specifics around which data we'll collect and how we'll analyze it.

The "add a link" structured task increases our core metrics of activation, retention, and productivity.
“Add a link” edits are more likely to be successful than unstructured suggested edits, meaning that a user completes the task and saves the edit. They are also more likely to be constructive, meaning that the edit was not reverted, than unstructured suggested edits.
Users seem to understand this task more than unstructured tasks.
Users who start with "add a link" will move on to other kinds of tasks, instead of staying siloed (the latter being a primary community concern).
The perceived quality of the link recommendation algorithm will be high, both from the users who make "add a link" edits and the communities who review those edits.
Users who get “add a link” and who primarily use/edit wikis on mobile see a larger increase in the effects on retention and productivity relative to desktop users.

Experiment Plan

A randomly selected half of users who get the Growth features will get "add a link" tasks, and the other randomly selected half will get unstructured link tasks. We prefer to give users maximum exposure to these tasks and will therefore not give these users any copyedit tasks by default. In other words, for the purposes of this experiment, we’ll change the default difficulty filters from “links” and “copyedit” to just “links”. For wikis that don’t have unstructured link tasks, all those users get “add a link” and in that case we’ll exclude that wiki from the experiment.

We plan to continue to have a Control group that does not get access to the Growth features, which is a randomly selected 20% of new registrations.

Group A: users get “add a link” as their only default task type.
Group B: users get unstructured link task as their only default task type.
Group C: control (no Growth features)

The experiment will run for a limited time, most likely between four to eight weeks. In practice the experiment will start with our four pilot wikis. After two weeks, we will analyze the leading indicators below to decide whether to extend the experiment to the rest of the Growth wikis.

Experiment Analysis and Findings

Řešeno přes Phabricator
Úkol T286816

After completion of "Add a link" Experiment Analysis, we can conclude that the "add a link" structured task improves outcomes for newcomers over both a control group that did not have access to the Growth features as well as the group that had the unstructured "add links" tasks, particularly when it comes to constructive (non-reverted) edits. The most important points are:

Newcomers who get the Add a Link structured task are more likely to be activated (i.e. make a constructive first article edit).
They are also more likely to be retained (i.e. come back and make another constructive article edit on a different day).
The feature also increases edit volume (i.e. the number of constructive edits made across the first couple weeks), while at the same time improving edit quality (i.e. the likelihood that the newcomer's edits are reverted).

Leading Indicators and Plan of Action

Řešeno přes Phabricator
Úkol T277355

We are at this point fairly certain that Growth features are not detrimental to the wiki communities. That being said, we also want to be careful when experimenting with new features. Therefore, we define a set of leading indicators that we will keep track of during the early stages of the experiment. Each leading indicator comes with a plan of action in case the defined threshold is reached, so that the team knows what to do.

Indicator	Plan of Action
Revert rate	This suggests that the community finds the Add a Link edits to be unconstructive. If the revert rate for Add a Link is significantly higher than that of unstructured link tasks, we will analyze the reverts in order to understand what causes this increase, then adjust the task in order to reduce the likelihood of edits being reverted.
User rejection rate	This can indicate that we are suggesting a lot of links that are not good matches. If the rejection rate is above 30%, we will QA the link recommendation algorithm and adjust thresholds or make changes to improve the quality of the recommendations.
Task completion rate	This might indicate that there’s an issue with the editing workflow. If the proportion of users who start the Add a Link task and complete it is lower than 75%, we investigate where in the workflow users leave and deploy design changes to enable them to continue.

Analysis and Findings

We collected data on usage of Add a Link from deployment on May 27, 2021 until June 14, 2021. This dataset excluded known test accounts, and does not contain data from users who block event logging (e.g. through their ad blocker).

This analysis categorizes users into one of two categories based on when they registered. Those who registered prior to feature deployment on May 27, 2021 are labelled "pre-deployment", and those who registered after deployment are labelled "post-deployment". We do this because users in the "post-deployment" group are randomly assigned (with 50% probability) into either getting Add a Link or the unstructured link task. Users in the "pre-deployment" group have the unstructured link task replaced by Add a Link. By splitting into these two categories, we're able to make meaningful comparisons between Add a Link and the unstructured link task, for example when it comes to revert rate.

Revert rate: We use edit tags to identify edits and reverts, and reverts have to be done within 48 hours of the edit. The latter is in line with common practices for reverts.

User registration	Task type	N edits	N reverts	Revert rate
Post-deployment	Add a Link	290	28	9,7%
Post-deployment	Unstructured	63	22	34,9%
Pre-deployment	Add a Link	958	49	5,1%

For the post-deployment group, a Chi-squared test of proportions finds the difference in revert rate to be statistically significant ( $χ^{2} = 16.5, d f = 1, p ≪ 0.001$ ). This means that the threshold described in the leading indicator table is not met.

Rejection rate: We define an "edit session" as reaching the edit summary or skip all dialogue, at which point we count the number of links that were accepted, rejected, or skipped. Users can reach this dialogue multiple times, because we think that choosing to go back and review links again is a reasonable choice.

User registration	N accepted	%	N rejected	%	N skipped	%	N total
Post-deployment	597	72,4	125	15,2	103	12,5	825
Pre-deployment	1 464	65,1	595	26,5	189	8,4	2 248
	2 061	67,1	720	23,4	292	9,5	3 073

The threshold in the leading indicator table was a rejection rate of 30%, and this threshold has not been met.

Over-acceptance rate: This was not part of the original leading indicators, but we ended up checking for it as well in order to understand whether users were clicking "accept" on all the links and saving those edits. We reuse the concept of an "edit session" from the rejection rate analysis, and count the number of users who only have sessions where they accepted all links. In order to understand whether these users make many edits, we measure this for all users as well as for those with five or more edit sessions. In the table below, the "N total" column shows the total number of users with that number of edit sessions, and "N accepted all" the number of users who only have edit sessions where they accepted all suggested links.

User registration		N total	N accepted all	%
Post-deployment	≥1 edit	96	31	32,3
	≥5 edits	6	0	0,0
Pre-deployment	≥1 edit	64	10	15,6
	≥5 edits	19	1	5,3

We find that some users only have sessions where they accepted all links, but these users do not typically continue to make Add a Link edits. Instead, users who make additional edits start rejecting or skipping links as needed.

Task completion rate: We define "starting a task" as having an impression of "machine suggestions mode". In other words, the user is loading the editor with an Add a Link task. "Completing a task" is defined as clicking to save an edit, or confirming that all suggested links were skipped.

User registration	N Started a Task	N Completed 1+ Tasks	%
Post-deployment	178	96	53,9
Pre-deployment	101	64	63,4
	279	160	57,3

The threshold defined in the leading indicator table is "lower than 75%", and this threshold has been met. In this case, we're planning to do follow-up analysis to understand more about the tasks, e.g. if they had a low number of suggested links, or if this happens on specific wikis or platforms.

Rejection Reasons

Řešeno přes Phabricator
Úkol T301884

We've analyzed data on why users reject suggested links, focusing on newcomers to help us understand how they learn what constitutes good links in Wikipedia. In this analysis, we used rejections from January and February 2022, and restricted it to actions made within 7 or 28 days since registration. There was no significant difference in patterns between the two, and the data reported here uses the 28 day window. The data was split by wiki, platform (desktop or mobile) and bucketed by the number of Add a Link edits the user had made. We used a logarithmic bucketing scheme with 2 as the base, because that gives us a fair number of buckets early in a user's life while at the same time being easy to understand since the limits double each time.

Rejection reason counts and percentages by platform.
Platform	Rejection reason	N	%
Desktop	Almost everyone knows what it is	2 732	53,0%
	Linking to wrong article	1 377	26,7%
	Other	688	13,0%
	Text should include more or fewer words	378	7,3%
Mobile	Almost everyone knows what it is	1 835	53,3%
	Linking to wrong article	791	23,0%
	Other	484	14,1%
	Text should include more or fewer words	271	7,9%
	Undefined	62	1,8%

The distribution of these reasons is generally the same across all wikis, platforms, and number of Add a Link edits made. For some combinations of these features, we run into the issue of having few data points available (e.g. because some wikis lean strongly to usage of one platform) and that might result in a somewhat different distribution (e.g. just ones marked "Text should include more or fewer words"). In general, we have a lot of data for users with few edits as that's what most users are.

One thing we do appear to see is that for some wikis the usage of "Other" decreases as the number of Add a Link edits made increases. We interpret this to mean that "Other" might be a catchall/safe category for less experienced users, and that as they become more experienced and confident in labelling a link they'll use a different category.

Engineering

Link recommendation algorithm

See this page for an explanation of the link recommendation algorithm and for statistics around its accuracy. In short, we believe that users will experience an accuracy around 75%, meaning that 75% of the suggestions they get should be added. It is possible to tune this number, but the higher the accuracy is, the fewer candidate link we will be able to recommend. After the feature is deployed, we can look at revert rates to get a sense of how to tune that parameter.

For a detailed understanding of how the algorithm functions and is evaluated, see this research paper.

Link recommendation service backend

To follow along with engineering progress on the backend "add link" service, please see this page on Wikitech.

Articles selection

Articles are selected based on the topic(s) the user chooses. Then articles with a low ratio of links compared to the number of words are selected. A small amount of randomness was added to it so that not every article suggested look the same. The formula is documented on Phabricator.

Nasazení

27. května 2021 jsme nasadili první iteraci tohoto úkolu na naše čtyři pilotní wikiny: arabskou, českou, vietnamskou a bengálskou Wikipedii. Je k dispozici pro polovinu nových účtů, jak je popsáno výše. Tuto funkci budou mít k dispozici i všechny účty vytvořené před nasazením. Po dvou týdnech analyzujeme naše předstihové indikátory, abychom zjistili, zda je třeba provést nějaké rychlé změny. Přibližně po čtyřech týdnech využijeme data a zpětnou vazbu od komunity k určení, zda a jak tuto funkci nasadit na více wikinách.

Od počátečního nasazení na našich pilotních wikinách shromáždil tým Growth rozsáhlou zpětnou vazbu od komunity a data o používání a hodnotě funkce Přidat odkaz. Tyto poznatky jsme pak využili k vylepšení funkce, aby nováčci měli lepší zážitek a zkušení editoři viděli kvalitnější úpravy. Dokončili jsme vylepšení a komunity nyní používají opakování 2 funkce Přidat odkaz.

Nasazení na všechny Wikipedie bylo dokončeno na konci roku 2023, chybělo jen několik málo wikin: německá a anglická, protože vyžadují specifické zapojení komunity, a velmi malé Wikipedie, kde neexistuje kritické množství odkazů pro dostatek odkazů.

In 2024, the Add a Link task was deployed at German and English Wikipedias. As we gradually scaled the feature to newcomers on English Wikipedia, we used this opportunity to run a natural A/B test to evaluate its impact.

The test aimed to determine whether "Add a Link" improves constructive activation on English Wikipedia—specifically, whether it helps more new account holders complete a first edit. The A/B test confirmed our hypothesis: the task led to a relative increase in constructive activation on both mobile and desktop platforms.

Full Report: Add-a-link Experiment on English Wikipedia.