• No results found

The influence of online reviews on API adoption : a developer-centric view

N/A
N/A
Protected

Academic year: 2021

Share "The influence of online reviews on API adoption : a developer-centric view"

Copied!
65
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

The Influence of Online Reviews on API Adoption

− A Developer-centric View

Master’s Thesis

MSc Business Administration - Digital Business Track

Konrad Kirner

11758686

22 June 2018

Supervisor: Dr. Somayeh Koohborfardhaghighi

Second reader: Prof. dr. Peter van Baalen

(2)

2

Statement of originality

This document is written by Student Konrad Kirner who declares to take full responsibility for the contents of this document.

I declare that the text and the work presented in this document is original and that no sources other than those mentioned in the text and its references have been used in creating it. The Faculty of Economics and Business is responsible solely for the supervision of completion of the work, not for the contents.

(3)

3

Abstract

In today's digital service economy, digital service creation is attracting widespread interest due to its new role as the main driver of innovation. Application Programmable Interfaces (APIs) and their emerging ecosystem are at the centre of this digital service innovation trend. Giant tech companies depend on third-party developers to use their APIs for open innovation. Companies must understand how developers select APIs to position their offers. We perform a literature review about online customer reviews (OCRs) and we link them to the topic of API adoption and service innovation. The aim of our work is to explore how OCRs influence the API adoption by developers. To test our hypotheses, a conceptual framework is created, and a choice based conjoint experiment with a randomised treatment and control groups is conducted. The data analysis leads to the following results: The OCR dimensions (i.e., valence and volume) and the API attributes (i.e., brand and technical features) all have a significant impact on the choice probability of the developers (p<0.001). As expected, volume and valence show a significant interaction effect and the availability of OCRs is observed to diminish the perception of the API attributes on a high level. These findings contribute to new knowledge about APIs and OCRs and yield valuable workable advice for practitioners. The most remarkable results to emerge from the data are that the presence of OCRs diminishes the perception of the API attributes and that the influence of volume is direct. The power of OCRs can therefore be used by market entries to challenge the high brand value of established players. The direct impact of volume indicates that volume may be especially important for services which have a special network component.

(4)

4

Acknowledgement

I would like to thank my supervisor, Dr. Somayeh Koohborfardhaghighi, for the guidance, encouragement, and advice she has provided throughout the whole thesis writing process.

(5)

5

Contents

Statement of originality... 2 Abstract ... 3 Acknowledgement ... 4 List of figures ... 6 List of tables ... 7 1. Introduction ... 8 2. Literature review ... 16

2.1. Application Programmable Interfaces and mashups ... 16

2.2. The role of APIs for service innovation ... 18

2.3. The role of the developer ... 20

2.4. Online customer reviews and choice probability ... 22

3. Conceptual framework and hypotheses ... 27

4. Methodology and data ... 32

4.1. Setup of the choice based conjoint experiment ... 32

4.2. Estimation models ... 34

5. Empirical analysis... 36

5.1. Inspecting choice data ... 36

5.2. Main effects and replicating prior work ... 37

5.3. Interaction effects ... 39

5.4. The effect of OCRs on technical features and brand ... 40

6. Conclusion and Discussion ... 45

7. Limitations and future research ... 53

References ... 58

(6)

6

List of figures

Figure 1: The API value chain (Jacobson et al. 2012) ... 9

Figure 2: Developer-centric API value chain ... 10

Figure 3: Proposed conceptual framework ... 28

Figure 4: Example of a choice-set used in the online experiment ... 34

Figure 5: API attribute coefficients for the two groups ... 42

(7)

7

List of tables

Table 1: Related literature ... 25

Table 2: Proposed estimation models ... 35

Table 3: Raw data choice counts ... 36

Table 4: Estimation results Model 1 ... 37

Table 5: Estimation results Model 1 and 2 ... 39

(8)

8

1. Introduction

To compete in a changing business landscape, companies must constantly adapt to changing conditions brought by the market, the customer, and technology (Sørensen, De Reuver, & Basole, 2015). Due to the growth of global communication networks and the availability of digital technologies, the creation of tangible products will not be the main source of innovation anymore. Innovation becomes increasingly intangible and digitally enabled in the form of new digital services (Lusch & Nambisan, 2015). These new services emerge as vast numbers of applications and create new value every day. One crucial component of the new digital services today is the Applications Programmable Interface (API), a machine-readable interface which enables applications to connect to each other’s distinctive abilities and to use them without knowing their inner mechanisms (Jacobson, Brail, & Woods, 2012). Therefore, researchers and practitioners are in line that APIs play a vital role in the service innovation process (Jacobson et al., 2012; Wulf & Blohm, 2017). As the trend towards hyper-connected companies continues, APIs are even seen to be crucial for a company’s survival and the lack of a clear and sophisticated API strategy becomes one of the biggest risks for a modern enterprise (Kirschner 2015; Vukovic et al., 2016). By connecting consumers, business or business-like institutions and developers via digital services, the importance of these APIs is especially vital for these three main classes of users. Right now, the API economy is growing in a fast pace and spans over thousands of API-providing companies which can be clustered in many categories. Within these categories, competing companies fight for the affection of third-party app-developers to expand their ecosystem and make use of open innovation. That is to say, companies open the innovation process to players outside of the enterprise. In this specific case, service developers use company provided APIs and create new services and functionalities on top of them or combine them for service composition. The combination of more than one API in one application is called a mashup. By creating new complementary

(9)

9 services and thereby increasing the accessibility to new users, these third-party developers add value to the API-providing platform or company (Iyer & Subramaniam, 2015). Instead of employing more developers themselves, companies rather offer APIs because server space is getting cheaper while the wages for developers are raising. This way, API-providing companies are also saving costs (Jacobson et al., 2012). On a more holistic level, a company can access distinctive resources and services from other companies by plugging into their API and using their services. This is especially important for companies who want to use digital features and services without developing a new system for themselves. As the number of APIs is growing, API providers must position themselves against other providers and establish relationships with API developers to make use of their abilities via open innovation (Jacobson et al., 2012; Vukovic et al., 2016). In conclusion, the differentiation from competitor’s APIs is shown to be a major challenge in gaining competitive advantage in digital service innovation (Jacobson et al., 2012; Wulf & Blohm, 2017). Figure 1 shows the API value chain introduced by Jacobson et al. (2012). We can use it to summarise the process of value creation through APIs in a more holistic manner.

(10)

10 This value chain shows that between the business assets and the end-users, the API, the developer, and the developer’s application are set. From a business perspective, this value chain is a sequential line from the business assets of a company to the end-users. The company transforms assets into an API which then is used by a developer to create an application. When we look at the position of the developers more closely, they become a bottleneck in this process. Due to the growth of the software as a service (SaaS) ecosystem, developers can select multiple APIs and their selection therefore significantly impacts the success of a provider’s API. Thus, the business success of the provider is depending on developers’ choice making. To highlight the important role of the developer in the value chain, we propose a developer-centric API value chain which is shown in figure 2.

Figure 2: Developer-centric API value chain

In this chain, it becomes more obvious that not only developers per se but also their decision-making in the API selection process is crucial. In contrast to the traditional value chain

(11)

11 in figure 1, they can choose from more than one service provider’s API. If the developer, for example, needs two distinctive functions (i.e., X and Y) for service composition, they have two offers for each function. They have two offers (A and B) for function X and two offers (C and D) for function Y. In this process, the developers are assumed to be influenced by API attributes like technical features and the brand (a) and online reviews from the developer community via ratings, reviews, and reports (b). The two functional APIs (X and Y) are combined by creating a new service composition in form of an application or mashup. Both APIs will be indirectly experienced by the end-user. The decision-making in the selection process is therefore central for companies, the developer, and the end user. Companies want developers to use their APIs, developers try to create a high-quality application for the end-user, and end-users search for the best application to satisfy their needs. This proposed value chain can also be used to explain how potential feedback could be given and experienced by the different parties involved. The feedback loops (1-3) are assumed to exist between the end user, the developer and the application and the service provider. The end-users give feedback to the application they use (1). This way, the developers, who can access the feedback from the application (2), experiences feedback from the end-user which they can use to improve their services. Developers give feedback to the service provider (3). This feedback can be used to improve the service offering in form of the API and help them to improve their competitive edge against the competition. Online reviews are part of the last feedback loop (3) and visible to the service provider company and to other developers. Thus, loop (3) is very important for the providers if they want their API to be used. If providers want developers to favour their API over others in the adaption process, companies have to understand how developers make their choices (Yu & Woodard, 2009). If this is clear, API providers can take measures to attract more developers to use their APIs and therefore gain a competitive edge in their digital service innovation

(12)

12 efforts. Free availability, popularity, co-opetitive1 relationships and online interaction are

described as important for developers when choosing an API (Huhtamäki, Basole, Still, & Russell, 2017; Jacobson et al., 2012; Vukovic et al., 2016; Wulf & Blohm, 2017; Yu & Woodard, 2009). It is also shown that effective developer programs focus on saving developers’ time and help them to earn money (Jacobson et al., 2012). We also assume that implementing new technical features or investing in better reputation by offering support and broader engagement with the community has a positive impact (Huhtamäki et al., 2017). We compare the choice making of developers to the product selection of customers in the online environment, which also see themselves faced by a high number of competing products and must select one of them. Next to a product’s features, there is a social component which influences the selection process. This additional factor is described as online reviews. The role of online reviews in the selection process among comparable offerings in the product category (i.e., in an online environment) has been already investigated (Kostyra, Reiner, Natter, & Klapper, 2016). Online customer reviews (OCRs) have become a major source of information for customers on the internet. Understanding the impact of OCRs on customers' decisions is an important challenge for academics and practitioners. We apply a choice-based conjoint experiment that combines all relevant levels of the OCR dimensions (valence, volume, and variance) and that estimates the effect of OCRs on choice. The experimental setting allows us to estimate the direct effects but also the interaction effects of the OCR dimensions, which have been largely neglected in previous research. The impact of the OCR dimensions is evaluated against the results from a control group that did not face OCRs when making their choices. Therefore, our experiment enables us to investigate the extent to which the presence of OCRs affects customers' consideration of brand, price, and technical product attributes. In contrast to

1 Co-opetitive relationships are described as a relationship in which competition and collaboration take place at

(13)

13 previous findings, our results show that volume and variance do not affect customers' choices directly but that they moderate the impact of valence on customers' choices. Moreover, we find that OCRs decrease the importance of brand for customer purchase decisions, indicating that managing OCRs have become a challenge for brand management (Kostyra et al., 2016; Chang & Chin, 2010; Maslowska, Malthouse, & Bernritter, 2017). In this research we argue that comparing to the product category, reputation and user-created feedback can be used to ensure a certain quality standard in the API market. Consequently, the product-centric view must be widened because not only the selection of products but also the selection of services is influenced by online reviews. In this research, we aim to detect the adaption of APIs by service developers and investigate the role of OCRs in the process of API selection. This is the gap which we identified in the current literature. The outcome of this research will help to diminish the identified gap by assessing the role of online reviews in the process of API adaption by service developers.

Based on the line of arguments presented so far, we generate the following research question: In addition to reputation and technical features of an API, to what extent does the presence of online reviews affect the API adoption process?

The insights derived from this research will contribute to theory as well as to practice. In the reviewed literature, the influence of online reviews and its dimensions as well as product attributes like price, brand and technical features on customer decision making have been investigated and will be reviewed in chapter 2.4. The role of reputation in the context of service adoption has yet to be elaborated and this thesis will diminish this gap by testing the derived results of Kostyra et al. (2016) in the context of API adoption. From the perspective of service innovation research and APIs, Yoo et al. (2010) encouraged further research about the design and usage of APIs. Yu & Woodard (2009) highlighted that in order to truly understand digital

(14)

14 service innovation, the API selection process of developers must be further investigated. The findings of our study can also be used to explain the distribution of APIs in mashups as described by other researchers such as Yu & Woodard (2009) and Koohborfardhaghighi and Altmann (2015). In a practical way, the results of this research can be used by companies who want to participate in the digital service innovation process. That is to say, by harnessing the power of the API ecosystems and open innovation, they can improve their positioning towards other API providers. They can strategically alter the OCR factors or API attributes by continuously investing in their reputation, giving support to the developer community or changing their revenue model and technical features. Therefore, they have to know what developers need and want (Jacobson et al., 2012). The obtained results of this research are expected to offer specific advice for new market entries. APIs positioning and thereby its adoption is increasingly important for the survival of every modern business. It, therefore, offers substantial value to practitioners (Kirschner 2015; Vukovic et al., 2016).

To answer our research question, a choice based conjoint experiment is conducted in which developers are facing a choice making task. In this fictional task, developers select one out of three APIs for service composition (depicted in the appendix). The three APIs show variations in their technical attributes, their brand, and their online review. Thus, the experiment is used to discover developers’ preferences when making the choice and is explained in chapter 4.1. We analyse the data using elaborated tests and multinomial logistic regression models as proposed by Chapman and Feit (2015).

The rest of this thesis is organised as follows: In chapter 2 the relevant literature on APIs, the role of APIs for service innovation, the developers’ role in API adoption and the role of online customer reviews are discussed. In chapter 3, we formulate our theoretical model and we present our hypotheses. This is followed by an extensive explanation of the research design

(15)

15 and method in chapter 4. The results of our analysis will be presented in chapter 5. In chapter 6 we provide the conclusion and discussion over our findings. The limitations and future research directions will be presented in chapter 7.

(16)

16

2. Literature review

To conduct this research, insights into APIs, the role of APIs in service innovation and the role of developers in the API ecosystem should be investigated. After that, the latest research about the influence of online customer reviews on decision making is covered and connected to the service composition process in the API ecosystem.

2.1. Application Programmable Interfaces and mashups

According to scientists and practitioners, APIs are the most important building blocks for digital transformation and service innovation. APIs are machine-readable interfaces which connect applications and digital services with each other and enable the seamless and easy exchange of data and services. The topic of APIs is not new, but their number has increased dramatically over the last decades, powered by the commodification of cloud computing (Yu and Woodard 2009). In an API ecosystem, APIs can be used by developers according to the principles of open innovation. It means that API providers open their digital assets to developers which can innovate on top of them. The potential benefits for both groups are enormous. API providers can reach a broader customer base across markets, platforms, and devices, create new markets, extend their brands and foster innovation. Developers can take a shortcut by using available building blocks for their new services without reinventing the wheel all over (Jacobson et al., 2012; Vukovic et al., 2016). In conclusion, developers have the ability to use service software (Software-as-a-Service services) provided by big corporations and can exploit their power and functionality in new service compositions (Koohborfardhaghighi & Altmann, 2015). Newly created applications which combine the functionalities of various APIs to create a new seamless experience are called mashups (Yu & Woodard, 2009). The consequence of this new way of application development and co-creation leads to the emergence of a developer ecosystem which can be strategically used by companies to foster service innovation (Vukovic et al., 2016). To summarise the process and fully understand how

(17)

17 APIs are used on a theoretical level, we can again refer to the API value chain of Jacobson et al. (2012) (presented in figure 1 in chapter 1). The chain consists of five steps and includes specific business assets, the APIs provided, the developers, the applications they create and finally the end-users. The specific business assets can be a service, a form of data or specific information which belong to a company. These assets are provided to developers via the API, which often breaks bigger software in smaller compounds with distinctive functionalities. The developer selects APIs and in the next step to create the new application which ultimately will be used by the end-user to satisfy specific needs (Jacobson et al., 2012). The API value chain has the final goal to create a new service for customers and depends highly on the developers’ abilities and motivation. This way of leveraging APIs impacts companies’ business models and results in a growing market for APIs. Many companies do not only use APIs as a contributing part of their business model but can even attribute major parts of their revenue to their APIs. Others do not yet fully recognise the potential of APIs and have no API strategy (Basole, 2016). The market for APIs and their composition in mashups is already characterised by Yu and Woodard (2009). They described the distribution of APIs in mashups with the principles of power-law distribution and the long tail of the market. Power-law distribution means that in a given set, a small number of events occurs often whereas many events are extremely rare. In terms of the API market, first mover advantage and the prominence of some APIs presumably leads to high usage and exponential growth of establishes players but makes it hard for new offerings to enter the market. The long tail of the market describes the high number of low-frequency occurrences which, when cumulated, can outweigh the most frequent events. Even though this long tail is still shorter compared to the online retail market of tangible consumer goods (i.e. books and video games), both markets are driven by the fact that they have no physical constraints and search costs are low. Yu and Woodard (2009) observed that about half of all APIs (51%) are not used in any mashups at all. These insights are in line with the work

(18)

18 of Koohborfardhaghighi and Altmann (2015), who proposed a new network formation model to explored how SaaS networks emerge as a result of developers API composition and found out that established connections between specific APIs are used in a high frequency even though other APIs would have similar functionalities. To put it briefly, there are many unused APIs and that the pure creation and publication of an API with specific functions does not automatically lead to its usage (Yu & Woodard, 2009). This means that there are other factors than pure functionality which influence a developer’s adaption of an API. Thus, API providers must actively attract developers and include other factors than pure functionality (Jacobson et al., 2012).

2.2. The role of APIs for service innovation

The value of APIs and their adoption by developers is rooted in their importance for service creation and service innovation. While there are many service offerings available, the so-called service composition process, in which service developers use established SaaS services via their APIs, is increasingly vital. This process, in which new solutions are built on the foundation of established service offerings, can be regarded as one of the most profound developments in service architecture and in service innovation (Koohborfardhaghighi & Altmann, 2015). To make the connection between APIs and service innovation clearer, we first analyse the service innovation process in general and connect it to specific API archetypes afterward. Service innovation can be structured using Den Hertog’s (2000) four dimensions, namely, the service concept, the service client interface, service delivery systems/organisations and the technological options. These dimensions are interrelated and each of them can be innovated by itself. A new service concept describes the idea how a problem can be solved in a new, often intangible way. The degree of novelty can reach from a completely new solution to an established service in a new market. The client interface describes how client and service-provider interact with each other. Especially in the production of services, clients are often

(19)

19 involved in the creation process and have a more active role than for example in product design. The service delivery system/ organisation focuses on the internal capabilities and processes of a company which enable the workforce to innovate and to deliver services to the clients in an efficient manner. Even though service innovation can happen without technology, in practice it is often related to technological development and technological innovations. Thus, new technological options are closely linked to the other dimensions and, as a dimension, is a main driver and enabler of service innovation (Den Hertog, 2000). The important role of IT for service creation and innovation is acknowledged by academia from innovation research as well as from research streams within information system (Lusch & Nambisan, 2015). Based on Den Hertog’s (2010) dimensions, Wulf and Blohm (2017) elaborated how APIs are used for innovation and how they could be systematised according to the different dimensions. Wulf and Blohm (2017) identified three types of APIs based on their distinctive design elements and highlight their important role in digital service innovation. According to that, API archetypes are the Integrator, the Free Data Provider, and the Mediator. Integrator APIs are often built to add a functionality to already used software of a client or to create a new channel for the provider’s capabilities. These APIs provide additional data and often also new data processing capabilities. A good example is the API of the company Salesforce.com. It enables the integration of data and functions of their customer relationship software into the already used enterprise software of their clients. This way the Salesforce software can be integrated into the enterprise software via API. This type of API is usually subscription or transaction-based. A Free Data Provider API opens specific data to developers, mostly free of charge. The intention of the provider is to create new services and functions through open innovation and expand the user base. Wine.com, for example, encourages developers to use their API to access their wine catalogue and data related to their wines. Wine.com hopes for new innovative applications which will ultimately drive their own business. The Mediator API service-innovation approach

(20)

20 focuses on the providers’ own customer base. The providers’ intention is to trigger developers into creating new services for current customers. In contrast to the other archetypes, the focus is not primarily on multi-channel access. These APIs are usually free of charge. In this specific case, the platform owners, who provide the APIs, are in a power position because they can easily close the platform for individual developers or applications. A famous example is Facebook, which opens its platform for developers to create games and new applications for its user base. Other platforms like Amazon and LinkedIn follow similar approaches. By creating new functions within these networks, developers create additional value for the platform, consequently, the use of these APIs is mostly free of charge (Wulf & Blohm, 2017). Finally, all these archetypes have in common that they depend on the motivation and capability of developers to find, select and use companies’ APIs. On that account, we highlight that service innovation is considered to be unambiguously important for businesses and that IT, and more specifically APIs, are a great source for new service development. By consequence of that, APIs are drivers of service innovation and developers consequently take on a fundamental role in the API driven service innovation process.

2.3. The role of the developer

Developers have an important position within the API ecosystem and their role is clear in the API value chain (depicted in figure 1 in chapter 1). Due to their position between the API and the end-users, they can be seen as an important bottleneck within the API value chain (Jacobson et al., 2012). By looking at the developer-centric value chain depicted in figure 2 in chapter 1, it becomes even more obvious that two things are crucial for the process. Firstly, the professional capabilities of the developers to create a new application, and secondly, their choice making process when picking one amongst several APIs. Developers select among different APIs to use the service and functionalities for their new application. Because third-party developers are not employed by API providers, their individual choices do not depend on

(21)

21 the service providers intentions. For example, if a specific API is too expensive, developers can switch to a similar offering from another provider. To make use of a developer’s value-adding capabilities, the providers have to incentivise the right way and the question is, how they can differentiate their APIs from competitors and raise visibility (Huhtamäki et al., 2017; Jacobson et al., 2012). Thus, they have a role comparable to the customer in an online retail environment, where a customer tries to find the best possible offer. They have an innovative role in a coevolving ecosystem which depends on both, the APIs, which is offered by providers, and the developer’s choice (Jacobson et al., 2012; Tiwana, Konsynski, & Bush, 2010). Free availability, popularity, community support, co-opetitive relationships and social interaction are described as important for developers when choosing an API in addition to pure functionality. Developers are also very active on developer forums like GitHub, ProgrammableWeb, StackOverflow and engage with the community to share code samples and experiences and seek for advice (Huhtamäki et al., 2017; Jacobson et al., 2012; Vukovic et al., 2016; Wulf & Blohm, 2017; Yu & Woodard, 2009). In addition to having a customer role, developers are also providers themselves. They provide new applications to their own clients or companies (Jacobson et al., 2012). The quality and reliability of an API are assumed to have a crucial role due to the high risk of damage for the developers and their client company if new mashups or applications do not work or fail. Selecting the wrong API when creating an application will ultimately damage the quality of developers’ own creations and thereby their reputation. Therefore, the need for quality assurance is an important explanation for why developers decide to pick APIs which are often used by other developers and neglect the long tail of the market. We believe that comparable to the online retail market and the category of products, reputation and user-created feedback can be used to assure a certain quality standard (Kostyra et al., 2016). Conclusively, the developer is a choice maker who is comparable to a customer, but also to a provider. This ultimately highlights developers’ need for a reliable,

(22)

22 high-quality API, which can be ensured by selecting an API that is proven to work for other and subsequently has high-rank online reviews. Thus, the following paragraph will cover the latest research about the influence of online reviews in the decision-making process on online marketplaces.

2.4. Online customer reviews and choice probability

There are multiple occasions in which people must make choices in the online environment. Customers purchase from a vast number of diverse companies, select from various service offerings and choose to consume different content. Online customer reviews (OCRs) have become an increasingly popular information source for consumers in this selection process (Kostyra et al., 2016). OCRs create an online reputation which becomes increasingly credible in customers’ eyes and is influencing their decision-making (Luca, 2016, Park & Lee, 2009, Kostyra et al., 2016). Online reviews act as referrals in an online environment. The rating of an offering can be used by customers as an additional dimension to other attributes like price, brand, features and appearance (Hahn et al., 2017). Depending on the website and reputation system, ratings and feedbacks can be given for the platform itself, the seller or for the products. OCRs can be either quantitative or qualitative (Sridhar & Srinivasan, 2012). Qualitative reviews allow the customer to give feedback in any written form, in quantitative reviews, the review is given as a single grade or must be put in a certain format. Quantitative reviews can later be cumulated and presented in statistics (Jiménez & Mendoza, 2013). Chintagunta, Gopinath, and Venkataraman (2010) segmented OCRs into the three dimensions valence, variance and volume. Valence hereby indicates the average satisfaction of the customers, variance is the heterogeneity or discrepancy of the different reviews on a rating scale. Volume is the overall number of ratings or the number of ratings per rated level. As it is displayed in table 1, until now, research about reputation and customer reviews focuses mainly on the impact in the product category. Kostyra et al. (2016) investigated the relationship between

(23)

23 online customer reviews and choice probability when purchasing goods in their extensive study. They revised the latest literature about online reviews and customers’ decision-making in the context of products and contributed to that knowledge with their own research. The three dimensions of online customer reviews, namely, valence, volume, and variance were used to explore how they influence customers’ product choice and how they interact which each other. Finally, they investigated how the existence of online reviews impacted customers’ perception of brand, price and product attributes. The results of their review are presented in table 1 and are extended in this research with a categorical classification to highlight scholars’ focus on the product or service category. This product-centric view provides relevant insights but must be extended to consider a service perspective too. The body of research about service offerings, service innovation, and digital services has grown significantly and spreads about over many different business-related fields. Different schools try to find common patterns as well as differences between product and service innovation and their mechanisms (Lusch & Nambisan, 2015). The underlying trend of offering digital services rather than products leads to the question if and how service adoption is influenced by online reviews. As presented in table 1, this study falls into the service category which is a clear differentiation from most of the existing literature about the influence of customer reviews on customers choice-making in an online environment. Another difference between this study and most of the previous work in this field (please refer to table 1) is also the experimental approach. The work of Jang et al. (2012), in which hotels were used as the subject, can be categorised into the service category as well, however, it represents a service that is only taken for a limited amount of time and the service includes many physical attributes and tangible goods. In addition to the value of OCRs for a potential customer, Prosperio and Zervas (2015) highlighted in their work that customer-generated feedback also provides valuable insights for the seller. According to them, companies can use the online reviews to position their offering and to communicate with the

(24)

24 customer. The response to negative feedback and the use of feedback derived from ratings to optimise services and products is therefore shown to have a positive influence on a company’s average rating.

Altogether, we successfully covered the relevant literature about OCRs which is presented in table 1. What we can conclude is that the influencing factor of different OCR dimensions is adequately explored in the category of consumer products. Furthermore, this line of research must be expanded by investigating the same mechanisms in the service category to find out how OCRs change and influence the decision-making process of service developers and their service adoption patterns. To include this new perspective and add it to the existing research on OCRs and APIs adoption, we will deliver our conceptual framework and hypotheses in the next chapter.

(25)

25

Table 1: Related literature

Category Study Subject of

Study Object of Study OCR-Dimensions Influence on Attributes Relevant Findings

Valence Volume Variance

Products Amblee and

Bui, (2011) Short stories Effect of reviews on sales rank

X X •Only volume is observed to be significant Chen et al. (2011) Cameras Differential and interaction effects of WOM and observational learning X X • Negative word-of-mouth is most influential • Only positive

observational learning has a positive effect • Over time, WOM shows a diminishing effect Chevalier and Mayzlin (2006) Books Effect of reviews on relative sales

X X • Relative sales improve with better valence and higher volume Chintagunta et al. (2010) Movies Impact of reviews on box office sales X X X • Valence is important in the prediction of sales; volume and variance are not Clemons et al. (2006) Beer Predictive power of electronic WOM for product sales growth

X X X • the influence of volume is not significant • Variance is significantly correlated with sales growth • Average valence is significant • Only mean top quartile remains significant after valence is decomposed Cui et al. (2012) Consumer electronics Effect of online reviews on sales of new products

X X • Valence and volume show significant impact • Valence has a stronger impact than volume on search goods • This relationship switches for experience goods Dellarocas et al. (2007) Movies Forecasting box office sales using electronic WOM

X X • Volume and valence show a relationship that is significant Dhar and Chang (2009) Music Predicting sales with electronic WOM

X • Valence is significant for accurate predictions Duan et al. (2008) Movies Impact of electronic WOM on revenue X X • Only volume significantly influences revenue, not valence

Ho-Dac et al. (2013) Blue-Ray and DVDs Explanatory power of OCRs and brand equity for revenue

X X • OCRs have a significant impact on sales when the brand is weak • If the brand is strong, OCRs have no significant impact on sales

• OCRs positively impact the transition from a weak to a strong brand Kostyra et al (2016) E-book reader Effect of OCR on product choice probability X X X Product attributes, namely price, brand and technical features

• Valence has a positive, direct effect on product choice

• Volume positively moderates high valence (only)

• Variance negatively moderates high and medium valence • Online customer reviews draw importance from brand relevance, price

(26)

26

sensitivity, and technical product characteristics Moe and Trusov (2011) Beauty products Dynamics of online product ratings

X X X • Rating dynamics can affect future ratings directly or indirectly • Positive direct effect of valence on sales • No direct effect of variance and volume on sales

Sun (2011) Books Effect of reviews on sales rank

X X X • Impact of volume and valence is positive and significant • Interaction of valence and variance is significant; higher variance increases relative sales when valence is low; higher valence increases relative sales when low variance occurs Zhu and Zhang (2010) Console Games Impact of OCR on Sales

X X X • Valence and variance are significant for less popular games • Volume is significant for popular and less popular games

Services (Jang et al.

(2012) Hotels Influence of reviews on consideration set and choice X X X • Increasing valence is important, volume is less important, and impact of variance depends on prior perceived quality Proserpio & Zervas (2015) Hotels The influence of response to reviews on a company’s online reputation • Responding to negative feedback increases the star rating and decreases the quantity of negative feedbacks

This study APIs Influence of OCRs on the API choice of developers X X Technical attributes and brand

• Valence and volume directly influence the choice probability • Volume moderates valence

• The presence of valence and volume diminishes the perception of API attributes brand and technical features

(27)

27

3. Conceptual framework and hypotheses

On multiple API dictionaries and websites (e.g. programmableweb.com, APIs.io, publicaapis.com, mashape.com, and therightapi.com) developers can find different information about APIs and mashups. On one side, there are attributes which are provided by the API provider and on the other side, there can be customer reviews, representing the average user rating2. These online reviews are not yet used regularly on API directories but can be considered as a tool to overcome information asymmetry and create a quality assurance for products and services. In this study, these two sources of information are assumed to influence the choice probability of the developer in the selection of APIs. The proposed conceptual framework is presented in figure 1.

In the first scenario (i.e., without the online reviews), service developers compare the variety of APIs and make their decisions based on APIs’ functional offerings and their certain attributes only.

OCRs occur in nearly every website in which choices between offerings are made and used by customers to get information about quality (Zhu & Zhang, 2010). Therefore, in the second scenario, we capture the influence of OCRs on the adaption of APIs by service developers. Similar to Kostyra et al (2016), we use the OCR dimensions of Chintagunta et al. (2010), but we excluded the variance dimension in our model. This issue will be discussed in the following paragraph.

2 The developer who selects a certain API is more a user than a customer. But for brevity, we will use online

(28)

28

Figure 3: Proposed conceptual framework

The proposed conceptual framework consists of two blocks which are assumed to influence the choice probability of the developer when selecting a specific API. The first one is the OCR block, which includes the two OCR dimensions valence and volume in this study. Valence describes the overall satisfaction of users (i.e., service developers) with the API and can be used to make a quality assessment. Volume is particularly interesting because it can not only be used to identify how general the opinion of the community about the use of an API is, but also to estimate the number of users. The user number, in turn, can hold implications about documentation and community support of an API. As we showed in table 1, the dimension variance is often used in the product category and is not used in this study due to the following assumptions: The developer community is believed to be more homogeneous in their quality assessment and their individual needs than the generic consumers in the product category. Due to their use of APIs on a professional level, they are believed to be more objective in rating the

(29)

29 service. In addition to that, high variance in retail markets, where consumer goods are purchased, is at least partly connected to diverse experiences with shipping, the purchase process, pricing and subjective entities like physical appearance. APIs, which can be described as producer services, have none of these physical attributes by nature and no third-party services like shipping are included. Therefore, we assume that variance plays a less important role in the API adoption process than it does in the online retail market of tangible products. As a result of that, it is not included and tested as an OCR dimension in this study.

The second block includes API related attributes which are assumed to influence the developers’ choice making. While the attribute price plays an important role in most of the related research in table 1, it will not be part of this study. As explained in chapter 2.2, APIs are based on different archetypes which lead to different business models and pricing structures. Most APIs are offered for free while some other APIs require payments. The latter usually belong to a closed network and they offer highly specialised or differentiated services for which there are no comparable offers in the market. As a result, we exclude price from our study because we assume that APIs which are comparable in their functionality usually follow the same pricing strategy. Remembering the power-law distribution between mashups and APIs (chapter 2.1), and the orientation on developer communities, the attribute brand is assumed to be a major influential factor which impacts the adoption process. The traditional use of a brand as quality assurance does underpin this assumption (Kostyra et al., 2016). There are many technical attributes which can be implemented in or assigned to APIs. Security schemes like personal identification are often used in the online sector due to the growing security concerns (Jacobson et al., 2012). In this study, OAuth 2.0 will be used as a security attribute. OAuth 2.0 is an open protocol for secure authorisation and is a safe way to handle protective data. OAuth 2.0 is a popular standard-protocol which is often used in the market (OAuth 2.0, n.d.). It helps service providers to prevent data from being used by unauthorised

(30)

30 parties. However, this authorisation process via OAuth 2.0 can also prevent developers from trying an API due to the time-consuming procedure (Jacobson et al., 2012). Another important technical attribute which can be used to make APIs and their response rates fast and reliable is a cache function. This function will increase the functional capabilities of the API and is therefore important for developers. If an API works slowly, the application or mashup the developer creates will also work slowly. In consequence, we include caching in this study as it is assumed to be an important factor for developers (Jacobson et al., 2012).

Based on the proposed conceptual framework, we create the following hypotheses. Regarding the OCR dimension valence: As already mentioned, valence can be used as an overall proof of quality (Kostyra et al., 2016). Due to the high-quality requirements and the reputation risk of the developer, this attribute is assumed to have a high impact on developers’ choice making. We therefore assume that:

H1. The valence of online feedback assigned to a specific API positively influences the choice probability that a developer is choosing this API.

Regarding the OCR dimension volume: Research shows that the higher the volume of the feedback is, the more trustworthy the valence becomes in the eye of the user (Kostyra et al., 2016). We follow this finding from the product category and suggest that:

H2a. The volume of online feedback assigned to a specific API moderates the influence of valence on the choice probability.

Looking at the insights derived from Yu and Woodard (2009) and Koohborfardhaghighi and Altmann (2015), one can see that developers tend to use popular APIs and mashups. Developers favour APIs which have a bigger user base and a community which can support the development process and provides documentation. The size of the community and user background can be indicated by a higher volume. This distinctive focus on the community

(31)

31 around a certain API leads us to a hypothesis which is different to the findings of recent OCR literature in the product category and especially by Kostyra et al (2016), who only found a moderating effect of volume. Thus, we hypothesise the following:

H2b: The volume of online feedback assigned to a specific API positively influences the choice probability that a developer is choosing a specific API.

In the product category, the products’ attributes are perceived as less important when combined with online reviews (Kostyra et al., 2016). The market characteristics of the power-law distribution and the long-tail lead to the assumption that the popularity and overall usage of an API are more relevant than functional aspects. Also, the special role of the developer as a provider of the service, which was mentioned in chapter 2.3, lead to the assumption that developers try to avoid the risks of choosing an API which may have the same proclaimed function and attributes but has not been tried yet. Additionally, the traditional function of a brand as a quality seal is assumed to be deposed by the OCR dimension valence, which has a similar function. Therefore, we assume that:

H3. The importance of the API attributes (i.e., brand and technical features) decreases when online reviews are available.

(32)

32

4. Methodology and data

The following chapters provide an extensive description of the experiment and the methodology used in the study. In chapter 4.1. we explain the setup of the experiment and the steps chosen to create a replicable and insightful data set. In chapter 4.2. we describe how the data analysis is executed to test our hypotheses in a clear way.

4.1. Setup of the choice based conjoint experiment

To test the proposed conceptual framework and the presented hypotheses a choice based conjoint experiment is chosen to explore the causal relationship between the different factors (Chapman & Feit, 2015; Vargas, Duff, & Faber, 2017). In comparison to using market data, the online experiment can be used to exclude external factors and diminish endogeneity that often occurs when using market data (Meyer, 1995). This endogeneity can be created by the influence of overlooked, external factors (e.g. advertising, advertising spending, non-observable word-of-mouth, different OCR scales on different websites) in market data or by the use of variables like revenue or sales instead of the actual choice variable or by not randomly assigned participants (Meyer, 1995; Kostyra et al., 2016). For the choice based conjoint experiment, a full factorial design was applied. The experiment was coded and run using DISE, a sophisticated online survey tool to facilitate advanced data collection methods. DISE was developed and freely provided by Schlereth and Skiera (2012). Different APIs with a mapping function are used as subjects in the experiment. Mapping APIs provide services for navigation and location, which are the base of many new applications (Wagner, 2015). We chose mapping APIs because they are among the most frequently used APIs in practice (Wagner 2015; Koohborfardhaghighi & Altmann, 2015). By using the most popular API category (i.e., mapping APIs), we make sure that developers can relate to the choice task of the experiment even though they might use APIs from other categories for their professional work. This way the choice task is more similar to a real-life selection process than using an unknown

(33)

33 and highly specialised API category. These assumptions were confirmed by several developers. In the experiment, developers were confronted with the fictional task of selecting a mapping API to create a new application with a mapping function (please refer to the appendix). In the treatment group, every subject had to choose between three different APIs’ and one extra ‘none’ option which was set to ‘I would not use any of the APIs’ option. This ‘none’ option lowers the risk of participants randomly selecting a given API if they have no specific preference. Every participant repeated the choice process 12 times with 12 different choice sets. To increase the variance four different variations of the survey with different choice sets were designed. In addition to that two questions regarding participants demographics where asked. As proposed in our conceptual model, every API (stimulus) was described with a brand name, technical features, and variations of the used OCR dimensions valence and volume (Oehlert, 2003). Thus, the following variables with their different levels are used in our model:

Dependent variable: The dependent variable is the choice probability of the developer. It is operationalised as the stated preference of the developer in the experiment.

Independent variables: The independent variables are the OCR dimensions volume and valence and the API attributes brand and technical features. The OCR dimensions are operationalised as follows: Valence is operationalised using a star rating scheme which is comparable to ratings in an online environment (e.g. Amazon). It is differentiated between a low valence (1 star), medium valence (3 stars) and high valence (5 stars). Volume of the review is operationalised as high number of feedback (200), medium number of feedback (50), and low number of feedback (5).

Different API attributes are used to describe the APIs. As different levels of brand, two known brands (Google and Microsoft) and one fictional brand (GeoLocate) are used. Cache ability and OAuth are chosen as technical attributes.

(34)

34 To examine the impact of OCRs on the product attributes, a control group does the experiment without any OCR information included. Participants are randomly assigned to either the treatment group to the control group by the software. The link to the experiments was shared on multiple developer forums and websites and provided directly to known developers. In that sense, participants are selected by self-selection and also by using the snowball approach. Figure 4 shows one of the choice sets which are presented to the treatment group. In total, the survey was successfully completed by 99 participants (N=99). The treatment group included 77 participants (N=77), while the control experiment version was completed by 22 (N=22). On average, participants where 28 years old and came from 16 different countries with a clear majority from Germany (42%) (Oehlert, 2003).

Figure 4: Example of a choice-set used in the online experiment

4.2. Estimation models

The estimation models we use to test our hypotheses, the included variables, and the tested hypotheses are presented in table 2. The combination of these three models and the analysis is successfully introduced by Kostyra et al. (2016).

Model 1 follows an approach that is often used in previous studies to test the direct influence of variables. Kostyra et al. (2016) argue that model 1 has shortcomings because it neglects interaction effects. As a result, we use model 2 to include interaction effects between

(35)

35 the OCR dimensions volume and valence, which are often neglected by previous research. Model 2 might, therefore, lead to different insights and is used to test hypotheses 1, 2a and 2b. The comparison between the models 1 and 2 can help us to investigate why our results might differ from previous research. Model 3 is used to explore the effect of OCRs on the relationship between the API attributes and choice probability by introducing an additional treatment indicator and estimating its interaction with the API attributes. We estimate model 1-3 with a multinomial logit model by using the mlogit package of Croissant (2003) in R (Chapman & Feit, 2015).

Table 2: Proposed estimation models

Variables Model 1 Model 2 Model 3

API attributes (brand and technical features) X X X

OCRs (valence and volume) X X X

Interaction effect between OCRs X X

Control vs. Treatment Group X

Method MNL MNL MNL

Hypotheses tested 1, 2a and 2b 3

(36)

36

5. Empirical analysis

5.1. Inspecting choice data

Before estimating the models, a basic description can be used to inspect the data. Choice counts are computed to create an overview and to assess the number of times respondents chose an alternative based on each feature level (Chapman & Feit, 2015). The numbers for each attribute and the corresponding levels are presented in table 3.

Table 3: Raw data choice counts

Attributes Levels

Valence Low Medium High

57 212 559

Volume Low Medium High

188 264 376

Technical Features

None OAuth Cache

195 339 294

Brand Google Maps Microsoft Bing GeoLocate

331 244 253

Number of non-choices: N = 107

According to this raw data count, participants selected high valence APIs much more often than medium and low valence APIs. In comparison, high volume is also selected more often than medium and low volume, but it is more balanced. Based on that higher balanced counts of volume, we can suggest that valence is more important to the choice maker than volume (Chapman & Feit, 2015). Technical features are also more balanced than the levels of valence but a preference for OAuth and cache ability is suggested. When we look at the brand data, a slight preference for Google Maps can be seen. But, compared to the other attributes, the levels

(37)

37 of brand are more balanced. This could indicate that brand is the least important feature, but it could also mean that the individual preferences of the participants in the set are more variant than assumed. The total number of participants selecting the ‘none’ choice was 107. This raw data exploration leads in a direction which is further explored by using a multinomial logit model, which is frequently used to estimate basic choice models (Chapman & Feit, 2015).

5.2. Main effects and replicating prior work

Model 1 replicates some of the previous research from table 1 and the estimates are presented in table 4 below. Model 1 shows the main effects of OCRs on product attributes without including interaction effects.

Table 4: Estimation results Model 1

Estimation Results Model 1

Choice probability

Attribute Standard Errors Coefficients

Brand 0.05 -0.13* Technical Features 0.07 0.67*** Valence 0.08 1.38*** Volume 0.06 0.87*** Observations 925 Log Likelihood -871.99 Note: *p<0.05; **p<0.01; ***p<0.001

All attributes tested show a significant influence on the choice probability. Brand shows a low significance level (p<0.05) and has a negative estimate (-0.13). We tested different brands in our experiments and they are displayed in table 3 (1 = Google Maps, 2 = Microsoft Bing, and 3 = GeoLocate). While Google Maps is the most popular brand, Microsoft Bing is a known brand while GeoLocate is a fictional one. The negative estimate is interpreted based on this

(38)

38 computation and we can argue that the more popular the brand is, the higher is its influence on choice probability. The algebraic sign of the estimate for features can be interpreted in the same way. The positive estimate of Features, which shows high significance (p<0.001), indicates that technical features (2 = OAuth, 3 = Cache), are perceived as more important than the option without features (1 = none). The positive estimate (+0.67) even suggests that cache is more important to the developer than OAuth.

As expected, the two OCR dimensions are statistically significant on a high level (p<0.001) and have the positive coefficients. The positive estimates indicate that higher valence and volume are preferred over lower values. Higher magnitudes of a coefficient for the parameter valence and volume indicates stronger preferences and therefore it can be argued that valence has a stronger influence than volume (Chapman & Feit, 2015). The high positive impact of valence on the choice probability supports hypothesis 1 and also our underlying assumption that higher valence is interpreted by the developer as higher API quality. The positive estimate of volume also supports the assumption that the number of reviews is used as a benchmark for the popularity and the existence of a community using the API. Kostyra et al. (2016) argued that without measuring an interaction effect, the direct effect of volume can be questioned. The effect of volume in our first model (i.e., model 1) might be based on the corresponding level of volume with the choice count of valence which is found to be very strong. It means that due to the high number of choice counts with high valence, the direct impact of volume could only be a coincidence (Kostyra et al., 2016). In our case, only 5.08% of all choice counts observed in the experiment can be attributed to a low-valence API, while 60.43% of the choice counts in question have high-valence as an attribute level. Interaction effects are not included in model 1 and the positive direct impact of volume can therefore be biased. To overcome these shortcomings, interaction effects must be included in model 2.

(39)

39

5.3. Interaction effects

Table 5 shows the results of the estimation model 2, which includes interaction effects between valence and volume and overcomes the shortcomings of the model 1. Model 2 is used to answer our hypotheses 1, 2a and 2b. Valence still shows a strong significant impact on the choice probability (p<0.001). This result is in line with hypothesis 1, which assumes a direct positive impact of valence on the choice probability. The estimate is positive and indicates that a higher valence leads to a higher probability.

Table 5: Estimation results Model 1 and 2

Estimation Results Model 1 and Model 2 Choice probability

Model 1 (without interaction) Model 2 (with interaction)

Attributes Standard

Error

Coefficients Standard Error Coefficients

Brand 0.05 -0.13* 0.06 -0.32*** Features 0.07 0.67*** 0.07 0.55*** Valence 0.08 1.38*** 0.12 0.51*** Volume 0.06 0.87*** 0.10 1.46*** Volume:Valence 0.06 0.49*** Observations 925 925 Loglikelihood -871.99 -834.94 Note: *p<0.05; **p<0.01; ***p<0.001

By comparing the estimates of volume in model 1 and 2, we find some results which are different from prior research, especially to the work of Kostyra et al. (2016). As hypothesis 2a suggest, we find an interaction between valence and volume, which is significant on a high level (p<0.001). Based on literature in the related field of OCRs (please refer to table 1), we interpret this interaction as a moderation effect of volume. The progression coefficient of the interaction term (Volume:Valence) is positive, which indicates that the moderating variable (volume) strengthens the causal effect of valence on choice probability. To put it differently, if

(40)

40 the volume of a review increases, the effect of the average rating on choice probability becomes stronger. The estimates in table 5 also show that volume has a strong direct positive impact on the choice probability which supports hypothesis 2b. Volume is shown to moderate valence but also has a strong direct impact. Consequently, volume can be interpreted as a major factor because its increase directly leads to a higher probability of choice but also to a higher influence of valence. These findings consequently are not in line with the work of Kostyra et al. (2016), who found out that the effect of volume does not directly influence the choice probability. This result can be explained by revisiting the distinctive characteristics of APIs in comparison to consumer products and developers’ preferences (as discussed in chapter 2.2 and 3) and will be elaborated in chapter 6. In conclusion, volume (i.e. the number of reviews) can be used as an indicator of an API’s popularity. A Developer can therefore use volume to make assumptions about the number of users, the existing documentation and the size of an active community around an API. Conclusively, in comparison to the related literature in the product category, the OCR dimension volume, which can be used as a benchmark for a high user number, has a strong significant direct influence on the choice probability (p<0.001). We also observe that the coefficients of valence and volume change between model 1 and 2. The coefficient of valence decreases from model 1 to model 2 while the coefficient of volume increases. This indicates that, when the interaction between volume and valence is included, the direct influence of volume on choice probability is even higher than the impact of valence (Chapman & Feit, 2015). Since all API attributes are highly significant, the question about the impact of OCRs on API attributes becomes more apparent and hence is investigated in the next chapter to test hypothesis 3.

5.4. The effect of OCRs on technical features and brand

Model 3 is used to investigate if OCRs impact developers’ consideration of the product attributes (technical features and brand) when being available as an additional information

(41)

41 source. The model is used to test H3, which hypothesises that OCRs diminish the perception of the studied API attributes. To test this hypothesis, we combine the data from the control group and the treatment group and add a binary treatment indicator. This indicator specifies the treatment group by adding a 1 to the treatment group and a 0 to the control group. The relationship between this treatment indicator and the API attributes can now be tested. A significant interaction between the treatment indicator and product attributes indicates that the existence of OCRs significantly impacts developers’ perception of these product attributes when making a choice in the treatment group (Kostyra et al., 2016). The API attribute results of estimation model 3 are detailed in table 6.

Table 6: Estimation results Model 3

Estimation Results Model 3

Choice probability

Attribute Standard Errors Coefficients

BrandT 0.06 -0.32*** Brand:treat_ 0.15 0.78*** BrandC 0.15 -0.67 FeaturesT 0.55 0.55*** Features:treat 0.14 -0.67*** FeaturesC 0.13 0.94 Note: *p<0.05; **p<0.01; ***p<0.001

The variables marked with “C” are computed parameters of the control group. The variables marked with “T” are computed variables of the treatment group. “:treat” indicates the interaction with the binary treatment indicator.

In addition to that, figure 5 shows the difference between the coefficients for the API attributes in the treatment group and the control group. As it can be seen in table 6, the interaction between the treatment indicator (treat) and the specific API attribute (i.e., Brand/Features) are statistically significant on a high level (p<0.001). This result shows that an interaction between the treatment indicator and the API attributes exists which indicates that

(42)

42 the availability of OCRs influences the perception of the API attributes (i.e., technical features and brand) significantly (Kostyra et al., 2016). In both table 6 and figure 5 and 6 (left side) it is also apparent that the coefficients of all API attributes decrease which indicates that the impact of product attributes is decreased by the presence of the OCR categories valence and volume. Transferred to the actual choice situation, it means that developers’ perception of the explored API attributes (i.e. technical features and brand) is lower when they have OCRs as an additional source of information. It can be concluded that developers actively use the OCR dimension valence to make assumptions about the APIs’ quality and the dimension volume as an indicator for the existence of a community using the API.

Figure 5: API attribute coefficients for the two groups

To reinforce these findings, the change in decision weights apportioned to the API attributes in the treatment and control group is explored. This investigation is insightful because it is possible that even just the mere existence of the additional information provided by the OCRs, independent from their values, could lead to a systematic bias in the path worth estimations of the product attributes. Thus, the decision weights of both attributes (technical

-0.8 -0.6 -0.4 -0.2 0 0.2 0.4 0.6 0.8 1 1.2 C oe ffic ient S iz e API Attribute

Attribute coefficients in control and treatement group

Control Group Treatment Group Technical Features

Referenties

GERELATEERDE DOCUMENTEN

Social practices of using printed books in the digital age are mostly based on the symbolic power of book communication.. All contemporary values attributed to the printed book

Hence in order to construct a manifold invariant from a spherical Hopf algebra A which is not semisimple it is necessary to find a proper spherical subcategory of the category of

• “To what extent do consumers rely on electronic word of mouth (eWOM) in an online decision making process for annuities, compared to regular durable goods?”.. • “To what

He defines the five most important perceived attributes that determine the adoption rate of innovations: relative advantage, compability, complexity, trialability and

Finally, a number of less prevalent safety risks (abuse of the guest system, joint use of shoot- ing ranges, inadequate supervision of recreational shooters) and the storage of

To underline the validity of our com- ponent selection procedure and the usefulness of ICA in general for the removal of eye movement artifacts, we compared the results of the

The passive existence of this data in itself can be beneficial or unbeneficial, for instance the impact that positive or negative reviews on an independent review

The data required to do this was the passive drag values for the swimmer at various swim velocities, together with the active drag force value for the individual at their