CJA shared metric looks like a black box: make its definition auditable

An analyst sees a shared metric in Workspace but cannot tell which field or rule produces it. The higher risk is organizational: a shared definition can be reused in several data views while nobody knows which reports would move if it changes.

Trace the component to its source

Start in the data view where the metric is used. Record its shared-component name, source schema field or derived field, settings, attribution and filters. Adobe's shared metrics and dimensions guide says edits to shared components apply across linked data views; sharing does not cross connections. For derived fields, Adobe documents the rule builder and component linkage. If the Shared section does not reveal the rule, inspect the underlying schema or derived field through the component editor with appropriate admin permissions.

Build a change record, not a screenshot library

For every business-critical shared component, store its owner, definition, intended grain, connected data views, a sample calculation and a change date. Before editing it, run a small fixed comparison in each affected data view. A consistent name can still hide a changed denominator, exclusion or attribution rule.

Decide where the rule belongs

Keep reusable presentation logic in CJA when the same definition serves several analysts and is easy to test. Move upstream rules that must govern activation or warehouse outputs into a documented source contract. Do not create a shared CJA metric as the only record of a business definition used outside CJA.

Adovo’s view

A shared metric is a policy on what the business means by a number. If the policy can change many reports, its logic and owner must be visible before anyone clicks Save. Reuse without accountability scales confusion.