Reference · built on requestOperator by FibricReporting & analysis

KPI Drift

Governed metrics watched against a baseline, definition changes told apart from behavior changes, drift notes proposed to owners.

Request accessPricing ↗

About

A metric can move because the business moved or because someone edited the query. This operator tells the two apart. It reads each governed metric's values by period from the warehouse, and it reads the text of the view or query that produces the metric, with the timestamp it was last altered. When a value leaves its baseline band, it checks whether the definition changed in the same window and reads source record counts in the storefront and help desk as an outside check.

The result is a drift note addressed to the metric's owner, stating what moved, when, and whether the definition or the behavior explains it. The owner approves the note, a re-baseline, or neither.

This is a reference listing. It documents what Fibric would read from KPI Drift and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Metric values by period from the tables or views you register in Snowflake, PostgreSQL, or BigQuery
  • View text and LAST_ALTERED timestamps from the Snowflake INFORMATION_SCHEMA VIEWS view for each registered metric
  • View definitions from pg_views in PostgreSQL, compared against the copy stored at the last baseline
  • Statements that altered a metric's view, from Snowflake ACCOUNT_USAGE QUERY_HISTORY with the user and role that ran them
  • Order counts by day from Shopify and ticket counts by day from Zendesk, as a check that is independent of the warehouse
  • The owner, baseline window, and tolerance registered for each metric

Proposed actions

  • Target capability: propose a drift note to the metric owner naming the period, the size of the move, and the definition or behavior cause
  • Target capability: propose a new baseline for a metric whose definition changed on purpose, starting from the change date
  • Target capability: propose an annotation on the metric's history marking the definition change and who made it
  • Target capability: propose a hold that labels the metric under review in your metrics sheet until the owner decides

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Separate a re-definition from a real drop

    Conversion falls in Snowflake. QUERY_HISTORY shows an ALTER VIEW two days earlier by a named analyst. The note to the owner says so and proposes a baseline from that date.

    With Snowflake, Slack

  • Check the warehouse against the storefront

    Daily order count in PostgreSQL diverges from orders listed in Shopify for the same days. The note flags the warehouse load, since the definition is unchanged.

    With PostgreSQL, Shopify

  • Hold a metric in the shared sheet

    Owners track metrics in a Google Sheet. A drift the owner cannot explain is proposed as an under-review label in that sheet, written once and removed when the owner clears it.

    With Google Sheets, BigQuery

  • Support volume versus ticket exports

    A contact-rate metric moves in the warehouse. Zendesk incremental exports for the same window give the ticket count directly, so the note states whether the source or the pipeline moved.

    With Zendesk, Snowflake

Requirements

  • A warehouse connector with read on the metric tables and on view definitions: Snowflake, PostgreSQL, or BigQuery
  • A registry of metrics: name, query or view, owner, baseline window, and tolerance
  • A commerce or support connector whose record counts can stand in as an outside check
  • A place to send notes: Slack, or a Google Sheet the owners already read
Authentication
Read access to the warehouse schemas that hold the metrics and their view definitions, plus read scopes on the commerce and support connectors used as an outside check.

Limits

  • Snowflake ACCOUNT_USAGE views lag by up to 45 minutes and keep 365 days of history. Older definition changes are invisible to it.
  • pg_views shows the current definition only. Earlier versions exist only if a baseline copy was stored.
  • It detects a definition change by comparing text. A change that yields identical text, such as a table swapped underneath, is reported as behavior.
  • It watches the metrics you register. It does not discover metrics on its own.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request KPI Drift ↗

Questions and answers

What does the owner approve?
A note, a re-baseline, or an annotation. Each shows the metric, the period, the baseline band, the value, and the definition text before and after if it changed. The owner can approve, edit the cause, or dismiss with a reason.
What is left on the record?
Each drift and its outcome: the values compared, the definition hash at both ends of the window, the outside check, the note sent, and who approved it. A re-baseline records the old and new windows.
Does it change a metric definition?
No. It reads definitions and reports changes. It never runs ALTER VIEW, edits a query, or moves a baseline without an approval. A held metric is unheld only when the owner clears it.
Ask about KPI Drift

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy