[Feedback] :thumbsdown: negative — today's data - engagement, acquisition, etc

## Feedback (negative)

**Question:** today's data - engagement, acquisition, etc
**Tool:** `posthog_query`

### Corrected SQL
```sql
SELECT toStartOfWeek(signup_date) AS cohort_week, uniq(person_id) AS cohort_size, round(uniqIf(person_id, max_w1 = 1) / uniq(person_id) * 100, 1) AS w1_retention_pct FROM (SELECT s.person_id, toDate(s.signup_ts) AS signup_date, maxIf(1, dateDiff('day', toDate(s.signup_ts), toDate(e.timestamp_ts)) BETWEEN 7 AND 13) AS max_w1 FROM (SELECT person_id, min(timestamp_ts) AS signup_ts FROM semantic.posthog_events WHERE event_name = 'sign_up_success' AND user_type = 'external' GROUP BY person_id) AS s LEFT JOIN semantic.posthog_events AS e ON s.person_id = e.person_id AND e.is_core_action = 1 AND e.core_action_name != 'sign up' GROUP BY s.person_id, s.signup_ts) AS u GROUP BY cohort_week ORDER BY cohort_week
```

### Notes
PostHog retention widget pulled all-time historical users into weekly cohort buckets, producing cohort sizes of 1,600–5,500 when actual weekly signups are ~120–240. The retention_first_ever_occurrence type with weekly intervals inflates cohort sizes massively. Should always use raw ClickHouse posthog_events table with explicit signup-week joins for retention analysis instead of the PostHog retention widget.

---
_Feedback ID: `1af384c3-18dc-4bf8-bfbf-5f64d79614b2` | Recorded at 2026-03-09T20:54:33.387Z_

Start at the posthog_query entry point and compare its retention handling with the corrected SQL in this issue. Verify that retention analysis uses the raw ClickHouse posthog_events table with explicit signup-week joins rather than the PostHog retention widget, and check that cohort sizes reflect actual weekly signups.

Written by the indexing model from the issue text.