Posted on June 27, 2013 @ 08:10:00 AM by Paul Meagher
The underlying process that generates revenue for a line-of-business can be stationary or non-stationary in nature. A stationary revenue process is one in which the parameters for the probability distribution representing a revenue factor (e.g., average lobster price) is specified once for the period that your revenue model covers. A non-stationary revenue process is one in which you must specify the parameters multiple times (e.g., average lobster catch size) during the period that your revenue model covers. In my last blog I argued that in order to construct a more realistic revenue model for a lobster fishing season, we should take into account the fact that lobster catch sizes diminishes over the course of a season because the rate of extraction from the lobster fishing grounds exceeds the rate of replenishment as the season progresses. I argued that an exponential decay function is a useful function to use to represent how the catch size diminishes over the course of a season. I showed a worked example of the math required to estimate the relevant decay parameter k that captures how the catch size decreases over the course of the season.
In this blog, I want to illustrate how to integrate this non-stationary factor (i.e., catch size) into our lobster fishing revenue model. The essential observation is that we cannot be content to set the parameters of our catch size distribution (average catch size and standard deviation) only once, but instead need to set these parameters multiple times as we iterate through each catch of the season. In other words, the catch size distribution that we sample from changes after each catch; specifically, the mean and standard deviation parameters are reduced by a constant percentage after each catch. This better represents the true state of affairs with respect to how revenue is generated over the course of a lobster fishing season. Our first attempt at creating a revenue model for a lobster fishing season assumed that the lobster catch-size distribution was stationary over the course of a fishing season. Now we are assuming it is non-stationary so that we can construct a more realistic revenue model.
The new script that I developed to model lobster fishing is called lobster_revenue_with_decay.php and the code for that model is illustrated below. I was also informed that instead of the lobster season consisting of 28 trips, it will consist of around 40 trips this season so that is one other change to the revenue model I presented previously.
What is critical to note in this code is that we set the parameters of our $lobster_catch_distribution multiple times according to our exponential decay function for the mean catch size and the standard deviation of the catch size. In general, a non-stationary process involves re-setting parameters inside the loop that generates revenue for each time unit in your model. In contrast, the parameters for the $lobster_price_distribution is only set once outside the loop and remains constant for each time unit of the model. This structure will be common to all revenue models that consist of stationary or non-stationary factors that determine revenue.
This is what the output of our new lobster fishing revenue model looks like.
Catch # |
Price/LB |
Weight(LB) |
Revenue |
1 |
$3.57 |
629 |
$2245.53 |
2 |
$3.67 |
853 |
$3130.51 |
3 |
$3.67 |
1065 |
$3908.55 |
4 |
$3.33 |
819 |
$2727.27 |
5 |
$3.50 |
848 |
$2968.00 |
6 |
$3.49 |
1075 |
$3751.75 |
7 |
$3.72 |
1038 |
$3861.36 |
8 |
$3.75 |
933 |
$3498.75 |
9 |
$3.57 |
756 |
$2698.92 |
10 |
$3.58 |
731 |
$2616.98 |
11 |
$3.54 |
610 |
$2159.40 |
12 |
$3.29 |
822 |
$2704.38 |
13 |
$3.56 |
757 |
$2694.92 |
14 |
$3.31 |
501 |
$1658.31 |
15 |
$3.59 |
644 |
$2311.96 |
16 |
$3.35 |
649 |
$2174.15 |
17 |
$3.34 |
718 |
$2398.12 |
18 |
$3.61 |
415 |
$1498.15 |
19 |
$3.22 |
842 |
$2711.24 |
20 |
$3.28 |
626 |
$2053.28 |
21 |
$3.49 |
464 |
$1619.36 |
22 |
$3.48 |
588 |
$2046.24 |
23 |
$3.37 |
234 |
$788.58 |
24 |
$3.42 |
530 |
$1812.60 |
25 |
$3.88 |
256 |
$993.28 |
26 |
$3.05 |
321 |
$979.05 |
27 |
$3.43 |
575 |
$1972.25 |
28 |
$3.37 |
420 |
$1415.40 |
29 |
$3.23 |
554 |
$1789.42 |
30 |
$3.35 |
420 |
$1407.00 |
31 |
$3.55 |
498 |
$1767.90 |
32 |
$3.63 |
305 |
$1107.15 |
33 |
$3.44 |
407 |
$1400.08 |
34 |
$3.24 |
335 |
$1085.40 |
35 |
$3.00 |
455 |
$1365.00 |
36 |
$3.53 |
359 |
$1267.27 |
37 |
$3.79 |
242 |
$917.18 |
38 |
$3.31 |
177 |
$585.87 |
39 |
$3.43 |
440 |
$1509.20 |
40 |
$3.74 |
293 |
$1095.82 |
|
Totals |
23204 |
$80695.58 |
What you should note about this output is how the revenue is greater at the beginning of the season than towards the end of the season. This gives us a better sense of what type of cashflow to expect over the season. It conforms better to the day-to-day revenue expectations a fisherman has over the course of a lobster fishing season.
Conclusion
In this blog I've illustrated how stationary and non-stationary factors are included in a revenue model. Although I am focusing on a lobster fishing example, the programmatic lessons about how to incorporate stationary and non-stationary factors into a revenue model is more general and you can use this model as a template for constructing a revenue model for your own line-of-business. When specifying the non-stationary component of your revenue model you have many choices as to what function might be used to determine the parameter settings for probability distribution representing that component. I used an exponential function but there are a large number of other possible functions you might use. One common function would be a sine wave function if your revenue model has a seasonal component. Gompertz functions are often used in situations where the sales are brisk at first then die off rapidly thereafter, such as happens when a new movie is released. Piecewise linear functions are also very useful and flexible.
I'm not quite done with revenue modelling as there is one more aspect that I want to add to the lobster-fishing model make it more realistic. Stay tuned for my next blog to find out what else we might do to make our revenue models more realistic.
|