Validate and save a custom metric

Decide the calculation before writing syntax

A custom metric is a saved expression built from the approved server field catalog. Start with a question that can be answered by those inputs, such as a difference between two compatible values or a ratio whose denominator has a meaningful unit. Write down the units and expected sign before entering a formula. A descriptive label cannot add a missing input or make an unsupported calculation available. Custom metrics use bounded calculations; they are not a way to run arbitrary programs or retrieve credentials.

Inspect Available metric fields

Open Settings → Metrics and expand Available metric fields. Read the actual identifiers and any descriptive information returned by the catalog. Use those names in the expression rather than copying a human-readable chart heading. For example, a chart might abbreviate a measure for display while the expression engine uses a different field identifier. The available catalog is the reliable starting point for the current environment. If the input you need is absent, stop and choose a supported approach instead of guessing a close-looking name and treating a zero result as confirmation.

Enter and validate a small expression

In New metric, give the calculation an identifiable Name and enter its Expression. Choose Validate and inspect the returned result before saving. Start with the simplest supported expression involving your selected field, then add the next operation once validation is understood. This makes a refused field or syntax problem easier to locate than a long expression containing several simultaneous mistakes. Changing the expression clears the previous displayed validation result, so validate the exact current text rather than relying on success from an earlier draft.

1. Open Settings → Metrics and inspect the field catalog.
2. Enter a clear name and the smallest useful expression.
3. Choose Validate, read its result and correct the identified issue.

Check units and missing-input behavior

A formula can be syntactically valid while being analytically unsuitable. Subtracting values with incompatible units, dividing by a quantity that can be unavailable, or comparing a session aggregate with a single observation can produce a misleading interpretation. Validation is not a promise that every selected symbol has fresh data for every field. Compare the inputs' source, session and time coverage before trusting a derived number. Missing market observations should remain an availability issue, rather than being mentally replaced by zero to make a desired result appear.

Save and identify the resulting record

Choose Save metric after validating the intended expression and confirm the record appears in Your metrics. The list shows the saved name and expression, which lets you verify that the correct version was committed. A success notice for Validate is different from a completed save. If saving fails, retain your expression and read the error before retrying. When creating a different calculation, use a distinct name that explains its purpose; otherwise similar labels can obscure which saved record you are selecting in a supported consuming workflow.

Delete obsolete calculations carefully

Your metrics provides a delete action beside each saved record. Read both its name and displayed expression before removing it, especially when you have created several variations during testing. Deleting the record removes that saved custom expression rather than a provider-supplied market field. Consider any workflow in which you deliberately selected that custom record before cleaning up. A saved expression belongs to the current account, so a metric created under another email is not missing merely because it does not appear in this account's list.

Diagnose validation and availability separately

For an invalid-expression response, check the approved identifiers, exact spelling and supported calculation syntax, then test a smaller expression. For a saved metric with unavailable inputs, keep the formula fixed and check the selected instrument, session, source timestamps and entitlement state. A successful save does not prove complete live provider coverage. When opening a support ticket, include the safe expression, relevant field identifiers, selected market context and exact error. Do not include developer keys or authentication tokens; the expression engine does not need those values inside a formula.