Data-Decide SOP
Boundary
This skill (data-decide) = HOW to interpret data. The data analyst: event taxonomy design, cohort analysis methodology, A/B test statistical rigor, vanity vs actionable metric evaluation, and decision frameworks for acting on data.
Not this skill — use growth-track instead for WHAT to track: AARRR funnel metrics, North Star metric definition, budget management, experiment design templates, and weekly growth reports.
1. Event Taxonomy
Design events before writing code. Use object_action naming convention consistently.
Core events to track (minimum viable analytics):
- Authentication:
user_signed_up, user_logged_in, user_logged_out
- Activation:
onboarding_started, onboarding_completed, feature_first_used
- Engagement:
project_created, item_edited, search_performed
- Monetization:
plan_selected, payment_completed, subscription_cancelled
- Retention:
session_started, user_returned (after 7+ day absence)
Naming rules (Amplitude taxonomy best practices):
- Always
object_action, never action_object — keeps autocomplete useful
- Past tense for completed events (
payment_completed), not gerunds
- Properties use snake_case:
plan_name, referral_source, time_to_activate_seconds
- Never put PII (email, name) in event properties — use anonymous user IDs
- Document every event in a tracking plan (living doc, reviewed monthly)
Source: Amplitude — Plan Your Taxonomy, PostHog SaaS Guide
2. Vanity vs Actionable Metrics (Eric Ries, Lean Startup)
The test: if the metric doesn't change your next action, stop tracking it.
| Vanity (feels good) |
Actionable (drives decisions) |
| Total registered users |
Activation rate (% completing onboarding) |
| Page views |
Conversion rate (visitor → signup) |
| Total revenue (cumulative) |
MRR growth rate (week over week) |
| App downloads |
Day-7 retention rate |
Three A's of actionable metrics (Ries):
- Actionable — clear cause and effect; you know what lever moved it
- Accessible — simple enough that the whole team understands it
- Auditable — you can trace the number back to raw data
Source: Eric Ries on Tim Ferriss blog, Lean Startup Co.
3. Cohort Analysis
Group users by signup week. Track retention at day 1, day 7, day 30.
How to read cohort curves:
- Flattening curve = users who stay are sticky (good)
- Newer cohorts retaining better than older = product is improving (great)
- All cohorts dropping to zero = you have a leaky bucket (fix retention before growth)
Implementation (minimal):
- Store
signup_date with every user
- Query: for each signup week, count active users at +1d, +7d, +30d
- Plot as a retention table or curve chart
- Compare curves across cohorts — the shape matters more than absolute numbers
4. A/B Test Design
Before running any test:
- Write the hypothesis: "If [change], then [metric] will [direction] by [amount]"
- Bad: "The new button will be better"
- Good: "If we change CTA from 'Start Free' to 'Try It Now', signup rate will increase by 10%"
- Calculate sample size BEFORE running — use Evan Miller's calculator
- Inputs: baseline conversion rate, minimum detectable effect (MDE), power (0.80), significance (0.05)
- Run for full weeks — minimum 14 days to avoid day-of-week bias
- Do not peek — checking results early inflates false positive rate
- Statistical significance: p < 0.05 minimum (95% confidence)
- Practical significance matters too — a statistically significant 0.1% improvement may not be worth implementing
Source: Statsig — Determine Sample Size, GuessTheTest — Sample Size Guide
5. Decision Framework
Data informs, doesn't decide. Use this ladder:
| Data clarity |
Action |
| High confidence (>95%, large effect) |
Follow the data |
| Moderate (80-95%, small effect) |
Data + qualitative signals (user interviews, support tickets) |
| Ambiguous (<80% or conflicting) |
Use judgment, acknowledge uncertainty |
| No data at all |
Run the smallest possible experiment first |
When data and intuition conflict: favor data for incremental decisions, favor vision for strategic bets. Document why you overrode data when you do.
6. Tools (Solo/Small Team)
| Need |
Recommendation |
Why |
| Product analytics |
PostHog (self-hosted, free) |
Full-featured, privacy-friendly, no data caps |
| Web analytics |
Plausible |
Privacy-focused, lightweight, GDPR-compliant |
| A/B testing |
GrowthBook (free tier) or PostHog feature flags |
Proper statistical engine, integrates with your data |
| Error tracking |
Sentry (free tier) |
Stack traces + user context |
| Avoid unless necessary |
Google Analytics |
Privacy tradeoff, complex, overkill for early stage |
Next Steps
Report to user: "Analysis complete. Key finding: [one line]. Recommendation: [action]"
Suggested next steps (user decides):
- Product issue found → "Run product-eval"
- Acquisition issue → "Run growth-track"
1---2name: data-decide3description: Data analyst: HOW to interpret data and make decisions (event taxonomy, cohort analysis, A/B test statistical rigor, vanity vs actionable metrics, decision frameworks). Triggers ONLY when: user asks to set up analytics, interpret metrics, design an A/B test, or make a data-driven decision. Do NOT trigger during development or casual metric discussion.4---56# Data-Decide SOP78## Boundary910**This skill (data-decide)** = HOW to interpret data. The data analyst: event taxonomy design, cohort analysis methodology, A/B test statistical rigor, vanity vs actionable metric evaluation, and decision frameworks for acting on data.1112**Not this skill — use `growth-track` instead** for WHAT to track: AARRR funnel metrics, North Star metric definition, budget management, experiment design templates, and weekly growth reports.1314## 1. Event Taxonomy1516Design events before writing code. Use `object_action` naming convention consistently.1718**Core events to track (minimum viable analytics):**19- Authentication: `user_signed_up`, `user_logged_in`, `user_logged_out`20- Activation: `onboarding_started`, `onboarding_completed`, `feature_first_used`21- Engagement: `project_created`, `item_edited`, `search_performed`22- Monetization: `plan_selected`, `payment_completed`, `subscription_cancelled`23- Retention: `session_started`, `user_returned` (after 7+ day absence)2425**Naming rules (Amplitude taxonomy best practices):**26- Always `object_action`, never `action_object` — keeps autocomplete useful27- Past tense for completed events (`payment_completed`), not gerunds28- Properties use snake_case: `plan_name`, `referral_source`, `time_to_activate_seconds`29- Never put PII (email, name) in event properties — use anonymous user IDs30- Document every event in a tracking plan (living doc, reviewed monthly)3132> Source: [Amplitude — Plan Your Taxonomy](https://amplitude.com/docs/data/data-planning-playbook), [PostHog SaaS Guide](https://bix-tech.com/posthog-for-saas-a-practical-guide-to-product-analytics-and-event-tracking/)3334## 2. Vanity vs Actionable Metrics (Eric Ries, Lean Startup)3536**The test:** if the metric doesn't change your next action, stop tracking it.3738| Vanity (feels good) | Actionable (drives decisions) |39|---|---|40| Total registered users | Activation rate (% completing onboarding) |41| Page views | Conversion rate (visitor → signup) |42| Total revenue (cumulative) | MRR growth rate (week over week) |43| App downloads | Day-7 retention rate |4445**Three A's of actionable metrics (Ries):**461. **Actionable** — clear cause and effect; you know what lever moved it472. **Accessible** — simple enough that the whole team understands it483. **Auditable** — you can trace the number back to raw data4950> Source: [Eric Ries on Tim Ferriss blog](https://tim.blog/2009/05/19/vanity-metrics-vs-actionable-metrics/), [Lean Startup Co.](http://2015.leanstartup.co/day-1830-vanity-metrics-vs-actionable-metrics/)5152## 3. Cohort Analysis5354Group users by signup week. Track retention at day 1, day 7, day 30.5556**How to read cohort curves:**57- Flattening curve = users who stay are sticky (good)58- Newer cohorts retaining better than older = product is improving (great)59- All cohorts dropping to zero = you have a leaky bucket (fix retention before growth)6061**Implementation (minimal):**621. Store `signup_date` with every user632. Query: for each signup week, count active users at +1d, +7d, +30d643. Plot as a retention table or curve chart654. Compare curves across cohorts — the shape matters more than absolute numbers6667## 4. A/B Test Design6869**Before running any test:**70711. **Write the hypothesis:** "If [change], then [metric] will [direction] by [amount]"72 - Bad: "The new button will be better"73 - Good: "If we change CTA from 'Start Free' to 'Try It Now', signup rate will increase by 10%"742. **Calculate sample size BEFORE running** — use [Evan Miller's calculator](https://www.evanmiller.org/ab-testing/sample-size.html)75 - Inputs: baseline conversion rate, minimum detectable effect (MDE), power (0.80), significance (0.05)763. **Run for full weeks** — minimum 14 days to avoid day-of-week bias774. **Do not peek** — checking results early inflates false positive rate785. **Statistical significance: p < 0.05 minimum** (95% confidence)796. **Practical significance matters too** — a statistically significant 0.1% improvement may not be worth implementing8081> Source: [Statsig — Determine Sample Size](https://www.statsig.com/perspectives/determine-sample-size-abtest), [GuessTheTest — Sample Size Guide](https://guessthetest.com/calculating-sample-size-in-a-b-testing-everything-you-need-to-know/)8283## 5. Decision Framework8485Data informs, doesn't decide. Use this ladder:8687| Data clarity | Action |88|---|---|89| High confidence (>95%, large effect) | Follow the data |90| Moderate (80-95%, small effect) | Data + qualitative signals (user interviews, support tickets) |91| Ambiguous (<80% or conflicting) | Use judgment, acknowledge uncertainty |92| No data at all | Run the smallest possible experiment first |9394**When data and intuition conflict:** favor data for incremental decisions, favor vision for strategic bets. Document why you overrode data when you do.9596## 6. Tools (Solo/Small Team)9798| Need | Recommendation | Why |99|---|---|---|100| Product analytics | PostHog (self-hosted, free) | Full-featured, privacy-friendly, no data caps |101| Web analytics | Plausible | Privacy-focused, lightweight, GDPR-compliant |102| A/B testing | GrowthBook (free tier) or PostHog feature flags | Proper statistical engine, integrates with your data |103| Error tracking | Sentry (free tier) | Stack traces + user context |104| Avoid unless necessary | Google Analytics | Privacy tradeoff, complex, overkill for early stage |105106## Next Steps107Report to user: "Analysis complete. Key finding: [one line]. Recommendation: [action]"108109Suggested next steps (user decides):110- Product issue found → "Run product-eval"111- Acquisition issue → "Run growth-track"