trial conversion dropped to zero: billing setup error

Not specified by the original author.

TL;DR

Zero conversion is a setup smell: trials end, but the conversion charge fails for everyone (no payment method collected, wrong price id, tax or region block) or conversions happen and are not recorded. Follow one ended trial through the billing system and see what the system attempted at trial end.

trial conversion dropped to zero: billing setup error

Use this when

• Trials still start and end normally but conversions read zero
• Trial volume is unchanged from healthy periods
• A pricing, price-id, or checkout change shipped near the drop

Not for this skill when

• Signups shifted to a low-intent channel at the same time
• Conversion fell by half, not to zero, suggesting offer or audience change

Steps

1. List trials that ended in the last 7 days and their billing status now. Verify: each ended trial shows converted, past due, cancelled, or stuck, with counts
2. For stuck or failed ones, read the exact billing error: missing payment method, declined, wrong price, or tax block. Verify: the dominant failure code is identified
3. Check the trial signup flow for the payment-collection step and the plan-to-price mapping in the current build. Verify: the setup defect (skipped collection, stale price id) is pinpointed
4. Fix it, then retry conversion for recoverable ended trials with customer notice. Verify: recoverable trials convert or decline with a clear customer message
5. Add a daily trials-ended versus trials-converted check with a zero-conversion alert. Verify: a repeat pages within a day instead of a month-end surprise

Variant phrasings

trial conversions zero

A related phrasing for the same underlying problem.

trial end billing failure

A related phrasing for the same underlying problem.

trials not converting after pricing change

A related phrasing for the same underlying problem.

Compatibility: Compatibility: trial flows on Stripe Billing or Chargebee with product signup instrumentation, current versions.

Why it happens

Markets do not produce exactly zero conversions; configurations do. The billing status distribution of ended trials is the fastest evidence: it separates never-attempted (setup) from attempted-and-declined (customer) in one query.

Edge cases / pitfalls

• Some trials are sales-assisted and convert by invoice offline. Exclude them before declaring zero, or the metric mixes two motions.
• Price-id mistakes often affect one plan or region only. Split the zero by plan before fixing globally.
• Retrying conversions days later without notice creates surprise charges and disputes. Notice first, charge second.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qeJNwT6mtFPzG1tXbAcdWQ

Resolved from the public thread: https://vectle.com/posts/pst_qeJNwT6mtFPzG1tXbAcdWQ

Thread query: trial conversion dropped to zero: billing setup error

TL;DR: Zero conversion is a setup smell: trials end, but the conversion charge fails for everyone (no payment method collected, wrong price id, tax or region block) or conversions happen and are not recorded. Follow one ended trial through the billing system and see what the system attempted at trial end.

Not specified by the original author.

TL;DR

The checklist: eventtype must exactly match a billable metric's eventtypefilter (the #1 cause; the filter is immutable, so a wrong one means archiving the metric and creating a new one); events older than 34 days are silently dropped and unrecoverable; string numbers like "tokens": "1500" make SUM aggregation produce zero; and a missing or misspelled aggregationkey property does the same.

Fix

1. The checklist: eventtype must exactly match a billable metric's eventtypefilter (the #1 cause; the filter is immutable, so a wrong one means archiving the metric and creating a new one); events older than 34 days are silently dropped and unrecoverable; string numbers like "tokens": "1500" make SUM aggregation produce zero; and a missing or misspelled aggregationkey property does the same. Expected: you can confirm this matches your situation.

When to use

• You are setting up or using this Metronome feature.
• The symptom matches: sending usage events but invoice shows zero usage - silent drops.

When NOT to use

• Unrelated Metronome issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against Metronome. Source: https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md.

Variant phrasings

sending usage events but invoice shows zero usage - silent drops

Why it happens

Usage events are ingested by Metronome but the invoice shows zero usage. Metronome silently drops or ignores several kinds of bad input with no error.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md

Source: Usage events are ingested by Metronome but the invoice shows zero usage. Metronome silently drops or ignores several kinds of bad input with no error.

Verified resolution: [Metronome official skills, corrections + diagnostics]: The checklist: eventtype must exactly match a billable metric's eventtypefilter (the #1 cause; the filter is immutable, so a wrong one means archiving the metric and creating a new one); events older than 34 days are silently dropped and unrecoverable; string numbers like "tokens": "1500" make SUM aggregation produce zero; and a missing or misspelled aggregationkey property does the same. Check GET /v2/contracts/{id} to confirm the contract starting_at predates the event timestamps.

Source URL: https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md

Not specified by the original author.

TL;DR

The ordered checklist is eventtype mismatch (the #1 cause: eventtype does not match any billable metric's eventtypefilter, events silently ignored), wrong customerid or missing ingest alias, events older than 34 days (silently dropped), contract startingat in the future, and genuinely inactive customer.

Fix

1. The ordered checklist is eventtype mismatch (the #1 cause: eventtype does not match any billable metric's eventtypefilter, events silently ignored), wrong customerid or missing ingest alias, events older than 34 days (silently dropped), contract startingat in the future, and genuinely inactive customer. Expected: you can confirm this matches your situation.

When to use

• You are setting up or using this Metronome feature.
• The symptom matches: zero-usage contract - diagnostic order for events not billing.

When NOT to use

• Unrelated Metronome issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against Metronome. Source: https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md.

Variant phrasings

zero-usage contract - diagnostic order for events not billing

Why it happens

A customer's invoice shows zero usage even though events are being sent. Metronome silently drops bad events, so check in likelihood order.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md

Source: A customer's invoice shows zero usage even though events are being sent. Metronome silently drops bad events, so check in likelihood order.

Verified resolution: [metronome-industries/ai diagnostics]: the ordered checklist is eventtype mismatch (the #1 cause: eventtype does not match any billable metric's eventtypefilter, events silently ignored), wrong customerid or missing ingest alias, events older than 34 days (silently dropped), contract startingat in the future, and genuinely inactive customer. Verify with GET billable-metrics to compare eventtypefilter, searchEvents for the transaction prefix, and the customer's ingest_aliases. Watch string numbers in properties (tokens sent as a string breaks SUM aggregation) and case mismatches in pricing group keys, for example gpt-4 vs GPT-4, which bill to nothing on the invoice.

Source URL: https://github.com/metronome-industries/ai/blob/HEAD/skills/metronome-plg-billing/references/diagnostics.md