Skip to main content
A post-action reward turns a moment of accomplishment into a gift. The user just did something worth celebrating (finished a purchase, kept a streak alive, hit a level), and your app says congratulations with a premium brand offer: a real perk a brand funds to acquire customers, presented as part of your celebration screen, and you earn a bounty on each server-verified activation. This page is the canonical description of the use case; Integration surfaces routes you to the walkthrough for the surface you build on.

The moment

The trigger is an achievement your app already detects:
  • A completed purchase: the checkout success or thank-you screen.
  • A milestone or streak: the user’s seventh consecutive day, a finished course, a cleared level, a savings goal reached.
These moments share three properties that make them ideal reward surfaces: the user is in a positive state, the screen is one your app fully controls, and your own code already fires at exactly the right instant, with no detection machinery needed from Encore.

The mechanic

The reward is a premium brand offer, paid for by the brand, never by you. A brand funds the perk (a free trial, a discount) as its cost of acquiring a customer; your app supplies the moment and the audience. You render the offer as part of your congratulations UI (“You did it, here’s something on us”), the user claims it by tapping through, and the brand fulfills it on their side. There is no coupon inventory for you to buy and no reward budget for you to hold. One use case, room for more than one screen. post-action-reward names the moment, not the layout. Encore renders the celebration screen suited to the moment, and further layouts, such as one tuned for a purchase thank-you, can be added inside the same use case later. Your call site does not change when that happens: you keep naming the moment, and Encore keeps choosing what to draw.

The economics

Revenue from this use case lands in the brandOfferRevenue metric: a CPA bounty, paid per verified activation. Two rules govern how it’s counted:
  • A claim is not a conversion. A claim means the user tapped through to the brand. Nothing pays out on a claim.
  • Activation is server-verified. The bounty is earned only when the brand-side completion is verified on Encore’s servers. Your app never attests to a conversion, which is why the economics survive scrutiny.

Integration surfaces

There is nothing to turn on. Your app is granted its use cases when the app is created, so post-action-reward is available to every surface below from your first call. If a request resolves as unavailable, read it the way you’d read the churn-intervention sheet resolving that way: no eligible offers right now, or the user is in the measurement control cohort. It never falls back to a paywall screen, because a purchase ask on a “you did it!” moment is exactly what this use case exists to avoid.
Choose by who renders the offer. The API gives you the reward as data and you draw it yourself, which works on any platform including server-side and is the only option when the moment lives outside an app. Both the native SDKs and the Web SDK hand rendering to Encore: you tell it the moment happened and it presents the celebration screen, so there is no UI for you to build or maintain. Handing over the rendering doesn’t mean handing over the words: every SDK, web and native alike, lets you set the headline and subheadline at the call site, so the sheet can name the moment that triggered it. Where the copy comes from has the resolution order.

Where the copy comes from

Presentation time is where you set the copy. You supply the finished string for one presentation, on every SDK and on both use cases. On the native and bridge SDKs that is .headline() and .subheadline() on the placement builder:
On the Web SDK the same two slots are flat placement options rather than builder methods:
The flat web options require the current @encorekit/web-sdk 2.x release; upgrading an existing integration: Updating to 2.x.
Beneath that override the sheet falls back to copy Encore resolves for your app, and beneath that to the copy shipped with the screen. Three sources, strict priority order, 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. An empty or whitespace-only string falls through to the next source rather than clearing the line, so it is never a way to render a headless sheet. That is deliberate: it keeps a `Nice work, ${name}!` template from collapsing into a blank heading when name comes back empty. To deliberately show less, omit the override rather than passing ''. Leave both unset and Encore’s shipped default renders: 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 unconfigured app shows nothing. The default is streak-shaped even though this use case also covers purchases, milestones, and levels, which is one good reason to set your own.
Watch for accent markup in copy you didn’t write, especially on web. The shipped default 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. Passing your own headline and subheadline sidesteps the question everywhere, since you control every character that reaches the sheet. On web that is the fix rather than a stopgap: the Web SDK has no accent-run rendering to wait for, so plain text is what it renders.
A per-call override outranks the copy Encore resolved for your app. If a screen shows something other than the copy configured for the app, check whether the call site sets a headline or subheadline. The per-call 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 at one call site keeps winning after the app’s configured copy changes.