In Which We Consider Digg's Mobile App
Matt Langer wrote an interesting post yesterday questioning Digg for the way our iOS apps present stories. On Apple mobile devices, the Digg app by default frames and pre-caches the stories our editors highlight so that users can read them offline -- on the subway or an airplane, for example.
Matt’s making a really important point that we take seriously.
Curatorial sites and mobile apps like Digg need to drive traffic back to publishers, along with the ad impressions and clicks that many depend on for monetization. Digg has two goals: (a) provide a terrific experience for our users, and (b) drive loads of traffic to the best publishers, big and small, so that they can keep producing more great creative work. We want The Digg Effect to be welcome, as users discover not only individual pieces of great writing, graphics, and video, but great sites, sources, publishers, and authors.
And indeed, the Digg website -- where the vast majority of our traffic happens -- does not frame or pre-cache stories, but sends readers directly to the source webpages, replete with the ad units and monetization tools the publishers have deployed. In the mobile environment, however, we got a raft of input from users to the effect that they wanted Digg to provide a good offline experience. In response to that, we implemented pre-caching and an embedded frame that presents only the target story. As Matt rightly points out, that fails to immediately drive impressions and clicks back to the publisher.
Here’s the conundrum for mobile reading apps: (1) we want to support and improve publisher monetization as effectively as possible; and (2) we also want to give Digg app users a great offline experience; but (3) the vast majority of publishers do not provide portable ad formats that we can grab, attach, and render in ways that enable the publisher to capture all the impressions and clicks their ads can earn. Here's one promising approach that we’ve been talking with some publisher friends about: Publishers provide standardized portable ad units that we can automatically ingest and position alongside their stories; Digg and other mobile reading apps embrace those portable ad units and deliver impression data, including offline impressions.
We would love publishers to provide standardized, portable ad formats that will effectively monetize their content in mobile readers. That’d be awesome. To see if that's viable, we’re going to do a round of conversations with publishers to figure out whether they’ve actually already got something workable (for example, the ad units that accompany mobile web versions of their content, or that some ad platforms have inserted directly into RSS outputs), or whether we should join together to build and implement something new that’d work not only for Digg, but all the other mobile reading apps out there.
It should be possible -- easy, even -- for publishers to know that their ad units are accompanying their content, and being rendered as they want, regardless of whether the reader is reading via a web browser, smartphone browser, web-based reader, online mobile app, offline mobile app, tablet reading app, Kindle, etc. That may require some rudimentary standardization of portable ad unit formats that can painlessly be created by publishers and automatically interpreted and implemented by all the various types of reading experiences.
The other piece of feedback that we hear from publishers is that they want to know who their readers are. This is a tricky technical challenge that very few publishers have the resources for, but it’s a solvable problem that we’ve been thinking about for a while. Ted Roden and Mike Young — the guys behind the first version of News.me — proposed this to the New York Times and it looks like they’re starting to roll it out now, in the form of NYT Everywhere.
In the meantime, we’re going to take a close look at our iOS experience to see what adjustments might do a better job of sending as many impressions and clicks back to publishers’ own sites as possible, as well as doing right by individual authors. That may require a change in defaults or more granular user options, or maybe even something more extreme. We'll keep you posted.