Reference · built on requestOperator by FibricReporting & analysis

Change Annotation

Finds price, campaign, policy, and deploy changes as each system records them and proposes each as an annotation on your metric timeline.

Request accessPricing ↗

About

A dip on a revenue chart is easier to read when the chart shows that a campaign went out that morning and a deploy landed at noon. Change Annotation reads the systems where those changes are recorded. Shopify sends PRODUCTS_UPDATE and DISCOUNTS_CREATE webhooks and dates each shop policy with updatedAt. Klaviyo lists campaigns with a send_time. GitHub lists deployments with a sha, an environment and a created_at.

For each change it proposes one annotation: a time, a short text naming what changed, and tags for the system and the kind of change. A person approves it before it appears on a Grafana dashboard, in a Mixpanel project, or in the annotations table in your warehouse. Nothing is drawn on a chart without that approval.

This is a reference listing. It documents what Fibric would read from Change Annotation 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

  • Shopify PRODUCTS_UPDATE webhooks, which fire when a product or its variants change, including a price edit
  • Shopify DISCOUNTS_CREATE and DISCOUNTS_UPDATE webhooks, and each ShopPolicy's updatedAt read through Shop.shopPolicies with the read_legal_policies scope
  • Klaviyo campaigns from GET /api/campaigns, filtered by messages.channel, with name, status, send_time and audiences
  • GitHub deployments from GET /repos/{owner}/{repo}/deployments, filtered by environment, with sha, ref, created_at and description
  • Annotations already on the target, so a change marked once is not proposed a second time
  • The metric tables in BigQuery or Snowflake that the annotations sit beside, so an annotation carries the same time zone as the metric

Proposed actions

  • Target capability: propose a Grafana annotation through POST /api/annotations with time, text and tags, scoped to a dashboardUID and panelId or left organization-wide
  • Target capability: propose a Mixpanel annotation through POST /projects/{projectId}/annotations with a date and a description
  • Target capability: propose a row in your warehouse annotations table in BigQuery or Snowflake, keyed by system, change kind and time
  • Target capability: propose one summary annotation when a bulk edit touches many products at once, with the count and the first and last time seen
  • Target capability: propose a PATCH to an approved Grafana annotation's text or timeEnd when a deploy is rolled back or a campaign is rescheduled

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

What you can build

  • Mark campaign sends on a revenue panel

    Each Klaviyo campaign with a send_time in the period becomes a proposed Grafana annotation on the revenue dashboardUID, tagged with the channel, so a spike lines up with its cause.

    With Klaviyo, Grafana

  • Show deploys on a conversion chart

    GitHub deployments for the production environment are proposed as Mixpanel annotations, described by sha and ref, so a change in checkout conversion can be read against the release that preceded it.

    With GitHub, Mixpanel

  • Keep a price and policy change log beside your metrics

    PRODUCTS_UPDATE webhooks and ShopPolicy updatedAt changes are proposed as rows in a BigQuery annotations table, joined by day to the metrics your reports already query.

    With Shopify, BigQuery

  • Annotate a discount launch

    A DISCOUNTS_CREATE webhook becomes one proposed annotation with the discount's title and start, written to Grafana and to Snowflake, so both readers see the same mark.

    With Shopify, Grafana, Snowflake

Requirements

  • A commerce connector with product, discount and policy events: Shopify, or another store whose API dates each change
  • A marketing connector that lists campaigns with a send time: Klaviyo, with the campaigns:read scope
  • A source-control or deploy connector that lists deployments by environment: GitHub
  • An annotation target: Grafana with annotations:create, Mixpanel with a service account, or a table in BigQuery or Snowflake
Authentication
Change Annotation keeps no keys of its own. It reads webhooks and lists through the store, marketing, source-control and dashboard connectors you connect, and each annotation is a proposal until a person approves it.

Limits

  • A change is found only where a system records it. A price edited in a spreadsheet and imported shows as a product update, reason unknown.
  • An annotation's time is the system's own: the webhook's receipt, the campaign's send_time, the deployment's created_at. Not the moment a customer saw the change.
  • Klaviyo's campaign list allows bursts of 10 requests per second and 150 per minute steady. Large accounts are polled, not streamed.
  • The operator never deletes an annotation. It proposes edits; removal is a person's action in Grafana or Mixpanel.

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 Change Annotation ↗

Questions and answers

What is approved before an annotation appears?
Each annotation: its time, text, tags, and where it will be written. A reviewer can change the text, move the time, or reject it. A bulk edit is shown as one summary annotation with a count, and the reviewer can expand it into individual marks.
Does it change any price, campaign, or deploy?
No. It reads the record each system keeps of a change and proposes a mark on the timeline. It writes to Grafana, Mixpanel, or your warehouse table, and only after approval.
What is recorded for each annotation?
The source system, the event or record id, the time as the source gave it, the text proposed, the decision and who made it, and the annotation id returned by Grafana or Mixpanel, so the mark can be edited or removed later.
Ask about Change Annotation

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