LMNT_Discovery_Memo_ReCharge

LMNT — Data source discovery memo — ReCharge (Snowflake RAW.POLYTOMIC_RECHARGE)

Client: LMNT · Audience: Leadership, Analytics, Engineering · Warehouse: Snowflake account OZ69039, database RAW · Profiled: 2026-04-14 (Snowflake CLI lmnt_service; INFORMATION_SCHEMA.TABLES plus CREATED_AT ranges on SUBSCRIPTIONS and CHARGES)

Executive summary

ReCharge holds subscription lifecycle and recurring billing: subscriptions, charges, ReCharge-scoped orders, customers, addresses, payment methods, and supporting reference data. Polytomic lands this in RAW.POLYTOMIC_RECHARGE. It does not replace Shopify for storefront sales; it is the right place for subscription behavior—billing attempts, cadence, and churn-related analysis—once Finance defines revenue rules.

CHARGES and ORDERS are multi-million row facts; SUBSCRIPTIONS is roughly one million rows. Profiling shows CREATED_AT on subscriptions and charges from about May 2019 through April 2026. Some tables show zero rows (for example BUNDLE_SELECTIONS, CREDIT_ACCOUNTS), which usually means unused features or not replicated—not a failed pipeline.

Access and lineage

ReCharge → Polytomic → RAW.POLYTOMIC_RECHARGE. Coordinate keys with RAW.POLYTOMIC_SHOPIFY in staging; do not assume column names imply a safe join.

---

Per-table catalog

Each table below lists metrics, business objective, and questions this table answers.

CHARGES

• Metrics: ~4,287,802 rows. CREATED_AT (non-deleted rows) roughly 2019-05-08 through 2026-04-13. Grain: one row per charge event (many per subscription over time).
• Business objective: Record every billing attempt and outcome for recurring revenue operations and cash timing.
• Questions this table answers:
  • How often do we bill subscribers, and what is the success or failure pattern over time?
  • How does recurring cash timing behave by month or cohort?
  • What charge history supports dunning, retries, or Finance close?

ORDERS

• Metrics: ~3,814,397 rows.
• Business objective: Represent ReCharge’s order objects (not the same as Shopify ORDERS without a join rule).
• Questions this table answers:
  • What does ReCharge consider an order in subscription or hybrid flows?
  • How do ReCharge orders link to CHARGES and SUBSCRIPTIONS?
  • Where must we reconcile to Shopify order ids for a single customer journey?

SUBSCRIPTIONS

• Metrics: ~1,037,277 rows. CREATED_AT roughly 2019-05-08 through 2026-04-13.
• Business objective: Anchor subscription lifecycle: active, paused, cancelled, and historical states for cohort reporting.
• Questions this table answers:
  • How many subscriptions exist or existed, and how does that change by cohort or plan?
  • What is the starting point for churn, expansion, or downgrade analysis?
  • Which subscription connects to which customer and charge history?

ADDRESSES

• Metrics: ~1,440,241 rows.
• Business objective: Store shipping and billing addresses for subscription fulfillment and compliance.
• Questions this table answers:
  • What address did we use for a given subscription or shipment window?
  • How many address rows exist per customer (moves, corrections)?

PAYMENT_METHODS

• Metrics: ~805,002 rows.
• Business objective: Hold stored payment instruments for recurring charges.
• Questions this table answers:
  • Which payment methods are on file for a subscriber (at the level ReCharge exposes)?
  • What is the mix of card brands or methods (where columns support it)?
• Governance: Treat as sensitive; restrict exports and self-serve access per policy.

CUSTOMERS

• Metrics: ~685,732 rows.
• Business objective: ReCharge customer identity for subscriptions and billing.
• Questions this table answers:
  • Who is the subscriber in ReCharge’s model?
  • How do we map ReCharge customer ids to Shopify or Gorgias (via integration fields, not guesses)?

DISCOUNTS

• Metrics: ~41,535 rows.
• Business objective: Discount objects applicable in ReCharge (coupons, rules as modeled).
• Questions this table answers:
  • What discount entities exist for subscription pricing or promotions?
  • How do discounts tie to charges or subscriptions in reporting?

ONETIMES

• Metrics: ~102 rows.
• Business objective: One-time purchase objects in ReCharge (low volume in this snapshot).
• Questions this table answers:
  • Are one-time add-ons material for our business, and how are they recorded?
  • Should this table be excluded from most dashboards given low row count?

PLANS

• Metrics: 23 rows.
• Business objective: Plan master: selling plans, intervals, and labels as ReCharge defines them.
• Questions this table answers:
  • What named plans or SKUs exist for subscription reporting?
  • How do plan ids join to SUBSCRIPTIONS and CHARGES?

COLLECTIONS

• Metrics: 2 rows.
• Business objective: Small grouping construct in ReCharge (confirm in product docs).
• Questions this table answers:
  • What collections or bundles does ReCharge expose here?
  • Is this used in any live reporting, or is it legacy?

BUNDLE_SELECTIONS

• Metrics: 0 rows (snapshot).
• Business objective: Intended for bundle selections if the feature were used.
• Questions this table answers:
  • None in current data; confirm with Revenue Ops whether bundles exist elsewhere.

CREDIT_ACCOUNTS

• Metrics: 0 rows (snapshot).
• Business objective: Would hold credit balance entities if used.
• Questions this table answers:
  • None in current data; confirm whether credits are managed outside ReCharge.

Joins and caveats

• Model cohort and churn from SUBSCRIPTIONS; use CHARGES for payment patterns.
• Document customer id, order id, and checkout id logic for Shopify alignment.
• Finance must own whether subscription revenue for leadership views comes from ReCharge, Shopify, or a blended rule.

Recommended next steps

1. Publish a one-page grain diagram: subscription → charge → ReCharge order → Shopify order.
2. Add relationship tests in dbt after keys are confirmed.
3. Mark zero-row tables inactive in documentation if they remain empty across snapshots.