Reading/Web/Projects/Related pages

Read more is an experiment that will be carried out by the Reading team on desktop and mobile web, in order to further engage readers and increase their browsing time. The concept already exists on apps, where you can check the performance report

Read more aims to drive page views by engaging users by directing them to related content. We aim to show that at least 5% of page views that see read more engage with read more driving new eyes on our articles and more engagement in our project.

The Problem
If a reader has reached to the bottom of the article, they might be looking to read more about the topic and surfacing articles that are similar might be exactly what they are looking for.

This has been released on apps and saw a 16% click-through (For users who saw it). Additionally, 25% of the users who saw read more results clicked through at least more than once.

The How
Using the Extension:RelatedArticles extension we will show suggested articles at the bottom of pages encouraging the user to read another page. A user who gets to the bottom of an article on either mobile or desktop web is shown a list of other articles that are related to the one they just finished. The notion is that if the reader has read to the end of the article, they might be looking to read more about the topic and surfacing articles that are similar might be exactly what they are looking for. This has been release on apps and saw a 16% click-through (For users who saw it). Additionally, 25% of the users who saw read more results clicked through at least 1x in a 1-day period (data).

Rationale
If readers are offered suggestions that are similar to the topic they are reading about, this will further engage their reading session time, it will further educate them about the topic they are looking for, and supports a richer reading experience for those who are just randomly browsing topics.

Success criteria

 * %CTR (click through rate, clicks/views) is higher than 10%.
 * Ideally, we will be able to ensure that these clicks are not-cannibalistic (increasing overall clicks as opposed to taking clicks from blue links)

Prototyping
This will be tested in beta first.

MVP
A user reaching the bottom of an article is shown the title and lead image for 3 articles that relate to the article they just finished. We are able to measure the engagement clicks/impressions with this feature.

User Stories
A user reaching the bottom of an article is shown the title and lead image for 3 articles that relate to the article they just finished so that they can continue reading about that topic. Someone editing a Wikipedia article can manually change the article suggestions using wikitext so that they can correct any erroneous or sub-optimal suggestions. A project stakeholder (such as PM or data analysis) is able to measure the engagement clicks/impressions with this feature so they can determine if it is adding user value.

Metrics Implementation
We will want to track:
 * Impressions of read more suggestions (the lump--not each item suggested)
 * Clicks to read a suggested article
 * The position of article (1,2,3). Ideally: whether or not article was edited manually
 * Ideally: a)overall referrals from a page with read more, b)overall referrals from same page without read more

Timeline Estimate

 * 1)     discuss with community
 * 2)     build read more according to mobile web specs ✅
 * 3)     launch on mobile web beta
 * 4)     measure impact using event logs CTR (referral data won't be helpful at these numbers)
 * 5)     launch on mobile
 * 6)     build for desktop
 * 7)     launch on desktop (open discussion about whether we launch in beta first and/or do progressive rollout)
 * 8)     Delivery Estimate: End of December on desktop?

FAQ
A more like query which will programmatically choose related pages based on similarity to the existing corpus of text. User:Jkatz (WMF) thinks that making them editable is a problem because: They have pretty pictures. Which increases click-through rate. Which is the metric of success for this feature.
 * Where do articles come from?
 * Do editors have any control or are they given any preview of the suggested articles?
 * the results are not automatically updated
 * it means that improvements we make to the algorithm/selection will be lost to pages where an editor has overridden the automated selection.
 * right now the manual selection option only applies to the web (not the apps), which is misleading
 * some editors have requested that we do automated refreshes every time you load the page--this would not be possible if it was manually derived.
 * How is related articles different from the See also section, navigation boxes and the category system?

Join the conversation
This task is being tracked on Phabricator and we'd love to hear your thoughts.