Measure types and where the results actually land

What it does

A measure is a calculation defined over tables related to the unified Customer table. The type you pick at creation decides the shape of the output: either a new column bolted onto every customer profile, or a separate table with its own grain.

Key facts

Four types in the builder: Customer attribute, Customer measure, Customer measure (for Customer Insights - Journeys) and Business measure.
A Customer attribute measure writes a single value per customer into the Customer_Measure table as a new column. It is the only type that shows on the customer profile card.
A Customer measure gets its own dedicated table, keyed on CustomerId plus whatever dimensions you add, so it can hold several rows per customer.
A Business measure has zero or more dimensions and no CustomerId. It is the company-level number — total revenue, transaction count by region — not a per-customer one.
Dimensions are what separate the types in practice. CustomerId is added automatically for customer measures; strip it out and the measure converts to a business measure.
Aggregation functions available: Sum, Average, Count, Count Unique, Max, Min, First, Last, ArgMax, ArgMin.
A single measure can hold more than one calculation — use New calculation, and the Preview pane shows the resulting output schema as you go.
The Rules section lets you substitute non-integer results, most commonly turning nulls into 0 so downstream segment rules behave.
On the customer profile detail page, configured customer attribute measures appear in the Insights section as per-customer KPIs.
Segments and measures share a combined ceiling of 1,000 active objects per environment before performance degrades; a calculated measure stored in Dataverse holding more than 10 million rows should be split.

When to use / skip

Almost every unification project ends up with measures, because segments built purely on raw source attributes are brittle. The question is which type. If the number belongs on a customer record and you want it visible on the profile and usable as a plain numeric attribute in segment rules, it is a customer attribute measure — that covers total spend, order count, days since last purchase, and probably eighty percent of what a client asks for.

Reach for a customer measure with dimensions when the client genuinely needs spend split by category or channel per customer, and accept that you have gained a table rather than a column. Business measures are reporting artefacts — the client will usually be better served by Power BI or Fabric over the same data, and if they already have a warehouse doing that, do not rebuild it here just because the builder is in front of you. Skip business measures entirely on projects where Customer Insights is purely feeding activation.

Configuration decisions

Type per measure, decided before you build — the output shape follows from it and changing your mind means rebuilding.
Whether a given number needs dimensions at all, since adding one moves the output off the profile card and into its own table.
Naming convention. Customer attribute measures become columns in Customer_Measure and land in the same attribute list a marketer picks from, so names need to read well without context.
Null handling in Rules — decide up front whether "no purchases" means 0 or means absent, because segment counts differ sharply between the two.
Whether the value belongs in a measure at all, or whether it should be computed upstream in the source system or the lakehouse and ingested as a plain column.
Which measures get exported to Dataverse for Journeys or other apps, since that is what drives the row-count concern.

Gotchas

Removing CustomerId from the dimensions silently reclassifies the measure as a business measure. You lose the profile card and any segment rule that referenced it.
Only customer attribute measures show on the profile card. Clients who have seen a demo profile page and then get a dimensioned customer measure will ask why nothing appeared.
Business measures are not usable as per-customer attributes in segment rules — there is no customer to attach them to. This catches people who build "total revenue" and then try to filter on it.
Everything writes into a table you did not name. Customer_Measure grows a column per customer attribute measure, and every dimensioned measure adds a table, which matters when someone downstream is reading the Dataverse schema.
Count and Count Unique on the same attribute give very different answers over transaction tables with repeated line items. Check which one the client's existing report actually uses before agreeing the numbers match.
The 1,000 combined segment-and-measure ceiling is per environment, and unused measures pile up quickly on projects with several analysts in the tenant.

Consultant notes

Ask the client to bring their existing definition of each KPI in writing, including the filter conditions, before you open the builder. Half of measure delivery is arguing about what "active customer" means.
Demo the profile card early. It is the thing that makes measures land with a business audience, and it is only ever populated by customer attribute measures.
Push back on requests for large dimensioned measures aimed at reporting. That is a BI job; measures should exist to drive segmentation and activation.
Before go-live, reconcile at least two measures against a number the client already trusts from their own reporting, and write down why any difference exists.
Keep a register of every measure with its owner and business definition. Nobody remembers in six months, and the auto-cleanup will start deactivating the ones nobody uses.

Worth another look if the builder gains new measure types or the profile card starts showing dimensioned measures.