Amplitude Retention Drop + Stripe Churn Precursor: Weekly Correlated Alert to Slack via Make
Catch the product engagement signal that predicts churn 2–3 weeks before it shows up in your Stripe MRR.
The stack in the order it runs — data flows from the source through to where it lands.
Churn almost never surprises an informed operator — it surprises one who isn't connecting product signals to billing signals. When Week-2 retention drops in Amplitude, that at-risk cohort hasn't cancelled yet. They're still paying. But they will. By the time Stripe shows MRR decline, you've already lost the intervention window. The gap between 'user stopped using product' and 'user cancelled subscription' is typically 2–6 weeks.
Amplitude's retention charts expose cohort-level drop at precise intervals. Stripe's subscription API lets you cross-reference those cohorts against subscription status, trial end dates, and payment method health. Together they give you a leading indicator, not a lagging report.
Make's scenario builder handles multi-branch logic visually — you need to pull from Amplitude's API, join on user email or ID, query Stripe for matching customers, filter, format, and post. Make's iterator and aggregator modules handle this join pattern cleanly without custom code. n8n is equally capable; choose Make if your team is non-technical, n8n if you want self-hosted.
One hard tradeoff: Amplitude's API requires a Growth plan or above — the free Starter plan has no API access. If you're on Starter, swap Amplitude for PostHog (open source, full API access on all plans). The logic is identical, just different HTTP endpoints. And if your Week-4 retention is already stable above 40% and monthly churn is under 2%, skip this workflow for now — it'll generate false positives. Build it once you have at least 8 weeks of cohort history to establish a meaningful baseline.
The stack (5)
How it runs
- 1
Create a Make scenario with a weekly schedule trigger
In Make, create a new scenario. Set the trigger to Scheduler, running every Monday at 7:00 AM. That captures weekend data and lands the alert before your Monday standup. Name the scenario `Retention-Churn Correlation Weekly`.
- 2
Fetch Week-2 retention cohort from Amplitude via HTTP module
Add an HTTP module, method GET. Endpoint: `https://amplitude.com/api/2/retention`. Auth: Basic using your Amplitude API key and secret. Params: `{"retention_type": "n-day", "interval": 14, "start_date": "YYYY-MM-DD"}` — compute `start_date` as 30 days ago using Make's date functions. Parse the response to extract the Week-2 retention percentage per cohort. Flag any cohort where Week-2 retention is more than 8 percentage points below the 4-week rolling average. That's your anomaly threshold.
- 3
Extract user list from flagged cohorts
Amplitude's retention endpoint returns aggregate data, not user lists. Make a second HTTP call to Amplitude's User Activity endpoint or, if you're using Amplitude's Cohort Sync feature, pull from a pre-configured cohort export. Alternatively, query your Supabase or internal DB for users in the at-risk signup cohort date range. Either way, you need a list of emails or Stripe customer IDs before the billing lookup.
- 4
Cross-reference against Stripe subscription status
Add a Make iterator over the user list. For each email, use the Stripe module `Search Customers` with query `email:'user@example.com'`. Then call `List Subscriptions` for that customer, filtering for `status: active`. Flag users where `current_period_end` is within 21 days — low engagement plus an imminent renewal is your highest-risk combination. Store flagged users as an array.
- 5
Write at-risk accounts to Airtable for tracking
Use Make's Airtable module to upsert records into a table named `Churn Risk Tracker`. Fields: `customer_email`, `stripe_customer_id`, `cohort_week`, `week2_retention_pct`, `subscription_renewal_date`, `risk_flagged_date`, `status` (default: `open`). Your CS team works this table directly — they update `status` to `contacted`, `resolved`, or `churned` as they move through accounts.
- 6
Build a Slack Block Kit summary message
Add a Make Slack module using `Send a Message`. Build the message body dynamically: header `📉 Retention-Churn Risk Report — Week of {date}`, then a stat block showing `Cohorts flagged: N | Users at risk: N | Avg Week-2 retention this week: X% vs. baseline Y%`. List the top 5 at-risk accounts by renewal date — name, renewal date, and a direct Stripe dashboard link (`https://dashboard.stripe.com/customers/{id}`). Hard cap at 5. More than that and the message stops being actionable.
- 7
Add a conditional high-severity branch for MRR-material accounts
Before the Slack post, add a Make Router module. Branch 1: if any flagged user's subscription MRR exceeds $500/month, send a separate Slack DM to the CS lead or founder with the specific account details and a suggested outreach script. Branch 2: everything else goes to the standard channel digest. High-value accounts get immediate human attention; the main channel stays signal, not noise.
Want me to build this for you instead?
Product Audit and CTO Mode run out of this same thinking. If you’re reading this thinking “I want this, but in my product” — let’s talk.
See servicesMore like this
Google Analytics 4 + HubSpot Lifecycle Stage: Weekly Acquisition-Quality Digest to Slack via Pipedream with Claude Narrative
Stop reporting traffic numbers. Report whether the traffic you paid for last week actually became pipeline — with a one-paragraph executive summary written by Claude.
Gmail Thread Aging + Stripe Invoice Overdue: Unified AR Follow-Up Digest to Slack via Zapier
Surface overdue Stripe invoices and the exact age of your last Gmail thread with that customer — every morning at 8:30, automatically — so AR follow-up stops living in someone's head.
Outlook Calendar Load + HubSpot Deal Velocity: Weekly Ops Digest to Microsoft Teams
Every Monday at 07:30, your revenue team gets one Teams card: last week's deal pipeline movement next to each rep's actual meeting load — so you stop guessing whether low close rates are a pipeline problem or a capacity problem.