ShipEasy Experiments lets you ask "is the new thing actually better?" and get a defensible answer.

You define what you want to measure (a metric), set up variant payloads (the groups), let users land in one bucket or another, log conversions, and look at the dashboard the next morning. The platform handles assignment, exposure stitching, deduplication, daily aggregation, and the statistics.

The five building blocks

The 5-minute mental model

You ship feature X behind a flag. You believe it'll lift purchase_conversion. So instead of just gating it, you make it an experiment: half the eligible users see X, half don't. Both groups are tracked. The next day, you look at the dashboard and read either "X lifts conversion by 3.1% (p=0.002)" — or "no significant difference, scrap it."

The honest version requires more care than that summary, and the docs walk through it.

When to gate vs. when to experiment

A practical workflow is to gate first (so the rollout is safe), then promote the gate to an experiment once the feature is stable.

The 5-minute path

Wire the SDK

import { configureShipeasy, flags, experiments } from "@shipeasy/sdk/server";

configureShipeasy({ apiKey: process.env.SHIPEASY_SERVER_KEY! });
await flags.init();

const result = experiments.assign<{ label: string }>("checkout-cta", {
  user_id,
  plan,
  country,
});
const label = result.params.label; // "Pay" or "Buy now"

// Wherever the purchase succeeds:
flags.track(user_id, "purchase", { value: orderTotal });

The first time you call assign() for a user, an exposure is logged automatically. Subsequent calls in the same process don't re-log — exposures are deduplicated.

API · experiments.assign

The return shape:

{
  inExperiment: boolean,   // false if stopped, holdout, or excluded
  group: string,           // "control" | "v1" | …
  params: T,               // typed payload from the assigned group
  reason: AssignmentReason // "assigned" | "holdout" | "stopped" | "excluded"
}

What the daily analysis does