> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/audience-and-activation/automate/post-purchase-engagement.md).
# Post-purchase engagement
Scenarios that fire after the conversion: satisfaction surveys, anniversaries, rewards, and churn prevention.
## Your goal
Act on users **after** they converted or engaged - to measure satisfaction, to reward loyalty, to bring back someone drifting away - rather than to push them towards a first conversion.
## Expected outcome
An active automation triggered by a completed action or by segment membership, which reaches the user through the right channel at the right moment.
## When this is useful
Four worked scenarios, all built from the same components. Read the one closest to your case, then the table at the end for the general shape.
## Post-purchase satisfaction
{% hint style="info" %}
**The scenario.** Abra Inc is a pure player in the flower industry, focused on customer experience, and wants to measure it. They want to push a Net Promoter Score survey link to clients who recently purchased flowers.
{% endhint %}
The automation should add users who purchased, wait a day or more before sending a complementary communication, then send an NPS email with a link to a survey.
{% stepper %}
{% step %}
### Trigger on the purchase
Entry is triggered by a `$transaction_confirmed` event.
{% endstep %}
{% step %}
### Wait a day
The **Wait** node is configured to **1 day** - long enough for the order to have been experienced, short enough for the memory to be fresh.
{% endstep %}
{% step %}
### Send the survey
The **Send email** node is configured to send the NPS mail with the attributes you need.
{% endstep %}
{% step %}
### Add an exit condition
An exit condition on a `$transaction_confirmed` event makes users leave the automation.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Note that here the *same* event both triggers entry and forms the exit condition. That is deliberate: a user who purchases again while waiting leaves the scenario, and so becomes eligible to enter it afresh for the newer order. Without it, the [re-entry rule](/audience-and-activation/automate/automations-reference/triggers.md#re-entry) would keep them parked.
{% endhint %}
## Last order anniversary
An anniversary communication - a notification, an email, an SMS - to a client, with a discount voucher for example. It needs no new implementation pattern: it is the wait-then-send shape of the scenarios above, with the wait sized to the anniversary rather than to hours.
## Rewarding frequent readers
{% hint style="info" %}
**The scenario.** News Inc is a major app publisher and likes rewarding the subscribers who read most - typically by pushing a free special edition. A user counts as a frequent reader if they read **over 30 articles a month**.
{% endhint %}
There are two ways to build it, which is instructive in itself.
{% tabs %}
{% tab title="Segment first" %}
* Trigger the automation on **entry into the segment** "Frequent readers" - users who have read more than 30 articles on the app.
* Configure a **Custom action** node to push a notification containing a link to the special edition.
Creating the segment before implementing the automation makes the setup easier, and gives you an audience you can inspect and reuse.
{% endtab %}
{% tab title="Event first" %}
1. Create an automation triggered on a specific event from your schema - here, "page displayed".
2. Add an **If** condition node.
3. Configure the If node for the fact that readers should have consulted at least 30 articles over a month.
4. Add a **Custom action** node on the true branch, to push the notification.
This keeps the logic inside the scenario, at the cost of evaluating it per event rather than once per computation.
{% endtab %}
{% endtabs %}
{% hint style="info" %}
There can be multiple ways to design automations that lead to the same result. Prefer the segment-first version when the audience is useful on its own; prefer the event-first version when the condition is specific to this scenario.
{% endhint %}
## Preventing subscriber churn
{% hint style="info" %}
**The scenario.** News Inc wants to address a special communication to potential churners. A user counts as a churner if they have **not read an article over the last month**.
{% endhint %}
Again two setups, and here the difference is which side of the boundary you watch.
{% tabs %}
{% tab title="On segment exit" %}
* Trigger the automation on **segment exit**, from a segment of users who have read at least one article over the last month.
* Configure a **Custom action** node to push notifications containing special content.
You are watching people fall out of the engaged audience.
{% endtab %}
{% tab title="On segment entry" %}
* Trigger the automation on **segment entry**, into a segment of users whose last article reading date is more than 30 days ago.
* Configure a **Custom action** node to push notifications containing special content.
You are watching people arrive in the disengaged audience.
{% endtab %}
{% endtabs %}
Both use segment triggers, so both run at the pace of [segment computation](/audience-and-activation/build-your-audiences/segment-reference.md#counting-is-not-persistence) - which is appropriate here, since a month-long inactivity window does not need minute-level reaction.
## The general shape
| Scenario | Trigger | Flow control | Action |
| -------------------------- | ----------------------------------------- | ------------------------------ | ------------------------------- |
| Post-purchase NPS | `$transaction_confirmed` event | Wait 1 day | Send email |
| Last order anniversary | The purchase event | Wait, sized to the anniversary | Send email, notification or SMS |
| Rewarding frequent readers | Segment entry, or an event plus an **If** | - | Custom action |
| Preventing churn | Segment exit, or segment entry | - | Custom action |
{% hint style="warning" %}
Two constraints apply to every one of them:
* **Custom actions are in alpha.** Contact your Account manager to enable them. See [Custom action](/audience-and-activation/automate/automations-reference/actions.md#custom-action).
* **Email frequency capping defaults to 1 email per user every 13 months.** An anniversary scenario survives that default; an NPS scenario on repeat purchasers does not. See [Frequency capping](/audience-and-activation/automate/automations-reference/actions.md#frequency-capping).
{% endhint %}
## Verification
Test each scenario by forcing a user through with the **Test** button, and read the notifications in that user's timeline. Once live, use the per-node counters - remembering they count passages, not unique users. See [Lifecycle, testing & analytics](/audience-and-activation/automate/automations-reference/lifecycle-testing-and-analytics.md).
## Related pages
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.mediarithmics.io/audience-and-activation/automate/post-purchase-engagement.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.