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
Digital Marketplaces Unleashed Page 73