A lot of mHealth research suffers from a basic confound: the app doing the tracking is also doing the intervention. When you compare a gamified app to a non-gamified app, you don't know whether behavior changed because of the game mechanics or because the app was better-designed, more polished, or just newer. Most studies don't separate those things.
A paper published in April 2026 in JMIR took a different approach. "A Gamified Mobile Health Intervention to Promote Physical Activity, Executive Function, and Mental Health in College Students: Randomized Controlled Trial" ran a 2-arm RCT where both groups used the same platform and were assigned the same physical activity targets. The only difference was whether the app included gamification features: team-based competition, points, leaderboards, and personalized feedback. 160 college students, 8 weeks.
The gamification group outperformed the control group on physical activity, adherence, and mental health outcomes. Because the platform was held constant, that result is a cleaner estimate of gamification's independent contribution than most of what you'll find in the literature.
Let me explain what that means for product teams, and where the result stops applying.
What the design actually isolates
This is a component study. The researchers were trying to answer a specific question: does gamification add anything above and beyond the app itself? That's a good question, and this design answers it credibly.
The typical alternative is comparing a gamified product to a paper diary or a completely different app. That's not a test of gamification, that's a test of whether your whole product beats an inferior baseline. The null result you get from a lot of gamification research comes from this design flaw.
Here, by randomizing within a single platform, the study estimates what product teams actually want to know: if we add this feature layer, does behavior change more?
The answer in this study is yes, with p-values that held up over 8 weeks. That's not nothing.
What the design doesn't isolate is which specific gamification element drove the effect. Team competition, leaderboards, points, and personalized feedback were bundled together. You can't tell from this study whether team competition alone would have worked, or whether leaderboards without teams would have underperformed. Those are follow-on questions the study wasn't designed to answer.
Why SDT is the right theoretical frame, and what "relatedness" actually means
The authors ground the mechanism in Self-Determination Theory (SDT), which is one of the more durable frameworks in behavior change research. SDT argues that behavior is sustained when it satisfies three psychological needs: autonomy (I feel in control of my actions), competence (I feel like I'm getting better), and relatedness (I feel meaningfully connected to other people).
Product teams often hear SDT and immediately focus on autonomy and competence because those map cleanly to familiar UX ideas: user choice, progress bars, mastery curves. Relatedness gets treated as "add social features."
That's too thin a reading. Relatedness in SDT doesn't mean knowing that strangers exist in your app. It means feeling a genuine sense of mutual care or shared stake with other people. The study's gamification arm used team-based competition, which creates a structural reason for teammates to be invested in each other's behavior. If you're on a team and you don't show up for a workout, your team's score drops. That's actual relatedness pressure, not simulated community.
This distinction matters a lot for product design. A leaderboard with strangers satisfies almost none of the relatedness need. Seeing that "User847" in Portland is ahead of you doesn't create mutual investment. A team structure where people have opted in together, where their individual choices affect people they care about, is a meaningfully different mechanism.
The BCT Taxonomy v1 distinguishes between "social comparison" (BCT 6.2) and "social support" in its unspecified, emotional, and practical variants (BCTs 3.1, 3.2, 3.3). Social comparison is about knowing where you stand relative to others. Social support is about people actively backing you up. The gamification bundle in this study probably activated both, but the team structure is doing more of the heavy lifting via social support, not just comparison.
If your product has a leaderboard with strangers, you're implementing BCT 6.2 and calling it a social feature. That's likely weaker than what this study actually tested.
The caveats product teams need to own
The sample is 160 college students. That's a population with very specific characteristics: high baseline digital literacy, structural free time, and social networks where peer competition carries real meaning. Physical activity norms in college settings are also different from sedentary adult populations or patients managing chronic conditions.
Eight weeks is enough time to see a behavior change effect but not enough to know whether the effect sustains. Gamification research consistently shows early spikes followed by decay, which is sometimes called the "novelty effect." This study can't rule that out.
The activity domain matters too. Physical activity is one of the better-studied areas in behavior change, and it responds to gamification more reliably than domains like medication adherence or dietary behavior, where the reinforcement loops are harder to design. Don't take this study as evidence that gamification is broadly effective across all mHealth contexts. It's evidence for this domain, this population, and this time window.
Generalizability to clinical populations is genuinely unclear. Patients managing a chronic condition have a different relationship to their health goals than a college student who wants to walk more. The stakes are higher, the barriers are different, and the social dynamics around health behavior don't work the same way.
The design implication: real social structure is doing the work
Here is the honest product takeaway from this study: the gamification that worked had a real social structure underneath it. Teams, not just leaderboards. Mutual stake, not just visibility.
Most apps I audit implement gamification as a points-and-badges system on top of individual tracking. That's a competence mechanism, not a relatedness mechanism. It might improve short-term engagement, but it doesn't create the social fabric that this study was actually testing.
If you want to build something that approximates what this RCT tested, you need social structures with actual commitment. Users who opt in together, groups with shared goals, designs where one person's behavior is visible and meaningful to specific others, not just an anonymous cohort.
That's harder to build than a badge system. It requires thinking about user acquisition and retention as social, not individual. It requires features for group formation, group communication, and group-level progress that most mHealth products skip because they're expensive to develop and hard to moderate.
But that's what the evidence points at. The gamification that produces behavior change is the kind that makes people feel accountable to people they actually care about. The version that doesn't require that structure, points and ranks with strangers, is probably doing a lot less than product teams assume.
The JMIR paper is one of the cleaner causal estimates available right now for gamification's role in mHealth. Use it carefully, cite its limitations honestly, and don't generalize it further than its design supports. But do take seriously what it's actually showing: that team-based social competition, grounded in relatedness, is an independently effective behavior change mechanism when isolated from the app platform underneath it.
That's a meaningful finding for product teams who are still deciding whether social features are worth the complexity.