Define user segments once.
Reuse them everywhere.

A canonical segmentation layer that lets marketers self-serve audiences without duplicating logic or dragging your data team into every request.

  • Warehouse-native evaluation
  • Versioned, inspectable segment definitions
Try the interactive demo Request early access
Segment definition canonical spec
{
  "name": "Recently Active Paying Users",
  "description": "Users who logged in recently 
  			and have at least one successful payment",
  "specification": {
    "userbase_id": "primary_users",
    "inclusion": {
      "relation": "intersection",
      "slices": [
        {
          "type": "past_action",
          "past_action": {
            "relation": "intersection",
            "user_actions": [
              {
                "event_id": "login",
                "window": {
                  "operator": "in_the_last",
                  "params": ["7d"]
                }
              },
              {
                "event_id": "payment_succeeded",
                "occurrence": {
                  "operator": ">=",
                  "count": 1
                }
              }
            ]
          }
        }
      ]
    }
  }
}

Segmentation is broken in modern data stacks

Everyone has user data. Very few teams agree on what a segment actually means.

Audience drift

The same segment is defined differently in analytics, CRM, ads, and product tools. Numbers never match. Trust erodes.

Data teams become bottlenecks

Every new campaign turns into a SQL request. Engineers spend time exporting lists instead of building systems.

No source of truth

Segments live inside tools instead of being shared, versioned, and owned as a first-class definition.

How Slicer works

Slicer defines what a segment means before it is evaluated or activated.

1. Define

Write a segment once using a canonical specification. Definitions are explicit, versioned, and reviewable.

2. Evaluate

The definition is compiled into warehouse-native SQL and evaluated where your data already lives.

3. Activate

The resulting audience is reused across analytics, marketing, product, or machine learning workflows.

Try a real segment definition

This is the actual segmentation spec. Not a screenshot. Not a diagram.

Segment definition canonical spec
{
  "name": "Recently Active Paying Users",
  "description": "Users who logged in recently 
  			and have at least one successful payment",
  "specification": {
    "userbase_id": "primary_users",
    "inclusion": {
      "relation": "intersection",
      "slices": [
        {
          "type": "past_action",
          "past_action": {
            "relation": "intersection",
            "user_actions": [
              {
                "event_id": "login",
                "window": {
                  "operator": "in_the_last",
                  "params": ["7d"]
                }
              },
              {
                "event_id": "payment_succeeded",
                "occurrence": {
                  "operator": ">=",
                  "count": 1
                }
              }
            ]
          }
        }
      ]
    }
  }
}
Compiled output warehouse SQL
(SELECT user_id
FROM events
	WHERE
		event_name='login'
		AND event_ts BETWEEN ? AND ?
	GROUP BY user_id)
INTERSECT
(SELECT user_id
	FROM events
	WHERE
		event_name='payment_succeeded'
	GROUP BY user_id
	HAVING COUNT(user_id) >= ?)

Built as infrastructure, not a dashboard

Slicer is designed to sit alongside your data stack, not replace or abstract it.

Warehouse-native

Segments are evaluated directly in your data warehouse. No data ingestion. No shadow copies. No sync delays.

API-first

Segments are defined, versioned, and consumed through APIs. They can be used by analytics, marketing, product, or ML systems.

Not a CDP

Slicer does not store user profiles, events, or traits. It defines meaning, not state.