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": "Jakarta Shoppers",
  "description": "Users from Jakarta who purchased in the last 14 days",
  "specification": {
    "userbase_id": "default_userbase",
    "inclusion": {
      "relation": "intersection",
      "slices": [
        {
          "type": "past_action",
          "past_action": {
            "relation": "intersection",
            "user_actions": [
              {
                "event_id": "purchase",
                "window": {
                  "operator": "in_the_last",
                  "params": ["14d"]
                }
              }
            ],
            "user_attributes": [
              {
                "key": "city",
                "operator": "=",
                "value": ["Jakarta"]
              }
            ]
          }
        }
      ]
    }
  }
}

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.

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.