The problem with disconnected data
Your product knows everything about how customers use your app — which features they adopt, how often they log in, where they drop off. Your billing system knows everything about revenue — MRR, subscription status, invoices, payments.
But without a shared key linking them, these two datasets live in separate silos. You can't answer questions like "which accounts are at risk of churning based on their product usage?" or "which features correlate with expansion revenue?" — because there is no way to join the data.
The correlation key: group_id
ThriveStack uses a single field — group_id — as the correlation key between product telemetry and billing data. It represents the paying account or organisation in your system (e.g. organization_id, account_id, workspace_id).
The same group_id value must be present in two places:
- Product telemetry — passed as
group_idin yourthrivestack.group()calls - Stripe customers — set as
metadata[group_id]on every Stripe customer object - Chargebee customers — set as
meta_data[group_id]on every Chargebee customer object
When the same value appears on both sides, ThriveStack joins the two datasets at the account level automatically — no manual mapping required.
How group_id flows
The group_id originates in your product and must be set as customer metadata in each billing provider with the exact same value.
| Account | Journey | MRR | Status |
|---|---|---|---|
| Monday.com | 1/2 activated | $2,800 | Active |
| Miro | 1/2 activated | $3,200 | Active |
| Figma | 0/2 activated | $6,000 | Failed |
| Linear | 2/2 activated | $950 | Active |
| Airtable | 2/2 activated | $2,200 | Past due |
What this unlocks
Once both sides carry the same group_id, ThriveStack can correlate product behaviour with revenue outcomes for every account. This powers:
Churn Risk Signals
Accounts whose product usage is declining while still paying. Flag before the cancellation happens.
Contraction Signals
Accounts downgrading or reducing seats. Correlate the revenue drop with the product usage drop that preceded it.
Expansion Signals
Accounts hitting usage limits or activating high-value features — ready to upgrade. Surface them before they ask.
Full Bow-tie Model
Map every account from first marketing touch → product activation → revenue → expansion or churn. End-to-end visibility.
The one rule
Thegroup_idvalue must be exactly identical in both places. Format, casing, and type must match —"Org_ABC123"and"org_abc123"are treated as different accounts. A mismatch silently breaks revenue attribution with no error message.
Exceptional use cases
Chargebee + Stripe as payment gateway
Some businesses use Chargebee for subscription management while routing payments through Stripe as the underlying payment gateway. On top of that, Stripe may also receive direct platform-level charges — for example, a marketplace that takes a percentage cut from customer transactions outside of the subscription cycle.
In this setup, you must connect both the Chargebee connector and the Stripe connector to ThriveStack in order to ingest all transaction data — Chargebee captures subscription events, while Stripe captures the direct marketplace/platform-fee transactions that never flow through Chargebee.
Potential duplicate transactions
When Chargebee uses Stripe as its payment gateway, subscription payments are recorded in both systems — once in Chargebee (as an invoice/transaction) and once in Stripe (as a charge). If both connectors are active, ThriveStack may ingest the same subscription transaction twice, inflating MRR and ARR figures.
The direct Stripe transactions (platform cuts, marketplace fees) do not appear in Chargebee at all — those must come from the Stripe connector. But the overlap on subscription payments creates a deduplication challenge.
We're working on this
ThriveStack is actively building automatic deduplication for the Chargebee + Stripe gateway scenario. Once released, duplicate subscription transactions will be collapsed into a single record so your revenue metrics stay accurate.