Daily churn-risk re-engagement emails from Mixpanel

Every weekday at 7am, find paying users in Mixpanel who look like they are about to churn and send each one a short, personalized re-engagement email through Customer.io. Build this as an agent workflow.

Inputs the user configures:

- Mixpanel project and credentials.

- Customer.io account and the transactional message template ID to send.

- The key event name that defines 'engaged' (for example 'Created Report').

- Active window (default 60 days) and inactivity window (default 14 days).

- Daily send cap (default 50).

- Dedupe window (default 7 days) and the Mixpanel profile property name used for dedupe (default last_reengagement_email_at).

What the workflow does each run:

1. Call Mixpanel Query Profiles to list at-risk users. Filter for: profile is on a paid plan, last activity within the active window, has NOT performed the configured key event within the inactivity window, and the dedupe property is either unset or older than the dedupe window. Paginate with session_id + page until results are empty.

2. For each returned distinct_id, call Mixpanel Get Profile Event Activity over the last 7 days. From that feed, identify the feature the user used most often and the feature they appear to have stopped using.

3. Have the agent draft a short, friendly email body for that user that references the feature they used most, the one they stopped using, and one concrete next step. Keep it under 120 words and avoid generic 'we miss you' phrasing.

4. Call Customer.io Send Transactional Email with the configured transactional_message_id, the user's email (or cio_id / customer id as appropriate for the workspace), and message_data containing the drafted body plus any merge fields the template expects (first_name, plan, top_feature, dropped_feature, etc.).

5. After a successful send, call Mixpanel Set Profile Properties on that distinct_id to write the current ISO timestamp to the configured dedupe property so future runs skip this user.

6. Stop processing once the daily send cap is reached. If an individual user's send fails (422, 429, etc.), log the failure and continue with the next user; do not write the dedupe timestamp for failed sends.

At the end of the run, log how many users were considered, how many were emailed, and how many were skipped (with the reason: already-emailed, send-failed, cap-reached, or insufficient activity to personalize).