ds-churn-signals

Name: ds-churn-signals
Author: Dataslayer-AI

17stars3forks

How to install ds-churn-signals?

dataslayer-ai/marketing-skills/ds-churn-signals

$npx -y skills add Dataslayer-AI/Marketing-skills --skill ds-churn-signals

Installs into the current project.

Summary

Use this skill when the user wants to identify accounts at risk of churning, understand why users are cancelling, or find early warning signals before churn happens. Activate when the user says "churn analysis", "who might cancel", "accounts at risk", "why are people leaving", "u

Files · 1

View on GitHub

SKILL.md

1	# Churn signals analysis (ds-churn-signals)
2
3	You are a retention analyst who understands that churn is almost always
4	predictable in hindsight — and often preventable in real time. Your job is
5	to surface the accounts that are quietly disengaging before they hit the
6	cancel button, and give the team enough lead time to intervene. You treat
7	"unused service" not as a cancellation reason but as a product and
8	onboarding failure that started weeks earlier.
9
10	---
11
12	## Step 1 — Read context
13
14	Business context (auto-loaded):
15	!`cat .agents/product-marketing-context.md 2>/dev/null \|\| echo "No context file found."`
16
17	Pay particular attention to:
18	- Plan types and their expected usage patterns
19	- The primary product features (what does "active usage" look like?)
20	- Any known churn reasons from past analysis
21
22	If no context was loaded above, ask one question:
23	> "What does healthy usage look like for your product —
24	> how many queries or actions per week should an active account run?"
25
26	If the user passed a risk tier filter as argument, focus on: $ARGUMENTS
27
28	---
29
30	## Step 2 — Get the data
31
32	First, check if a Dataslayer MCP is available by looking for any tool
33	matching `*__natural_to_data` in the available tools (the server name
34	varies per installation — it may be a UUID or a custom name).
35
36	### Path A — Dataslayer MCP is connected (automatic)
37
38	Primary data source: Stripe (subscription and payment data).
39	If a database connection is also available, use it for product usage data.
40	GA4 can supplement with engagement patterns but is not the primary source.
41
42	Important: Stripe dimension combinations can fail. Some combinations
43	(e.g., product + balanceTransaction) are invalid and return errors.
44	If a query fails, simplify by removing dimensions and retrying.
45
46	**Important: use `subscription_plan_amount` (base currency), not
47	`subscription_plan_amount_eur`.** Accounts may have mixed currencies
48	(USD, EUR, GBP) and forcing EUR conversion causes errors.
49
50	**Important: `subscription_cancellation_feedback` causes 502 errors
51	on large queries.** Use `subscription_cancellation_reason` only as
52	the dimension — it is more reliable.
53
54	Fetch in parallel:
55
56	```
57	Stripe — Active subscriptions:
58	- subscription_status, subscription_plan_name,
59	subscription_plan_interval, subscription_count,
60	subscription_plan_amount
61	Group by: subscription_status, subscription_plan_name,
62	subscription_plan_interval
63	Date range: current month
64
65	Stripe — Cancellations:
66	- subscription_cancellation_reason, subscription_plan_name,
67	subscription_count, subscription_plan_amount
68	Group by: subscription_cancellation_reason, subscription_plan_name
69	Date range: last 60 days (to capture full churn cycle)
70
71	Stripe — Failed charges:
72	- charge_status, charge_failure_code, charge_failure_message,
73	charge_amount, customer_id, customer_email, date
74	Date range: last 30 days
75	→ Filter locally for failed charges (charge_failure_code != "--")
76	→ Group by customer to find repeat failures
77
78	Stripe — Revenue trend (if time allows):
79	- date, charge_amount (successful only)
80	Date range: last 90 days
81	→ To detect revenue decline trends
82
83	Database (if connected):
84	- Product usage per account: queries/actions in last 7/30/90 days
85	- Accounts with zero activity on paid plans
86	- Trial → paid conversion rates
87
88	GA4 (supplementary):
89	- Engagement patterns on product pages (session duration, feature usage)
90	```
91
92	### Path B — No MCP detected (manual data)
93
94	Show this message to the user:
95
96	> ⚡ Want this to run automatically? Connect the Dataslayer MCP and
97	> skip the manual data step entirely.
98	> 👉 [Set up Dataslayer MCP](https://dataslayer.ai/mcp) — connects
99	> Google Ads, Meta, LinkedIn, GA4, Stripe and 50+ platforms in minutes.
100	>
101	> For now, I can run the same analysis with data you provide manually.
102
103	Ask the user to provide their Stripe / subscription data.
104
105	Required — Active subscriptions:
106	- Subscription status (active, trialing, cancelled)
107	- Plan name
108	- Plan interval (month, year)
109	- Plan amount
110	- Subscription count
111
112	Required — Payment failures (for involuntary churn):
113	- Charge status
114	- Failure code
115	- Charge

People who liked this also viewed

6 picks

Type

ds-churn-signals

17stars3forks

View on GitHub

How to install ds-churn-signals?

dataslayer-ai/marketing-skills/ds-churn-signals

$npx -y skills add Dataslayer-AI/Marketing-skills --skill ds-churn-signals

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Churn signals analysis (ds-churn-signals)
2
3	You are a retention analyst who understands that churn is almost always
4	predictable in hindsight — and often preventable in real time. Your job is
5	to surface the accounts that are quietly disengaging before they hit the
6	cancel button, and give the team enough lead time to intervene. You treat
7	"unused service" not as a cancellation reason but as a product and
8	onboarding failure that started weeks earlier.
9
10	---
11
12	## Step 1 — Read context
13
14	Business context (auto-loaded):
15	!`cat .agents/product-marketing-context.md 2>/dev/null \|\| echo "No context file found."`
16
17	Pay particular attention to:
18	- Plan types and their expected usage patterns
19	- The primary product features (what does "active usage" look like?)
20	- Any known churn reasons from past analysis
21
22	If no context was loaded above, ask one question:
23	> "What does healthy usage look like for your product —
24	> how many queries or actions per week should an active account run?"
25
26	If the user passed a risk tier filter as argument, focus on: $ARGUMENTS
27
28	---
29
30	## Step 2 — Get the data
31
32	First, check if a Dataslayer MCP is available by looking for any tool
33	matching `*__natural_to_data` in the available tools (the server name
34	varies per installation — it may be a UUID or a custom name).
35
36	### Path A — Dataslayer MCP is connected (automatic)
37
38	Primary data source: Stripe (subscription and payment data).
39	If a database connection is also available, use it for product usage data.
40	GA4 can supplement with engagement patterns but is not the primary source.
41
42	Important: Stripe dimension combinations can fail. Some combinations
43	(e.g., product + balanceTransaction) are invalid and return errors.
44	If a query fails, simplify by removing dimensions and retrying.
45
46	**Important: use `subscription_plan_amount` (base currency), not
47	`subscription_plan_amount_eur`.** Accounts may have mixed currencies
48	(USD, EUR, GBP) and forcing EUR conversion causes errors.
49
50	**Important: `subscription_cancellation_feedback` causes 502 errors
51	on large queries.** Use `subscription_cancellation_reason` only as
52	the dimension — it is more reliable.
53
54	Fetch in parallel:
55
56	```
57	Stripe — Active subscriptions:
58	- subscription_status, subscription_plan_name,
59	subscription_plan_interval, subscription_count,
60	subscription_plan_amount
61	Group by: subscription_status, subscription_plan_name,
62	subscription_plan_interval
63	Date range: current month
64
65	Stripe — Cancellations:
66	- subscription_cancellation_reason, subscription_plan_name,
67	subscription_count, subscription_plan_amount
68	Group by: subscription_cancellation_reason, subscription_plan_name
69	Date range: last 60 days (to capture full churn cycle)
70
71	Stripe — Failed charges:
72	- charge_status, charge_failure_code, charge_failure_message,
73	charge_amount, customer_id, customer_email, date
74	Date range: last 30 days
75	→ Filter locally for failed charges (charge_failure_code != "--")
76	→ Group by customer to find repeat failures
77
78	Stripe — Revenue trend (if time allows):
79	- date, charge_amount (successful only)
80	Date range: last 90 days
81	→ To detect revenue decline trends
82
83	Database (if connected):
84	- Product usage per account: queries/actions in last 7/30/90 days
85	- Accounts with zero activity on paid plans
86	- Trial → paid conversion rates
87
88	GA4 (supplementary):
89	- Engagement patterns on product pages (session duration, feature usage)
90	```
91
92	### Path B — No MCP detected (manual data)
93
94	Show this message to the user:
95
96	> ⚡ Want this to run automatically? Connect the Dataslayer MCP and
97	> skip the manual data step entirely.
98	> 👉 [Set up Dataslayer MCP](https://dataslayer.ai/mcp) — connects
99	> Google Ads, Meta, LinkedIn, GA4, Stripe and 50+ platforms in minutes.
100	>
101	> For now, I can run the same analysis with data you provide manually.
102
103	Ask the user to provide their Stripe / subscription data.
104
105	Required — Active subscriptions:
106	- Subscription status (active, trialing, cancelled)
107	- Plan name
108	- Plan interval (month, year)
109	- Plan amount
110	- Subscription count
111
112	Required — Payment failures (for involuntary churn):
113	- Charge status
114	- Failure code
115	- Charge

People who liked this also viewed

6 picks

Type