Relationship paths and why two measures over the same table disagree

What it does

A measure aggregates a source table back up to the unified Customer table, and the route it takes to get there is the relationship path. Where more than one route exists, the builder makes you pick one, and each route returns a different number.

Key facts

Relationships come in three flavours: system relationships created by unification, inherited relationships detected during ingestion, and custom relationships you create yourself. Only the custom ones are editable.
Supported cardinality is many-to-one and one-to-one only. Many-to-many is modelled as two many-to-one relationships through a linking table.
A relationship is defined by source table, target table, source and target cardinality, source key field and target key field. The relationship name is case-sensitive.
Custom relationships are created under Data > Tables > Relationships tab > New relationship.
The measure builder exposes Relationship path only when more than one path exists between the chosen data table and Customer. With a single path it does not appear at all.
Longer paths are more restrictive: a record has to exist in every table along the route, so multi-hop paths generally return fewer rows and a smaller aggregate.
Table paths in segments and measures can traverse up to 20 relationship hops between the start table and the target table.
The path also decides which tables' attributes are available to you for filters and dimensions inside that calculation.
Indirect paths pass through intermediary tables; multi-path means the source table joins directly to several targets. You can hit both at once.

When to use / skip

You do not choose to use relationship paths — they turn up whenever a client has more than one system holding customer transactions, which is most of them. The decision you actually make is whether to model the join properly or to flatten the problem upstream.

If the source data already carries a clean customer key that unification matched on, the direct path to Customer is the right answer and you should stop there. Where you genuinely need to route through a loyalty or contact table — because the transaction table only holds a loyalty number, say — build the custom relationship deliberately and document why. If you find yourself picking between four paths on every calculation, that is a signal the data model needs work before the measures do. Denormalising a couple of columns into the source extract is often cheaper than maintaining a five-hop path that nobody else understands.

Configuration decisions

Whether to create a custom relationship at all, or to add the missing key to the source extract so the direct path works.
Which path each measure uses, decided per calculation rather than once per measure — two calculations in the same measure can take different routes.
Cardinality on each custom relationship, since getting the direction wrong changes the join semantics rather than producing an error.
Whether transactions attach to the unified Customer or to a source contact table that itself resolves to Customer, which drives how many hops you end up with.
Whether to standardise on one path across the whole solution and record it, so segment authors and measure authors do not diverge.

Gotchas

The Relationship path control is hidden when only one path exists, so a measure built early in the project can silently change behaviour once someone adds a second relationship and the control appears with a default selection.
Two measures over the same transaction table with different paths will disagree, and nothing in the UI flags it. This is the single most common cause of "the numbers do not match" on delivery.
Longer paths quietly drop customers. A customer with purchases but no loyalty record vanishes from a measure routed through the loyalty table, and the measure just returns a smaller total rather than erroring.
Custom relationship names are case-sensitive, which bites when someone recreates a relationship after a deployment and casing differs.
Deleting or replacing a table that sits in the middle of a path breaks every measure and segment routed through it, and you find out at the next refresh.
The 20-hop ceiling is generous enough that nobody hits it, but performance degrades long before that. Treat anything past three or four hops as a modelling smell.

Consultant notes

Draw the relationship map on a whiteboard with the client before building a single measure. It takes an hour and saves the reconciliation argument later.
When a client challenges a number, check the relationship path first, before the filters and before the aggregation. It is usually the path.
Tell the client plainly that adding a relationship can change existing measure results. It is not a purely additive change.
Demo the same measure built two ways over two paths, with different totals, so the business understands why definitions have to be written down.
Before go-live, list every measure with its chosen path in the handover doc. Nobody can reconstruct it from the UI at speed.

Worth revisiting if custom relationship editing or path selection changes in a future wave.