Beginner question: What's the difference between a segment and a cohort?

A surprisingly common point of confusion I see in both product analytics and marketing data pipelines is the conflation of "segment" and "cohort." While both are used for grouping users, their fundamental purposes, temporal characteristics, and underlying data models are distinct. Using them interchangeably, especially in performance-critical queries, can lead to significant analytical errors and resource waste.

Let me define each term operationally, as I would when designing a data schema or writing a benchmark query.

* **Segment:** A **state-based** grouping of users (or entities) defined by their **current properties or attributes** at a given point in time. Segments are dynamic; membership changes as user attributes change. They answer the question, **"Who right now fits this description?"**
* *Example:* `users WHERE plan_tier = 'premium' AND last_active_date >= CURRENT_DATE - INTERVAL '7 days'`
* This query defines a "Active Premium Users" segment. A user who downgrades their plan tomorrow leaves this segment. The query is evaluated against the *current* state of the data.

* **Cohort:** An **event-based** grouping of users defined by a **shared initial event or timespan** (usually their first action). Membership is static once defined; users belong to a cohort permanently based on that initial qualifying event. They answer the question, **"How do users who started in a particular period behave over time?"**
* *Example:* `users WHERE date_trunc('week', signup_date) = '2023-11-06'`
* This defines the "Week 45, 2023 Signups" cohort. A user who signed up that week is forever part of that cohort, regardless of their future activity or status.

The critical difference is the **immutability of the group definition**. A cohort's membership is fixed in historical cement, while a segment's membership is a mutable snapshot. This has profound implications for query patterns and performance.

Consider a typical analytical query to measure 30-day retention. Using a cohort approach is correct and efficient:

```sql
-- Cohort-based Retention Analysis
WITH signup_cohort AS (
SELECT
user_id,
date_trunc('week', signup_date) AS signup_week
FROM users
WHERE signup_date BETWEEN '2023-11-01' AND '2023-11-07'
),
activity_events AS (
SELECT
user_id,
date_trunc('day', event_timestamp) AS activity_day
FROM events
WHERE event_type = 'login'
)
SELECT
c.signup_week,
(a.activity_day - c.signup_week) AS days_since_signup,
COUNT(DISTINCT c.user_id) AS cohort_size,
COUNT(DISTINCT a.user_id) AS active_users,
COUNT(DISTINCT a.user_id) * 1.0 / COUNT(DISTINCT c.user_id) AS retention_rate
FROM signup_cohort c
LEFT JOIN activity_events a
ON c.user_id = a.user_id
AND a.activity_day BETWEEN c.signup_week AND c.signup_week + INTERVAL '29 days'
GROUP BY 1, 2
ORDER BY 1, 2;
```

Attempting the same analysis with a segment (e.g., "users active in the last 30 days") would be logically flawed, as the group itself changes daily, making longitudinal comparison meaningless.

In performance terms, cohort analysis often benefits from pre-aggregation and materialized views, as the defining event (`signup_date`) is a single immutable timestamp. Segment queries, especially on real-time attributes, often require full table scans or expensive indexed lookups on volatile data, which is a key consideration for database load and latency SLAs. Misapplying these concepts can lead to queries that are not only incorrect but also unnecessarily expensive.