Skip to main content
Every integration surface (the Web SDK’s useCase option, the iOS and Android SDKs, the Encore API) reads the same per-app setting. Ask for a use case your app isn’t enabled for and the request is still well-formed, so nothing fails loudly: the SDK logs sdk_offer_presentation_failed with reason use_case_unavailable and resolves as unavailable (the exact result shape varies by SDK). This page is the cross-platform reference for what “enabled” means and how to get there.
This page describes both use cases that exist today: Reduce Churn (churn-intervention) and Reward Users (post-action-reward).

​
Reduce Churn is on by default, no action needed

Every app is enabled for churn-intervention from the moment it’s created, with no setup step. An app with no explicit configuration for this use case still serves it: that row’s absence means “on,” not “off,” which is what makes every existing SDK integration byte-identical to before this dimension existed. If you’re only using the paywall/cancel-flow offer sheet, there is nothing to enable.

​
Reward Users needs an explicit enable

post-action-reward is off by default. An app with no row for it resolves every request as not-enabled, so the SDK no-ops rather than falling back to the churn-intervention experience. This is deliberate: showing a purchase-ask offer sheet on a “you did it!” moment is exactly the failure mode the Reward Users use case exists to avoid.

​
Turning it on

Open the app in your Encore dashboard, go to the Analytics view, and find Placements by use case → Turn on Reward Users. The write is additive, so it never touches the churn-intervention configuration you already have working, and idempotent, so turning on a use case that’s already on succeeds rather than erroring. Behind the button is POST /publisher/portal/v1/apps/{appId}/use-cases.
This button is rolling out. If your dashboard doesn’t show it yet, reach out to your Encore contact and they’ll turn the use case on for your app.
Ask for copy without accent markup, especially on web. Encore’s shipped default reward headline uses the SDKs’ inline accent syntax (asterisks around the run to emphasize, as in *gift*), and support for it is uneven right now:Until that evens out, a surface that doesn’t support the syntax shows the asterisks on screen. Ask your Encore contact to set copy without the markup when they turn the use case on for you. On web that is the only way to avoid them, because the Web SDK has no accent-run rendering to wait for.

​
What “enabled” gets you

Once enabled, a post-action-reward request resolves normally instead of unavailable, and the offer sheet renders using:
  • A headline and subheadline, customizable per app. Setting them is not self-serve yet: the dashboard has no copy editor, so ask your Encore contact to set them when they turn the use case on. Leave them unset and Encore’s shipped default is used: headline Congrats! We got a *gift* for you both to celebrate your 30-days streak!, subheadline Choose one of our partner offers below. Both render even unconfigured, so don’t assume an unset app shows nothing. Two reasons to set your own anyway: the default is streak-shaped even though the use case also covers purchases, milestones, and levels, and its asterisks are the accent markup from the preceding warning, which most surfaces still render literally.
  • The offers your app is otherwise eligible for. Turning the use case on doesn’t change which campaigns can serve; it only turns on the surface itself.

​
Where the copy comes from

The headline and subheadline on the sheet resolve from up to three sources, in strict priority order. The first one set wins, and each field resolves on its own, so setting only the headline leaves the subheadline to fall through: You pass the finished string, so the wording, the tone, the pluralization, and any emoji are yours to decide. There is no streak-count or milestone-count parameter: Encore never assembles a sentence out of a count. A blank override is not an override, so the chain falls through to the next source rather than rendering an empty line.
A per-call override beats dashboard-configured copy. If a screen shows something other than what you set in the dashboard, check whether the call site passes .headline() or .subheadline(). The SDK value wins every time. That is deliberate, so a single placement can speak to the moment that triggered it, but it does mean a stray override outranks anything your team configures later in the dashboard.

​
Declaring it in your Setup guide is a separate, cosmetic step

Project Settings → Outcomes lets you declare which use cases your project is building toward; this personalizes which rungs your Setup guide shows, nothing more. Picking “Reward Users” here does not turn the use case on for your app; that’s the separate per-app step this page describes. Outcomes answers what a project is building; the per-app enable step answers “is it actually on.” Today, you need both, and neither implies the other.