[ Main page | About Your System | Knowledge Bases | Rule Traces | Demand Modelling | About Fuzzy Logic | The Importance of Explainability | Commercialising ]
I have built a simulation of dynamic pricing, showing how this can be controlled by an expert system. As explained on the main page, this is not yet a commercial product but an MVP — Minimum Viable Prototype. However, it could be scaled up to a commercial product. I have ensured that it needs no specialist knowledge to understand, so it should be easy for you to explain to the government inspectors. For further information about fuzzy logic and how the expert system works, please see About Fuzzy Logic . These are explained on a somewhat less technical level in Knowledge Bases and Rule Traces.
To access the system, please go to https://expertsystemdemos.net/sim_dp.html . Do this on a laptop or desktop computer rather than a phone, as the simulation needs ample screen space for controls, charts, and diagnostics.
Note that the simulation concerns airline flights. I realise that you may be interested in pricing a different type of product or service. I chose flights because they are an everyday topic that everyone understands, and that you can easily explain. The same principles will apply elsewhere. These include market segmentation, sensitivity to time before purchase and to capacity utilisation, sensitivity to special features (such as events, in the simulation), and the use of demand modelling versus of explicit other variables. More generally, fuzzy logic can help you code reactions to any price-related variable, in a way that is easy to read and explain to other people. Use of the Prolog AI language in ancillary areas, as in my demand modelling, gives other benefits. It is more concise than languages such as Java and Python, easier to analyse mathematically, closer to logic, and relatively easy to interface with machine-learning software.
When you first load this page, you
will see a page with green buttons at
the top, and some largely empty boxes below.
It looks like this, possibly with
adjustments for browser size:
The simulation generates nine-week (63 day) scenarios of events in Alpenstadt, a fictitious Bavarian city similar to Munich. The idea is that at the start of this period, a traveller decides to fly from the small rural airport of Oxford Kidlington in the UK, to Alpenstadt.
Once a scenario is generated, you can demonstrate dynamic pricing by asking the price of the travel ticket for any date within the 63 days. There are seven knowledge bases, each with a different slant on how to calculate the price.
Each knowledge base reacts to various input variables, such as days until flight. You can set these with the controls explained below.
One knowledge base reacts directly to demand. The simulator calculates this by generating events within Alpenstadt. They are: Christmas; Easter; Alpenfest, a festival similar to, and on the same dates as, Oktoberfest; skiing season; and assorted trade and business fairs, concerts, and other cultural events. They get plotted as green blocks in the diagram at the top of the chart area. Each one has a name, shown in a label starting above and at the left of its block.
Demand charts for the first four events (if there are that many) get plotted under this diagram. The demand calculations are described in Demand Modelling. The input variable used by the knowledge base is total demand. You can imagine working this out by slicing all the demand charts with the draggable green vertical bar, and summing the Y values on the curves it intersects.
Pricing any product or service is likely to involve combining a similar variety of features. As you look at the event charts, it is worth asking how they correspond to the features of interest to you. That, indeed, is one reason I included them.
There is important information at the foot of the draggable green bar, on its right. This includes the start date for the timeline, the current date, and the end date for the timeline. You can see these on the screenshot above, and confirm that the start and end dates are nine weeks apart.
The fourth line at the foot of the draggable green bar
is a listing of input variables.
As I have introduced these by talking about their display, it's appropriate to explain them. The simulator indicates them by emoji, here and on other parts of the screen. They are:
Unlike the other variables, this is categorical, not numerical.
This varies from 62 to 0, and depends on the position of the draggable bar.
This is a measure of how efficiently the airline is using its space. It varies from 0% to 100%.
This is the total demand mentioned above. More strictly speaking, it is the increment above baseline demand that the sum of all events at this date adds. It varies between 0% and around 200%. See Demand Modelling.
This is used with total demand, to modulate price depending on worries about, say, sudden outbreaks of Covid. It varies from 0% to 100%.
Again, this is used with total demand. It enables you to make the aggregate events more or less popular than they would otherwise be, for example assuming the sudden visit of a star entertainer. It varies from -100% to 100%.
This section is about the controls
at the top of the screen area.
This is the button on the left. Press it to generate a new scenario. The knowledge bases will not work unless you do this. It will be apparent if a scenario is loaded, because the area at the foot of the draggable bar will be populated, as above. There will probably also be event charts and an event block diagram.
This is the button next right. Pressing it toggles travel class between tourist and business. The new value will be visible as the leftmost emoji at the foot of the draggable bar. It is only used by knowledge bases three, four, and six, but you can change it at any time.
This is only used by the fifth and sixth knowledge bases. However, you can change it at any time. It is changed by the third control, a radial menu with a spin box. Click one of the five numbers to get a coarse setting. The spin box will update accordingly. If necessary, use it to make fine changes. The new value will appear at the foot of the draggable bar after the πͺ emoji.
This is only used by the seventh knowledge base. Change it via the second radial menu, the same way as above.
This also is used by the seventh knowledge base. Change it via the third radial menu.
This largest control contains the names of the seven knowledge bases. To use it, make sure you have loaded a scenario. Adjust your inputs if necessary. Then click the appropriate option. These are summarised below, and described in more detail in Knowledge Bases. A rule trace will appear in the panel on the right. If there already are rule traces there, it will be appended. For how to interpret it, please see Rule Traces.
This control is to the right of the knowledge-base menu. It controls the number of digits after the decimal point used to display fuzzy-set memberships and calculated prices in the rule trace. The default of two is normally enough, but you can select more if you think that, say, a value is close to zero but not quite at it.
Pops up a picture of Alpenstadters enjoying themselves at Alpenfest.
As just mentioned, the seven knowledge bases are run by the big radial menu with the seven rows of emoji on it. They are described in detail in Knowledge Bases. Below is a summary.
Linked from here. The knowledge base reacts
to one input variable, days_to_flight, demonstrating
time sensitivity.
Linked from here. This knowledge base also reacts
to days_to_flight. It takes into account last-minute
purchases, which the other didn't, and also gives a more nuanced
rise in prices as the flight date draws nearer.
Linked from here. This knowledge base
reacts to the input variable class, demonstrating
market segmentation.
Linked from here. This knowledge base combines Days To Flight and Tourist Or Business, demonstrating how rules allow input variables to be combined.
Linked from here.
This reacts to
capacity_utilisation, the proportion of a flight's seats
that are occupied or sold at any given time. Unlike the variables
above, capacity utilisation will not usually be visible
to a customer. The knowledge base shows that one
can react to such hidden variables as easily as
to those that are visible.
Linked from here.
This reacts to
capacity_utilisation and also to
days_to_flight and to class. It is a more
complex example of combining variables.
Linked from here. This knowledge
base marks a change in modelling style. Suppose we wanted to adjust price
according to how popular the expected weather at this
time of year makes each event. We could introduce a
weather variable, then have rules which loop
over all the events applying it to each. Similarly for other variables.
That could be done, and I did consider it as another demo. Unfortunately, there wasn't enough time. But in any case, it would be hard to integrate with other sources of data, such as how competitors are allocating seats, and how your seats fared in previous years. So instead, we could subsume all of these into a demand variable. This is what is assumed here. The knowledge base reacts to total demand, tweaked by health concerns and event popularity change.