Calculated Metrics Best Practices

Two years after a company finally agrees what its conversion rate is, open the metric list and count. There will be four of them. One called Conversion Rate, one called Conversion Rate (Visits), one called CVR, and one called Conversion Rate NEW that has been called that since a Tuesday in March.

Each of them is a calculated metric: a formula over data already being collected, saved under a name, evaluated whenever a report runs. None of them required a developer, a release, or a single line of code, and each took about four minutes. That is exactly why there are four.

Nobody did anything wrong. Each was built by a competent person solving a real problem in the time they had. A feature that costs nothing to use, produces something permanent, and has no owner will always end in the same place.

Two kinds of failure live in that library, and they need separating. One is a number that is wrong and looks fine. The other is a library full of numbers nobody can choose between. The first is arithmetic. The second is ownership. Most of this section is about the first, because the second gets far more attention and does far less damage.

The total row does not add up, and that is correct

Sooner or later somebody exports a table, sums a column in a spreadsheet, compares it against the total row, finds a gap, and concludes that Adobe is wrong.

Adobe is not wrong. The rows and the total are answering different questions, and the difference is deduplication.

A visit that lands on the home page, searches, and reaches the cart is a visit to all three pages. It appears in all three rows, because each row is asking how many visits touched that page. The total row is asking a different question, how many visits there were in total, and it answers with a deduplicated figure calculated on the server rather than by adding the column.

The ratio inherits that behavior, which is the part people find genuinely counterintuitive. The conversion rate on the total row is not the average of the three row rates. It is orders divided by visits, computed from the deduplicated totals, so it can sit outside the range of every individual row on the table and still be exactly right.

Two things follow. Never validate a rate by summing rows, and never let a stakeholder do it either, because the conversation that follows is expensive. And when a table is deliberately configured to show a total as the sum of its current rows, expect the deduplication to disappear and the numbers to move, which is intended behavior rather than a defect.

Before you trust a number, run these seven

Every one of the following returns a clean, well formatted, confidently wrong figure. None of them produces an error, and none of them is caught by anything except a person who thought to look.

The last one is the reason metric design cannot be done entirely in the reporting interface. A formula is only as honest as the persistence rules of the things it divides, and those rules were decided during implementation by somebody who was not thinking about this metric.

The dependency graph nobody drew

A calculated metric can contain another calculated metric, and it can contain a segment that other people also use. Both are references rather than copies, so both are live.

The consequence takes a while to appear and then appears everywhere at once. An analyst adjusts a base metric or a shared segment to fix their own report. Every metric built on top of it moves. Some of those are approved, one of them feeds a scheduled workbook, and the finance figure in Monday's pack is different from last Monday's for reasons nobody in the room can reconstruct.

The habit worth building is small. Anything with consumers gets a new metric rather than an edit, and the old one is renamed to say it is superseded rather than deleted. Renaming is visible to everybody using it. Editing is visible to nobody.

Somebody has to decide which conversion rate is the conversion rate

There is no universally accepted definition of conversion rate. Not in Adobe, not in the industry, not anywhere. Orders per hundred visits, orders per hundred visitors, orders per hundred cart additions and orders per hundred checkouts are all conversion rates, all correct, and all measuring different stretches of the same journey.

That is not a flaw to be fixed. A site of any size genuinely needs several of them, because a rate anchored on visits tells you that something is wrong and a rate anchored on checkouts tells you where. The flaw is leaving the choice implicit, because then every team makes it independently and the four metrics at the top of this page appear.

So the decision has to be made once, by somebody, and then published. Which two or three rates are the organizational standard. What each one is called. What it deliberately excludes. Which one is meant when a person in a meeting says "the conversion rate" without qualifying it. None of that is a reporting task and none of it happens in the builder, which is precisely why it never gets done.

The right hand column is not smaller because metrics were deleted. It is smaller because three of them were chosen, and the rest were allowed to exist without pretending to be the standard.

When not to build one at all

Three requests arrive looking like calculated metrics and are not.

If the request is about who, it is a segment. Visitors from paid search, people who used the store locator, sessions on mobile. A slice of the audience is a segment applied to a report, not a metric. The tell is that the answer is a population rather than a number. Understanding Segments covers what belongs there.

If it is genuinely one off, keep it out of the library. The builder can hold a metric inside the single project it was made in. An exploratory ratio built during one investigation should live and die there. Saving it to the shared library adds a permanent object to serve a temporary question, and that is the mechanism by which libraries reach four hundred entries.

If the number needs data nobody collects, it is an implementation request. No formula recovers a value that was never sent. That is the boundary drawn in What Are Calculated Metrics, where the choice between deriving a number and collecting it is the architect's decision rather than the analyst's.

A name that survives its author

Library hygiene as a general discipline is covered in Segment Best Practices, where naming, tagging and findability are worked through for components at large, and none of that changes here. Two things are specific to metrics and worth stating.

Put the denominator in the title. Conversion Rate (Visits) and Conversion Rate (Visitors) can coexist forever without confusing anybody. Two metrics both called Conversion Rate cannot coexist for a week.

Write the description as though the reader is arguing with the number. Not a restatement of the formula, which is visible anyway, but the decision behind it: what it counts, what it deliberately excludes, and which conversation it was built to settle. That field is the only thing that will still be explaining this metric after its author has changed jobs.

Approved is a promise somebody has to keep

An administrator can mark a metric as approved, and the flag then shows up beside it in the component list and in the Data Dictionary. Most organizations treat this as a tidiness feature. It is closer to a signature.

Approval tells every analyst in the company that this definition is the canonical one and that they should stop building their own. That is a strong claim, and it is only worth making if somebody will actually maintain the metric when the business changes, when a variable is repurposed, or when the definition turns out to be wrong. An approved metric that nobody owns is worse than an unapproved one, because it stops other people from questioning it.

Approve a small set and mean it. A library with twelve approved metrics and two hundred unapproved ones is in far better shape than one where everything carries a checkmark.

There is a second reason the approved set should be a set rather than a single blessed number, and it is worth stating plainly because the industry rarely does. A ratio on its own never settles anything. Email converting at ten percent against search at two percent says nothing about where the budget should go until somebody also looks at how many people each channel reached, and neither figure means much until both are read against what the organization actually committed to this year. Rate without volume is a half answer, volume without rate is the other half, and both without an objective are trivia. Approving a small basket, rather than crowning one metric, is what keeps that visible.

Auditing a library in an afternoon

The audit below is deliberately mechanical, because the value is in doing it at all rather than in doing it cleverly. It is a read for the first five steps, and nothing is deleted until the consumers of a metric are known.

Nothing else needs to be configured, and there is no scheduled job or automation to set up: Adobe provides no housekeeping for this, which is exactly why it accumulates. This sequence is a floor rather than a ceiling. A mature practice does it quarterly, keeps the CSV exports, and can therefore say how the library changed over a year. A practice doing it for the first time will find most of the value in step 4 alone.

Where this leaves you

A calculated metric is arithmetic over collected data, which makes it almost free. Everything difficult about it comes from the fact that the arithmetic is invisible once the metric has a name: the denominator, the metric type, the fused segment, the attribution model, and the persistence of the variables underneath all vanish behind a label in a component list. A wrong metric never announces itself, because there is nothing to announce. It simply produces a number, and people plan around it.

That is why the checks in this section are worth more than the building technique in Building Calculated Metrics, and why the naming and approval habits matter more than they appear to. The technique takes an afternoon to learn. The discipline is what keeps a metric library usable by somebody who was not there when it was built, and it is also what keeps the organization honest about the fact that no single number in that library is a verdict on anything.

Metrics answer how much. The other half of analysis asks about whom, and that is the work of segmentation, starting with Understanding Segments, where a saved definition of a population becomes an object you can apply anywhere, including inside the metrics built here. Both instruments meet in Analysis Workspace Overview, which is where a formula and a population finally become an answer somebody can act on.