Cost Optimization and Technology Financial Management Questions

Direct answer

The net saving is $20,000 - $3,000 = $17,000 a month, so simple payback (the time until cumulative savings equal the upfront cost) is $500,000 / $17,000 = 29.4 months, about 2.45 years. Payback misleads when benefits arrive after the payback date, when two options are being ranked, when savings have a short life, or when money later is worth less than money now. NPV (net present value, the sum of future cash flows each divided by (1 + discount rate) raised to its time, minus the upfront cost) captures all of those. Payback is a fast liquidity check and a poor ranking tool.

Working

• Both figures are monthly, so the comparison is like for like: gross saving $20,000 a month (hosting and operations) minus added cost $3,000 a month (cloud monitoring and support) = $17,000 a month net.
• Payback = $500,000 / $17,000 = 29.4 months. In years, 29.4 / 12 = 2.45.
• The calculation assumes the saving starts in month 1. If the first three months are dual running (both estates paid for), payback moves out by roughly three months or more.

When payback misleads, and what NPV shows

Take an 8% annual discount rate (illustrative; use the organisation's hurdle rate, the minimum return it requires for a project of this risk), converted to a monthly rate of 1.08^(1/12) - 1.

r_annual = 0.08
r_m = (1 + r_annual) ** (1 / 12) - 1          # equivalent monthly discount rate

def npv(upfront, monthly_flows):
    return -upfront + sum(f / (1 + r_m) ** (t + 1) for t, f in enumerate(monthly_flows))

net_saving = 20000 - 3000                      # USD per month
print(f"simple payback: {500000 / net_saving:.1f} months")
for years in (2, 3, 5, 10):
    print(f"Migration A, savings last {years:>2} yrs: NPV = {npv(500000, [net_saving] * (12 * years)):>10,.0f}")
# Project B: pays back faster but its savings stop after 12 months
print(f"Project B payback: {500000 / 45000:.1f} months, NPV = {npv(500000, [45000] * 12):,.0f}")

Output:

simple payback: 29.4 months
Migration A, savings last  2 yrs: NPV =   -123,061
Migration A, savings last  3 yrs: NPV =     44,737
Migration A, savings last  5 yrs: NPV =    343,963
Migration A, savings last 10 yrs: NPV =    918,351
Project B payback: 11.1 months, NPV = 18,079

Other cases where payback misleads: benefits ramp up slowly (a later, larger benefit is penalised by a cutoff rule), cash flows change sign again later (a hardware refresh or contract renewal in year 4), the risk differs between options (one saving is contractual, the other depends on traffic), and the organisation applies an arbitrary cutoff ("must pay back inside 24 months") that rejects a high-NPV project.

Recommendation

Quote payback as the simple answer (29.4 months), then state the life of the savings. If the savings plausibly last five years or more, the NPV of about +$344,000 says to proceed. If the hosting contract or the hardware being replaced limits the savings to three years, the case is marginal and I would ask what else justifies it. For ranking several projects, use NPV (or discounted payback, which discounts the flows before counting months) and keep simple payback as a cash-exposure check.

Pitfalls

• Mixing bases: a monthly saving against an annual cost, or net against gross.
• Forgetting costs that begin after go-live (support tier, monitoring) or that end (old licences).
• Reporting NPV without the discount rate and the life assumed. Both change the answer, as the table shows.

Direct answer

Annual TCO (total cost of ownership: all the costs of running the product for a year) per monthly active user (MAU, someone who used the product at least once in a month) is $1,200,000 / 120,000 = $10.00 a year, or about $0.83 a month. Daily actives (DAU, users active on a given day) are a quarter of MAU, so 30,000, and the TCO per DAU is $1,200,000 / 30,000 = $40.00 a year, about $3.33 a month. Per-user cost sets the price floor, shows how much the free tier costs to carry, and tells you which customers to pursue, but only if you also split fixed from variable cost and look at usage by segment.

The calculation

tco, mau = 1_200_000, 120_000
dau = mau // 4
print("TCO per MAU per year:", tco / mau, "per month:", round(tco / mau / 12, 2))
print("DAU:", dau, "TCO per DAU per year:", tco / dau, "per month:", round(tco / dau / 12, 2))
# Scale effect: assume 70% of TCO is fixed, 30% scales with users; MAU grows 10%
fixed_share = 0.7
new_mau = int(mau * 1.1)
new_tco = tco * fixed_share + tco * (1 - fixed_share) * 1.1
print("new TCO:", round(new_tco), "added:", round(new_tco - tco), "per MAU:", round(new_tco / new_mau, 2))
# Free tier: only 40,000 of the 120,000 MAU pay
paying = 40_000
print("break-even price per paying user per year:", tco / paying, "per month:", tco / paying / 12)

TCO per MAU per year: 10.0 per month: 0.83
DAU: 30000 TCO per DAU per year: 40.0 per month: 3.33
new TCO: 1236000 added: 36000 per MAU: 9.36
break-even price per paying user per year: 30.0 per month: 2.5

The DAU figure is four times the MAU figure because the daily-to-monthly ratio (stickiness) is 25%. Neither is "the" right denominator: MAU matches how most products are priced and counted, while DAU describes the users who actually generate the load.

How per-user cost should influence pricing and go-to-market

1. Price floor. The price floor is the lowest price that still covers cost, and it depends on how many users pay. If every one of the 120,000 MAU paid, any price below $10 per MAU per year would lose money on a fully loaded basis, and a price of exactly $10 only breaks even ($1,200,000 of revenue against $1,200,000 of cost). Because this TCO covers everything, a $15 price would give a 33% margin ((15 - 10) / 15, the share of the price left after cost). That $10 floor holds only if everyone pays.
2. Free tier economics. In a freemium model (a free tier funds the product and a share of users pay) the paying users must cover everyone's cost. If only 40,000 of the 120,000 MAU pay, a conversion rate (share of users who become paying) of 33%, the real floor is $1,200,000 / 40,000 = $30 per paying user a year, $2.50 a month. At $15 each, 40,000 payers bring in $600,000 against $1,200,000 of cost, a $600,000 loss, so $30, not $10, is the floor that applies with this free tier. Free users are a marketing cost, so the conversion rate and the cost to serve a free user decide whether freemium is sustainable.
3. Fixed versus variable cost. Fixed costs (committed infrastructure, salaries) do not grow when users do, while variable costs (usage-driven compute) do. If 70% of TCO is fixed ($840,000, an assumption to be replaced with the real split) and 30% variable ($360,000), a 10% rise in MAU raises only the variable part by 10%, so it adds only $36,000 of cost and the unchanged $840,000 is spread over 132,000 users, which lowers cost per MAU from $10.00 to $9.36, a 6.4% drop. Growth is cheap, so go-to-market (how you sell and launch the product) investment is justified, but the opposite holds if cost scales with usage.
4. Segment by usage. Average cost hides heavy users. If daily users consume most of the compute, a flat price subsidises them and a usage-based price (charged per unit consumed) or a tiered price (steps by plan size) protects margin.
5. Go-to-market focus. Pursue segments with high revenue per user relative to cost per user, and raise stickiness (DAU/MAU, how often monthly users come back daily), since it increases value delivered per user without adding a user.

Pitfalls

• Treating average cost as marginal cost. Pricing a new customer uses the incremental cost of serving them.
• Quoting the fixed share as fact. It is the assumption the scale result is most sensitive to: at 40% fixed the same 10% growth lowers cost per MAU only to $9.64 (a 3.6% drop) instead of $9.36.
• Mixing bases: monthly price against annual cost, or per-DAU cost against a per-MAU price.

Direct answer

Discounted TCO (total cost of ownership in today's money) is the upfront capital plus each year's run cost, grown at the cost growth rate and divided by (1 + discount rate) raised to the year. I write one pure function (it uses only its inputs and returns a result, with no hidden state or side effects) that prices a single option, and a second function that runs it for both options across named scenarios and reports the cheaper option in each, so the scenario table is the product and the first function is the engine.

Approach

• Convention (stated so a reader can reproduce it): capital is paid at time 0; the run cost in year t is annual_run x (1 + growth)^(t - 1), paid at the end of year t and discounted by (1 + rate)^t.
• A scenario is a (discount rate, horizon in years) pair. The scenario function loops over scenarios, calls the TCO function for both options and compares.

Code

def discounted_tco(capex, annual_run, growth, rate, years):
    """Upfront cost at time 0 plus run costs for years 1..years.
    Run cost in year t is annual_run * (1 + growth) ** (t - 1),
    paid at the END of year t, discounted by (1 + rate) ** t."""
    if years < 0 or rate <= -1:
        raise ValueError("years must be >= 0 and rate > -1")
    total = capex
    for t in range(1, years + 1):
        total += annual_run * (1 + growth) ** (t - 1) / (1 + rate) ** t
    return total


def compare_scenarios(option_a, option_b, scenarios):
    """option_* = (capex, annual_run, growth). scenarios = {name: (rate, years)}.
    Returns a list of (scenario, tco_a, tco_b, cheaper)."""
    rows = []
    for name, (rate, years) in scenarios.items():
        a = discounted_tco(*option_a, rate, years)
        b = discounted_tco(*option_b, rate, years)
        cheaper = "A" if a < b else "B" if b < a else "tie"
        rows.append((name, a, b, cheaper))
    return rows


if __name__ == "__main__":
    on_prem = (500_000, 120_000, 0.05)   # capex, year-1 run cost, run-cost growth
    cloud = (0, 260_000, 0.02)
    scenarios = {
        "base (8%, 5y)": (0.08, 5),
        "high rate (14%, 5y)": (0.14, 5),
        "long horizon (8%, 10y)": (0.08, 10),
        "short horizon (8%, 3y)": (0.08, 3),
        "zero rate (0%, 5y)": (0.0, 5),
    }
    print(f"{'scenario':<24}{'A on-prem':>12}{'B cloud':>12}  cheaper")
    for name, a, b, cheaper in compare_scenarios(on_prem, cloud, scenarios):
        print(f"{name:<24}{a:>12,.0f}{b:>12,.0f}  {cheaper}")
    print(discounted_tco(100, 0, 0, 0.1, 5))
    print(discounted_tco(0, 100, 0, 0.0, 3))

Output

scenario                   A on-prem     B cloud  cheaper
base (8%, 5y)              1,025,537   1,077,185  A
high rate (14%, 5y)          949,519     924,246  B
long horizon (8%, 10y)     1,482,026   1,886,602  A
short horizon (8%, 3y)       824,160     682,842  B
zero rate (0%, 5y)         1,163,076   1,353,050  A
100.0
300.0

The last two lines are hand-checkable: 100 of capital with no run cost is 100.0 at any rate, and 100 a year for 3 years at a 0% rate is 300.0.

One real case by hand, A (on-premises) in the base scenario at 8% over 5 years. Year t run cost is 120,000 x 1.05^(t - 1), discounted by 1.08^t. Year 1: 120,000 / 1.08 = 111,111. Year 2: 126,000 / 1.08^2 = 108,025. Year 3: 132,300 / 1.08^3 = 105,024. Year 4: 138,915 / 1.08^4 = 102,107. Year 5: 145,861 / 1.08^5 = 99,270. These sum to 525,537; adding the 500,000 of capital paid at time 0 (not discounted) gives 1,025,537, the first row of the output.

Reading the result

Option A (on-premises: $500,000 upfront, $120,000 a year growing 5%) wins at the base case, over a long horizon and at a 0% rate, because its capital is spread over many years of cheaper running. Option B (cloud: no capital, $260,000 a year growing 2%) wins when the discount rate is high (future costs shrink, so avoiding the upfront payment matters more: going from 8% to 14% cuts B's total from 1,077,185 to 924,246, a drop of 152,939, but A's only from 1,025,537 to 949,519, a drop of 76,018, because A's 500,000 is paid at time 0 and is never discounted) and when the horizon is short (A's capital is not amortised). The conclusion therefore flips on two assumptions, rate and horizon, which is what the scenario function exists to expose.

Key points

• The function is pure (no globals, no input or output), so it is testable; the two printed sanity checks are the start of a test suite.
• Growth is passed per option: on-premises costs often escalate (maintenance, staffing) while cloud prices may be flat or falling.
• A tie is reported as "tie"; with floating-point inputs compare with a tolerance (Python's math.isclose, which treats two decimals as equal when they differ by a tiny amount) if exact equality matters.

Complexity

Each TCO call is O(years) time and O(1) memory (work grows in step with the number of years; memory stays constant); the scenario function is O(S x years) for S scenarios (work grows with scenarios times years), since it calls the TCO function twice per scenario.

Edge cases

• years = 0 returns the capital alone.
• rate = 0 is valid (an undiscounted sum); rate <= -1 would divide by zero or flip signs, so the function raises ValueError. Negative growth (falling run costs) is allowed.
• Not modelled: tax, resale value, mid-year payment timing, staffing curves, uncertainty. For uncertainty, replace the fixed scenarios with sampled inputs (random draws from assumed ranges) and report the share of runs in which each option is cheaper.

Direct answer

Score the overlapping BI (business intelligence) tools against a weighted rubric (cost, fit, integration effort, vendor support) after a pass/fail gate for must-haves like security and compliance, keep the best fit, and retire the others in order of lowest risk and nearest contract end, only after their critical content has been rebuilt. Put a number on soft benefits such as analyst productivity, but count them separately from hard savings and discount them for how many freed hours are really redeployed.

Deciding which to keep

1. Inventory the overlap. Tool, owner, licence cost and renewal date, active users, and what each is actually used for.
2. Gate first. Any tool that fails a must-have (data residency, security review, a required feature) is out regardless of score.
3. Score the rest on the rubric below, with weights agreed with stakeholders before anyone sees the scores.
4. Test the ranking. Change the weights and see whether the winner changes. If it does, the decision is a values question, not a data question, and it should be taken by the sponsor.

Worked example (illustrative scores and prices)

# Illustrative scoring of three overlapping BI tools. Scores 1-5 (5 = best). Weights sum to 1.
weights = {"cost": 0.30, "fit": 0.35, "integration_effort": 0.20, "vendor_support": 0.15}
tools = {
    "Tool X": {"cost": 2, "fit": 5, "integration_effort": 4, "vendor_support": 4},
    "Tool Y": {"cost": 4, "fit": 3, "integration_effort": 3, "vendor_support": 3},
    "Tool Z": {"cost": 5, "fit": 2, "integration_effort": 2, "vendor_support": 2},
}
assert abs(sum(weights.values()) - 1) < 1e-9
for t, s in tools.items():
    print(t, round(sum(weights[k] * s[k] for k in weights), 2))

# Savings: hard vs soft kept separate
annual_licence = {"Tool X": 120_000, "Tool Y": 60_000, "Tool Z": 40_000}
retire = ["Tool Y", "Tool Z"]
hard = sum(annual_licence[t] for t in retire)
migration_one_off = 45_000
# Soft: analysts stop maintaining duplicate dashboards
analysts, hours_saved_per_week, weeks, loaded_rate = 12, 2, 46, 70   # USD per hour, loaded
soft_gross = analysts * hours_saved_per_week * weeks * loaded_rate
realisation = 0.5   # only half of freed hours turn into other useful work (assumption)
soft = soft_gross * realisation
print("hard annual saving:", f"{hard:,}")
print("one-off migration:", f"{migration_one_off:,}", "payback months on hard only:", round(migration_one_off / hard * 12, 1))
print("soft gross:", f"{soft_gross:,.0f}", "soft counted:", f"{soft:,.0f}")

Tool X 3.75
Tool Y 3.3
Tool Z 2.9
hard annual saving: 100,000
one-off migration: 45,000 payback months on hard only: 5.4
soft gross: 77,280 soft counted: 38,640

Tool X wins at 3.75 even though it is the most expensive, because fit carries the heaviest weight (0.35). The decision is sensitive to that weight: with cost weighted 0.50, fit 0.20 and integration effort and vendor support 0.15 each, X scores 3.2 and Y and Z both score 3.5, and X loses first place. That is why the weights are agreed first and the sensitivity is shown.

Retiring Y and Z saves $60,000 + $40,000 = $100,000 a year in licences. With a $45,000 one-off migration, payback on hard savings alone is 45,000 / 100,000 x 12 = 5.4 months.

Valuing soft benefits

Analyst productivity is a real benefit and a soft one. The estimate: 12 analysts x 2 hours a week x 46 working weeks x $70 loaded hourly cost = $77,280 of time. I would not put all of that in the business case. Freed hours turn into value only if someone redeploys them, so I apply a realisation factor (here 50%, an assumption to be replaced with evidence from a pilot), which counts $38,640. Show it as a separate line below the hard savings, so the case stands on $100,000 of hard savings and the soft benefit is upside. Other soft benefits worth naming: fewer conflicting numbers, faster onboarding, lower security surface.

Sequencing the consolidation

1. Align with contract dates. Note notice periods, because a missed renewal window costs another year.
2. Start with the lowest-risk, lowest-use tool (Z here, on the assumption that the inventory shows it is the least used; the example scores give only its low fit and low price, not its usage) to prove the migration playbook.
3. Rebuild before you retire. Identify the reports and data pipelines that matter, migrate them, and validate outputs side by side.
4. Freeze new content in the retiring tool as soon as the decision is made.
5. Run in parallel for one reporting cycle, then set a sunset date and keep an export for audit.
6. Communicate early with the owners of each dashboard and train users on the retained tool.

Pitfalls

• Choosing on licence cost alone. The cheapest tool that fails the fit test creates shadow tooling.
• Counting soft savings as cash. Finance will discount it, so do it first and show how.
• Forgetting migration and retraining cost.
• Skipping the decision owner: weights are a judgement that someone senior must own.

Direct answer

Build the comparison as year-by-year cash flows for both options over the same five years, discounted at the same rate (discounting converts a payment made later into today's money, because a dollar paid in year 4 costs you less than a dollar paid today), so a purchase paid on day one and a bill paid monthly are compared on one basis. The hardware is priced for its peak and idles the rest of the time, while the cloud bill follows the demand curve, so the model has to be driven by an hourly or daily demand profile and not by an average. On my illustrative numbers the hardware is the higher-cost option (about $1.14M against $1.04M headline, a gap that widens to about $0.20M once the up-front timing is discounted), and I would still choose it in two situations: when the latency requirement is worth more than about $51k a year, or when sustained demand will run above about 1.21 times today's level.

How to build the TCO

TCO (total cost of ownership) means every cost of having and running the option over its life, not only the purchase price. Use one tab of inputs and one of year-by-year calculations, and put each option's lines in the same rows so a reviewer can compare them.

Model the utilisation curve, not the average

Hardware capacity is bought for the peak plus headroom (spare capacity above the peak you expect), and you pay for all of it every hour. Cloud cost is roughly (instances running) times (hours) times (rate). If demand peaks at 100 units for 10 hours a day and sits at 30 units for the other 14, the average is about 59 units but the hardware must hold the peak. That peak-to-average gap is the main reason a cloud bill can undercut a purchase that looks cheap per unit of capacity.

Worked example (illustrative inputs, not vendor prices)

Inputs: the hardware costs $600,000 up front and is sized for 150 demand units (50% above today's peak of 100), runs at $115,000 a year ($70,000 power, colocation and support plus 0.25 of a full-time employee at about $180,000 loaded, meaning salary plus benefits and overhead, which is $45,000), and resells for $40,000 at the end of year 5. A cloud instance serves 10 demand units and costs $4.00 an hour. Discount rate 8%. NPV (net present value) in the output below means each year's cost divided by 1.08 once for every year it is away, then added up, so it is the five years of cost expressed in today's money.

import math

# Illustrative inputs (not vendor prices)
RATE = 0.08
YEARS = 5
HW_CAPEX = 600_000            # year-0 purchase, sized for 150 units (50% above today's peak of 100)
HW_RUN = 70_000 + 45_000      # power/colo/support $70k + 0.25 FTE (~$180k loaded) = $45k, per year
HW_RESALE = 40_000            # end of year 5
UNIT_PER_INSTANCE = 10        # demand units one cloud instance serves
INSTANCE_HOUR = 4.00          # $ per instance-hour, illustrative
HOURS = 365 * 24

# Daily demand curve: 10 busy hours at 100 units, 14 quiet hours at 30 units
def cloud_year_cost(demand_multiplier):
    busy = math.ceil(100 * demand_multiplier / UNIT_PER_INSTANCE) * 10
    quiet = math.ceil(30 * demand_multiplier / UNIT_PER_INSTANCE) * 14
    return (busy + quiet) * 365 * INSTANCE_HOUR

def pv(amount, year):
    return amount / (1 + RATE) ** year

def hw_npv_cost():
    return HW_CAPEX + sum(pv(HW_RUN, y) for y in range(1, YEARS + 1)) - pv(HW_RESALE, YEARS)

def cloud_npv_cost(m):
    return sum(pv(cloud_year_cost(m), y) for y in range(1, YEARS + 1))

hw_head = HW_CAPEX + HW_RUN * YEARS - HW_RESALE
cl_head = cloud_year_cost(1.0) * YEARS
print(f"headline 5-yr: hardware {hw_head:,.0f}  cloud {cl_head:,.0f}")
hw, cl = hw_npv_cost(), cloud_npv_cost(1.0)
print(f"NPV 5-yr cost at {RATE:.0%}: hardware {hw:,.0f}  cloud {cl:,.0f}")
annuity = sum(1 / (1 + RATE) ** y for y in range(1, YEARS + 1))
print(f"hardware premium {hw - cl:,.0f} NPV = {(hw - cl) / annuity:,.0f} per year of latency value needed")
print("average utilisation of hardware at today's demand:", f"{(10*100 + 14*30) / 24 / 150:.0%}")
print("demand multiplier vs today -> NPV cost (hardware fixed while demand fits 150 units)")
for m in (0.5, 1.0, 1.25, 1.5):
    print(f"  x{m:<4}: cloud {cloud_npv_cost(m):>10,.0f}   hardware {hw:>10,.0f}")
m = next(x / 100 for x in range(50, 151) if cloud_npv_cost(x / 100) >= hw)
print(f"cloud costs more than hardware from about x{m:.2f} of today's demand")

headline 5-yr: hardware 1,135,000  cloud 1,036,600
NPV 5-yr cost at 8%: hardware 1,031,938  cloud 827,769
hardware premium 204,170 NPV = 51,136 per year of latency value needed
average utilisation of hardware at today's demand: 39%
demand multiplier vs today -> NPV cost (hardware fixed while demand fits 150 units)
  x0.5 : cloud    454,690   hardware  1,031,938
  x1.0 : cloud    827,769   hardware  1,031,938
  x1.25: cloud  1,084,260   hardware  1,031,938
  x1.5 : cloud  1,282,458   hardware  1,031,938
cloud costs more than hardware from about x1.21 of today's demand

Reading it: the headline gap is $1,135,000 minus $1,036,600, which is $98,400. Discounting widens it to $204,170 because the hardware money is spent on day one while the cloud money is spread out. At today's demand the hardware averages 39% utilisation (59.2 average units over 150 of capacity).

When the higher-cost option wins

1. A latency requirement with a price on it. Spreading the $204,170 premium over five years at 8% gives $51,136 a year. If the slower cloud path costs more than that in lost revenue, breached service-level agreements (SLAs, the response-time promises made to customers) or abandoned sessions, the hardware wins. Get the number from the business (conversion lost per extra millisecond, penalty clauses) and do not assume it.
2. Sustained demand growth. Hardware cost is fixed until capacity runs out, while cloud cost scales with demand. The cloud NPV (net present value, the discounted total) passes the hardware's from about 1.21 times today's demand, so if the roadmap says demand will sit above that, the hardware is cheaper.
3. Fragility of the cheaper option. Cloud rates, egress charges and commitment terms move: the cloud NPV in the example has to rise by 24.7% ($1,031,938 divided by $827,769) before it reaches the hardware's NPV; a rise of more than that makes the hardware the cheaper option, and a smaller rise leaves the hardware's cost disadvantage in place.

Essential sensitivities

The demand multiplier is the one to test first, because it has a clear break-even of about 1.21 times today's demand; the value placed on latency has one too ($51,136 a year), and the remaining inputs refine the picture. In order: demand multiplier (the table shows hardware losing by $577,000 at 0.5 times demand, since $1,031,938 minus $454,690 is $577,248, and winning above about 1.21 times), the value placed on latency, the discount rate, hardware life and refresh timing, and the cloud rate with and without a reserved or committed discount (a lower price in return for promising to pay for a fixed amount of capacity for a year or more). A commitment lowers cloud cost and so widens the hardware's premium.

Trade-offs and pitfalls

• Comparing a sunk purchase with a monthly bill without discounting flatters the hardware's timing risk away and understates its cost.
• Sizing the hardware for today's peak and ignoring the second purchase when demand grows, or sizing for a growth case that never arrives and paying for idle capacity.
• Treating cloud instance counts as continuous; they come in steps, which is why the demand rows use whole instances.
• A recommendation should be conditional: choose the hardware if the latency value or the growth case holds, and revisit at a defined review date with the real utilisation data.