Dimensions let you drill down into experiment results. For example, if you define a browser dimension, you can see how Safari users behaved vs Chrome.

Be careful, the more dimensions and metrics you look at for an experiment, the more likely you are to see false positives - something that looks significant when it really isn't. For example, if you break out results by country, it's pretty likely that at least one of the 100+ countries in your dataset will be signficantly different just by random chance.

It's best to treat dimensions as an exploratory tool and not something to directly draw conclusions from. The two best use cases are identfying bugs (the browser example) and getting ideas for dedicated follow-up experiments.

Dimensions are supported for both Mixpanel and SQL data sources.


There are two types of dimensions for SQL data sources: User Dimensions and Experiment Dimensions.

User Dimensions

These are attributes of your users that are relatively stable over time. For example, subscription plan, age group, cohort.

A user dimension is defined by a simple SQL query that returns two columns: an identifier and value. The name of the identifier column depends on which identifier type the dimension is using.

Here's an example SQL:

-- Assumes identifier type is "user_id"
  plan_type as value

It's best to keep the number of unique values for a dimension small if possible to avoid the False Positive issues discussed above. We automatically cap the number at 20, but you can do it youself if you want more control. Here's an example for a "country" dimension:

    CASE WHEN country = 'us' THEN 'US'
    WHEN country = 'uk' THEN 'UK'
    ELSE 'Other' END
  ) as value

Experiment Dimensions

These are attributes that are specific to the point-in-time that a user was put into an experiment. For example, browser or referrer.

Instead of a standalone SQL query, experiment dimensions are simply extra columns you return from the Experiment assignment query defined for your data source.

As an example, if you set the following as your experiment assignment query:

  received_at as timestamp,

The first 4 columns are standard, but browser is a custom one that can be used as an Experiment Dimension.


For mixpanel, there is just a single type of dimension that is based on event properties (at this time Mixpanel user properties are not supported).

For simple dimensions, you can just put the event property name directly. For example: $browser.

We also support complex javascript expressions. For example:

event.properties.$browser.match(/chrome/i) ? "Chrome" : "Other"

For more complex expressions, you can wrap your code in an anonymous function:

(() => {
  // ...some complex logic
  return dimensionValue

You can also reference the experiment start/end date in your javascript expression. For example, if you add a super event called userRegistrationDate that stores a unix timestamp, you could make a New vs Existing dimension like this:

event.properties.userRegistrationDate >= {{ startDateUnix }} ? "new" : "existing"

The variables you can reference are:

  • startDate - YYYY-MM-DD HH:mm:ss of the earliest data that needs to be included
  • startYear - Just the YYYY of the startDate
  • startMonth - Just the MM of the startDate
  • startDay - Just the DD of the startDate
  • startDateUnix - Unix timestamp of the startDate (seconds since Jan 1, 1970)
  • endDate - YYYY-MM-DD HH:mm:ss of the latest data that needs to be included
  • endYear - Just the YYYY of the endDate
  • endMonth - Just the MM of the endDate
  • endDay - Just the DD of the endDate
  • endDateUnix - Unix timestamp of the endDate (seconds since Jan 1, 1970)