Set up a client-side button color A/B test

WHAT THIS TESTS This probes whether you understand deterministic bucketing, exposure logging, and the difference between assignment and rendering. Color is trivial; the consistency machinery is the real subject.

A GOOD ANSWER COVERS Start with a stable identity: a logged-out user gets a persistent device or cookie ID, a logged-in user gets the account ID. Assignment is deterministic: hash the identity concatenated with the experiment key, take the hash modulo a bucket count, and map ranges to control or variant. The same input always yields the same bucket, so the user is sticky across loads and devices that share the account. The button renders conditionally on the resolved variant. Fire an exposure event the moment the variant is actually shown, not at assignment time, and tag every downstream click event with the experiment id and variant so analysis can attribute outcomes.

COMMON WRONG ANSWERS Using Math.random per page load, which re-randomizes and corrupts both groups. Storing the variant only in memory so it resets on refresh. Logging exposure at assignment even when the component never paints, inflating the denominator. Hardcoding a 50 percent split with no flag system, making rollback a redeploy.

LIKELY FOLLOW-UPS How do you avoid flicker, where control briefly shows before the variant swaps in? How do you handle a user who logs in mid-session and switches from device ID to account ID? How would you ramp from one percent to fifty percent safely?

ONE CONCRETE EXAMPLE Experiment key button-color-v1. User device ID abc123. Compute hash of abc123:button-color-v1, modulo 100 gives 73; buckets 0 to 49 are control, 50 to 99 are variant, so this user sees the green button. On render the client posts an exposure event, and the later sign-up click carries variant equals treatment. Every subsequent visit recomputes 73 and stays green.