HOPPERSTADCONSULTING

Market/Airline/Class (MAC) Revenue Management

AGIFORS RM 2003

HopperstadJune 03

2

HOPPERSTADCONSULTING

RM modeling assumptionsa short (public) history

• 80’s – leg/fare class demand independence 4 to 6% revenue gains over no RM

• 90’s – path (passenger itinerary)/class demand independence 1 to 2% revenue gains over leg/class RM

• Current – excursions into path demand independence< ½% revenue gain over path/class RM

3

HOPPERSTADCONSULTING

• Yet, everyone here knows that flights are picked on a market basis– trading-off airlines, paths, fares and fare class

restrictions

• Thus, an ultimate RM system must be market-based

• However, full-up market-based RM is a giant step– it is proposed here that a small next step is to assume

independent market/airline/class demand

RM modeling assumptions

4

HOPPERSTADCONSULTING

Subjects

• Background: PODS

• Functional form

• Some results

• Potential real-world application

• Lines of inquiry

5

HOPPERSTADCONSULTING

• PODS is a full-scale simulation in the sense that:– passengers by type (business/leisure) generated by

their• max willing-to-pay (WTP)• favorite/unfavorite airlines & the disutility attributed to unfavorite airlines• decision window & the disutility assigned to paths outside their window• disutility assigned to stops/connects• disutility assigned to fare class restrictions

– passengers assigned to best (minimum fare + disutilities) available path with a fare meeting their max WTP threshold

– RM demand forecasts based on historical bookings

Background: PODSpassenger origin/destination simulator

6

HOPPERSTADCONSULTING

• Leg/class baseline: Expected Marginal Seat Revenue (EMSRb)

• Three path/class RM systems available in the current version of PODS– Network bidprice (NetBP)– Prorated bidprice (ProBP)– Displacement adjusted virtual nesting (DAVN)

Background: PODS

7

HOPPERSTADCONSULTING

• EMSRb processes (virtual) classes on leg in fare class order– solves for the forecast demand and average fare for

the aggregate of all higher classes– obtains a protection level of the aggregate against the

class– sets the booking limit for the class (and all lower

classes) as the remaining capacity – protection level

Background: PODS

8

HOPPERSTADCONSULTING

• NetBP solves for leg bidprices (shadow price) using a network flow LP equivalent– path/class is marked as available if the fare is greater

than the sum of the bidprices of the associated legs

Background: PODS

9

HOPPERSTADCONSULTING

• ProBP solves for leg bidprices by iterative proration– prorate path/class fare by ratio of bidprices of

associated legs– for each leg order the prorated fares and solve a leg

bidprice using standard (EMSRb) methodology and re-prorate

– path/class is marked as available if the fare is greater than the sum of the bidprices of the associated legs

Background: PODS

10

HOPPERSTADCONSULTING

• DAVN uses the bidprices from NetBP as displacement costs and then for each leg– reduces path/class fare by the displacement from

other leg(s)– creates (demand equalized) virtual classes– uses standard (EMSRb) leg/class optimizer to set

availability

Background: PODS

11

HOPPERSTADCONSULTING

• Embed NetBP/ProBP/DAVN in a MAC shell rather than develop a new optimizer (for now)

• Use current PODS forecasters and detruncators– pickup and regression forecasting – pickup, booking curve and projection detruncation– aggregate path/class observations into MAC observations– a MAC is marked as closed only if all paths closed

• Assumption: all spill is contained within a MAC until all paths (of index airline) are closed for the class

Architecture

12

HOPPERSTADCONSULTING

• Bidprice engine (NetBP, ProBP)

Optimizers

*Rule: no path/class can be re-opened

yes

no

allocate MAC forecasts to associated path/classes

solve for leg bidprices

close path/classes with fares less than sum of bidprices for the associated legs*

re-allocate spill from newly closed path/classes to open path/classes

any new path/classes closed?

quit

13

HOPPERSTADCONSULTING

• Path/class availability solver (DAVN)

Optimizers

yes

no

allocate original MAC forecasts to associated path/classes and create virtual classes using final MAC bidprices

solve for leg/virtual class availability

close path/classes that have been assigned to closed virtual classes on associated legs re-allocate spill from newly closed

path/classes to open path/classes

any new path/classes closed?

quit

recalculate leg/virtual class demand

14

HOPPERSTADCONSULTING

• First-choice preference estimation for paths of a MAC– constructed from historical bookings for open paths– iterative procedure to account for partial observations

(not all paths open for a class)

• Assumption: second-choice, third-choice,…… preference can be calculated as normalized (removing closed paths) first-choice preference

Additional technology

15

HOPPERSTADCONSULTING

• Estimation of spill-in rate from, spill-out rate to competitor(s)– Key idea: equilibrium

• if the historical fraction of weighted paths open for time frame for the index airline (hfropa) and the competitor(s) (hfropc) is observed

• and if the the current fraction of weighted paths open is observed for both the index airline and the competitor(s) (fropa, fropc)

• then when fropc is less than hfropc, spill-in must occur• and when fropc is greater than hfropc, spill-out must occur

• Fraction of competitor paths open inferred from local path/class availability (AVS messages)

Additional technology

16

HOPPERSTADCONSULTING

• Competitor demand estimation– based on observed historical market share

(which is also a function of equilibrium)– uses booking curves to adjust for limited (input) time

horizon

• Spill-in/spill-out defined by adjusted competitor demand and maximum spill-in rate across classes

• Assumed that once MAC demand modified for spill to/from competitor, all spill is contained within a MAC

Additional technology

17

HOPPERSTADCONSULTING

• PODS network D– 2 airlines– 3 banks each– 252 legs– 482 markets– 2892 paths– 4 fare classes

• Demand – demand factor = 1.0– 50/50 business/leisure

Some results

20 CITIES

HUBAL 1

HUBAL 2

20 CITIES

18

HOPPERSTADCONSULTING

• Airline 1 uses one of the path/class systems– without a MAC shell– with a MAC shell

• Airline 2 uses the PODS standard leg/class system (EMSRb)

• Results quoted as % revenue gains compared to both airlines using EMSRb

Results 1

19

HOPPERSTADCONSULTING

Results 1

-1.50%

-1.00%

-0.50%

0.00%

0.50%

1.00%

1.50%

2.00%

2.50%

3.00%

3.50%

Airline 1

Airline 2

NetBP ProBP DAVN

+MAC +MAC +MAC

reve

nue

gain

20

HOPPERSTADCONSULTING

• Airlines 1 and 2 follow a sequence of RM improvements using DAVN– start with both using EMSRb– move 1: airline 1 adopts DAVN– move 2: airline 2 adopts DAVN– move 3: airline 1 adopts DAVN + MAC– move 4: airline 2 adopts DAVN + MAC

• Results quoted as % revenue gains compared to both airlines using EMSRb

Results 2

21

HOPPERSTADCONSULTING

Results 2

-1.00%

-0.50%

0.00%

0.50%

1.00%

1.50%

2.00%

Airline 1

Airline 2

AL1 DAVN AL2 DAVN AL1 MAC AL2 MAC

reve

nue

gain

22

HOPPERSTADCONSULTING

• Components of MAC revenue gain– optimizer (NetBP, ProBP, DAVN) by itself– MAC without spill-in/spill-out– MAC spill-in/spill-out

• Results quoted as % revenue gains compared airline 1 using EMSRb

Results 3

23

HOPPERSTADCONSULTING

Results 3

NetBP ProBP DAVN0.00%

0.50%

1.00%

1.50%

2.00%

2.50%

3.00%

3.50%

MAC spill

MAC

Optimizer

reve

nue

gain

Note: Mac spill gain dominated by spill-in compared to spill-out

24

HOPPERSTADCONSULTING

• Can’t say how difficult

• But can propose it will provide for a new level of technical integration of RM and the rest of the airline– use of external path preference models to determine first-

choice preference, conditional second, third,…. preference and account for the effect of schedule changes

– use of external marketing data, econometric models, etc. to define at least components of market demand

Potential real-world application of MAC

25

HOPPERSTADCONSULTING

• New optimizer that integrates the MAC arguments– rather than embedding in a shell

• Model vertical/diagonal buy-up– requires the new optimizer

• Market-based RM– pessimistic unless competitor RM itself is modeled

Lines of inquiry