Reference · built on requestOperator by FibricReporting & analysis

Cohort Watch

Customer cohorts tracked across orders, contacts, and payments, with a cohort note proposed when retention or contact rate departs.

Request accessPricing ↗

About

A cohort is a set of customers defined by something they share: first-order month, acquisition channel, plan. This operator follows each cohort you define across three systems. Orders and order counts per customer come from the storefront. Tickets per requester come from the help desk. Refunds, disputes, and subscription status per customer come from the payment processor or billing system. It joins them on the customer key you specify and recomputes retention and contact rate for each cohort at the interval you set.

When a cohort's curve departs from the cohorts before it, it proposes a note to the owner with the members and the systems that moved.

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

  • Customers with created_at, orders_count, total_spent, last_order_id, and tags from the Shopify Customer resource
  • Orders per customer with financial_status and cancelled_at from the Shopify Orders resource, or orders from Magento
  • Tickets by requester_id, status, and created_at from Zendesk, read through incremental exports
  • Refunds and disputes by charge from Stripe, with dispute reason and status
  • Subscription status, cancelled_at, and cancel_reason from Chargebee where customers are on plans
  • The cohort definitions, the customer key used to join systems, and the owner of each cohort

Proposed actions

  • Target capability: propose a cohort note to the owner naming the cohort, the measure that departed, and the members behind the move
  • Target capability: propose a definition update when members no longer meet the rule that defined the cohort
  • Target capability: propose a ticket tag in the help desk marking open tickets from members of a cohort under watch
  • Target capability: propose a list of members for outreach, handed to the owner rather than contacted

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

What you can build

  • First-order-month cohorts from Shopify and Zendesk

    Each month's new customers form a cohort. Repeat orders from Shopify and tickets from Zendesk are counted per member. A cohort whose contact rate departs from prior months gets a note.

    With Shopify, Zendesk

  • Refund and dispute exposure by cohort

    Stripe refunds and disputes are attributed to cohort members by charge. A cohort where disputes rise is proposed for a note before the evidence deadlines pass.

    With Stripe, Shopify

  • Plan cohorts on Chargebee

    Customers grouped by plan and start month. Subscription status and cancel_reason from Chargebee define retention; Kustomer conversations define contact rate.

    With Chargebee, Kustomer

  • Mark the cohort in the help desk

    Open Zendesk tickets from members of a cohort under watch are proposed for one ticket tag so agents see it. Tags are written once and removed when the watch ends.

    With Zendesk, Magento

Requirements

  • A commerce connector with customer and order records: Shopify, Magento, or BigCommerce
  • A support connector with tickets keyed to a requester: Zendesk, Kustomer, or Gorgias
  • A payments or billing connector with refunds, disputes, or subscriptions per customer: Stripe, Chargebee, or Recurly
  • A customer key that exists in all attached systems, usually email, and the cohort rules
  • An owner per cohort and the comparison rule: which prior cohorts a new one is measured against
Authentication
Read scopes on customers, orders, tickets, and payments in each attached system, and a tag write scope only where you enable the tag proposal.

Limits

  • Shopify customer and order data is protected customer data. Access is granted per app and can be restricted by Shopify.
  • It joins on the key you specify. Customers with different emails across systems appear as different people.
  • Retention is computed from orders and subscriptions it can read. Purchases in channels without a connector are not counted.
  • A cohort note names members. Where privacy rules forbid that, the note carries counts only, and you set that per cohort.

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 Cohort Watch ↗

Questions and answers

What does the cohort owner approve?
The note, and separately any tag or definition change. The note shows the cohort rule, the measure, the prior cohorts it is compared with, and the member list or counts. The owner can approve, narrow the members, or dismiss with a reason.
What is kept for each cohort?
Per period: the members, the counts read from each system, the computed retention and contact rate, the note sent, and any tag written with the time and the approver. Definition changes keep the old rule.
Does it contact customers or issue refunds?
No. It reads orders, tickets, refunds, disputes, and subscriptions. It never sends a message to a customer, creates a refund, or changes a subscription. The outreach list goes to the owner only.
Ask about Cohort Watch

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