Ecommerce KPIs: CAC, AOV, retention, LTV and payback

A shop can sell more while having less money available to cover its costs. It can also report better conversion simply because the definition of a visit changed. That is why I start a KPI discussion by asking exactly what we count, which data supports it and which decision the result should inform.

We will work through customer acquisition cost, average order value, repeat purchasing, customer value and the time needed to recover acquisition costs. I will add conversion because orders and buyers are easily confused. Every calculation uses one small fictional shop, so you can follow the relationships and check the numbers yourself.

Write the definition before calculating

A KPI needs a name, formula, unit, reporting period, source and someone responsible for its interpretation. For sales, specify the currency and treatment of taxes, discounts, delivery charges and refunds. For customers, establish whether identity comes from an account, email address or another agreed key. A heading such as “customer value” does not provide enough information to reproduce the result.

Check the level of detail in each dataset. One order may contain several products, one customer may place several orders and a single session may contain two purchases. Joining those tables without checking can multiply amounts. Before building a dashboard, compare distinct order counts and totals before and after the join. A plausible final number is not evidence that the underlying records were combined correctly.

Specify the information cutoff too. January sales viewed at the end of March may include later corrections. That differs from a report using only information known on the final day of January. Both views can be useful, but they need separate labels. Otherwise, readers may mistake a data update for a defect or a change in customer behaviour.

One dataset for every metric

Our fictional shop has three customers: C1, C2 and C3. Each made their first purchase in January 2026. We have their complete purchase history through the end of March. Amounts are in PLN, after discounts, excluding taxes and delivery charges collected from customers. Variable costs include the product and order servicing costs agreed for this exercise.

The six accepted, fulfilled orders appear below. None was cancelled. Each row represents an entire order rather than a product line. We keep the original amount separate from the later refund adjustment so that its effect remains visible.

Order O4 has a partial return: on 10 February, the customer received a 50 PLN refund and 20 PLN of product cost was recovered. Our order-date analysis assigns that adjustment back to January. This is a restated view using information available on 31 March. It is neither a cash movement calendar nor a reconstruction of what was known on 31 January.

January recorded 30 sessions from 20 distinct users. Three sessions contained at least one purchase; S1 contained two orders. Acquiring the entire January customer group cost 300 PLN, including 120 PLN of advertising. The remaining 180 PLN represents allocated acquisition labour and tools. These are exercise inputs, with no claim that they describe an actual company.

Conversion: choose the denominator

We define session purchase conversion as sessions containing a purchase divided by all sessions within the measurement scope. January therefore gives 3 / 30, or 10%. If we ask for the proportion of users who bought, the answer is 3 / 20, or 15%. The difference reflects a different question and denominator, rather than contradictory arithmetic.

Four orders divided by 30 sessions gives approximately 13.33 orders per 100 sessions. I would not call that the percentage of sessions that resulted in a purchase. One session contained two orders and cannot count twice as a distinct purchasing session. This mistake is easy to miss when a report uses event counts where session counts are required.

The Google Analytics Data API documentation distinguishes the session rate for any key event from the rate for a particular key event. Check whether a card concerns purchases or includes other goals. Our calculation is an explicit definition applied to synthetic data, without claiming to reproduce a service’s default report.

When comparing months, inspect tracking coverage and user identification. A measurement change, missing events or a different traffic mix can alter the result without improving checkout. Separate those possibilities before choosing an experiment on the basket or product page. A higher rate alone does not establish its cause or tell you which change produced it.

AOV: value per order

Average Order Value describes the mean value of an order. In this exercise, I divide sales after discounts and allocated refunds by the number of fulfilled orders. January amounts total 500 PLN before the refund and 450 PLN afterwards. Dividing by four orders gives an AOV of 112.50 PLN.

Ignoring the refund would produce 125 PLN. You may show both values when their scope is clearly labelled. Our partial refund reduces the numerator while leaving the original order in the denominator. The calculation 450 / 3 = 150 PLN instead describes sales per purchasing customer. That is useful too, but answers a different question from AOV.

Do not remove inexpensive products or promotional orders merely because they lower the average. Show relevant segments instead of improving the number through convenient selection. Examine basket value, variable costs and subsequent purchases among customers acquired through the promotion. A larger order may require a larger discount and leave less money available for other expenses.

Consider the distribution as well. One unusually large order can shift the mean substantially in a small shop. Order count, median and the range of values can help when the available data supports them. Here we focus on the mean and do not pretend that six purchases describe a typical market. Small examples explain calculations; they do not establish a commercial benchmark.

CAC: the cost of acquiring a new buyer

Customer Acquisition Cost compares agreed acquisition costs with the number of new customers. Shopify’s CAC explanation uses sales and marketing costs and new customers. In our model, a new customer has made a first purchase, rather than merely creating an account or subscribing to a newsletter. Those other events may have their own metrics.

We divide 300 PLN by three new buyers, giving a CAC of 100 PLN. Using only the 120 PLN advertising spend would give 40 PLN. Label that advertising spend per new buyer. Do not compare it silently with a more complete CAC that includes additional costs. A changed numerator can look like improved acquisition performance even when nothing operational has improved.

For a real report, agree how to allocate shared costs, campaigns spanning several periods and work that also serves existing customers. Dividing every company expense by new buyers does not produce a useful acquisition definition. You need rules that can be applied consistently and explained to the person responsible for the budget. Record changes so that later comparisons remain interpretable.

Our example measures the cost for the whole group. It does not establish that one advertisement caused all three purchases. Assigning an order to a channel and estimating a campaign’s incremental effect are separate tasks. When reporting channels, retain unassigned purchases and explain the attribution rule. Do not distribute them arbitrarily just to fill every column in the report.

Retention: follow the same customer group

A cohort is a group sharing a starting point. Here that point is a first purchase in January. The Shopify customer cohort report describes grouping by first order too. You still need to choose an activity measure appropriate to the question you want to answer.

Only C1 bought again in February. The share of January customers purchasing that month is therefore 1 / 3, approximately 33.33%. C1 bought again in March, producing the same rate. Do not add those percentages to count distinct returning customers: the same person appears in both months. Across the later observation window, one of the three customers returned.

The absence of purchases by C2 and C3 in February does not establish permanent customer loss. A shop selling infrequently purchased products has a different rhythm from a recurring subscription service. Define the time horizon and return event. Do not automatically call the remaining cohort share churn without specifying what departure means in this business model.

Compare cohorts at the same age. By the end of March, January customers have had two subsequent months in which to return. March customers have not. An unobserved future month should remain blank, rather than becoming zero. Seasonality, promotions and customer composition matter too. A cohort difference may suggest a hypothesis, but does not by itself demonstrate that a new feature worked.

LTV: distinguish observation from prediction

Lifetime Value concerns customer value across the relationship. Three months of purchases only provide value for the observed window. In our dataset, sales after the refund total 450 + 80 + 120 = 650 PLN. Divided among three customers, that is approximately 216.67 PLN of order revenue per customer through March. I would not label it predicted LTV without an additional model.

We can also calculate contribution after variable costs. January has 450 PLN of sales and 280 PLN of adjusted costs, leaving 170 PLN. February contributes 50 PLN and March 80 PLN. Total contribution is 300 PLN, or 100 PLN per customer before acquisition cost. This scope is closer to the question of covering CAC than revenue alone.

Subtracting the cohort’s 300 PLN acquisition cost leaves zero in this simplified calculation. We have still not included every fixed cost, tax or other component of company performance. This does not establish that the whole shop is profitable. A high ratio of revenue to CAC is insufficient to support that conclusion, especially when the cost basis is unclear.

A future value forecast needs assumptions about subsequent purchases, refunds, costs and observation length. Document scenarios and how you will later compare the prediction with realised outcomes. Do not automatically extend the behaviour of one active customer to everyone in the group. With such a small sample, stating the limitation is more useful than presenting a seemingly precise multiyear value.

Payback: when contribution covers acquisition

Payback describes the time needed to recover acquisition cost. Stripe explains the idea and a simplified formula using monthly customer profit. Our monthly amounts vary, so we accumulate the cohort’s observed contribution after the agreed variable costs. We do not divide CAC by revenue from an arbitrarily selected month.

The 300 PLN threshold is first reached in the March bucket, the third observed month. A cohort table labelling the acquisition month as zero would call this month index two. Put the convention next to the result so that readers do not interpret two labels as conflicting calculations. Monthly buckets also do not justify a claim about an exact recovery day.

This is retrospective payback under our contribution definition, with the refund adjustment assigned to the original order. It does not establish cash payback: that requires payment, settlement and expense dates. If the threshold has not been reached by the cutoff, report “not reached during the observed period”. Do not turn an unavailable result into zero months or a promise of future recovery.

Checks before interpretation

First, inspect order identifier uniqueness. A retransmitted O1 event must not create another sale. Two different orders with the same amount remain two orders. If one identifier carries conflicting values, you need a versioning rule or an explanation of the conflict. Arbitrarily retaining the first row is not a reliable resolution merely because it produces a unique table.

Next, inspect refunds and missing values. An adjustment must reference an existing order, use the correct currency and represent the cost actually recovered. A missing amount does not mean a free order. No new customers means CAC is undefined for that division; no orders means AOV is undefined. The report should explain why a result is absent instead of presenting a misleading zero.

Finally, reconcile totals with order data and the agreed cost scope. A difference between web analytics and the sales system requires an explanation of coverage and definitions. Do not repair it with a hidden multiplier. The data cleaning guide covers preparation more broadly, while SQL for analysts explains why the level of detail matters when combining data.

Compare segments using consistent rules

If you split the shop by channel, device or product group, retain the same definitions across segments. Calculate overall AOV from total value divided by total orders. A simple average of averages gives a small and a large group equal weight, potentially changing the answer. Similarly, reconstruct overall conversion from the relevant numerators and denominators rather than arbitrarily averaging percentages.

For products, decide what it means for an order to belong to a category. A basket containing several categories may appear in several groups. Their order counts will then not necessarily add up to the shop total. Document that property or use another explicit allocation rule. Concealing the overlap makes later dashboard reconciliation unnecessarily difficult.

For a fully refunded order, decide whether it stays in the AOV denominator. Our example contains only a partial refund and does not resolve every possible shop policy. Make the chosen rule visible, especially when comparing operational and financial reports. A definition change needs an effective date or a recalculation of the comparison history; otherwise, the trend mixes different measures.

Agree the time zone at month boundaries too. An order close to midnight may belong to different dates in a technical source and a business report. Choose a common basis before assigning purchases to cohorts. A small timing difference can move a customer’s first purchase and every subsequent retention column, even though the underlying buying behaviour has not changed.

Turn the result into a question

Our example shows that one customer accounts for every subsequent purchase and cumulative contribution only covers acquisition cost in March. That is a starting point for examining repeat behaviour, costs and a larger sample. It is not yet a recommendation to increase a budget or stop a campaign. First establish whether the pattern appears in other comparable groups.

For an initial dashboard, I would show a few metrics with counts, periods, an information cutoff and concise definitions. Beside them, record the question to investigate and who owns the next step. That report can support a decision conversation. A long list of abbreviations alone does not tell anyone what should be checked tomorrow or what evidence would change the current interpretation.