Chargebee Retention calculates Saves as any customer who does not complete a cancel from the Chargebee Retention Page within 30 days of first landing on the Chargebee Retention Page. But what if a customer cancels another way? What if they land on the Chargebee Retention page to cancel, then simply let their renewal date expire, or remove their credit card information? If you're connected to one of our billing integrations, currently supporting Chargebee Billing, Stripe and Recurly, you can validate Chargebee Retention saves against that customer's account in your billing system.
Save Validation works by cross-checking your billing system for every Save to identify if a customer still has an active, non-canceled subscription 30 days after their initial deflection. With Save Validation, Chargebee Retention only reports on valid saves in Chargebee Retention Reports, and show the Validation Status for each Customer that hits your Chargebee Retention Page in the Customers Reports.
Chargebee Retention uses the Billing_ID field provided in the exit session via the Chargebee Retention.JS or Salesforce Integration to match up when your customer visits the Cancel Page to the subscription in your billing system.
We compare both the status and key dates on the subscription with the exit session to determine if the customer was really saved. The table below details each possible status with the description of what happened in each instance, and the outcome we present.
| SAVES | ||
| Status | Description | Outcome |
| Valid Save | The subscription is still active and has not been set to cancel when the save event occurs. | Saved |
| Invalid Save | The subscription was canceled between the session and the save event, meaning that the save was not valid. | Canceled |
| Expired Pre-Chargebee Retention | The subscription was expired before the session and therefore they were not a paying customer when the session occurred. | Unknown |
| Canceled Pre-Chargebee Retention | The subscription was set to cancel before the session but did not expire until after it and thus was still a paying customer when they visited Chargebee Retention. | Canceled |
| Activated Post-Chargebee Retention | Subscriptions that are activated after the Chargebee Retention Exit Session, either through a winback campaign or some other means. | Unknown |
| No Match | When we cannot match an Exit_Session to a Subscription record. | Unknown |
| Cancels | ||
| Status | Description | Outcome |
| Valid Cancel | The subscription is still active when the exit session occurs. | Canceled |
| Canceled Pre-Chargebee Retention | The subscription was set to cancel before the session but did not expire until after it and thus was still a paying customer when they visited Chargebee Retention. | Canceled |
| Expired Pre-Chargebee Retention | The subscription was expired before the session and therefore they were not a paying customer when the session occurred. | Unknown |
| No Match | When we cannot match an Exit_Session to a Subscription record. | Canceled |
We use the results of the Status field to determine the true outcome of each Chargebee Retention exit session, and update the Chargebee Retention database to report invalid saves as Cancels. We also update the expired Pre-Chargebee Retention cancels to Unknown and remove the cancel value for these accounts since we can only confirm that they were a past customer.
We treat Saves we cannot match to subscriptions as Unknown status and remove the save from all of our reporting. We do not remove unmatched Cancels as we know that the customer visited the page and tried to cancel. Unmatched Cancels will not have revenue values associated with them as we can't cross check the billing system for MRR.
In addition to validating saves, we also check against your billing system for customers on the Watch List. All of the validation status and outcomes that apply to Saves apply to our cross-check for Watch List customers.