Book Read Free

Digital Marketplaces Unleashed

Page 73

by Claudia Linnhoff-Popien


  Trust & perceived risk

  Strengthen trust

  Reduce perceived risk

  Does the platform enhance trust? How can the perceived risk of platform participants be minimized?

  Pricing

  Pricing subsidy

  Revenue

  Who is setting the price? Who decides on participation, who is paying and who values?

  External Relationships

  External relationship management

  How are inter‐firm dependencies managed? What is the architecture of participation? Does the platform allow technical interoperability between other systems?

  Governance structure, for example, contains decision rights and the ownership status of the company. An MSP can be organized centrally or diffused. There might also be an imbalance in power between the different parties in terms of authority and responsibility.

  Platform transparency and usage of platform boundary resources are covered in the dimension resources & documentation. They describe the use of application programming interfaces (APIs) or helpful tools like software development kits (SDKs) as well as having a documentation in place.

  Accessibility & control combines the mechanisms of output control & monitoring, input control and securing, as well as platform accessibility, openness and process control. They describe how the output of a developer is evaluated, penalized or rewarded, what is allowed to be on the platform, who is allowed to collaborate and which procedures are in place to regulate the platform.

  Trust & perceived risk are forming the next dimension, which relates to the nature of a platform ecosystem to foster trust on the user or developer side.

  The seventh section topic is pricing and clarifies which party is setting the price, who decides on participating on the platform, who is paying and which side profits. The last dimension is represented by managing external relationships and describes how inter‐firm dependencies are governed. Apart from these dimensions, also the underlying business model might have an impact on how the implementation of governance mechanisms is shaped. Therefore, we complemented this dimension in the following multiple case study analysis.

  47.3 Governance Mechanisms in Practice

  After identifying important platform governance mechanisms, we wanted to analyze if and how successful MSP providers apply those aspects. Therefore, we selected seven MSP companies with four different underlying business models, each of them successful in terms of market capitalization or market shares. On the basis of these companies we identified several cases for each of them and conducted a multiple case study analysis [9]. Table 47.2 summarizes the final results and practical implications. Table 47.2Result of the multiple case study analysis

  Business Model

  External relationships

  Pricing

  Trust & perceived risk

  Accessibility & control

  Resources & documentation

  Governance structure

  Output

  Input

  Control

  Social network

  Strategic partnerships

  Advertising, marketing, applications

  Privacy settings/Privacy issues

  Rating, “Likes”, comments, Advertising dashboard

  Community standards

  No restrictions besides terms and conditions

  API, Software Development Kit (SDK), documentation

  Autocratic and centralized, self‐organizing platform

  Facebook

  Strategic partnerships, service extension

  Advertising, marketing, applications

  Account verification, limited number of messages

  Follower, broadcast interfaces

  Strict rules for platform curation

  No restrictions for users, strict restrictions for businesses

  API, SDK, help center, guides

  Autocratic and centralized, high degree of control

  WeChat

  Merchant

  Partnerships through acquisition

  Sales margins, payment and service fees

  Several services to strengthen trust (e. g. Trust pass)

  Reviews, ratings, feedback profile, statistics

  Optional inspection service

  No restrictions

  API, SDK, learning, and training center

  Central, self‐organizing

  Alibaba

  Table 47.2(Continued)

  Business Model

  External relationships

  Pricing

  Trust & perceived risk

  Accessibility & control

  Resources & documentation

  Governance structure

  Output

  Input

  Control

  Service Platform

  Localities and local communities

  Service and conversion fee

  Insurance, verification and rating system

  Asynchronous ranking, reviews, statistics, comments

  Identity verification

  Host is in control, identity verification

  Help center

  Split, host has decision rights

  Airbnb

  Strategic partnerships, service extension

  Dynamic pricing, Service fee

  Background check, pricing surging, insurance, privacy issues

  Two‐sided ranking, suspension on ranking, comments

  Background check. Car requirements

  Background check, Uber controls pricing

  Help center, API, documentation

  Split, Uber controls pricing, passenger controls through rating

  Uber

  Application Platform

  Many partnerships

  30% of sales, One‐time registration fee

  Malware, rating, diversity of systems

  Ratings, comments, number of downloads

  No manual App reviews

  Google developer account needed

  SDK, API, documentation, checklist

  Centric, from loose to tight control

  Play‐Store

  Selective, strategic partnerships

  30% of sales, Annual fee

  Rating, feedback mechanism, less fraud, and malware

  Ratings, comments, number of downloads

  Manual reviews, censorship, protected system

  Apple developer account needed

  SDK, API, toolkits, documentation, guides

  Centric, tight control

  App‐Store

  It can be shown that each of the previously defined platform governance mechanisms can be incorporated in a different way. The governance structure ranges from a very centralistic and autocratic organization to a more split approach with empowerment on the user side. In terms of resources & documentation, it can be shown that six out of seven companies used APIs to engage third‐party application developers. Accessibility and control vary from having no restrictions to requiring users to pass a detailed background check if they want to enter the platform. The same applies to the input control. Measurements can be applying very basic community standards or reviewing each input manually. The output control describes how other users evaluate the user‐generated output. A noticeable feature is that every analyzed MSP uses a rating or review system. If there are two distinct sides participating in the platform, the use of two‐sided or asynchronous ranking systems was representative. In order to establish trust and decrease the perceived risk, all companies used techniques and tools. They include very basic forms of individualized privacy settings and account verifications, to more sophisticated solutions like offering extra services, insurances or requiring background checks. Pricing shows models like advertising, getting sales margins or one‐time fees. The last mechanism deals with external relationships and indicates that all seven MSPs use forms of partnerships. Most common are strategic partnerships and partnerships through acquisition. As mentioned
before each analyzed MSP can be categorized into a different business model. Facebook and WeChat, for example, fit in the category of social networks, Alibaba corresponds to the merchant model, Airbnb and Uber are service platforms and the App and Play‐Store are application platforms.

  After providing an overview of the different characteristics of implementing platform governance mechanisms, we will continue explaining their practical use and accompanied tradeoffs in detail.

  47.4 Characteristics and Tradeoffs of Governance Implementation

  This section discusses the characteristics and tradeoffs of a different platform governance mechanism implementation.

  Governance Structure

  This mechanism deals with centralistic and decentralistic structures, decision rights and the degree of ownership status. Different characteristics and implementations result in a high or low degree of platform monetization in exchange for user growth. A good example to show the implications of a low vs. a high degree of decision rights or ownership status can be found in the Google Play‐Store. Fig. 47.1 illustrates the shift from a free to use open source version with a decentralistic governance (1) to a tighter led model in an inverted u shape. The decentral and open approach led to a rapid growth in terms of the user base in comparison to the App‐Store but also brought tensions due to the lack of control and problems to commercialize the platform [10]. Therefore, the tradeoff of having a more closed and centralized governance with platform control and regulation abilities is a reduced user growth and problems with commercialization.

  Fig. 47.1Visualization of the tradeoff ownership status. (Own research)

  Across all cases, we could identify tradeoffs in implementing the platform governance structure in different ways. A more centralized governance model with moderate decision rights and ownership status offers a high degree of platform control and commercialization. On the other side, a more decentralistic approach allows benefitting from self‐organizational effects by reducing administrative work when implementing for example rating systems to determine the product or service quality. In summary, low ownership causes a loss of control, while a too high degree of ownership restricts user interaction.

  Resources & Documentation

  The two different characteristics of this dimension are if a platform provides additional resources like APIs or SDKs coupled with documentation or not. Providing insights and interfaces can open up new business opportunities while losing information superiority. Uber and Facebook for example both provide an API to open up new business markets [11]. In particular Uber expanded its platform by integrating the service of taxi reservations into hotel booking systems [12]. Facebook utilized the API to create the sub‐market of applications, which is now a million dollar market with over 150 million users every month [13]. By providing an API, both companies allowed developers to create new out of the box applications. It needs to be mentioned, that even in the presence of APIs companies can still regulate how much access they want to provide. Nevertheless, they open up the platform and provide insights and information.

  One example of not having an API is Airbnb. However, there is a sub‐community hosted by Airbnb called “nerds.airbnb.com” illustrating concepts like deep linking to overcome the fact of not having an API. Furthermore, unofficial platforms like “airbnbapi.org” appeared, providing unofficial endpoints and a documentation on how to use it. The result of not having an API is that there are no interfaces available to get, analyze or validate the data, which leads to a high degree of information control. On the opposite, business opportunities are dismissed in order to keep information superiority.

  The conclusion is that having an API, SDK and proper documentation offers companies to open up new business markets, increase interconnectivity and effectiveness of distribution, supply and customer channels. There are also arguments for not having an API. One might be information superiority by having a closed architecture, in return dismissing business opportunities and opening the field for third party platforms publishing platform data.

  Platform Accessibility

  This dimension deals with making the platform accessible to everyone and having restrictions. While restrictions and control mechanisms might improve the quality and increase transparency, it also comes at the expense of quantity of provided applications and services and potential user growth. An example for accessibility or openness is Facebook, struggling with negative feedback and abuse but granting users anonymity [13, 14]. The platform started with a restriction that only allowed universities to join and opened in 2006 for the public, gaining massive user growth [15]. On the other hand, WeChat requires verification in order to open business accounts, increasing the entry barriers by creating transparency [16]. The blue graph in Fig. 47.2b illustrates the tradeoff between the degree of openness and a potential increase in user growth in exchange for anonymity vs. transparency.

  Fig. 47.2Visualization of the tradeoff platform input & output control (a) and platform openness (b). (Own research)

  After analyzing all companies and cases, we could identify that a high degree of openness went with a potential higher user base, a less secure platform due to anonymity and increased perceived risk. Having restrictions in place showed in the case of the App‐ and the Play‐Store that the quality of products and services can improve if the process control is retained. The tradeoff is a lack of transparency and negative feedback limiting user freedom.

  Input Control and Securing

  The tradeoffs for this mechanism is strongly related to the previously discussed Platform accessibility. A vivid comparison of input control can be derived from the cases of the Google Play‐Store and the Apple App‐Store. Where the App‐Store follows strict censorship and manual application review processes, Google’s Play‐Store is less strict and executes only automated reviews. The result is that Apple has less security or quality issues, where Android has a broader variety of applications [17, 18]. This comparison shows that no or laissez‐faire input control causes a greater variety of input but entails a decreased quality.

  Output Control and Monitoring

  The multiple case study showed, that all MSPs use an output control mechanism to check the quality of products or services. Facebook, for example, uses “Likes”, comments and ratings to indicate the popularity of user‐generated content. Especially likes are giving a quick hint on how popular the content is, which is an important part of Facebook’s infecting success. Google and Apple implemented a one‐way ranking system to check the quality of applications [18, 19], where Alibaba, Uber and Airbnb use a two‐way‐ranking system, where the demand and supply rank each other [20, 21]. Both mechanisms shift quality assurance to the respective parties and therefore reduce administrative work for the platform owner in a tradeoff for a decreased control [20].

  In general Fig. 47.2a shows that control over input and output correlates in a non‐linear relationship to the degree of monetization. If there is no control, users can create whatever they like, quality decreases and malware increases. Having on the other hand, full control narrows the created content and therefore decreases the reach of a wider audience.

  Trust & Perceived Risk

  This mechanism describes how users and developers see the platform in terms of security and risks. Security measures lower the perceived risk in exchange for platform openness. WeChat for example, provides several services such as the business verification process or a security deposit for using the API to increase trust for the platform. Therefore users are likely to use the platform due to the protective mechanisms [16]. Facebook is offering privacy settings to reduce perceived risk but is not successfully overcoming those problems. The resulting tradeoff is that users have the chance to use Facebook anonymously without social consequences which can lead to a higher degree of percei
ved risk as the result of cyber mobbing or crimes [15], where WeChat’s services decrease anonymity but increase trust. This correlation can be seen in the red graph in Fig. 47.2b, showing that a security measure like the verification process of WeChat reduces the perceived risk, in exchange for a less open platform.

  Pricing

  Measures in this dimension address different price policies. There are indications that higher registration fees increase the quality for the sake of quantity. The case study review shows that all underlying price models are related to the associated business models (see Table 47.2). Therefore, a comparison between different business models does not seem to be constructive. Similar business models like the Play‐Store and the App‐Store show that high registration fees for the developer can be used as a quality gate trading quantity over quality [17]. The case of Uber shows that a lack of transparency on price setting can cause issues regardless of the business model.

  External Relationships

  Establishing business relationships and strategic partnerships might help to grow the user base, but also giving up control over the platform. The example of the Google Play‐Store and the Open Handset Alliance with 34 founding members aiming for an open standard for mobile phones illustrates the rise of the Play‐Store’s underlying operating system Android which even exceeded Apples’ iOS growth [17]. As Google wanted to maintain the control of Android and the Play‐Store to protect it from patent issues, the tradeoff was limiting the platform’s openness and partnerships [10].

  Business Model

 

‹ Prev