Confetti at Signup Beats Progress Bars 2:1 on Day-2 Return
The onboarding flow for a small productivity app got A/B tested last fall, and the result was lopsided enough that the team reran it twice to make sure the analytics weren't lying. Version A ended signup with a progress bar that filled from 0 to 100 percent as users completed four setup steps, each step labeled with a checkmark and a percentage. Version B did the same four steps but threw a burst of confetti on the screen when the final step completed, plus a short, specific congratulatory line. Both versions ended with the same "you're ready" screen and the same first task. Day-2 return rates came in at 19 percent for the progress-bar cohort and 38 percent for the confetti cohort — a 2:1 gap that held across a second sample and a third. The confetti version didn't make the product better. It made the moment of completion feel like something.
That gap is worth sitting with, because it's not really about confetti. It's about what happens in a user's head at the instant a task closes out, and whether the software marks that instant as an event or just updates a number. Behavioral psychology has a lot to say about this, and most of it predates the web. The interesting engineering question is how to translate those findings into code that doesn't feel manipulative — and where the line sits between a genuinely satisfying completion moment and a slot-machine lever.
The completion event is a psychological object, not a UI element
A progress bar is a representation of state. A confetti burst is an event. Those are different things to a nervous system. The bar says: here is where you are on a continuum, and the continuum has a known end. The confetti says: something just happened, and you were there for it.
Behavioral economics has a name for why the second one sticks: the peak-end rule, identified by Daniel Kahneman and colleagues in the early 1990s. People don't remember experiences as averages of their moments; they remember the peak intensity and the ending. A signup flow that's flat and mildly annoying throughout, ending on a checkmark, gets filed under "mildly annoying." The same flow with a sharp positive peak at the end gets filed under "kind of fun, actually." The retrospective judgment drives the return decision far more than the moment-to-moment experience did.
There's a second mechanism in play, and it's the one that makes engineers uncomfortable: variable-ratio reinforcement, the schedule B.F. Skinner documented in the 1950s where a reward arrives after an unpredictable number of responses. Variable-ratio schedules produce the highest, most persistent response rates of any reinforcement pattern — which is exactly why they power the most extractive products on the internet. The confetti result invites a lazy reading: "make rewards unpredictable and users will come back." That reading is wrong and dangerous. The confetti in the study above was predictable — it fired every time the final step completed. The variable part was which users happened to hit the final step on any given day.
The distinction matters for anyone building onboarding. Predictable completion rewards build a habit around finishing things. Unpredictable rewards build a habit around pulling the lever. The first compounds into a user who trusts your product. The second compounds into a user who resents it, churns loudly, and writes the Trustpilot review you deserve.
Why the progress bar underperformed
Progress bars fail as completion markers for a structural reason: they're always partially full, so they never arrive. At 75 percent the bar is still a bar. At 100 percent it's a bar that's now full — but the visual grammar is identical to every intermediate state. There's no perceptual discontinuity between "almost done" and "done." The user's brain has to read the label to know the state changed.
Confetti, by contrast, is a discontinuity. It's motion, color, and sound (if you're bold) arriving in a space that was previously static. It's impossible to miss and impossible to confuse with an intermediate state. That's the whole trick: the completion moment gets its own perceptual channel.
This is the same principle behind the "success state" pattern in well-designed forms — the green checkmark that replaces the submit button rather than sitting next to it. The state change is legible without reading. Progress bars ask the user to parse; completion events ask the user to notice.
What the research actually supports (and what it doesn't)
The confetti result isn't an outlier. It lines up with a body of work on goal-gradient effects — the observation, going back to Clark Hull in the 1930s and formalized in consumer research by Ran Kivetz and colleagues in the 2000s, that effort accelerates as people approach a goal. A coffee-shop loyalty card with 10 stamps gets completed faster than one with 12, even when the marginal cost of the extra stamps is trivial. The proximity of the finish line changes behavior.
But the goal-gradient effect has a dark twin that onboarding designers keep rediscovering: the post-completion collapse. Once the goal is achieved, motivation drops off a cliff. Users who sprint through signup to reach the confetti often have no reason to come back the next day, because the thing they were sprinting toward is done. The 38 percent Day-2 return in the study is good, but it's not 60 percent, and the missing 22 points are mostly users who got their confetti and had nothing waiting for them on the other side.
The fix isn't more confetti. It's a second goal that's visible at the moment the first one completes. The confetti marks the end of setup; something on the very next screen has to mark the beginning of the actual product. Teams that get this right report Day-2 returns in the 45–55 percent range on small consumer apps, though the variance is enormous and the sample sizes are usually too small to publish. The pattern, though, is consistent: completion reward plus immediate next-goal framing outperforms completion reward alone.
There's a third concept worth importing, and it's the one that separates good onboarding from predatory onboarding: loss aversion. Kahneman and Amos Tversky's work in the late 1970s established that losses loom roughly twice as large as equivalent gains. The ethical use of loss aversion in onboarding is to make the user's investment visible — "you've set up three projects, here they are" — so that leaving feels like abandoning something they built. The unethical use is to manufacture artificial loss — "your streak will reset!" — around a metric the user never cared about until you told them to. The first builds ownership. The second builds anxiety, and anxiety-driven retention has a half-life measured in weeks.
A concrete case: the streak that backfired
A habit-tracking app I've followed for a few years ran an experiment in 2022 that's instructive precisely because it failed. They added a daily streak counter to their onboarding, with a confetti burst on day one and a "don't break the streak" nudge on day two. Day-2 returns jumped from 24 percent to 41 percent. Day-30 retention, however, dropped from 31 percent to 22 percent. The streak had converted a product people used when they needed it into a product people opened to avoid a penalty. When the streak broke — and for most users it broke within two weeks — the reason to open the app broke with it.
The team killed the streak and replaced it with a "weekly review" screen that surfaced what the user had actually accomplished that week, with a modest completion animation on the review itself. Day-2 returns settled at 36 percent, Day-30 at 34 percent. Lower peak, higher floor. That trade is almost always the right one, and it's the trade the confetti study is really pointing at: reward the completion of meaningful work, not the maintenance of an arbitrary counter.
Engineering the completion moment without building a lever
So what does this look like in code, for a team shipping a real product on a real timeline?
The first decision is what counts as a completion event. It should be a user action with intrinsic value — finishing a profile, publishing a first item, connecting an integration, sending a first message — not a UI milestone like "viewed the tour." Tour completions are cheap to trigger and worthless to reward; users learn within two sessions that the confetti fires for clicking "next," and the reward stops meaning anything. Pick two or three events in the first session that correspond to real value delivered, and reserve the celebration for those.
The second decision is how loud the celebration is. Confetti is a strong signal, and strong signals decay with repetition. A burst on every completion becomes wallpaper by the third one. The pattern that holds up is a descending scale: full celebration on the first meaningful completion, a smaller acknowledgment on the second, a quiet checkmark on the third and beyond. This mirrors how the reward system in the user's head actually works — novel stimuli get attention, familiar ones get filtered — and it prevents the "confetti fatigue" that turns a delightful product into a noisy one.
The third decision is what happens on the next screen. The completion event should hand off to a next goal within one interaction. If the confetti fires and the user lands on an empty dashboard, you've spent your reward budget on nothing. If it fires and the user lands on a screen that says "here's what to do now, and here's why it matters," you've converted a moment of satisfaction into a reason to return.
In React, this is mostly a state machine problem, not an animation problem. A useOnboarding hook that tracks completed events, exposes a celebrate(eventName) function that respects the descending-scale rule, and fires the animation only when the event is genuinely new — that's the whole architecture. The confetti library itself is a dependency you'll swap out in an afternoon; the policy around when to fire it is the part that determines whether the feature helps or hurts.
// The policy matters more than the particle effect.
const CELEBRATION_TIERS = {
firstProject: 'full',
firstPublish: 'medium',
firstIntegration: 'light',
};
function useCompletionReward() {
const seen = useRef(new Set());
function celebrate(eventName) {
if (seen.current.has(eventName)) return null;
seen.current.add(eventName);
return CELEBRATION_TIERS[eventName] ?? 'light';
}
return { celebrate };
}
The seen set is doing the real work. It's the difference between a reward that means "you did a new thing" and a reward that means "you clicked a thing." Persist it server-side if you want the policy to survive device switches, which for most consumer products you do.
The measurement trap
The 2:1 result is easy to reproduce badly. Teams that read about confetti results tend to instrument the celebration itself — how many users saw confetti, how many clicked the button after — and conclude the feature works because the numbers go up. The number that matters is the one in the title: Day-2 return. Not session length, not celebration views, not "engagement." A completion reward that inflates same-session metrics while leaving Day-2 flat has done nothing except make the app noisier.
The other trap is cohort contamination. If you ship confetti to everyone at once, you can't separate the effect from whatever else changed that week. The study above held up because it was a clean A/B with a stable product behind it. If your product is changing daily — and for most indie teams it is — run the celebration test on a small traffic slice for two weeks minimum, and hold everything else still. Two weeks is enough to see Day-2 and Day-7; it's not enough to see Day-30, which is why the streak case above took a year to surface its damage.
Where this goes next
The interesting frontier isn't better confetti. It's completion events that carry information. A celebration that says "you just did the thing that 80 percent of users skip" is doing something different from a celebration that says "yay." The first gives the user a fact about themselves; the second gives them a dopamine hit. The first is durable, because it's true. The second is not, because it isn't.
That points toward a design pattern worth prototyping this quarter: earned-status completions. Instead of celebrating every milestone identically, tier the celebration by how much the milestone actually predicts about the user's future success — measured, not assumed. If your data says users who connect an integration in session one retain at 2x, then the integration completion deserves the full burst and the profile-photo completion deserves a checkmark. You're not manipulating the user; you're telling them the truth about which actions matter, in the only language the nervous system reliably reads.
The teams that get this right will be the ones that treat the completion moment as a product surface with its own metrics, not as a decoration bolted onto the end of a form. They'll instrument it, A/B it, and — crucially — kill it when it stops working. The confetti result isn't a recipe. It's a hint that the moment a task closes is one of the highest-leverage seconds in the entire user journey, and most products spend that second showing a bar that's now slightly fuller than it was before.