Welcome to the Works! This is the place where you will find detailed explanations of new product features and other exciting ways we’re tinkering with how we publish and present our content. First up, a deep dive into the reasoning behind Slate’s recent infinite scroll implementation:
Last week, Slate launched its infinite scroll reading experience. Now, when you visit most Slate stories and scroll to the bottom of the page, another story appears. Then another story appears if you keep scrolling.
This functionality was the culmination of many months of work, and we’re incredibly proud of the outcome. Our site is now more attractive and cleaner looking, and it leads people to spend more time with our content: In randomized controlled testing, we saw time on site per visitor increase by 9 percent for the infinite scroll test group relative to users on our old pages. But we didn’t simply want to increase time on site—we also strove to increase ad revenue per user, and to do so while eliminating features that prioritized immediate clicks above the overall quality of our readers’ experience.
Indeed, this summarizes our mission on the Slate product and development team: to offer the best possible reader experience while generating as much revenue as possible to support our journalism. We believe that eliminating clutter on our pages focuses attention on our content, that page-load time is a key element of the user experience, and that reducing the number of revenue-generating modules ensures that those remaining offer the best visual and advertiser impact. And we believe that prioritizing time spent on the site over drive-by traffic will enable us to balance editorial goals with revenue maximization. Our infinite scroll experience is a product completely rooted in these philosophies.
Our Goal: Grow Time on Site, not Page Views
For the first time since I’ve been the product lead at Slate, we’ve begun to prioritize reader loyalty above growth in unique visitors, and to focus on increasing time on site rather than page views. Our deliberate shift in strategy stems from our belief that the time on site goal uniquely aligns the priorities of readers, advertisers, and our editorial team. If readers spend more time with content that they value, they’ll be more likely to view more ads while they’re reading, they’ll be more likely to share our content, and they’ll be more likely to join our membership program, Slate Plus.
In contrast, an obsessive focus on maximizing page views can produce incentives that are at odds with a good UX (user experience), rather than in service of it. The classic example is the Internet slideshow where every image is on a different page, and ads are reloaded every time the user clicks “next.” Users spend a lot more time waiting around than they would if the images could be cycled through on a single page.
With time on site at the forefront of our minds as we developed our infinite scroll implementation, we were able to avoid the trap of pitting user experience and revenue against each other. We eliminated pagination and reduced the number of link suggestions, changes that had a slightly negative impact on total page views but ultimately increased the total time people engaged with our content.
What’s next on this front: While Comscore indicates that Slate does quite well relative to our peers in terms of time on site per user, we can do better. We have more work to do to focus the culture and provide the analytics and technology infrastructure to optimize time on site.
Eliminating Pagination
We’ve finally stopped paginating our articles. Perhaps Slate’s greatest usability sin over the last decade has been our pagination of articles longer than 1,000 words. In 2012, Farhad Manjoo, then Slate’s technology columnist, scathingly criticized his own publication for this policy. Asking readers to click through multiple pages of a story has been responsible for about 10 percent of Slate’s page views and ad impressions—had we simply eliminated it without changing anything else, it would have resulted in a substantial reduction in revenue, forcing us to produce less journalism.
So how did our infinite scroll plans allow us to revisit this policy?
First, while we are losing page views from depaginating all stories, we gain back most of those page views from users scrolling through more than one story in the infinite scroll stream. As this graph shows, 18 percent of interior page views occurred on scrolled pages during our testing:
Second, we are varying the number of ad impressions per page based on the length of the story. A story that was once two pages long, may have shown a total of six ads. This story may now be a single page, but with the same total number of ads inserted automatically at certain intervals—readers should see about one per screen. So we expect to serve approximately the same number of ad impressions per article, while holding ad viewability and ad CTR steady—all without increasing the total density of ads on the page.
Previously, the pagination links at the bottom of our pages were among the most clicked elements on our pages, with CTRs (click-through rates) upward of 20 percent. But that still meant most users did not make their way to the second half of the story. The elimination of multiple pages is undoubtedly part of the 9 percent improvement in time on site that we observed in testing. Users are more likely to reach the second half of a story when all they have to do is keep scrolling rather than having to click a link.
What’s next on this front: Some of our content in the scroll queue is too long to scroll through in its entirety. Lengthy stories in the stream can make navigation-by-scrolling a bit cumbersome. If users come across pieces they’re not interested in, we want it to be as easy as possible to get to the next story. So we’re planning to abbreviate scrolled articles and offer the option to view the entire story. This will help scrollers bypass the articles they’re less interested in and find stories they want to read more quickly and easily.
Simplifying the Page
Our former desktop site displayed a list of 25 to 40 recirculation links in the page space to the right of most of our stories, what we called the right rail. The collective CTR had been a quite-low 3.5 percent, and the link-filled right rail created clutter and distracted from the content. But we were concerned about removing those links without providing an alternative way for people to discover new Slate content.
Now, when our readers finish a story, they can find new stories by simply continuing the behavior they’ve already engaged in on the page: scrolling. This has replaced the recirculation efforts of the former right rail. With the updates we’ve made, at any given point in a story the user’s viewport will be dominated by actual content, where before, content frequently took up less than half of the page’s real estate. We’re excited to have improved both the aesthetics and the reading experience.
We’ve also seen improved CTR on the elements we kept in, such as the social share buttons, comment buttons, and the site-navigation bar. There are clearly positive returns to prioritizing the most important features on a page.
We were somewhat concerned that removing the links to sponsored content, Slate Plus content, and paid partner links would hurt revenue. In order to recover that promotional real estate, we’re now weaving sponsored stories and Slate Plus teasers into the infinite scroll queue. Every fifth story will be either a teaser for member-only content or native advertising content, both of which are designed to be clearly distinguished as such. Members and prospective members will be more likely to come across Slate Plus content they’d enjoy. And we believe that many users who today avoid sponsored content will be pleasantly surprised to find it can be as compelling as our traditional editorial content, even as it helps fund our traditional editorial content.
What’s next on this front: There’s more to be done to further clean up our pages and make them even better venues for reading and watching. We haven’t made any changes to the header bar at the top of the page or to the “burger button” and the navigation window it opens. Nor have we updated the ad units that appear inside stories.
The cleaner page and the lack of a rigid, persistent right rail means that we’ll have far fewer restrictions as we develop custom, high-impact ad executions—the sort that readers actually enjoy seeing because they’re unique and visually striking. We’ve started running one of these full-page ad units, and we’re excited about the freedom we now have to run jaw-dropping custom executions, sparingly, throughout the site.
Finally, while page performance is one of our top priorities, given our ambitious goals for this project we were focused on maintaining our current page speed rather than improving it. But we have two major upcoming projects that focus on page speed. Our next iteration of the website’s front-end will drastically reduce page-load time. And mobile readers will see faster page times from our upcoming integration with Google AMP.
Story Selection for the Infinite Scroll Queue
All this said, in order for our our infinite scroll implementation to succeed, readers must be interested in the stories they discover as they move down the page. If users don’t find stories that they want to read when trying out infinite scroll, they’ll be unlikely make it down to that point in the page again.
By default, the infinite scroll stream includes a mix of algorithmically curated stories and stories that our editors have decided to feature. The algorithmically chosen stories are selected because they are recent and relevant. Parsely, our algorithm partner, semantically analyzes the content of the initial story and finds other stories we’ve published lately that have covered similar topics. This seems to yield remarkably useful recommended stories, but we plan to continue experimenting with alternative presentations and story recommendation logic to see what works best.
In addition, over the last year our development team built a powerful API that pushes our content to different devices and applications in a platform-agnostic manner. The infinite scroll feed has been one of the first opportunities to utilize the content API. It greatly augments our ability to experiment with different logic for determining which stories appear as you scroll down the page. We’ll be sharing more about what we’ve learned in building the content API on this blog in the near future.
What’s next: We’ll be testing other ways of ordering recommended stories in the queue, including personalized recommendations based on the user’s read history. We’re also going to be more explicit about what the recommendations are based on. And we’ll offer ways for users to identify what stories they want to see next, whether it’s related content, the most popular content on the site, featured content, or something else. In user testing the ability to choose the stream was among the top feature requests.
Whither Mobile Web?
We haven’t yet implemented infinite scroll on our mobile site, but we expect to do so soon. We’ll be testing what impact infinite scrolling will have on mobile Web over the next several weeks, but assuming the results are comparable to desktop, the experience will soon be available across Web platforms.
Thank Yous
There were more significant contributors to this project than perhaps any I’ve worked on at Slate across the development, product, design, and ad operations teams. I’d like to thank Holly Allen, Mia Birkhead, Jennifer Castillo, James Dasinger, Chase Felker, Jeremy Green, Doug Harris, Kim Le, Jon Lechliter, Heidi Strom Moon, Erin Nichols, Chris Schieffer, Paul Smith, Artur Strumilowski, and David Tran for their incredible work to get this out the door.
