Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania...

28
Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania [email protected] www.seas.upenn.edu/~ssoumya Joint Work with: R. Guerin, K. Hosanagar 9 th December, 2010. University of Minnesota. Exploring the Trade-offs between Functionality-rich Versus Minimalist Design: A Two-sided Market Analysis

Transcript of Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania...

Page 1: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

Soumya Sen

Dept. of Electrical & Systems EngineeringUniversity of Pennsylvania

[email protected]/~ssoumya

Joint Work with: R. Guerin, K. Hosanagar

9th December, 2010. University of Minnesota.

Exploring the Trade-offs between Functionality-rich Versus Minimalist Design: A Two-sided Market Analysis

Page 2: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Success of new network technologies depends on:– Technological factors– Economic factors (e.g. price, costs, demand)

• Design choices should reflect our understanding of these factors– Analytical frameworks– What are the ‘qualitative’ insights from the model?

• Some Dimensions for Assessing Network Technologies:

– Topic 1: • Network Technology Adoption/ Migration (NetEcon’08, ToN’10)

– How can a provider help its technology (service) to succeed?

– Topic 2: • Network Infrastructure Choice (ReArch’09, WEB’10, ISR)

– What infrastructure should the new technology (service) be deployed on?– Understanding Trade-offs between Shared and Dedicated networks

– Topic 3: • Trade-offs between Functionality-rich versus Minimalist Designs

Background

2

Page 3: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

Exploring the Trade-offs between Functionality-rich Versus Minimalist Design: A Two-sided Market Analysis

1. Research Motivation

2. Review of Two-sided Markets

3. Problem Formulation

4. Model

5. Solution Methodology

6. Results

7. Conclusions

Talk Outline

3

Page 4: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Networks are becoming akin to services– Evolving from physical to virtual infrastructures

– Helped by progress in new technologies • e.g. Virtualization, Cloud computing, IP Multimedia Subsystem platform

– Network platforms to serve as software ecosystems

– Growing number of Internet intermediaries are providing different kinds of development platforms• Google and Microsoft want to build web platform -the powerful layer of basic services on top of which

everyone else builds their web sites and services

• Network Platforms are characterized by two customer segments or market sides– Application (Service) Developers – Consumers

• Platforms providers have to provide built-in functionalities in the platform– e.g., API, tool boxes, software modules – Availability of these software modules, APIs help to reduce app development costs of developers– But adding functionalities comes at a cost– A trade-off between functionality-rich versus minimalist design exists

Research Motivation

4

Page 5: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

Related Work: Two-sided Markets (1)

5

Platform Infrastructure

Service Providers Users

Network Provider

F

bdpc

nd xc

Page 6: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Network externalities: Katz and Shapiro (1985), Farrell and Saloner (1985)

• Two-sided markets definition– Cross-side externality: Bakos and Katsamakas (2008) – focus on design and ownership of platforms– Two-side externalities: Yoo (2002) -focus on B2B markets– Violation of Coase Theorem: Rochet-Tirole (2004)- “ A market is two-sided if, holding constant the total of prices

faced by the two parties, any change in the price structure would affect participation levels and the number of interactions on the platform”

• Two-sided platforms: Economides and Tag (2009) – focus on net neutrality debate• Pricing and Social Efficiency: Hagiu (2006)• Competition in two-sided markets: Armstrong (2004)• Pricing, subsidies: Armstrong and Wright (2004)

• Most closely related to our work:– Bakos and Katsamakas (2008)– Two-side externalities: Yoo (2002)

• Our focus on the interaction of how investments in functionalities by platform affect the application development costs, and therefore the platform’s design

Related Work: Two-sided Markets (2)

6

Page 7: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Monopolist Platform Provider• Two-sides: Application Developers and Consumers

• Each market sides benefits from the participation of the other side– Cross-side externality benefits (e.g., Android, Xbox)

• Platform provider invests in platform functionalities – basic functionalities to `niche’ functionalities

• Trade-offs between platforms with functionality-rich and minimalist designs• Charges flat-fees to both market sides

Functionality Rich Design:– Pros:

• Attractive to developers• Indirect benefits to consumers• Allows platform to charge higher fees

– Cons:• Expensive to build

Minimalist Design:– Pros:

• Cheaper to build– Cons:

• Less attractive to developers• Indirectly less attractive to consumers• Lowers the platform’s profit potential

Problem Formulation (1)

7

Page 8: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Developers create Applications (services) and generate advertisement revenues

• Services can be differentiated but they use the same set of underlying functionalities

• Note: Competition among developer apps can be allowed in the model

– Can be captured through negative network externalities among developers

– These negative network externalities will be proportional to the number of other developers present

– Quantitative values change, but not the qualitative findings

• Platform provider knows about this set of functionalities needed by the apps

– But may or may not provide all of them: The design decision (functionality-rich/minimalist)

Problem Formulation (2)

8

Page 9: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• In innovating apps, Developers will:

– Use the functionality as is, if already provided by the platform

– Otherwise, write their own software code to enable that functionality for their service

– The latter comes at an application development cost for developers (presence of cost heterogeneity)

• Consumers are application (service) users

– Benefit from the number of available applications (developers) on the platform (can be heterogeneous)

– Are oblivious to who provided the code for the functionality (i.e. do not experience any difference in the quality of platform provided verses developer provided functionalities)

– App downloads are transaction free

Problem Formulation (3)

9

Page 10: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Timeline for a three stage sequential decision process is considered:

• Design Stage

• Platform decides the level of functionalities, F

• Pricing Stage

• Platform decides on the flat fees (prices) to be charged to the two sides, pc (consumers) and bd (developers)

• Adoption Stage

• A xc fraction of consumers and a nd fraction of developers join the network

• Consumers and developers who join are those that enjoy positive utility from joining the platform

Model Formulation

10

Design Stage(Platform provider

chooses F)

Pricing Stage(platform chooses flat

fees pc and bd)

Adoption Stage(nd developers and xc consumers join the

platform)

Decision Tim

eline

Dire

ction

of s

oluti

on

Page 11: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Platform charges flat fees to both market sides– Users pay subscription fees– Developers pay certification and licensing fees

• Platform provider incurs a functionality development cost, C(F)– Functionalities are added from most basic to `niche’ ones– C(F) is monotonically increasing in F– C(F) is convex (concave) if the marginal cost of adding sophisticated (niche) functionalities is

increasing (decreasing)

• Consider F to be large, so the set of F is mapped onto an interval [0, Fmax] such that C(F) is continuous on the interval

Model : Platform Utility (1)

11

)(FCnbxpU ddccp

Page 12: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• α captures value that a consumer generates for the developer (cross-externality)• It accounts for advertising revenue (e.g. Facebook app iLike gets revenue from iTunes, Ticketmaster)

• bd is the flat fee developers pay to the platform– Android charges $25 market developer fee, Apple charges $99 licensing fee to distribute apps and $299 for ‘enterprise

programmers’ (iOS developer program)

• K(F) captures the baseline app development cost when F functionalities are provided by the platform (developers have similar baseline expertise in developing apps)

• φτ captures the heterogeneity among developers in development cost for apps (e.g., fixed costs, employee benefits)

• All system parameters are normalized w.r.t. τ• Assume• Development cost, K(F)

– More built-in functionalities, lower is this cost– K(F) is monotonically decreasing in F– K(F) is concave (convex) if the marginal cost of developing sophisticated (niche) functionalities is

increasing (decreasing)

• Developer utility when same side externalities are considered

Model : Developer Utility (2)

12

))(( FKbxU dcd

))(( FKbnxU ddcd

]1,0[

Page 13: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• q captures stand-alone benefits the platform provides to consumer

• β captures the value that a developer generates for the consumer (cross-externality)• θ captures the heterogeneity among consumers in how much they value the available apps,

• pc is the flat fee consumers pay to the platform

• All system parameters are normalized

• In some platforms, consumers may value the stand-alone qualities or brand name more• We consider the following alternative utility function to account for the case where users are

heterogeneous in their evaluation of stand-alone benefits, while valuing their cross-externalities equally• e.g. most players of games platform value the available number of games but can be more subjective

about the console characteristics and hardware features (captured by q)

Model : Consumer Utility (3)

13

cdc pnqU

cdc pnqU

]1,0[

Page 14: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

Model: C(F) and K(F)

14

Page 15: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Amazon Web Services provides a variety of functionalities with available APIs – EC2 (computing), SimpleDB (database) Amazon S3 (storage), CloudFront

(content delivery)

• API complexity is a proxy for platform’s cost of building-in the functionality

• Forum Activity levels is a proxy for usefulness of the functionalities

• Functionalities that are most useful to developers are most difficult for platform to provide, `niche’ functionalities can be added at decreasing marginal cost to the platform.– Note the correlation in EC2, FPS, SimpleDB, RDS, SQS, SNS, DevPay

15

Source: http://www.elastician.com/2010/06/aws-by-numbers.html

Model : Examples (1)- Amazon Web Services

Page 16: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• IP Multimedia Subsystems Platform provides a way for delivering integrataed voice, video, data services in a reliable standardized services

• Low level APIs are developed by the platform first at high marginal costs, but low-level APIs are too complex for app developers to work with, and involves complexity of learning the platform architecture

• As High-level APIs are made available by the platform, the developers costs decrease significantly

16

Model : Examples (2)- IMS Platform

Page 17: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

17

Solution Methodology: Adoption Stage

*1ˆ

d

cc n

px

)(ˆ * FKbxn dcd

)(

)1(**

**

FKnxb

nxp

dcd

dcc

• Consumers and developers are assumed to be:• Rational• Incentive compatible• Make simultaneous adoption decision, given

pc, bd and F

• At equilibrium:

Design Stage(Platform provider

chooses F)

Pricing Stage(platform chooses flat

fees pc and bd)

Adoption Stage(nd developers and xc consumers join the

platform)

Decision Tim

eline

Dire

ction

of s

oluti

on

Page 18: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

18

Solution Methodology: Pricing Stage

10,10..

)(max

**

**

, **

dc

ddccpnx

nxts

FCnbxpUdc

8

)(4))(3(

16

))(4))(((

*

2*

FKb

FKp

d

c

Interior Solution:

Design Stage(Platform provider

chooses F)

Pricing Stage(platform chooses flat

fees pc and bd)

Adoption Stage(nd developers and xc consumers join the

platform)

Decision Tim

eline

Dire

ction

of s

oluti

on

8

)(4)(

22

*

*

FKn

x

d

c

Proposition 1: The optimal price levels (p*c, b*d) and the optimal adoption levels of consumers and developers (x*c, n*d) of the two-sided market, which maximizes the platform provider’s profit are given by:

Only Boundary constraints need to be satisfied, second order conditions are satisfied

Page 19: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

19

Solution Methodology: Design Stage

8

)(

2

)()(

)(

)( 2***

*

*

FK

FnFK

FCd

Proposition 2: The optimal level of built-in functionalities (F*) for the platform which maximizes its profit is given by:

Design Stage(Platform provider

chooses F)

Pricing Stage(platform chooses flat

fees pc and bd)

Adoption Stage(nd developers and xc consumers join the

platform)

Decision Tim

eline

Dire

ction

of s

oluti

on

)(2

)]([)()( *

2**** FK

FKFnFC d

Second order condition needs to satisfy:

)()(

)( ***

*

FnFK

FCd

At the optima, the participation level of developers equals the ratio of rate of change in the costs to the platform and the developers.

Page 20: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• Using the conjugate pair theorem, we have:

• Proposition 3: Increase in cross-externality benefits provides incentives for the platform to invest in built-in functionalities

• How does F* change with the cost functions C(F) and K(F), i.e. when should a platform create a functionality-rich / minimalist design?

Analysis (1): Impact of cross-externalities on platform design

20

0

0

2*

2*

F

Usign

Fsign

F

Usign

Fsign

p

p

Impact of α and β on F*

Page 21: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• AWS example scenario• K(F) convex, C(F) concave• Basic functionalities help developers a lot (K’(F) is large -ve), marginal value to developers

from ‘niche’ functionalities is decreasing (K’(F) is small -ve →0 as F increases)• Cost of adding basic functionality is large, marginal cost of adding ‘niche’ functionality

decreases• Multiple maxima (Depending on K(F), the design should be minimalist or functionality rich)• Counterintuitive: For the K’(F) that initially decreases faster and slowly later on

(i.e. K(F)=0.25e-0. 43*F) the platform will invest in higher functionality level

Analysis (2): Presence of Multiple Maxima

21

Page 22: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• K(F) convex, C(F) convex• Basic functionalities help developers a lot (K’(F) is large -ve), marginal value to developers from

‘niche’ functionalities is decreasing (K’(F) is small -ve →0 as F increases)

• Multiple maxima (Depending on K(F), the design should be minimalist or functionality rich)• Counterintuitive: For the K’(F) that initially decreases faster and slowly later on (i.e. K(F)=0.5e -0.194*F)

the platform will invest in higher functionality level

Analysis (3): Presence of Multiple Maxima

22

Page 23: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• K(F) concave, C(F) convex

• Design depends upon boundary values as well as the rate of change of K(F)

• Non-intuitive platform functionality design outcome

Analysis (4): Complex design decisions

23

Page 24: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• IMS scenario• K(F) concave, C(F) concave

• F* is on the boundary, platform will be either minimalist or functionality-rich depending on the Fmax

Analysis (5): Boundary values

24

Page 25: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

25

Alternative Utility Function: Robustness

2*

2*

)(4

)())(2()(

)(4

))()()(2(

q

FKqqb

q

FKqqp

d

c

Interior Solution:

2*

2*

)(4

))(2(

)(4

)()(2

q

qFKn

q

FKqx

d

c

Proposition 1: The optimal price levels (p*c, b*d) and the optimal adoption levels of consumers and developers (x*c, n*d) of the two-sided market, which maximizes the platform provider’s profit are given by:

Boundary constraints need to be satisfied, second order conditions require

cdc pnqU

2

2

q

)()(

)( ***

*

FnFK

FCd

Design Solution:

Page 26: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

26

Alternative Utility Function: Robustness (1)

Using the conjugate pair theorem, we again have:

Proposition 3: Increase in cross-externality benefits provides incentives to the platform to invest in built-in functionalities

Proposition 4: Increase in platform’s stand-alone benefits decreases platform’s need to invest in higher levels of built-in functionalities

0

0

2*

2*

F

Usign

Fsign

F

Usign

Fsign

p

p

0*

q

Fsign

Page 27: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• K(F) convex, C(F) convex

• Non-intuitive behaviors still present• For the K’(F) that initially decreases faster and slowly later on (i.e. K(F)=0.5e -0. 35*F) the

platform will invest in higher functionality level

Alternative Utility Function: Robustness (2)

27

Page 28: Soumya Sen Dept. of Electrical & Systems Engineering University of Pennsylvania ssoumya@seas.upenn.edu ssoumya Joint Work with: R.

• We provide an analytical framework to investigate trade-offs in platform design

• Multiple design optima may arise

• The design decision can be complex and non-intuitive

• Design decision is based not only on the rate of change in costs from adding functionalities, but also the relative rate of change in platform’s and developer’s costs, as well as boundary values

• Robustness analysis:– Alternative demand function– Non-linear externality functions

• The model can help in providing design guidelines for network platforms

• Potential for future exploration

Conclusions

28

Thank you!