Introduction

Policymakers and analysts are heavily promoting data marketplaces to realize a single European Data Market in 2030 (European Commission, 2020a, 2020b, 2020c). Data marketplaces allow companies to securely trade, store, and access high-quality data assets (van de Ven et al., 2021). Similar to “traditional” electronic marketplaces for physical goods or services (Stahl et al., 2016), data marketplaces generally provide three essential mechanisms to (a) match demand and supply, (b) provide infrastructure for creating sales contracts, and (c) facilitate transactions for the transportation and payment of the sold products (Schmid, 2020). Nevertheless, such marketplaces vary significantly from the conventional model due to the nature of data as a trading good. Data is an experience good, making its quality and value often difficult to assess. Moreover, data is a non-rivalrous good that can be duplicated inexpensively and utilized concurrently by others (Koutroumpis et al., 2020). Thus, marketplaces for data trading are unique because of safeguard principles such as data sovereignty and data provenance (Alt, 2021).

Data marketplace literature suggests that such marketplaces can be of a much wider variety in terms of orientation and ownership dimensions (Stahl et al., 2016). Orientation can range from hierarchical (i.e., a data marketplace owner sets the data price and rules for buyers and sellers) to market-related (i.e., prices are set by buyers and sellers depending on competitive offerings). Ownership can vary between data marketplaces privately owned by one company, several companies, or an independent third party. Based on these two dimensions, we identify three data marketplace types. These are data marketplaces with (i) a hierarchical orientation and private ownership, (ii) a mixed hierarchical-market orientation and consortium ownership, and (iii) a market orientation and independent ownership.

Scholars identify various hurdles for using data marketplaces, such as data security and user privacy (Lobschat et al., 2021; Park et al., 2018; Schomakers et al., 2020; Spiekermann et al., 2015), data quality preservation (Koutroumpis et al., 2017; Perera et al., 2017), data monetization and revenue optimization (Mao et al., 2019; Spiekermann, 2019). In all, viable business models for data marketplaces appear to be lacking (Fruhwirth et al., 2020). Consequently, data marketplaces often struggle to take off and reach the commercial phase.

Business models are essential for data marketplace commercialization, but such topics are still limited in literature (Abbas et al., 2021) and generally fragmented (Fruhwirth et al., 2020). Most studies tend to focus on an individual component of business models, such as pricing mechanisms (e.g., Mao et al., 2019; Niu et al., 2020; Zheng et al., 2020), preferences to use data marketplaces (e.g., Schomakers et al., 2020), data properties as economic goods (Demchenko et al., 2018), a decision model to purchase data assets (Lawrenz & Rausch, 2021), or a specific technology implication for business models (e.g., Agahari et al., 2021; Travizano et al., 2020). Other studies examine general business model challenges and (potential) implications (e.g., Fernandez et al., 2020; Lis & Otto, 2020; Virkar et al., 2019). Moreover, the few papers that discuss an integrative view of business models take a narrow perspective on the phenomenon, i.e., only covering independently owned, multilateral data marketplaces (e.g., Fruhwirth et al., 2020; Spiekermann, 2019). Because today’s companies rarely trade industrial data sets on multilateral data marketplaces and preferably trade data bilaterally (Koutroumpis et al., 2017), viable business models for data marketplaces remain speculative. In order to understand why data marketplaces are not taking off in the market yet, we explore the differently arranged data marketplaces, considering their ownership and orientation dimensions. Specifically, we develop business model archetypes for data marketplaces and discuss the potential implications for business model viability. The archetypes provide a basis for explanatory theory development (e.g., on optimal configurations of business models that contribute to performance) and boundary conditions (e.g., specifying conditions under which specific success factors hold).

We focus on the business-to-business (B2B) automotive industry because data marketplaces differ vastly between industries. Data marketplaces are relatively mature in this industry, reflecting on the existence of such marketplaces that mediate between original equipment manufacturers (OEMs) and aftersales service providers (Martens & Mueller-Langer, 2018). Data marketplaces are emerging because OEMs can monetize vehicle data in new ways, mainly when third parties utilize them to create services that are different from their main products (Kaiser et al., 2021). Overall, data exchange within the automotive industry stimulates digitalization and innovative mobility services (Drees et al., 2021). For instance, it is required to unlock the full potential of Advanced Driver Assistance Systems (ADAS) to provide user safety and comfort features (Pillmann et al., 2017). Kaiser et al. (2021) identify the many types of traded data in the automotive industry. Vehicle data is produced by sensors and electronic control units when vehicles operate. Context data is additional data such as “geodata, weather data, traffic data, or map data” (p. 8). This data is often collected and transformed into proceeded vehicle/context data by OEMs. In this paper, we cover both types of data.

Hence, this paper addresses the following research question: What business model archetypes are applied by data marketplace owners from different ownership and orientation types in the B2B automotive industry?

We contribute to the understanding of data marketplaces by developing business model archetypes. We derive these archetypes from business model components that we describe in a taxonomy. Because many data marketplaces do not move past the conceptual stage, we started our taxonomy development by conducting exploratory interviews with data marketplace owners. Based on these interviews, we included only those business model components that exist in practice. Next, we classified different types of data marketplaces in our taxonomy based on their orientation and ownership structure. In doing so, we answer the call from Abbas et al. (2021) to conduct empirical research in business models to convey data marketplaces toward commercialization.

Section 2 provides the theoretical background on trading structures and business models. Next, we explain the taxonomy development processes in Section 3. The taxonomy and archetype results are presented in Section 4. Subsequently, we discuss our results in Section 5. Finally, we conclude the paper in Section 6 to answer the research question and provide future research recommendations.

Theoretical background

Section 2.1 examines trading structures based on economic theories that lead to the variation of data marketplaces. Section 2.2 describes the business model components to develop the taxonomy and archetypes. Section 2.3 discusses business models for data marketplaces.

Trading structures

As indicated in Section 1, we distinguish data marketplace types with a hierarchical and market orientation (Stahl et al., 2016). To characterize the orientation, we will discuss the market-hierarchy continuum to explain factors that cause a shift from a market to a hierarchical structure (Williamson, 1973, 1989).

First, Williamson (1989) introduces asset specificity. This entails the extent to which an asset can be used for multiple purposes. Williamson (1989) recognizes five different forms of asset specificity. These are site-specificity, physical asset specificity, human asset specificity, dedicated assets, and brand name capital. As assets become more knowledge-specific, they are likely traded in organizations with a hierarchical structure (Powell, 1990).

Second, opportunism entails the aim of actors to maximize their gain. Actors who aim for maximum personal gain are attracted to a market structure, and people who seek routine are attracted to a hierarchical structure (Williamson, 1973). Powell (1990) notes that interactions in a market structure do not “establish strong bonds of altruistic attachments” (p. 302) because exchange processes are determined by price competition. Meanwhile, actors in a hierarchal structure interact based on routines with familiar people.

We use the previous notions of asset specificity and opportunism to define organizations with a hierarchical or market structure. Asset specificity concerns the traded goods: organizations with a hierarchical structure likely trade in asset-specific goods; organizations with a market structure trade less asset-specific goods. In contrast, opportunism concerns the people attracted to organizations: organizations with a hierarchical structure trade on an authoritative basis between actors who are familiar with each other; organizations with a market structure trade on a competitive basis between actors who aim for the maximum individual gain. This leads to the following definitions in which data marketplaces can be classified (see Fig. 1):

  1. i.

    Data marketplaces with a hierarchical structure trade in asset-specific goods on an authoritative basis between actors who are familiar with each other.

  2. ii.

    Data marketplaces with a market structure trade in less asset-specific goods on a competitive basis between actors who aim for the maximum individual gain.

In practice, data marketplaces with a hierarchical orientation exist. Attempts are made to launch multilateral data marketplaces with a market orientation in practice, but these initiatives have not succeeded (Koutroumpis et al., 2017). In literature, scientists merely focus on data marketplaces with a market orientation (Fruhwirth et al., 2020; Schomm et al., 2013; Spiekermann, 2019). Therefore, our research contribution is to identify the business models that cover the whole market-hierarchy continuum.

Fig. 1
figure 1

Data marketplaces in the market-hierarchy continuum

Full size image

Business model components

One way to reveal business model archetypes is by analyzing reoccurring patterns in the combinations of taxonomy characteristics (Oberländer et al., 2019). Thus, we will develop a business model taxonomy for data marketplaces as a starting point. To do so, we need to understand what a business model is. Chesbrough and Rosenbloom (2002) state that business models transform technological potential into economic value. Teece (2010) defines business models as the way that companies deliver value to the customer. Amit and Zott (2001) explain that business models visualize the content, structure, and governance of transactions. Business models help discover new business opportunities. Despite the variety in business model definitions, most business model descriptions include component-based perspectives (Hartmann et al., 2014). For this reason, we represent business models based on business model components.

We classify business model components under the main dimensions of value creation, value delivery, and value capture (Teece, 2010). These three dimensions serve as the meta-characteristics in our business model taxonomy. First, value creation is the process of making something that brings worth to the customer. The components value proposition, customer segment, and customer relationships are assigned to this meta-characteristic. The value proposition comprises the product or service offering that solves a customer problem (Chesbrough, 2010; Osterwalder & Pigneur, 2010; Teece, 2010). The value proposition targets a group of customers from a market segment (Chesbrough & Rosenbloom, 2002) or customer segment (Osterwalder & Pigneur, 2010). The customer experience depends on customer relationships, ranging from personal assistance with a high level of human interaction to automated services performed online with minimal human interaction (Osterwalder & Pigneur, 2010).

Second, value delivery is about the asset arriving at the customer. Chesbrough and Rosenbloom (2002) conceptualize that value delivery occurs through a value chain, comprising the processes, activities, relevant resources, and capabilities required to build and distribute the proposition. Osterwalder and Pigneur (2010) argue that value delivery comprises four main components: channels, key resources, key activities, and key partners. Companies communicate, distribute, and sell their value proposition through their channels. The channels are the customer-company interface through which customers purchase the products or services. Companies produce and deliver their value proposition using key resources, including physical, financial, intellectual, and human resources. Key activities are actions to operate the business model, such as producing the value proposition, maintaining the channels, and employees’ training. Often, firms rely on key partners (such as technology providers) to access key resources.

Third, value capture allows monetization of created and delivered value. Simply creating a product or service is often insufficient to capture value (Teece, 2010). Instead of selling an item, providers should monetize solutions to customer problems. In particular, capturing value from intangible products and services is challenging because the property rights are unclear (Teece, 2010). Osterwalder and Pigneur (2010) distinguish revenue streams, such as licensing and brokerage, and pricing models, such as fixed and dynamic pricing. Value capture also includes the cost model covering all company expenses to operate the business model.

Business models for data marketplaces

Although the work on data marketplaces is nascent, a few studies have conceptualized the phenomenon. For instance, Stahl et al. (2016) propose a framework to classify data marketplaces based on two determinants: orientation and ownership. Koutroumpis et al. (2020) propose a similar data marketplace classification, depending on their matching mechanism. They distinguish four types of data marketplaces: one-to-one, one-to-many, many-to-one, and many-to-many data marketplaces.

Specifically for business model conceptualizations, a few other studies discuss business model taxonomies for data marketplaces (i.e., Fruhwirth et al., 2020; Spiekermann, 2019). Spiekermann (2019) identifies value proposition, market positioning, market access, integration, data transformation, architecture, price model, and revenue model as business model dimensions. Value-adding services such as data analytics are a crucial success factor in the business model. According to Spiekermann (2019), data exchange acceptance at data marketplaces is growing among data sellers and buyers. However, the taxonomy developed by Spiekermann (2019) remains high-level and can be extended with more granular business model characteristics.

Fruhwirth et al. (2020) develop a taxonomy that considers dimensions of value proposition, creation, delivery, and capture in their taxonomy. They identify four data marketplace archetypes: centralized data trading, centralized data trading with smart contracts, decentralized data trading, and personal data trading. The archetypes differ regarding platform infrastructure, privacy, and access type. In contrast to Spiekermann (2019), Fruhwirth et al. (2020) do not consider the platform owner’s market positioning and data transformation activities. At the same time, Spiekermann (2019) does not consider the dimensions of time relevancy and payment currency, which Fruhwirth et al. (2020) do consider. Considering these differences, we cannot simply build on one of the two existing taxonomies.

Both taxonomies are exclusively based on data marketplaces with a market orientation. However, market-oriented data marketplaces appear to be challenging to launch, and many initiatives fail (Koutroumpis et al., 2017). Given the exclusive focus on market-oriented data marketplaces in existing taxonomies and the high rate of failure of precisely this type of data marketplace, insight is limited into what business models other types of data marketplace owners apply in practice.

Taxonomy development for data marketplace business models

We follow the iterative taxonomy development approach by Nickerson et al. (2013) to achieve our objective (see Fig. 2). The approach offers a systematic way to develop a taxonomy and is widely used in the literature on digital business models (e.g., Langley et al., 2021; Szopinski et al., 2019). To start the taxonomy development, one should identify meta-characteristics (Step 1), referring to “the most comprehensive characteristic that will serve as the basis for the choice of characteristics in the taxonomy” (p. 343). Next, ending conditions are defined to determine when the taxonomy development process is completed (Step 2). Following these stages, one may start the taxonomy development iterations by choosing an empirical or conceptual approach (Step 3). In the empirical-to-conceptual approach (Step 4e-6e), concepts from existing objects are induced. In the conceptual-to-empirical approach, concepts are deduced from literature (Step 4c-6c). After each iteration, one should check whether the taxonomy has achieved the ending conditions or not (Step 7). Finally, based on patterns in our taxonomy, we derive business model archetypes, which we subsequently link to the data marketplace types. We now apply this approach to develop a business model taxonomy for data marketplaces.

Fig. 2
figure 2

Taxonomy development approach by Nickerson et al. (2013)

Full size image

Defining meta-characteristics (step 1)

We employed the main dimensions of business models as meta-characteristics explained in Section 2.2. These are value creation, delivery, and capture.

Defining ending conditions (step 2)

We adopted objective and subjective ending conditions from Nickerson et al. (2013). We satisfied all ending conditions after eight iterations (see Appendix 1). The summary of taxonomy evolvement for each iteration is presented in Appendix 2.

Iteration 1: Conceptual-to-empirical (Step 4c-6c)

We deduced general business model components. Subsequently, we classified the business model components under three meta-characteristics: value creation, delivery, and capture (Teece, 2010). Based on our elaboration in Section 2.2, we assigned the components of customer segment, value proposition, and customer relationship to the meta-characteristic of value creation. Next, value delivery comprises components of channels, key resources, key activities, and key partners. Finally, we assign components of revenue streams, pricing model, and cost model to value capture. The taxonomy results in this iteration can be seen in Appendix 2 (T1).

Iteration 2: Empirical-to-conceptual (Step 4e-6e)

We intended the taxonomy to contain dimensions that were practically relevant issues in business models. Therefore, we started with an exploratory step with interviews with data marketplace operators, which is unusual in the taxonomy development method (cf. Tönnissen et al., 2020; Weking et al., 2020). An exploratory approach is appropriate if little related work on a research domain is available (Nickerson et al., 2013). We argue that this is the case since related business model work focuses merely on market-oriented data marketplaces, implying no related work on any other types. We used an exploratory approach, using the principles from the grounded theory method as inspiration. We do not claim full theoretical saturation or the development of a full-fledged conceptualization of the dimensions. Instead, we apply the principles of the grounded theory method to establish a practically relevant initial set of dimensions, which reflects the understandings of the practitioners. In the later iterations, these preliminary dimensions will be further enhanced until ending conditions are attained. Overall, three main steps were performed to complete Iteration 2: (i) conducting interviews, (ii) constructing coding categories, and (iii) enriching coding categories and updating the taxonomy.

Conducting interviews

We conducted seven interviews with data marketplace owners to learn about their business models (see Table 1). Next to minimum selection criteria (i.e., availability, automotive data marketplace experience, business model knowledge, at least five years of work experience), we aimed for variety in the data marketplace types that the interviewees represent. Therefore, our sampling is sufficient to develop a pre-taxonomy conceptualization that consists of various relevant dimensions (Thomson, 2010). Interviewees were asked what trends and challenges they face, how these affect their business model, and how their data marketplace differs from competitors. Through follow-up questions, an open-ended, in-depth conversation unfolded.

Table 1 Interview participants
Full size table

Constructing coding categories

The interview data was analyzed through initial and focused coding (Charmaz 2006, p. 43). In initial coding, data segments were named line-by-line. For example, we assigned the codes “aggregate data,” “catalog data,” “tag data,” and “clean data” to the following fragment: “Data marketplaces often need to do data aggregation before giving data to the user. We use data cataloging for this process. There you can do data tagging and data cleaning.” We searched for the most frequent or significant codes and separated, sorted, and synthesized the codes into categories through focused coding. During this process, we started to recognize relationships and patterns between categories. For example, we selected “aggregate data” as the most significant code for the quote mentioned in this paragraph.

Next, the second round of focused coding constructed categories that apply to all interviews. Overarching categories were constructed to classify similar codes. For instance, we created the category data processing activities to group codes of “searching databases,” “aggregate data,” and “harmonize and synchronize data.” The decision rules of focused coding can be seen in Appendix 3. In conclusion, six more coding categories emerged in this process: data regulation, customers, platform infrastructure, revenue model, data quality, and others.

Enriching coding categories and updating the taxonomy dimensions

We further enriched these coding categories during theoretical sampling. Theoretical sampling is the process of collecting data from technical and non-technical literature to develop our tentative categories from the previous step into theoretical categories (Charmaz, 2006; Corbin & Strauss, 2014). The following explanation elaborates on how these coding categories were inducted into the taxonomy dimensions.

Regulating data trade and maintaining customer relationships in a contract ─ One updated taxonomy dimension is the contract, inducted from the previously coding categories of data regulation and customers. Data marketplace owners use contracts and formulate conditions to comply with regulations. For instance, they need consent for data trading because of a regulatory prerequisite. An interviewee explained: “We function as a consent management hub. We facilitate communication between a newly developed application and an Original Equipment Manufacturer to give consent to use parameters of a car” (DM6). The consent often comes with the agreement of data usage terms and conditions, which is stated in a contract: “Everyone comes here to do business, and we have clear terms and conditions that say how to trade data” (DM4). Data marketplaces with a hierarchical orientation have “negotiated contracts,” and data marketplaces with a market orientation have “standardized contracts” (Koutroumpis et al., 2017). In addition, customer relationship via trust and power relationships influence enterprises in their decision to enter a marketplace (Christiaanse & Markus, 2002; Nicolaou & McKnight, 2006; Pavlov, 2002). Data marketplace owners establish these customer relationships using contracts (Koutroumpis et al., 2017). Therefore, we include the contract as a dimension of the customer relationship component in our taxonomy, part of the meta-characteristic of value creation.

Storing data in a centralized or decentralized platform infrastructure ─ Data marketplace owners use their platform infrastructure as a resource to store data. In “centralized” platforms, data control shifts toward data marketplace owners who manage the storage location. Data sellers maintain data control in “decentralized” platform infrastructures (Koutroumpis et al., 2020). We consider the platform infrastructure as a key resource to deliver value to customers.

Performing data processing activities to transform data ─ We identified six data processing activities that data marketplace owners might perform: (a) data collection, (b) standardization, (c) cleaning, (d) storage, (e) analysis, and (f) distribution, which are developed by Curry (2016) and Koutroumpis et al. (2017). First, during data collection, terms and conditions are agreed on (DM7). The term and conditions influence data processing activities. Second, data is standardized to enable easy exchange of data. One interviewee explained: “We facilitate IT integration. We enable standardization of the data in such a way that it results in one common language to easily deliver data to consumers” (DM6). Third, during data cleaning, data marketplace owners check the data consistency and verify the data content. One data marketplace owner explained: “We collaborate with our customers to detect data that is incorrect and automatically improves this in the system. This brings us the advantage to improve the digital map without manual interaction” (DM7).

Fourth, data is stored at a scalable and secure centralized or decentralized location. Fifth, during data analysis, data marketplace owners aggregate and analyze the data sets to extract new insights. As one interviewee stated: “We process data, remove mistakes from the data, link data together, and sell this as an aggregated product” (DM7). Sixth, data is distributed to the participants. One data marketplace owner explained that they only collect and distribute data: “Our data marketplace has two main functionalities. One is to show the metadata of available data sets. The other is the brokerage functionality. That is to get data from a data provider and distribute this to all data users who need to subscribe to a data publication. It is a data delivery and brokerage service” (DM3). Overall, we noticed a difference in data marketplace owners who perform “all” or a “limited” number of data processing activities. We included the dimension data processing activities in our key activities component, part of the value delivery meta-characteristic.

Revenue streams to generate income ─ Data marketplace owners can receive numerous revenue streams to generate income. For example, they may charge customers for the usage of their marketplace or for the data that is transferred on the platform. Four commercial revenue models are: “usage-based process,” “package pricing,” “flat-fee tariff,” and “freemium” (Muschalle et al., 2012). These revenue streams can be combined. One interviewee (DM1) expressed that they apply the freemium and usage-based model. We include revenue streams as a dimension in our taxonomy as part of the value capture meta-characteristic.

Monetizing data with fixed or dynamic pricing mechanisms ─ Overall, data marketplace owners can apply two types of pricing mechanisms; fixed pricing and dynamic pricing. As explained by an interviewee, when fixed pricing mechanisms are applied, “the data price is predefined, and the total price is determined based on how much data the data seller consumed” (DM6). Data pricing mechanisms are often “set by data sellers” (Martens & Mueller-Langer, 2018) in the automotive industry. Martens and Mueller-Langer (2018) explain that OEMs can fix a price for their data because they have monopoly power. In limited cases, “data marketplaces owners” or “data buyers” can also set the price.

In contrast, dynamic pricing mechanisms are “negotiated,” “auctioned,” or based on “real-time market” conditions (Muschalle et al., 2012; Osterwalder & Pigneur, 2010; Täuscher & Laudien, 2018). For dynamic pricing to succeed, an interviewee stated: “There is a need for price discoveries and mechanisms that calculate liquidity based on the market and come up with the price” (DM4). We include the dimension data pricing mechanisms in our pricing model component, part of the value capture meta-characteristic. The taxonomy results in this iteration can be seen in Appendix 2 (T2).

Iteration 3: Conceptual-to-empirical (Step 4c-6c)

Five business model dimensions were induced in the previous iteration: (i) contract, (ii) platform infrastructure, (iii) data processing activities, (iv) data pricing mechanism, and (v) revenue streams. We supplemented these with dimensions from the taxonomies of Spiekermann (2019) and Fruhwirth et al. (2020). They define business model dimensions that we did not consider up to this point. The dimensions are integration, domain, marketplace participants, data origin, data output type, data quality guarantee, review system, privacy, market access, pre-purchase testability, and payment currency.

Spiekermann (2019) defines the integration of a data marketplace as domain-specific or domain-unspecific. The dimension overlaps with the domain dimension from Fruhwirth et al. (2020). We merge both these dimensions into the preliminary dimension of domain in our taxonomy. Next, as Fruhwirth et al. (2020) defined, the marketplace participants refer to the data sellers and buyers who are matched at the data marketplace. This dimension will be included as the preliminary dimension of participants in our taxonomy. These two newly identified dimensions belong to the customer segment component.

We alter the dimension of data origin from Fruhwirth et al. (2020) into the data source. Based on Fruhwirth et al. (2020), the characteristics “government,” “social media,” “commercial data sources,” “self-generated,” and “community” are added to this dimension. Then, Fruhwirth et al. (2020) characterize the data output with different format types. Data can remain unchanged and be transferred directly between the data seller and buyer. In addition, data can be processed by the data marketplace and sold as a transformed data product. Therefore, we adapted the characteristics of data output to “aggregated” and “standardized” data. Next, we merged the dimensions of data quality guarantee and review system from Fruhwirth et al. (2020). Fruhwirth et al. (2020) define who evaluates the data quality in the review system dimension. We altered the review system into the data quality dimension. Either “marketplace owner” or “user reviews” can review data quality. Furthermore, Fruhwirth et al. (2020) define the privacy dimension by “anonymization” and “encryption” as part of the value proposition. Thus, we include privacy as a preliminary dimension in our taxonomy. In summary, these four dimensions are added in the value proposition component.

Spiekermann (2019) defines the dimension of market access as closed or open. In a “closed” market, a limited number of participants are allowed, and in an “open” market, the number of participants is broad and unknown. We named this dimension platform access in our preliminary taxonomy, which belongs to the component of channels. Finally, our preliminary business model taxonomy considers the dimension of payment currency from Fruhwirth et al. (2020). Data marketplaces differ in payments that are transferred in “fiat currency” or “cryptocurrency.”

The dimensions of market positioning (Spiekermann, 2019), time relevancy, and access type (Fruhwirth et al., 2020) are excluded. The market positioning shows whether the platform is owned by an independent party or a buyer or seller. These characteristics are part of our definition of data marketplaces, as explained in Section 1. The dimension of time relevancy entails whether uploaded data is static or dynamic. This technical property should be discussed as part of the data output dimension in the taxonomy. Finally, the access type is distinguished by API, download, or specialized storage. We do not demand that level of specificity to distinguish the business models of data marketplaces. To sum up, the preliminary taxonomy can be seen in Appendix 4.

Iteration 4–6: Empirical-to-conceptual (Step 4e-6e)

We refined our preliminary taxonomy with induced business model characteristics from selecting existing data marketplaces. We analyzed six cases from three data marketplaces types for theoretical sampling and replication (Eisenhardt, 1989; Eisenhardt & Graebner, 2007; Siggelkow, 2007). The purposive sampling of cases helps us describe, analyze, and draw theoretical and practical implications in the analysis. Based on the theoretical dimensions laid out in Section 2.1, data marketplaces can have (i) hierarchical orientation and private ownership, (ii) a mixed hierarchy and market orientation and consortium-based ownership, and (iii) market orientation and independent ownership. We limit our analysis to six data marketplaces to perform in-depth case analyses and create more specific business model insights than are currently available in the taxonomies of Spiekermann (2019) and Fruhwirth et al. (2020). To select cases, we employed these selection criteria as minimum conditions: the data marketplaces should be automotive-oriented, business-to-business, past the conceptual stage, and documented in English. On top of that, we select cases that cover the three theoretically relevant types of data marketplaces: (i) hierarchical orientation and private ownership (TomTom, INRIX); (ii) mixed hierarchical and market orientation with consortium-based ownership (HERE, Caruso); and (III) market orientation and independent ownership (IOTA, Ocean Protocol). See Appendix 5 for further descriptions of the cases.

Through content analysis, business model characteristics from case documents were induced (see Appendix 6). First, we analyzed web pages, whitepapers, and terms of use documents to understand data marketplaces’ vision and activities. Additionally, Forbes was selected as an external source because it is renowned for business, investment, and technology insights. If additional information was required after analyzing these sources, we included news releases of the cases until no new dimension (and characteristic) was found. Next, similar to the coding process explained in Iteration 2, we applied initial and focused coding to induce categories.

During Iteration 4, we coded the documents of TomTom and INRIX. For example, a line on the website of TomTom states, “We license maps, navigation software, and online services as components for applications, offering tailor-made solutions to meet customer’s specific needs” (TomTom, 2021). We assigned this line the codes license products and offer tailor-made solutions. Based on this example, TomTom licenses products and offers these as tailor-made solutions. These offerings go beyond selling a product. These codes do not fit the dimension of data product or data processing activities. Therefore, through focused coding, the data service dimension emerged. In Iteration 5, we coded the documents of HERE and Caruso. We changed the naming of the dimension of data source into data input. During Iteration 6, the documents of IOTA and Ocean Protocol were analyzed. During this iteration, we removed the data input dimension to avoid overlap with the dimension of participants. Data sellers are participants at the data marketplaces and provide data input. We removed the cost model dimension since all data marketplaces do not provide any information related to their cost structure. For further information, the documentation related to initial and focused coding can be seen in Appendix 7.

Iteration 7–8: Evaluation

All data marketplaces were classified, and all objective ending conditions were met after Iteration 7. To assess the subjective ending conditions in Iteration 8, we conducted semi-structured interviews with the primary authors of the two related works (i.e., Fruhwirth et al., 2020; Spiekermann, 2019), whom we considered as experts in business model taxonomies for data marketplaces. The semi-structured interview method enables exploring new topics while still evaluating predefined conditions (Galletta, 2013) and is used by others to test taxonomy ending conditions (e.g., Keller & König, 2014). Both experts indicated that the number of dimensions and characteristics provides a clear overview. Nevertheless, one of the experts suggested removing the dimension of data processing activities because it overlaps with the data service dimension.

Results

Business model taxonomy

Our final taxonomy contains three meta-characteristics, eight components, and thirteen dimensions of business models (see Table 2), in which the characteristics of TomTom (TT), INRIX (IN), HERE (HE), Caruso (CR), IOTA, and Ocean Protocol (OP) are specified. Under the assumption that each data marketplace has one business model, we classified cases in one business model characteristic per dimension. Thus, our taxonomy contains characteristics that are mutually exclusive and collectively exhaustive.

Table 2
figure a

Business model taxonomy for data marketplaces in the B2B automotive industry

Full size image

Value creation

The customer segments of data marketplaces are specified in the dimension of domain and participants. The domain refers to the area of activity of the data marketplace. While TomTom, INRIX, and HERE are specialists in the location domain (i.e., they design dynamic maps and communicate real-time road conditions to their customers), Caruso focuses on the complete automotive domain. This includes numerous segments: (i) vehicle position, movement, and surroundings; (ii) vehicle health and maintenance; (iii) vehicle non-powertrain hardware; (iv) vehicle powertrain resources; (v) vehicle powertrain hardware; (vi) mobility services; and (vii) auxiliary devices, among others. IOTA and Ocean Protocol focus on all industries. They aim to accelerate the Internet of Things (IoT) and Artificial Intelligence (AI) developments by facilitating data trade across industries.

The dimension participants entails the actors who are matched at a data marketplace to trade data. The data marketplaces differ in terms of internal and external developers. TomTom, INRIX, and HERE have internal developers who use the data traded at their data marketplace to develop their value proposition. Caruso, IOTA, and Ocean Protocol do not process the data internally but target external developers who further process the data sets themselves. In these data marketplaces, the roles of marketplace owner and third-party service provider are separated.

The value proposition consists of the dimensions: data service, data output, data quality, and privacy. The data service is the service offered to the participants. TomTom and INRIX provide a customized map service. They aggregate the map data from their data sellers to navigate cars. Caruso, IOTA, and Ocean Protocol perform a data brokering service. This service comprehends minimal interference of the data marketplace owner. The data marketplace owner provides the technical infrastructure for direct trade between the data seller and buyer. HERE offers both the customized map service and data brokering service. Thus, HERE combines two different value propositions.

The data output shows in what form the data marketplace owner trades data. TomTom and INRIX trade aggregated data, which they produce with their customized map service. Caruso, IOTA, and Ocean Protocol trade standardized data. The data can be standardized by the data marketplace owner, as Caruso does, or the data sellers have to standardize the data themselves, as IOTA and Ocean Protocol implement. HERE offers both aggregated and standardized data output.

Data quality entails the preservation of data quality from the data seller. The identified characteristics are reviews by the marketplace, user reviews, and no information. TomTom and INRIX ensure high-quality data by reviewing the data themselves. Other data marketplaces such as IOTA and Ocean Protocol are not directly involved in preserving the data quality but let their participants review it. HERE and Caruso claim to provide high-quality data but do not provide information about who reviews the data quality.

Privacy indicates how stored data at a data marketplace is protected. All data marketplace owners guard data privacy by anonymizing (TomTom, INRIX, Caruso) or encrypting the data (HERE, IOTA, Ocean Protocol). The contracts are the agreements that enforce data trade between data sellers and buyers. INRIX, TomTom, and Caruso have negotiated contracts that demand close communication between partners. IOTA and Ocean Protocol apply standardized contracts. They make use of smart contracts, which are updated automatically. Smart contracts decrease transaction costs and enable multilateral trade. HERE offers both the negotiated and standardized contracts to trade data at their platform.

Value delivery

The platform access of a data marketplace is the degree of openness for participants to enter the platform. TomTom, INRIX, and Caruso have closed platform access. Their participants must provide company details and specifications about their data use before allowing the platform owner access. HERE, IOTA, and Ocean Protocol have open platform access and allow anyone to upload and buy data from the marketplace. The platform infrastructure specifies how data is stored at the data marketplace. TomTom, INRIX, HERE, and Caruso have a centralized platform infrastructure and store data in the cloud. IOTA and Ocean Protocol have a decentralized platform infrastructure and store data across locations. By performing data processing activities, data marketplace owners add value to data. The primary data processing activities are data collection, standardization, cleaning, storage, analysis, and distribution. TomTom, INRIX, and HERE perform all of these activities for their participants. Caruso, IOTA, and Ocean Protocol perform a limited number of activities. They do not clean the data and are limited in data analysis.

Value capture

The revenue streams indicate how a data marketplace owner generates turnover. TomTom and INRIX receive usage-based revenue streams. HERE combines the usage-based and freemium models. Caruso receives a commission from data transactions. IOTA is a non-profit organization and provides its platform for free. The organization is funded by donations from individuals and enterprises to maintain its platform. Ocean Protocol does not provide information about its revenue streams. The data pricing mechanisms indicate how the trading entities establish prices of the data they trade. TomTom and INRIX sell their data for which they set the price themselves. At Caruso, IOTA, and Ocean Protocol, the data sellers set the price for their traded data. HERE is a data marketplace that applies both pricing mechanisms. They set the price for their own aggregated data, and their data sellers set the price for the traded standardized data. No dynamic pricing mechanisms were observed at the included data marketplaces. The payment currency is the currency in which the payment is transferred. TomTom, INRIX, HERE, and Caruso use fiat currency. Ocean Protocol and IOTA have their cryptocurrency. These cryptocurrencies are called tokens and can be used only in their marketplace.

Business model archetypes (pattern recognition)

Data marketplaces with similar business model characteristics are grouped into archetypes. We develop the archetypes by conducting a pairwise comparison (See Table 2). In Table 2, cases are paired based on the characteristics they share using color-coding. The dark grey color represents similar characteristics of TomTom and INRIX, and the light gray one represents similar characteristics of IOTA and Ocean Protocol. Because of the high degree of similarities, we group TomTom and INRIX into an archetype. We also do the same with IOTA and Ocean Protocol. In contrast, HERE and Caruso only share two identical characteristics (indicated with bold lettering). Therefore, we separately create an archetype for HERE and Caruso.

These archetypes are developed to challenge existing understandings of data marketplaces, i.e., identifying which type of data marketplace business models are viable to be commercially exploited in practices. The identified archetypes are the (1) aggregating data marketplace, (2) aggregating data marketplace with an additional brokering service, (3) consulting data marketplace, and (4) facilitating data marketplace. Table 3 describes the business model archetypes. It connects an archetype to the respective data marketplace cases and describes its orientation and ownership type. Moreover, the business model characteristics of each archetype are also discussed.

Table 3 Business model archetypes for data marketplaces
Full size table

Aggregating data marketplace

TomTom and INRIX apply the aggregating data marketplace archetype. They create value for their customers by aggregating their sellers’ data to provide tailored maps for their customers. Data marketplace owners establish personal customer relationships with the data marketplace participants through bilaterally negotiated contracts. They have close contact with their participants during bilateral negotiations and offer personal assistance during data collection. Osterwalder and Pigneur (2010) introduce personal assistance as a manner for business owners to build customer relationships through human interaction.

Moreover, the data marketplaces have well-understood customer segments in the location domain. Within the location domain, the data marketplace owner knows the participants, the origin of the data, the information the data relates to, and the purpose of using the data. Furthermore, the customer groups are segmented as automotive or enterprise. Segmented customers have slightly different needs and problems and receive differing value propositions (Osterwalder & Pigneur, 2010). Segmentation leads to the customized value proposition that the data marketplace owner creates by offering a customized map service.

The aggregating data marketplace has closed platform access. Close access contributes to a controlled environment in which the data marketplace owner selects its participants. Furthermore, the aggregating data marketplaces need a centralized platform infrastructure. The centralized platform infrastructure is connected to the customer IT systems and realizes a central access point for the data marketplace owner to modify the data and perform their service. In the aggregating data marketplace archetype, the data marketplace owner sets the price of the traded data. The aggregated data output is owned and sold by the data marketplace owner. The sold data leads to direct revenue streams for the data marketplace owner.

Aggregating data marketplace with additional brokering service

HERE applies the aggregating data marketplace with additional brokering service archetype. This archetype includes two distinct value propositions. One value proposition is similar to the value proposition of the aggregating data marketplace. Data marketplace owners deliver a customized value proposition and aggregated data within the location domain in both archetypes. However, data marketplace owners who apply the aggregating data marketplace with additional brokering service archetype offer a second, standardized value proposition, which is the data brokering service. This service enables standardized data trade directly between data sellers and buyers at the data marketplace. The data marketplace owner uses negotiated contracts for their customized value proposition and standardized contracts for their standardized value proposition. The application of both negotiated and standardized contracts enables the data marketplace owner to offer personal assistance to some customers while simultaneously serving other participants through automated assistance.

The aggregating data marketplace with additional brokering service has open platform access. Anyone who creates a user account can enter the platform through a centralized platform infrastructure. Central data storage is required for the data marketplace owner to perform data collection, standardization, cleaning, storage, analysis, and distribution, as well as to deliver the customized value proposition. To capture value, the data marketplace owner maintains two data pricing mechanisms. The data marketplace owner sets the price for the aggregated data produced with the customized map service. The data sellers set the price for the standardized data that they sell via the brokering service.

Consulting data marketplace

Caruso applies the consulting data marketplace archetype. They offer a standardized value proposition. In the consulting data marketplace archetype, the owner pairs the service with negotiated contracts. The data marketplace owner gains knowledge about the data needs and price preferences of the participants and aligns the needs of the data sellers and data buyers. Participants are personally assisted on a bilateral basis by the data marketplace owner through negotiated contracts. Similar to the contracts of the aggregating data marketplace, these contracts lead to strong customer relationships. The data marketplace owner aims to be the intermediary, serving all interdependent participants interested in automotive data.

The consulting data marketplace has closed platform access. Closed access provides controlled provision and purchase of data at the marketplace. Furthermore, consulting data marketplaces have a centralized platform infrastructure. The data marketplace owner stores and publishes metadata about the data sets in the centralized platform infrastructure. Consulting data marketplaces do not store the exchanged data sets in their cloud but only keep track of metadata about the data sets. The consulting data marketplace also allows the data seller to determine the price of the sold data. The data marketplace owner consults their participants about possible data pricing mechanisms and receives a commission for the provided service.

Facilitating data marketplace

IOTA and Ocean Protocol apply the facilitating data marketplace archetype. They coordinate transactions between data sellers and buyers through the data brokering service without the interference of the data marketplace owner. The facilitating data marketplace contains a standardized value proposition that comprises a data brokering service. Data is traded between buyers and sellers across all industries to develop IoT and AI technologies further. The facilitation of standardized, smart contracts by the data marketplace owner foresees a high number of transactions between participants and automates the process of data trade.

The facilitating data marketplace has open platform access and decentralized platform infrastructure. The decentralized platform infrastructure allows the minimal intervention of the data marketplace owner and direct transactions between the data seller and buyer. Transactions in DLTs are immutable and transparent to ensure safe data delivery. The data marketplace owner’s main task is to define transaction rules and link transactions to be executed and verified by the participants. The marketplace owners who apply the facilitating data marketplace archetype enable the sellers to set the price for the traded data sets. The revenue streams are directly transferred between the data seller and data buyer, and the data marketplace owner does not make a profit from the data that is traded on the platform.

Discussion

Our business model archetypes are distinctive for the data marketplace types. TomTom and INRIX, the data marketplaces with private ownership and a hierarchical orientation, apply the aggregating data marketplace archetype. HERE and Caruso, data marketplaces with consortium ownership and characteristics from both a hierarchical and market orientation, apply the aggregating data marketplace with additional brokering service and consulting data marketplace archetypes. IOTA and Ocean Protocol, data marketplaces with independent ownership and market orientation, apply the facilitating data marketplace archetype.

A value proposition that offers a solution instead of data “items” ─ In its essence, all data marketplaces trade data. A data marketplace owner can distinguish their marketplace from other data marketplaces by performing additional services in their value proposition. Our business model archetypes show that data marketplace owners create additional value for their customers by performing a customized map service, reviewing the data quality, or offering personal assistance through negotiated contracts. The value proposition of data marketplaces with the facilitating data marketplace archetype is the only value proposition that focuses solely on a data brokering service.

This represents the problem that Teece (2010) describes as selling “items” rather than solutions. Data assets, or “items,” could be described as intangibles, know-how, and technological components. These goods are difficult to price and are rarely traded in market structures (Koutroumpis et al., 2017). According to Teece (2010), it is a common problem that the sale of assets that do not have perfect property rights leads to market failure. Business owners who apply business models that are based on selling intangibles may not capture significant value with their value proposition. Therefore, companies who trade intangible assets need to bundle them into a solution.

The aggregating data marketplace, aggregating data marketplace with additional brokering service, and consulting data marketplace archetypes comprise value propositions in which data is bundled into a solution. The data marketplace owners of these archetypes trade data and provide complementary services such as a customized map service, data quality reviews, or personal consultation about data sales and purchases. Spiekermann (2019) argues that such services enhance the value of data marketplaces for customers. He finds that data marketplace owners who aggregate data or assure data quality create value as they go beyond data forwarding (Spiekermann, 2019). The performance of such services does require higher investment in time and money from the data marketplace owner. Osterwalder and Pigneur (2010) explain that these companies focus on delivering a premium value proposition and have value-driven business models. Their customers pay not only for the data they get but also for the service that the data marketplace owner performs.

Data marketplace owners who apply the facilitating data marketplace archetype focus on data forwarding with their brokering service. These data marketplace owners have a lean cost structure and automate most of their processes. This is what Osterwalder and Pigneur (2010) call a cost-driven business model. Data marketplace owners who apply this business model promise an increase in data accessibility for their participants against a low price. Their value proposition entails trading data “items.” However, this does not appear to be the solution for their customers. Data sellers and buyers remain absent, which diminishes the ability to increase data access. There is a need for data marketplace owners from the facilitating data marketplace archetype to bundle their data brokering service with complementary services. This way, they can attract data sellers or buyers by offering a solution instead of trading data “items.”

Establishing strong customer relationships or competitive pricing ─ Data marketplace owners build customer relationships to attract customers and sell their value proposition. Our archetypes recognize those data marketplace owners who apply the aggregating data marketplace, aggregating data marketplace with additional brokering service, and consulting data marketplace archetypes implement bilaterally negotiated contracts. As explained in Section 4.2, data marketplace owners personally assist their customers in bilateral negotiations to build personal customer relationships. This approach aligns with the results of Koutroumpis et al. (2020), who note that one-to-one data marketplaces have relational contracts. These relational contracts enable repeated interaction between the data marketplace owner and their participants. We expect repeated interaction in organizations with a hierarchical trading structure. As Powell (1990) explains, the personal identification between the trading parties in a hierarchy causes them to trade repeatedly with each other. Actors who trade in these organizations are driven by routines and have less room to display opportunistic behavior (Powell, 1990; Williamson, 1973).

On the contrary, actors in organizations with a market structure aim to minimize their costs and behave opportunistically (Williamson, 1973). The buyers easily switch between sellers when they are not satisfied by certain pricing conditions. As Powell (1990) explains, price competition positively influences the behavior of actors in hierarchies. The trading parties seek quick and efficient interactions. Koutroumpis et al. (2017) note that many-to-many data marketplace owners standardize contract conditions to increase efficiency and lower transaction costs. The data marketplace owners implement standardized contracts to offer their customers automated assistance, which is efficient and has lower costs than personal assistance.

Data marketplaces with a market orientation need to set a competitive environment and keep product prices low. Therefore, data marketplace owners who apply the facilitating data marketplace archetype need dynamic pricing mechanisms and high demand and supply numbers. However, the high number of data sellers and data buyers has not yet been reached at data marketplaces with market orientation (Koutroumpis et al., 2017; Spiekermann, 2019). As shown in our business model archetypes, dynamic pricing mechanisms do not occur either. Instead, fixed data pricing mechanisms, set by the data marketplace owner or data seller, are applied in practice. Fruhwirth et al. (2020), who researched 20 data marketplaces, found that two data marketplace owners establish prices based on auction or negotiation. The other data marketplaces they researched have fixed pricing mechanisms. Out of the 16 data marketplaces that Spiekermann (2019) researched, only four data marketplace owners priced data based on market supply and demand. One of those data marketplaces withdrew from the market, and the others are still conceptual. The expected functioning of the invisible hand of the market remains obsolete. Because a competitive environment is not established, data marketplaces with a market orientation fail to attract participants who trade on a competitive basis and aim for the maximum individual gain.

Reflecting on personal data trading ─ Despite our focus on B2B data trading, our archetypes are also potentially applicable for personal data marketplaces. These marketplaces possess Consumer-to-Business (C2B) properties by trading user-generated personal data (Fruhwirth et al., 2020). For instance, MyAutoData enables drivers to sell their vehicle data by granting access to specific data sellers (MyAutoData, 2020). MyAutoData is an independently owned, multilateral data marketplace. It offers standardized and encrypted data, as well as brokering services to attract data sellers. This use case is generally similar to facilitating data marketplaces in the B2B case. Nevertheless, further examination is required to understand personal data trading with facilitating data marketplaces. For example, data quality reviews may not be applicable since data sellers can expect the same quality data for each end-customer. Another example is the standardized contract, which will not be as complicated as the B2B relationship since the data use cases have already been predefined.

Reflecting on platform business models and network effects ─ We built our taxonomy based on well-known business model frameworks provided by Osterwalder and Pigneur (2010) and Teece (2010). Alternatively, we could have utilized platform-specific business model frameworks to develop our taxonomy (cf. Staub et al., 2021, Täuscher & Laudien, 2018), which would possibly have altered our findings. However, our taxonomy does cover platform-specific business model characteristics (such as platform access, platform infrastructure, and pricing mechanisms). Further, our exploratory approach in the early stage of the taxonomy development processes (Iteration 2) did include several discussions with experts on platform-related business model issues. In addition, in Iteration 3, we incorporated taxonomy dimensions from Fruhwirth et al. (2020) and Spiekermann (2019), which cover platform business model characteristics.

Our taxonomy does not include core platform concepts of network effects and economies of scale (cf. Täuscher & Laudien, 2018). Network effects are generally crucial as they create a “chicken-and-egg” problem for platform-based business models. Prior data marketplace studies argue that third parties are needed to increase the size of network effects (Fruhwirth et al., 2020; Spiekermann, 2019). We argue that network effects are most important for the facilitating archetype. This archetype merely facilitates buying and selling data, so attracting a critical mass of buyers and sellers is essential. Nevertheless, network effects from buyers to sellers are less strong for the other archetypes. For instance, the aggregator type provides data assets rather than linking buyers to sellers. In the brokering and consulting types, especially data network effects are important, as the data marketplace can provide better advice if more data about usage is available (cf., Gregory et al., 2021). By collecting data on usage, these two types can offer more personalized and superior advice to data buyers (Haftor et al., 2021). For data network effects, the value of the network is more important than the size. In this way, our archetypes differ in terms of the importance and type of network effects that they create.

As the importance of network effects differs between the archetypes, important implications can be drawn. Considering that usage levels of data marketplaces are still low (European Commission, 2020b), aggregating, brokering, and consulting marketplaces are, today, easier to commercialize than facilitating marketplaces. Nevertheless, potential network effects increase once the data economy takes off and grows (see European Commission, 2020a), making the facilitating marketplace more viable in the long run. Consequently, the aggregating type may, in the long run, be outperformed by facilitating marketplaces. The brokering and consulting may be interoperable to the “ecology” of data marketplaces to leverage network effects, thereby surviving in future upcoming scenarios (cf. Abbas, 2021). In conclusion, scholars should distinguish the archetypes that we unearthed in the paper to understand the implications of network effects on data marketplace business models.

Conclusion and future research

This paper analyzed the business models of different types of data marketplaces that range from hierarchical to market orientation and private to independent ownership in the B2B automotive industry. We created a taxonomy and classified the business models of six data marketplaces with considerable market uptake. Patterns were identified in business model components of domain, data service, data output, contract, platform access, platform infrastructure, and data pricing mechanism. From this, we derived four business model archetypes that each apply to different data marketplace types.

TomTom and INRIX are data marketplaces with private ownership and a hierarchical orientation. They apply the aggregating data marketplace archetype and process data from their sellers to aggregate data into a customized value proposition. HERE is a data marketplace with consortium ownership and characteristics from both the hierarchical and market orientation. They apply the aggregating data marketplace with additional brokering service archetype. HERE aggregates data to create a customized value proposition as a core business and provides an additional data brokering service as an additional standardized value proposition. Caruso belongs to the same data marketplace type as HERE and applies the consulting data marketplace archetype. They provide a data brokering service and advise their participants about the usage and exchange of their data. IOTA and Ocean Protocol are data marketplaces with independent ownership and market orientation. They apply the facilitating data marketplace archetype and deploy a decentralized platform infrastructure to coordinate transactions between sellers and buyers with their data brokering service.

We contribute preliminary to academic knowledge by identifying four business model archetypes that co-exist in today’s data marketplace industry. We go beyond the few existing studies on data marketplace business models, as we consider data marketplace types ranging from hierarchical to market orientation and from private to independent ownership. We also create and discuss an explanatory understanding by linking these archetypes to theoretically informed dimensions of ownership and orientation.

A possible theoretical implication is that multiple configurations of business models exist, which each yield adequate performance. This theoretical assertion could be developed into a configurational theory that relates business model dimensions to performance outcomes. Our taxonomy and its dimensions provide a starting point for developing such configurational theory. A potential next step could be to conduct a qualitative comparative analysis to identify choices on business model dimensions that provide sufficient or necessary conditions for business model performance (see Bouwman et al. 2019). For example, facilitating data trading in a specific automotive domain (such as location data) by employing centralized platform infrastructure (as illustrated in the aggregating, brokering, and consulting marketplaces) may lead to superior value creation when compared to decentralized and cross-industry data trading (as illustrated in facilitating ones). Generally, decentralized architectures pose scalability challenges (Avyukt et al., 2021). In addition, data buyers and sellers prefer not to openly share their data since they are less familiar with other industry characteristics (Scaria et al., 2018). Considering this view, our taxonomy dimensions may represent different independent variables that can be manipulated (and further tested), while our archetypes suggest interaction effects between those independent variables. Hence, linking the specific business model choices to performance criteria can be a starting point to develop a “theory for explaining” (cf., Gregor, 2006).

An alternative theoretical implication is to use the archetypes as boundary conditions for future theory development. Recognizing that the business model archetypes are substantially different, future theory development should specify which archetypes are considered focal phenomena. More precise theoretical assertions can be developed by delineating the boundary conditions (cf. Bacharach, 1989) of such a future theory development effort. Making explicit which archetypes are being considered in theory development can avoid conceptual ambiguity, which has generally plagued the digital platform literature (De Reuver et al., 2018). Conceptual ambiguity is especially problematic if cumulative work results in seemingly contradictory evidence, whereas in reality, that evidence is based on fundamentally different data marketplaces. One example of this is the importance of network effects, which differs strongly between our archetypes. Without specifying which archetype is being considered, assertions on the impact of network effects on business model performance cannot be made. In this way, our study provides a basis for distinguishing different types of data marketplaces and thus poses an example of developing boundary conditions in a dynamic way (Busse et al., 2017).

The generalizability of these results is subject to certain limitations, primarily due to the characterization of the specifics of the sample and industry. While we cover all trading structures (the market-hierarchy continuum) in our analysis, we limit our analysis to six marketplaces to make a tradeoff to establish depth over breadth. Therefore, future work could extend our taxonomy by considering additional data marketplaces, both within and outside the automotive industry. When including other industries, the taxonomy likely has to be reformulated in a more generic way to cover the diversity of industries, lowering the granularity of the taxonomy and archetypes. In doing so, other archetypes may emerge.

Data marketplace owners can potentially make design choices based on our archetype and taxonomy to develop their data marketplaces. For instance, practitioners designing their data marketplace can use our archetype taxonomy to select their business model characteristics. Furthermore, practitioners from data marketplaces past the conceptual stage can use our artifacts for competitor analysis. They can identify whether their competitors are innovating their business models in areas where they should evolve. In addition, policymakers can reflect on our findings to stimulate commercialization, specifically for facilitating data marketplaces. Policy instruments such as property rights and data ownership protections for experience goods (like data assets) are highly relevant in stimulating data seller participation. Incentive mechanisms and liability protections (single-sided strategy) may also work to engage data sellers and thus solve the chicken-or-egg problem in market-oriented data marketplaces. Whether our artifacts suffice for those purposes is not evaluated and is therefore advised for future research.