Mobile Content Consumption

At TripleLift, our mission is "effective, user-centric publisher monetization wherever users consume content." That last phrase creates a wealth of opportunities and also challenges us to continue to think critically about where and how users will consume content.

It is relatively obvious that mobile is important, but decidedly less clear how mobile will look 2-5 years from now. The simplest debate - app v web - was seemingly won by app. App remains the primary form of engagement, but the conversation is slowly shifting as devices become more powerful, as HTML provides more and more hooks into the operating system, and as the divide between app and web continues to narrow.

feat_amp.png

The most obvious first step is simply improving the mobile web. Even today, many websites are simply reshaped versions of their desktop site that result in a very poor user experience. AMP is one solution that creates a strongly opinionated framework about how web pages can operate. The content must be loaded in a certain, very optimized way. This reduces the flexibility for the publisher but also greatly improves the speed. There are certainly some challenges with AMP - though the project seems to be committed to addressing them. Given the bright future of AMP and its rapid adoption, TripleLift has not only committed to supporting this framework, but being a leader. Indeed, TripleLift was the first partner in the new AMP for Ads.

AMP allows websites to function faster and more elegantly given the constraints of mobile devices - it's not the only way to do this, but it is the leading standardization. Poor site design and implementation were reasons that at least some content consumption was moving to apps. But AMP alone does not, and is not meant to address much of the distinction between mobile web and app. Other meaningful differences include the behavior of the app / site when there's no internet connection, its ability to save past behavior / data, it's access to the device itself (e.g. accelerometer), access to the notifications functionality, whether it can live on the home screens, and - on the flip side - whether it has to be downloaded before its use.

There has been meaningful movement to eliminate all of these distinctions - mostly by Google / Android (perhaps motivated by the ease of searching the web v the challenge of searching app). This comes in two flavors, neither of which are fully available but both are very promising. The first is instant apps (https://developer.android.com/topic/instant-apps/index.html). The challenge instant apps solves is that an app cannot be used until it is installed, and often installed apps are never used again. If a search is best answered by a single "page" in an app (e.g. making a reservation in OpenTable), the process to get the user there is cumbersome, involving a stop in the app store and then often downloading a substantial app - which may take several minutes. Instant apps is a framework by which app developers modularize their application, and only a small fraction needs to be downloaded at any given time. Now, the app can be deep-linked from the web (or anywhere), without requiring a stop in the app store. This is very new and currently only available for Android. It potentially requires significant re-engineering of existing apps, and may result in the app not being available on the home screen when accessed through this context - but may result in much higher interoperability with search and with other apps. So the uptake among app developers remains to be seen.

The other major initiative is progressive web apps (PWA) (https://developers.google.com/web/progressive-web-apps/). This is also a Google / Android-only framework. PWA allows for a web page to integrate deeper into the operating system. Once a PWA site has been loaded for the first time, it doesn't just load its specific, single-page of content the way most sites today do. Instead, the PWA has a service worker, which is basically javascript that is run in the background of the browser. This service worker allows things like push notifications to the notifications screen of the operating system, background syncing to ensure there's up-to-date information for the PWA if it's opened in the browser without an internet connection, and caching of assets. What's even more important is that the PWA can live in the application home screen on Android, and can be "installed" from the web (basically making a shortcut to the webpage, but because it acts like an app - Google has given it greater prominence). Because of the previously-discussed functionality, PWA apps won't open a blank page if there's no internet. The benefits are tremendous for PWA, including that they are theoretically cross-platform on an open spec (though Safari doesn't actually support it yet, service workers are on the 5-year plan from 2015), and can be updated immediately, without needing to go through app store updates. This means that, but for the performance needs of certain games, nearly all the functionality for most apps would be available through a PWA.

Between instant apps and PWA, the challenges of apps and web pages are, to a significant degree, both addressed in different ways. They remain very different approaches and are not a unified answer. But they both speak to a continued push toward app and web frameworks converging. That said, app does remain the current standard, and will likely remain for some time - as both instant apps and PWA are very new and require significant investments by developers to support, and it's unclear if either will actually catch on. Further, both are only really supported by Android. Apple has significant incentives not to support frameworks that allow for easy cross-platform development and that allow developers to bypass the app store, because user lock-in, platform differentiation, and revenue from the app store are very important to Apple's strategy. But we expect both to become important in the future and both may play important roles in our monetization strategies, should they grow in adoption.