Stripe Metadata & Paddle Custom Data: Beyond Revenue Analytics

Most guides to Stripe metadata - including ours - focus on revenue questions: which acquisition channel has the best LTV, whether annual plans churn less than monthly. Those are good questions. But they're not the only reason to use metadata, and treating metadata as purely a revenue-segmentation tool undersells what it actually is: a general-purpose key-value store that happens to live next to your billing data.

Whatever you've been storing in Stripe metadata or Paddle custom data - onboarding status, support tier, feature flags, NPS score, integration type, anything - you can explore it in Chartsy the same way, whether or not it has anything to do with money. Sometimes the answer you want isn't "how does this affect MRR." Sometimes it's just "how is this distributed across my customers."

Metadata Isn't a Billing Concept - It's a Storage Concept

Stripe metadata and Paddle custom data are both flexible key-value stores attached to customer, subscription, and transaction objects. Stripe calls the field metadata; Paddle's Billing API calls it custom_data - both accept arbitrary JSON key-value pairs, and neither cares what you put there.

// Paddle: custom_data on a customer object
{
  "email": "user@example.com",
  "custom_data": {
    "onboarding_status": "activated",
    "csm_owner": "sarah",
    "integration_type": "zapier",
    "nps_score": "9"
  }
}

Because these fields exist on the object regardless of what's in them, it's easy to fall into the assumption that they're "for" revenue segmentation - acquisition source, plan type, coupon code - because that's the most commonly documented use case. It's not the only one. If your product stores any structured fact about a customer, subscription, or transaction, that fact can live in metadata and be queried the same way.

Non-Billing Fields Worth Tracking

A few examples teams store in Stripe metadata or Paddle custom data that have nothing to do with pricing or acquisition:

onboarding_status - not started, in progress, activated. Useful for understanding where customers get stuck, independent of what they're paying.
feature_flags or enabled_features - which parts of the product a customer has turned on. Reveals adoption patterns that have nothing to do with plan tier.
csm_owner or support_tier - who owns the account internally, or what level of support they're entitled to.
nps_score or csat_rating - the last satisfaction score recorded for that customer.
integration_type - which third-party tool a customer connected (Zapier, native API, Slack, etc.).
referral_partner - which partner or affiliate introduced the customer, separate from paid acquisition tracking.
ab_test_cohort - which variant of an experiment a customer was assigned to.
persona or role - how the customer self-identified during onboarding (e.g., founder, marketer, developer).

None of these are revenue fields. All of them are still queryable the moment they're indexed.

Just Show Me the Distribution

Sometimes you don't want a revenue cross-tab at all - you just want to know how a field is spread across your customer base. That's a valid, complete question on its own, and it's the simplest thing Chartsy's Metadata Analytics does: index a field, and immediately show you the count and percentage breakdown of every value it contains.

Ask ChartsyAI something like:

"What's the distribution of onboarding_status across my customers?"
"How many customers have integration_type set to zapier vs. native?"
"Show me the breakdown of persona across all accounts."
"What percentage of customers have an nps_score recorded at all?"

No MRR, no churn, no dollar figure anywhere in the answer - just a count-based view of how your customer base is actually composed on a field that matters to your team, even if it has no direct billing implication.

You Can Still Cross It With Revenue - When You Want To

The distribution view is useful on its own, but nothing stops you from combining a non-billing field with a revenue question later, once you have a reason to. That's the advantage of indexing everything rather than only "revenue-relevant" fields upfront - you don't have to predict in advance which field will end up mattering for a retention or growth question.

"Is churn rate different between customers with onboarding_status = activated vs. not started?"
"Do customers with an nps_score below 6 churn faster than customers above 8?"
"What's the MRR distribution across integration_type - is zapier or native higher value?"

These are still revenue questions, but they start from a field that was never designed for revenue analysis in the first place. The field just had to exist and be populated - Chartsy doesn't need you to declare in advance whether a field is a "billing" field or not.

How Chartsy Indexes It

The mechanics are the same regardless of what the field is used for. Chartsy reads every metadata key present in your Stripe or Paddle data during sync - customer fields, subscription fields, transaction fields - and indexes it automatically. There's no schema to define and no need to mark a field as "for analytics" ahead of time. If the key exists on the object, it becomes a queryable dimension the next time your account syncs. See the full mechanics on the Metadata Analytics feature page.

Object	Stripe field	Paddle field
Customer	`metadata`	`custom_data`
Subscription	`metadata`	`custom_data`
Invoice / Transaction	`metadata`	`custom_data`

Frequently Asked Questions

Does metadata have to be related to billing to be useful in Chartsy?

No. Chartsy indexes every metadata or custom_data field it finds, regardless of what it contains. A field like onboarding_status or nps_score is just as queryable as acquisition_source - you can view its distribution on its own or cross it with revenue metrics later.

What's the difference between Stripe metadata and Paddle custom data?

They're functionally the same concept with different names. Stripe calls the key-value store metadata; Paddle's Billing API calls it custom_data. Both attach to customers, subscriptions, and transactions, and both accept arbitrary JSON key-value pairs.

Can I see the distribution of a field without tying it to revenue?

Yes - asking for a distribution or breakdown of a metadata field returns counts and percentages per value, with no revenue figures involved unless you specifically ask for them.

Do I need to tell Chartsy which fields are "analytics" fields?

No. Every metadata or custom_data field present on your synced objects is indexed automatically. There's no field registration step or schema to define ahead of time.

What if a field is only populated on some customers?

Chartsy shows the distribution based on whatever data exists, including how many records have the field missing or empty. Partial data is still usable - you just see the gap alongside the populated values.

Final Thoughts

Metadata's value isn't limited to the acquisition-source-and-plan-type playbook most guides default to. If you're already storing operational, product, or customer-success context in Stripe metadata or Paddle custom data, that data is already indexable and explorable - on its own, or alongside revenue, whichever question you actually have.

Connect Stripe or Paddle and explore your metadata →