PLG attribution is high-leverage and easy to break. A single misconfigured webhook can silently double-count trials, miss real conversions, or treat plan upgrades as new trials. Customers usually only notice the bug after a quarter of decision-making on bad data.
The four core events
Trial Started fires the moment a paid subscription is created with a trial period. Use Stripe’s `customer.subscription.created` event, filtered to subscriptions with `trial_period_days > 0`. This is your top-of-funnel PLG event.
Trial Converted fires when a trial actually becomes paid — not when it ends, and not when a new payment shows up. Use `customer.subscription.updated` and filter to status transitions from `trialing` to `active`. This is the only event that captures true trial-to-paid conversion.
New Customer fires the first time a Stripe customer ID makes a successful payment. Use Cometly’s built-in New Customer trigger rather than `invoice.paid` to avoid double-counting against recurring payments.
Recurring Payment uses `invoice.paid` filtered to status = `paid`. This is the event that powers monthly MRR reporting and LTV calculations.
- Trial Started — `customer.subscription.created` with `trial_period_days > 0`
- Trial Converted — `subscription.updated`, status `trialing → active`
- New Customer — built-in trigger, fires once per Stripe customer
- Recurring Payment — `invoice.paid`, filtered to status = `paid`
- Subscription Cancelled — `customer.subscription.deleted` (for churn reporting)
Avoid double-counting
If you’re also using a HubSpot or Salesforce trial/purchase event, turn the duplicate off when you bring Stripe online. Otherwise the same conversion fires twice and inflates every PLG report by 2x.
Verify the setup by running a backtest: pick the last 30 days of Stripe data, count trial conversions in Stripe, and reconcile against the Cometly Trial Converted event count. They should match within 1–2%.
What to watch for.
- Using `invoice.paid` for New Customer
It fires on every recurring payment, which double-counts existing customers. Use the dedicated New Customer trigger.
- Filtering trial conversion on payment amount
Plan upgrades with the same amount get falsely tagged as conversions. Use the `trialing → active` status transition.
- Skipping the backtest
Most setup bugs only surface on real production data. Always reconcile against Stripe’s native dashboard before trusting reports.
- Leaving the HubSpot trial event on
When Stripe events go live, the HubSpot trial event becomes a duplicate. Disable it explicitly.
Recap.
- Trial Started — use `customer.subscription.created` with `trial_period_days > 0`
- Trial Converted — use `subscription.updated` filtered to `trialing → active` status changes
- New Customer — use the dedicated New Customer trigger so first-time payers don’t double-count
- Recurring Payment — use `invoice.paid` for ongoing MRR tracking
- Disable HubSpot Trial / Purchase events when Stripe events are live to avoid duplicates