Docs
Lifecycle Offers is currently available as part of the Early Adopter Program (EAP).
Chargebee's lifecycle engagement solution supports multiple presentation modes for offers. Each of these presentation modes is used for a different use case and is, therefore, available based on the play configurations. Below are various types of options that are supported.
Modals are the most intrusive from a subscriber experience standpoint. They can be used to showcase information that needs user attention and focus. For example, display a modal with various plan options to upgrade your customer to a paid plan once the trial expires or display a modal with various plan options when your customer clicks a button for upgrading to the paid plan.
Popups are less intrusive than modals as they let your customer continue accessing different parts of the page and remain on the page until the user interacts with them. For Example, a popup can be displayed to encourage your customers to complete a renewal on time by providing them with incentive or non-incentive-based offers.
Banners are the least intrusive of the components, taking up very little space on the page and letting your customers continue accessing different parts of the website. For Example, a banner informing your customers about complementary products and services could be displayed and redirect users to a landing page with more details about those products and services.
The end subscriber actions for plays that are used proactively to present offers to the target subscribers are described below.
Any subscriber who is presented with an offer from the play can take three actions regarding the offer.
View the offer: Subscribers may choose to view the offer and ignore it if they want it to appear again when they login next time.
Accept the offer: If the subscriber is interested in the offer, they may click on the offer call to action (CTA) to accept it.
Reject the offer: If the subscriber is not interested in the offer, they may choose to close this by clicking on the close[x] button.
Users can choose to view the offer within their context and take no immediate action. In such a case, the same offer will be presented to the user every time play is triggered, provided the user is still eligible for the offer.
It is possible that multiple users belonging to the same customer may view the offer, e.g. in a B2B businesses. In such a case, the offer will be presented to each user, provided they meet the offer eligibility criteria. Each user can view the offer as many times as they like and for as long as they wish before taking action on it.
Users accept the offer by clicking on the offer and accepting the call to action (CTA) in the offer. Depending on the configuration, specific actions may be performed when the user clicks on the accept offer CTA.
Once a user accepts the offer as part of the play execution, the subscriber is marked ineligible for any offers from the same play.
If there are multiple users belong to the same customer, e.g, in B2B business, the offer is considered accepted for all users even if one of the users accepts it. I.e. Upon offer acceptance, all users of that customer are marked ineligible for any offers from the same play.
However, these users can still be presented with offers as part of a different play only after the cool-down period associated with offer acceptance has elapsed.
Users can choose to reject the offer presented to them. If a user rejects the offer, the same offer from the same play is not presented to the user again. It is possible that multiple users belonging to the same customer ID visit the app with their own unique logins (B2B scenario). In such a case, all the other users of the customer who have not yet accepted the offer can continue to be presented with the eligible offer from the same play to maximize offer acceptance.
The user who rejected the offer earlier will not be shown any other offer until the cool-down period has elapsed. In such a case, the user who rejected the offer will continue seeing no offer from the eligible play. However, once the cool-down period is over, the user can be shown the offer from the next eligible play. All the other subscribers however can still continue to be shown the offer from the previous play till they accept or reject the offer.
In order to control the number of offers that are being presented to a user, you can configure the cool-down period both for offer acceptance and offer rejection. The cool-down period is used to specify the amount of time that should elapse before a particular user who has earlier accepted or rejected the offer sees another any other offer as part of the play execution. In the case of offer acceptance, the cool-down period is applicable at a customer level, and no user of the customer sees any other offer till the cool-down period for offer acceptance has elapsed.
In case of offer rejection, the cool-down period is applicable at a user level and that too only for the user who has rejected the offer. All the other users of the customer can continue to see the offers from the same play till they accept or reject the same.
The cool down period is configured at an application level and is specific to each application. By default the value is set to 24 Hours however this can be changed based on the business requirement.
Lifecycle Engagement's play eligibility logic automatically resolves the best possible play that needs to be executed for each customer to present the offer.
In order to find the eligible play for the customer, we first need to identify a unique subscription belonging to the customer to which the offer can be applied. For this, we rely on the customer ID provided to us when initializing the SDK for lifecycle engagement. More on this here .
Once we have the customer ID we query for the active subscription of the customer in the billing site and evaluate each play against the active subscription of the customer. As soon as eligible play for the subscription in context is found, we pick up the play and further evaluate the eligible offer that can be presented to the subscriber. If an offer is found, the same is returned to the SDK for presentation purposes, else no offer is returned to the SDK.
If more than one play is found after matching the play audience criteria, the play's priority score is used to resolve the conflict. The play with the highest priority is picked up for further evaluation purposes. Learn more about prioritizing plays.
This play evaluation process continues until all the eligible plays for the subscriber are evaluated. If, after evaluating all the plays for the subscriber, the offer is not found, no offer is returned to the SDK.
It is possible that a customer has multiple active subscriptions within the billing system. In such a case, the above process is repeated for each subscription until an offer is found. Once an offer is found, it is returned to the SDK and displayed to the subscriber in context. The subscriber ID for which the offer is recorded for offer processing purposes if the user chooses to accept the offer. If after evaluating all the subscriptions of the customer, no eligible offer is found then no offer is returned to the SDK.
Evaluating eligible plays for a customer that has many active subscriptions can be time-consuming. This can have an adverse impact on the subscriber experience and delay displaying offers to the end subscriber. To ensure optimum performance, always ensure that you are specifying your play audience to identify each subscriber uniquely. E.g. if a customer has multiple subscriptions with different plans, use the plan ID in the audience builder to only execute the play for subscriptions that have a specific plan.
Another option to optimize performance is to send us the subscriber ID along with the customer ID as part of the SDK initialisation process. This will fast-track the play eligibility process by preventing unnecessary evaluation for other subscriptions belonging to the customer.
