Implement a welcome-message A/B test

WHAT THIS TESTS This is the canonical end-to-end client experiment: deterministic assignment, sticky rendering, and conversion tracking joined to the variant.

A GOOD ANSWER COVERS Assignment: hash a stable identity, the logged-in user id or a persistent device id, together with the experiment key, take modulo a bucket count, and map to control A or variant B. Determinism makes the assignment sticky across loads and sessions. Rendering: if control, show the generic welcome; if variant, render the personalized message using the user's name, with a sensible fallback when the name is missing. Exposure: emit an exposure event when the welcome is actually shown, tagged with experiment and variant. Conversion: attach the experiment id and variant to the Get Started click event so analysis computes click-through per arm. Compare conversion rates with a significance test.

COMMON WRONG ANSWERS Math.random per render, so the user flickers between welcomes. Storing the variant only in memory, resetting on refresh. Tracking the click without the variant tag, making attribution impossible. No fallback when the name is null, showing an empty or broken personalized message that confounds the test.

LIKELY FOLLOW-UPS How do you handle a user whose name is unknown in the variant arm? How do you prevent a brief flash of the control before the variant resolves? When do you stop the test?

ONE CONCRETE EXAMPLE User id u_77 hashed with welcome-msg-v1 yields bucket 18; buckets 0 to 49 are control. The user sees the generic Welcome. The Get Started click fires an event with experiment welcome-msg-v1 and variant control. Another user lands in variant and sees Welcome, Priya, with their click tagged variant treatment, letting analysis compare click-through across the two arms.