{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "/schemas/3.1.0-beta.3/enums/metric-type.json",
  "title": "Metric Type (Deprecated)",
  "description": "**Deprecated as of this minor.** Legacy free-form enum mixing metrics, verification, and attribution into one list with no layer alignment. New implementations SHOULD use `performance-feedback.metric` (the discriminated `(scope, metric_id, qualifier)` row shape) instead. This enum is retained for one-minor backwards compatibility on `performance-feedback.metric_type` and is removed at the next major. Migration guidance:\n\n- `viewability` → `{ scope: 'standard', metric_id: 'viewable_rate', qualifier: { viewability_standard: 'mrc' | 'groupm' } }` (or `viewable_impressions` / `measurable_impressions` depending on what's being fed back)\n- `click_through_rate` → `{ scope: 'standard', metric_id: 'ctr' }`\n- `completion_rate` → `{ scope: 'standard', metric_id: 'completion_rate', qualifier: { completion_source: 'seller_attested' | 'vendor_attested' } }`\n- `conversion_rate` → no clean direct target. `conversions` (count) is not the same as `conversion_rate` (ratio); senders feeding back conversion-rate effectively are encouraged either to feed back `{ scope: 'standard', metric_id: 'conversions' }` with the rate in the response narrative, or to use a vendor-scope entry for an MMM/MTA conversion-rate variant. Native `conversion_rate` may graduate to `available-metric.json` in a future minor if demand materializes.\n- `brand_lift` → `{ scope: 'vendor', vendor: { domain: '...' }, metric_id: '<vendor brand lift metric>' }`\n- `brand_safety` → typically `{ scope: 'vendor', vendor: { domain: 'doubleverify.com' \\| 'integralads.com' \\| 'humansecurity.com' \\| ... } }` with `metric_id` from the vendor's measurement-agent capabilities catalog. If the buyer doesn't know the vendor's specific `metric_id`, they MAY populate the top-level `vendor` field instead and OMIT `metric` entirely — the feedback row remains attributable via `feedback_source` + `vendor` even without a structured metric reference.\n- `overall_performance` → **omit `metric` entirely**. This was a meta-bucket without defined dispatch semantics — holistic campaign feedback (a trader flagging a campaign as underperforming without a specific metric) is now expressed by populating `performance_index` and the response narrative without setting `metric`. Same for general optimization signals.\n- `cost_efficiency` → **omit `metric` entirely** for general efficiency feedback. For specific cost-per concerns, use `{ scope: 'standard', metric_id: 'cost_per_acquisition' \\| 'cost_per_click' \\| 'cost_per_completed_view' \\| 'roas' }`.",
  "type": "string",
  "enum": [
    "overall_performance",
    "conversion_rate",
    "brand_lift",
    "click_through_rate",
    "completion_rate",
    "viewability",
    "brand_safety",
    "cost_efficiency"
  ]
}