Splitting Traffic by User

Causal splits traffic in a couple of different situations. When an experiment is running, we split between the experiment variants. When a feature is being rolled out, we split between users that are currently seeing the feature, and those that have yet to see it.

By default, Causal splits traffic by a session's persistent key. This typically comes from a cookie or a mobile device ID, so it means we are splitting traffic based on device.

There may be situations where you'd like to split traffic on a different value. For example, when a user is logged into two different devices and you'd like to serve up the same experience on both devices.

Causal allows you to choose a different session value on which to base your split on using the @split_key directive. For example, take the following session definition:

session {
    args {
        deviceId : String! @persistent_key
        userId : String @mutable @split_key
    }
}

The userId will hold the user's ID when logged in, null otherwise. Since it is marked with the @split_key directive, Causal will base all traffic splits on the user id, falling back to the deviceId in case the user is not logged in.

Mutable Values

You'll notice in our example that the userId is marked as @mutable. That means the value can change during the session. In this case, it will change when the user logs in sometime during the session.

In order to provide a less jarring experience, Causal chooses the traffic split the first time a feature is seen, and maintains that choice till the end of the session (typically 30 minutes of inactivity).

So, lets say that the user logs in, and is then exposed to an experiment. Since userId was set before the experiment's variant was chosen, that user is guaranteed to see that same variant the next time they visit your site (assuming they are still logged in).

Now, imagine that the user is exposed to an experiment, and then logs in. Since they saw the experiment when the userId is null, we fall back to the deviceId to choose the variant. This decision will persist until the end of the session even if the user logs in. That way the application won't be shifting underneath your user's feet.

The next time a user visits (after 30 minutes of inactivity) the variant may change because the user is now logged in and Causal will use the userId to pick the variant.

We feel this approach gives you the best mix of application stability and consistent variant selection.