Designing Viable Multi-sided Data Platforms: The Case of Context-Aware Mobile Travel Applications

While app developers have long struggled to seize the opportunity [1], they now commonly use context information to enrich their mobile applications. While GPS is the most prominent examples, app developers also rely on aggregated past behavior, inferred preferences and past transactions. However, if app developers share such context information among each other, even smarter context-aware applications can be envisioned. New technologies for linking and semantifying large sets of data as well as natural language querying approaches are driving these opportunities. One promising application area is that of travel applications: whereas most existing traveling apps focus either on booking, transport advice or local events, sharing user context data between such applications would enable far more integrated and coherent travel advice.

Sharing context information generated by a mobile application with other app developers risks violating user privacy as well as harming competitive position of the individual app developer. These issues could be circumvented by instantiating shared and trusted data platforms that aggregate user data. However, designing such platforms is challenging since they should satisfy multiple user groups: end-users, app developers and potentially even others. A core issue is then who should subsidize the platform, i.e. what is the source of revenues going to be [2, 3, 4]. User willingness to pay for more advanced context-aware travel advice is often problematic. Monetizing user data by selling it to third parties can be a risky approach as well.

The objective of this paper is to analyze who should subsidize multi-sided data platforms that enable mobile context-aware travel applications. We do so by analyzing the case of 3cixty: a data platform for mobile context-aware travel applications, developed within the context of 3cixty. We outline different revenue models and subsequently analyze user acceptance of such revenue models by analyzing the results of a survey among 197 early adopters in the Netherlands.

Section 2 develops a theoretical background based on multi-sided platform literature. Section 3 provides a background on the 3cixty case and technical platform. Section 4 sketches potential value networks and revenue models, which are subsequently assessed through user research in Sect. 5. Section 6 concludes the paper, draws limitations and implications for future research.

In general, platforms can be seen “as building blocks (they can be product, technologies or services) that act as a foundation upon which an array of firms can develop complementary products, technologies or services” [5]. A platform serving multiple user groups, such as buyers and sellers, is typically denoted as a multi-sided platform [6]. The objective of a multi-sided platform is to facilitate the transactions between different user groups, such as consumers and app developers. Multi-sided platforms can be analyzed using the framework of two-sided markets [3]. The focal artifact in this paper can be seen as a multi-sided platform as it connects multiple groups of actors (i.e., end-users and app developers) while providing generic functionality on which services can be developed (i.e., shared databases and querying tools).

Such shared platforms can generate considerable network externalities, which implies that the value of the platform depends on the number of users [7, 8]. Network externalities imply that the value of a system depends on the installed base of users [9, 10]. Increasing adoption levels can thus lead to a positive feedback cycle that further increases the usefulness of the technology [11].

Network externalities are direct if the value of the product increase by others buying, connecting, or using the same platform or services provided via the platform. The utility of the platform increases with the number of other using it. Examples of direct network effects are social media, which become more valuable if more end-users join the platform. But also because platforms have interchangeable components, users can share the benefits of the same technical advance. Backward compatibility, interoperability and interface standards are therefore crucial. Typically, direct network effect refers to positive effect between users in a group; however, when more consumers for a platform reduce the value for similar consumers, the platform entails a negative direct network effect.

Externalities are indirect when the value of the platforms depends on the number of users in a different user group. For instance, video game consoles become more valuable for consumers if there are more developers creating games for that console. Indirect network effects may also be negative, for instance more advertisers on a search engine platform decrease its value for searchers of independent advice. These indirect effects are typical for multi sided markets, where service providers, developers and consumers meet. As service providers as well as developers make the platform’s various components better, the platform gets more attractive over time. As consumers use the platform more, they make the market larger. Once the adoption of a product or technology has started, these network externalities provide benefits to both new and existing users such as reduced price, lower uncertainty about future versions of platforms as well as complementary services, communities of users, higher quality products, new market opportunities.

Network externalities are important since they call into question which user group should subsidize the platform. If one user group of the platform is considered to be of more value than the other, it may be that they are subsidized by lowering prices or offer access for a fee [3]. In practice, different subsidization models are being used. The concept of marquee user specifically refers to those user groups that have such great value for the other user groups that their adoption of the platform should be subsidized [12].

The objective of the project is to provide a data platform for apps and services for city visitors (i.e., tourists as well as citizens). The platform will retrieve data from websites (e.g. hotels, restaurants, events, sights), other platforms (e.g. social media), smartphones (e.g. apps for exploring a city) and/or sensors. The platform offers various data services to app developers, for instance a cross domain querying language, a crowdsourcing mechanism, a mobility profiling service, query augmentation and social media mining.

Apart from these enabling services, the platform provides a clean data repository about a city that can empower specific applications. The data is “semantified” (i.e. semantics of the data has been made explicit) and “reconciled” (i.e. heterogeneous data coming from various sources has already been integrated). App developers can access this clean data repository via a single application programming interface (API) which is web developer friendly (i.e. apps developer do not need to interact with many specific data sources APIs). App developers can access this clean data repository via queries which provide an additional level of expressivity and enable to provide answers to queries that no single data source can do. The platform can answer questions like “Give me the list of hotels reachable within 10 min by metro of the venue of the Franz Ferdinand concert”. The specific features of the platform are listed in Table 1.

Using enabling services on the platform and the clean data repository, app developers can develop applications such as city trip and accommodation planning, traffic update, cultural and entertainment updates and information about the city.

To roll out and commercialize the platform, different roles are required. The generic value network shows the business roles (blocks) and the value exchanged between them in the form of service and revenue flows (arrows). Typically different roles are required in the research phase and roll out phases of the services, see Fig. 1.

Basic value network

Full size image

Note that the ‘user’ is the actual person that uses the app while the ‘customer’ is the party actually paying for the app. For example a ‘mobility solution provider’ could act as service provider and commission an app developer to develop a 3cixty enabled mobility app. The app could be part of a mobility solution that is offered to companies (‘customers’). The company’s employees (‘users’) would use the app to manage their mobility. Of course the roles of service provider and customer need not be separated; some party may simply order an app with an app developer and offer it to users directly via an app store. Or an app developer may even directly develop and offer an app to users; in that case app developer, app owner/service provider and customer are the same actor. Further detailing of business roles is possible as well, as for instance the roles of app owners and service providers can be separated (accommodating for white label business models).

The production of the app is a joint effort of the parties on the left hand side of the picture with the platform provider (system integrator) playing a pivotal role. Several parties provide information to the platform which can, amongst other things, be stored, combined, enriched and aggregated in the platform. Possibly, the services could be subsidized or even paid for by finance providers like insures, (local) governments or other providers. As an extra revenue stream, advertisements could play a role in the value network as well. Advertisement agencies could offer profile based advertisements to their customers and the advertisement provider is in practice often a value chain in itself.

For defining the revenue model, two main issues have to be dealt with. First, it should be decided whether the platform is offered in a profit or non-profit approach. Second, it should be decided whether the platform is open or closed to third party app developers. The motivation for this distinction is that open and closed platforms as well as privately and publicly owned platforms occur in practice and provide relevant but distinct options for the 3cixty platform. In the closed model the platform is used internally as a service platform and in the open model the platform is offered ‘as-a-service’ to 3rd parties like app developers. The different scenarios are depicted in Fig. 2 together with some actual examples of platforms and/or apps that follow such business scenario. One may also consider a situation in which there is no platform provider at all, but where (some of) the developed 3cixty software is made available as open source. In that case any interested organisations could use the software.

Exploitation scenarios

Full size image

Several revenue models can be considered to commercialize the platforms. The app market is dominated by the freemium model as over 90 % of all apps are for free, so user willingness to pay is often low. One approach to monetizing a service platform is that the platform is owned by some app developer and used as an internal platform to create and deploy its own apps. In this scenario the roles of platform provider and app developer are played by the same actor. The platform is closed in business sense, i.e. it can only be used by the app developer owning the platform. Other app developers or service providers cannot make use of the platform to build apps. Many providers use service platforms to efficiently develop and deploy their services and apps. A different approach is that the roles of platform provider and app developer are separated. In this case the services of the 3cixty platform are made available to app developers/service providers to support the creation and deployment of apps. Third parties can use part or all of the 3cixty functionality and data to develop new apps or enrich existing apps. Within these two scenarios still many business models are possible with different actors taking up the role of platform provider (private vs public party) and supported by different revenue models, i.e. bundling, pay-per-use, affiliation, advertisement, subsidy and sponsoring, open source etc. However, the idea behind the development of the 3cixty platform is geared towards an open model.

Given these features many revenue models could be applicable. Affiliation models where commission fees from companies that appear in the traveling app and that realize transactions, e.g. bookings, via the app. Advertising models, in which contextual advertising based on user profiles (e.g. preferences following from searches or a wish list) and levels of context awareness (location, time). Or data driven model: local government, tourist board or tourist trade organisation may be interested in aggregated data from user preferences and behaviour. For any of the revenue models identified, user willingness to use 3cixty types of applications, willingness to pay for applications as well as willingness to share personal data with app developers and third parties are crucial issues.

For any of the revenue models discussed in the previous section, a key assumption is willingness of end-users to use mobile travel apps that are based on integrated sets of context data. To further validate the revenue models, key concerns are user willingness to pay for context-aware travel applications as well as willingness to share data with platform providers. Such data could both be actively shared (e.g. crowdsourcing) or passively (e.g. past transaction information or location data). We test these assumptions through a survey among potential end-users for the platform and its applications.

5.1 Method

The intended population comprises young people who have a smartphone and who have a habit of traveling to cities. A convenience sample of Dutch students is used. Invitations to participate in the survey were posted on the Facebook page of various students of a bachelor course in December 2014. To obtain a homogenous group, we only include students possessing a smartphone in our sample. 197 valid responses were received, most of them being bachelor students. Age varies between 17 and 29, with average 20.6 years old. Gender was balanced with 53 % male. Respondents make 2.3 city trips per year, with standard deviation 2.1 and a maximum of 12.

Constructs were operationalized into self-developed, reflective scales, see Table 2. Although respondents were not exposed to the exact 3cixty service mockups, they were asked to reflect on 3cixty type of applications that provide comprehensive travel information and booking possibilities. All items were measured on a 7-point Likert scale. Confirmatory factor analysis was carried out using WarpPLS, see Table 1. Convergent validity is acceptable with average variance extracted exceeding .5 benchmark, and standardized factor loadings exceeding .6. Construct reliability is acceptable.

Discriminant validity is acceptable as correlations between latent variables do not exceed the square root of average variance extracted, see Table 3.

5.2 Results

A structural model is assessed using WarpPLS. The advantage of using WarPLS is that it allows not only interval but also categorical and nominal variables, such as gender. The model shows acceptable overall fit according to the fit indices generally recommended with WarpPLS (Tenenhaus GoF = .359, Sympson’s paradox ratio = .846), and low multicollinearity (Average block VIF = 1.215), see Fig. 3.

Structural model (standardized regression weights on the arrows) * p < .05; ** p < .01

Full size image

Explained variance of both intention to use and willingness to pay is low. We find that intention to use depends on the degree to which respondents plan their trips (in advance or ad hoc) and the degree to which they are inclined to share data via social media. On the other hand, willingness to pay depends on travel frequency, gender and age, while willingness to share data has a negative impact. Intention to use does not significantly affect willingness to pay.

The tendency to share data via social media also affects the intention to use. This implies that users of a travel application will be more likely to share data, which opens opportunities to utilize such data for monetization.

Willingness to pay, on the other hand, depends on how frequent a person travels, as well as gender and age. Usage intention does not contribute to willingness to pay, which suggests that even if people are willing to use the application, they are not willing to pay for it.

Interestingly, intention to share has a negative impact on willingness to pay. Apparently, those that are less inclined to share data on social media are more willing to pay for a travel app.

Another striking finding is that intention to use the travel app has no significant impact on willingness to pay for the application. Overall, the findings illustrate a dilemma for this type of social media traveling apps. Factors that drive intention to use completely differ from factors that drive intention to pay. This explains why alternative revenue models need to be considered in which app providers do not depend on willingness to pay. Apparently, one should either focus on those willing to pay for a travel app, but are not willing to actively share their data via social media. And when one focuses on people that are willing to share their data, willingness to pay will generally be lower. As such, the findings suggest a dilemma between two revenue models: a free app with monetization of shared data or a paid app without sharing of data with third parties.

Designing data platforms for context-aware mobile services entails several issues that are typical for multi-sided platforms. For the case being studied, we identified at least four different user groups that may or may not subsidize the platform: end-users, advertisers, app developers and government organizations. Who should subsidize the platform strongly depends on the exploitation scenario, i.e. whether a profit or non-profit model is chosen and whether the platform should be open or closed.

To evaluate the revenue models developed in this paper, we studied the end-user (i.e. consumer) perspective. We found support for a typical paradox observed in this domain: the reasons why consumers are willing to use applications are completely different from the reasons why they would be willing to pay. In fact, the more a user is willing to share data and travel experiences, the less that user is willing to pay for a context-aware travel app. As such, providers of data platforms can target one segment of end-users with a premium-priced app or another segment with a for-free app in which data is being shared for commercial purposes with third parties.

The findings are in line with earlier research on privacy concerns in information systems which suggests that people make trade-offs between utility, price and privacy harm of an application [13, 14]. How such compensation of privacy concerns with discounts or added value from apps works out in a big data era where consequences of disclosing personal data cannot always be foreseen warrants further research.

The paper contributes to understanding of the complexity in designing multi-sided data platforms. Platforms that link data providers, end-users, application developers and advertisers create highly complex sets of network externalities between and within the different user groups. In the case studied in this paper, it became clear that without prior demarcations on profit-orientation and openness, a multifold of revenue models can be considered in parallel. Even after our user research, different revenue models are still relevant.

We used a convenience sample gathered through links on social media. As our research model included willingness to share travel experiences including via social media, there may be systematic bias in the sample. However, considering the high adoption rate of social media in the population of young technical students, we assume this will not be a major threat.

The present paper focused on end-users for the validation of the revenue models. Our next step will be studying the app developers’ perspective. Earlier workshop and informal interviews with app developers suggest they may be willing to pay for data platforms if they truly add value for their business. Whether this is the case depends strongly on technological issues such as how to structure the data, how to form the APIs and which of the technical features of the data platform become available first.