What Are Calculated Metrics

Ask a student what they scored and they add the subjects together. Ask a player how many goals are still needed and they subtract what has been scored from what it takes to win. Ask a company how it did this year and somebody says the profit was significant, which sounds like an answer and is not one, because nobody can act on it until that profit is set against last year's profit, and against the revenue it came out of.

None of those three people are performing analytics. They are doing what anybody does the moment data becomes quantifiable, which is to combine numbers until one of them starts to mean something.

Adobe Analytics collects something quantifiable and calls it a metric. Orders, visits, page views, cart additions, revenue. Everything in this section follows from a single fact about them: individually they are honest, and individually they are almost never enough.

The third panel is the one worth sitting with, because it is the shape of almost every question a business actually asks. A profit figure on its own is a fact without a verdict. It becomes a verdict only when something is divided into it.

A count can point at the wrong winner

Here is what that looks like with real reporting in front of you. Four marketing channels, one month, and the question is which of them deserves more money next month.

Search produced 100 orders. Paid search produced 80. Direct produced 20. Email produced 10. Read that list and the conclusion is obvious, and it is also wrong.

Divide each channel's orders by the visits it delivered, and the ranking turns over completely.

Search is still the largest source of orders and nobody should switch it off. But of every hundred people email brings, ten of them buy, and of every hundred people search brings, two do. Email is the channel with the strongest tendency to turn a visitor into a buyer, and the raw count not only failed to say so, it said the opposite loudly enough that a budget meeting would have acted on it.

Both tables are true. Only one of them answers the question that was asked.

A metric alone is a number. A metric against another metric is a statement.

Every tracking call that reaches Adobe carries counts of things that happened, because that is what collection is for. A page view. An order. A visit. A product added to a cart. Those become the metrics you see in reporting, and they are built in the implementation, which is what Events (Success Events) covers.

Now listen to how questions are actually asked. What is the conversion rate. How much revenue does an average visit produce. What share of traffic bounces. How many orders per customer. Not one of those is a count. Every one of them is two counts with an operation between them, and no tracking call has ever sent an operation.

So there is a permanent gap between the shape of what gets collected and the shape of what gets asked, and that gap has to be closed somewhere. There are only two places it can happen. Either every person closes it privately, in a spreadsheet, on the way to the meeting. Or it is closed once, inside the tool, with a name attached to it.

A calculated metric is the second option. Put plainly, it is a metric you derive from two or more existing metrics by adding, subtracting, multiplying or dividing them, and then keep.

The business already has a word for these, and the word is KPI

None of this is new, and it did not start with digital analytics. Business has been dividing one number by another for as long as there have been two businesses to compare, and it gave the useful ones a name: key performance indicators.

The reason for the name is comparability. Company A makes ten million in profit. Company B makes a hundred million. Company B is larger, and that is the only thing those two numbers establish. Which of them is performing better cannot be read off the raw figures at all, and it never could. It takes year over year growth, or margin per unit, or the ratio of cost to selling price, before the two become comparable, and at that point the smaller company frequently turns out to be the stronger one.

Digital analytics has its own name for its KPIs, which is conversion metrics, and it is the same instrument. How many of the people who arrived went on to do the thing you wanted, expressed against a reference point so it can be compared with something else. The reference point moves, which is why there is more than one conversion rate, and that is the subject of Building Calculated Metrics.

This is also the difference between a person reciting numbers in a meeting and a person holding the room. Anyone can read out that search delivered a hundred orders. Being able to say that the count favors search, the rate favors email, both are correct, and here is which one the budget question needs, is a different conversation entirely.

Mostly you will be dividing

Four operations are available and they are not used equally. Addition and subtraction combine metrics that are already in the same unit, which is occasionally what you want: total engagement events, orders minus returns, budget remaining. Multiplication turns up mostly for scaling a number into a readable form.

Division is different in kind, because it is the only one of the four that produces something the originals could not express. Two counts go in and a rate comes out, and a rate can be compared across things of wildly different size. That is exactly what made the email channel legible next to the search channel, and it is why the builder in Adobe Analytics puts a divide operator between two metrics by default rather than making you choose.

So the working rule for a first metric is simple: assume you are building a ratio, and make yourself justify it if you are not. That rule is scaffolding rather than law. Once you have built a few and can see what each one is for, you will know exactly when a subtraction is the honest answer, and at that point you should stop following the rule and follow the question instead.

A saved formula, not saved data

The mechanic underneath all of this is smaller than most people expect, and everything useful about the feature follows from it.

A calculated metric stores no data. It stores a formula. Orders divided by visits, held under a name, sitting in a list. Nothing is computed when it is saved. The formula is evaluated when a report runs, against whatever rows that report happens to be looking at, and then it is discarded and evaluated again the next time somebody asks.

Because the formula runs at report time, it applies to every day of data in the reporting window, including the years collected before anyone thought of the metric. Change the formula and every report that uses it changes with it, retroactively, in both directions through history. Delete it and no data is lost, because none was ever created.

An implementation change can do none of that. Deploy a new event this afternoon and it starts producing data this afternoon. Last quarter stays empty forever, and no amount of effort recovers it.

Derive it, or collect it, and the answer is usually derive

This is the decision the module is really about, and it arrives disguised as a request. Somebody asks for a new metric. The reflex in most teams is to open a ticket, add a variable, and wait for a release. That reflex is wrong often enough to be worth breaking on purpose.

Ask one question first: can this number be computed from things already being collected? If it can, it is not an implementation request. It is a formula, and it should take minutes.

Read the last row twice, because it is where the rule stops. Derivation is arithmetic on data that exists. If the order value was never sent, no formula in the world produces revenue, and no amount of cleverness in a metric definition substitutes for a value that was never collected. The test is what is already arriving, not what should have been.

Everything above that line, though, belongs in a formula. A team that reaches for implementation first spends weeks producing a number it could have had before lunch, and then owns that number forever whether it turns out to be the right one or not.

The one direction the arrow does not run

A segment can live inside a calculated metric. A calculated metric cannot live inside a segment.

That asymmetry surprises people, and it is worth understanding rather than memorizing. A segment answers a question about who: which visits, which visitors, which hits qualify. It is evaluated against the data itself. A calculated metric answers a question about how much, and it is evaluated after the data has already been gathered and arranged into rows. The metric sits downstream of the segment, so it can consume one, and the segment cannot reach back upstream to consume a metric.

The practical consequence catches teams out regularly. A request like "build a segment of visitors whose revenue per visit is above fifty" cannot be satisfied directly. The comparison has to happen inside the metric, or in the table, and not in the segment definition. Understanding Segments covers what a segment can express instead.

The Data Warehouse case is the one to plan for. Data Warehouse returns raw aggregated rows for you to process elsewhere, and a formula evaluated inside Adobe's reporting layer is simply not part of that pipeline. If a number has to appear in an export, the arithmetic happens in whatever consumes the export, and the calculated metric stays a reporting convenience.

Behind all five exclusions sits one boundary, and it is worth carrying instead of the list. A calculated metric operates on data that has already been counted and arranged into rows. It never sees an individual hit. So any logic that has to look at a single server call and decide something about it, cleaning a value, setting a variable, classifying a request, is not a metric problem at all and no formula will reach it. That work belongs upstream, in the data layer, in Processing Rules, or in the implementation itself. Knowing which side of that line a request falls on saves more time than knowing the whole function list.

Read the library before you add to it

The first useful thing to do with this feature is not to build anything. Adobe ships a set of default calculated metrics in every report suite, including Bounce Rate, Conversion Rate, Revenue per Order and Average Time on Site, and most organizations have built dozens more before anyone new arrives. Almost every metric a newcomer is asked to create already exists in some form.

There is nothing else to run. That sequence is a floor rather than a ceiling: it is the minimum a person should know about their own metric library before adding to it, and a team that repeats it once a quarter stops having most of its arguments about numbers.

The skill is asking, and this is the instrument

A calculated metric is a named formula, evaluated when a report runs, over data that was already collected. Because it stores nothing, it costs nothing, reaches back across all of history, and can be corrected the moment it is found to be wrong. Because it carries a name that other people see, it is also where an organization writes down what it means by its own words.

What the feature really gives you, though, is not arithmetic. Adding and dividing were never the difficult part. It is that most wrong answers in analytics are answers to a question nobody should have asked, and a rate is usually a better question than a count. Four channels ranked by orders is a question about volume. The same four ranked by orders per hundred visits is a question about quality. Knowing which one the room needs is the whole skill, and the metric library is where the good questions get kept once somebody has found them.

Two things follow, and they are the rest of this module. Building Calculated Metrics takes the builder apart, because the same sentence, orders divided by visits, still has several different meanings inside it. Then Calculated Metrics Best Practices deals with what happens when a feature this cheap has been in the hands of a whole organization for two years.