Scope
How to validate 'saves' against the billing system?
How to map a subscription to an exit session?
What if my customers land on the Retention page to cancel, then simply let their renewal date expire, or remove their credit card information?
Summary
Retention calculates Saves as any customer who does not complete a cancel from the Retention Page within 30 days of the first landing on the Retention Page. If your customer cancels it using another way, it is important for you to know this. If you're connected to one of our billing integrations, currently supporting Chargebee Billing, Stripe and Recurly, you can validate 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, Retention only reports on valid saves in Retention reports and shows the validation status for each customer that hits your Retention page in the customer's reports.
Solution
Save Validation is a three-step process:
- Mapping the subscription to an exit session (i.e. when a customer lands on your Retention Page)
- Deriving the validation status
- Updating the session outcome (Saved, Canceled)
Exit session to subscription mapping
Retention uses the Billing_ID field provided in the exit session via the Retention.JS or Salesforce integration to match up when your customer visits the cancel page to the subscription in your billing system.
Deriving validation status
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-Retention | The subscription was expired before the session and therefore they were not a paying customer when the session occurred. | Unknown | |
| Canceled Pre-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 Retention. | Canceled | |
| Activated Post-Retention | Subscriptions that are activated after the 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-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 Retention. | Canceled | |
| Expired Pre-Retention | The subscription 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 | |
Updating the session outcome
We use the results of the Status field to determine the true outcome of each Retention exit session, and update the Retention database to report invalid saves as Cancels. We also update the expired Pre-Retention cancels to Unknown and remove the cancel value for these accounts since we can only confirm that they were a past customer.
Note: 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.
Validation for Watch List customers
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.