Uses of Lifetime Value - Part 6: Final Thoughts

These past five posts have been a jolly romp through the delights of lifetime value. I think the main applications have been laid out clearly enough that I need not review them here in any detail. (For the record, they are: LTV itself, LTV components, comparisons of components, forecasts based on components, and, somewhat tangentially, simulation models.) But there have been several underlying themes that might benefit from explicit elucidation (plus I just like the word ‘elucidation’).

The Lifetime Value measure that counts is really aggregate Lifetime Value. That is, when we talk about trying to increase lifetime value, we usually want to increase the sum of the lifetime values of all customers (i.e., average lifetime value x number of customers). Since lifetime value is really future cash flow, this is simply saying we want to maximize the future cash flow of the company. Nothing radical about that. But it’s one of those things that are so obvious that you sometimes forget about them. Then you find yourself watching the wrong metric, such as LTV per customer. If the difference isn’t clear, think about acquisition programs: assuming the same cost, a program that brings in 100 customers worth $5 each ($500 LTV) is more valuable than one that brings in 50 customers worth $6 each ($300 LTV).

There are many ways to define Lifetime Value and the value of each is constantly changing. I went through this in some detail yesterday so I won’t repeat myself here. What’s important is to recognize that lifetime value is highly dynamic, so you can’t safely put a single figure in your head and apply it in many situations. Instead, you have to consider the purpose of each analysis and make sure you apply a definition that is appropriate. Then you have to remember that the value based on that definition will almost certainly change tomorrow—so don’t fool yourself into thinking any LTV figure is meaningfully precise.

Lifetime Value figures can be broken down by year. Again, see yesterday’s discussion of value buckets for the details. Sometimes a consolidated long-term figure such as “five year net present value” is the right one to look at, but often you really want to know about a shorter time frame. You don’t need to ignore lifetime value in those situations; you simply need to expose the time-sliced details that were used to generate the long-term value. The obvious example here is comparing actual LTV components against planned values: by looking at the one year component within the LTV calculations, you can isolate results during the past year. Otherwise, you risk being confused by figures that also include estimates for activities in the future.

You need a LTV system. I’ve referred to this numerous times without describing it explicitly. But it’s obvious you need some way to generate all those permutations of LTV: the different definitions (past, future, total); the different time periods; the different segments (defined ad hoc, no less); the time slices within each value; and so on. Basically, the LTV system I have in mind (and, yes, I’ve built them) captures historical information at the customer or granular segment level, and then lets you combine the data on demand to generate the various LTV values and components for whatever segments you create. Reports should include and compare multiple segments, such as customers from different sources or start years. Users should also be able to import plan or forecast values generated by an external modeling system, and compare actual results against these as well. The key to all this is that the LTV calculations must be performed automatically, without hand-tuning by an analyst. This places some limits on the sophistication of the calculations themselves, but that’s a small price to pay for the flexibility of on-demand results.

A simulation model is separate from the LTV system. Simulation models are very important for building business plans, creating forecasts, understanding relationships among interactions, and optimizing customer treatments. Model outputs can also include LTV figures and components. Within some constraints, a simulation model could also use LTV values as inputs and calculate the model assumptions (e.g. attrition rates) needed to generate those values. But despite these connections, the simulation model is quite distinct from the LTV system: it does different things in different ways. My earlier posts may have clouded this separation.

Project assessments must be based on incremental impact. This applies more to simulation models than LTV analysis, but it’s still important. The value of any project—marketing, customer service, manufacturing, whatever—is judged in comparison with the result of not doing that project. This is a particular challenge where customer treatments are concerned, since many factors affect customer behavior and it’s hard to isolate the effect of one change. The connection with LTV is two-fold: first, change in LTV should be the ultimate metric to judge the value of any change; and, second, a good LTV system may make it easier to compare the performance of treated vs. non-treated segments (assuming these can be isolated in the first place). But the main reason to bring up this issue is simply to point out that predicting or measuring incremental impacts is inherently difficult, regardless of whether you use LTV.

LTV components are good key performance indicators, but not the only ones. LTV components are good KPIs because they can be linked to real financial value (aggregate LTV). This means the impact of any change can be calculated directly, simplifying prioritization and helping managers to understand how different components are related. But it doesn’t follow that every KPI should have a measurable impact on LTV. Some important measures have no direct connection: imagine, for example, tracking the status of system development projects or employee training programs. These activities will eventually have a financial impact, but cannot be directly tied to their results. So, despite the superficial attractiveness of the notion, there is in fact no reason to insist that only LTV components be used as KPIs.

Multiple LTV applications reinforce the value of LTV as a management tool. This is the ultimate point of this series of posts. The more ways LTV is used throughout the company, the more everyone will focus on customer value. On a financial level, broader usage of an LTV system will help to justify its costs. But the real benefit is having people throughout the company share an understanding of the importance of customer value and of how their activities contribute to it. The more they care about customer value, the more successful the company will be.