Development of a Leaderboard for Mobile App Gamification

Note: when you have thousands of users, a plain ORDER BY score DESC starts killing the database. We've encountered this in projects for FinTech and EdTech clients — delays grew to 5 seconds, and users complained about lag. For real-time ranking among a million users, we use Redis with special data structures. In this article, we share architectural solutions proven on dozens of projects. A well-designed leaderboard is one of the most effective tools for boosting engagement. But implementation approaches vary greatly depending on scale and requirements. Implementation mistakes can lead to high latency and poor user experience.

We consider three main categories: up to 10,000 users, from 10,000 to one million, and over one million. For each case, there is an optimal stack and configuration. We use Redis with AOF persistence for reliability, and separate keys with TTL for periodic leaderboards. It's also important to define the leaderboard type: global, periodic, social, or 'around me' — each solves its own motivation tasks.

And don't forget about UX: animations, avatar caching, and smooth rank updates are critical for perception. In this material, we focus on technical details and best practices that help avoid common mistakes. On the client side, we use image caching and incremental list updates.

Choosing Technology for a Leaderboard Based on Scale

Up to 10,000 users: PostgreSQL with RANK() / DENSE_RANK() window functions. A paginated query runs fast even without special indexes. We cache the top 100 in Redis with a 5-minute TTL.

10,000 – 1,000,000 users: Redis Sorted Sets (ZADD, ZRANK, ZREVRANK, ZREVRANGE). Adding scores: ZADD leaderboard:global NX <score> <user_id> or ZINCRBY leaderboard:global <delta> <user_id>. Getting user rank: ZREVRANK leaderboard:global <user_id> — O(log N). Top 100: ZREVRANGE leaderboard:global 0 99 WITHSCORES — O(log N + 100). This works without degradation even on a million users.

Millions of users: Sharding Redis Sorted Sets by time periods and regions. A global leaderboard becomes an unattainable goal for most — demotivating. Better to segment.

Types of Leaderboards and Their Characteristics

Time Periods for Leaderboards

Global 'all time' — for top players. Weekly and monthly — for everyone else. Reset at the beginning of a period: don't delete data, archive it. The user should see their past results.

Reset implementation: separate key for each period leaderboard:weekly:YYYY-WW, leaderboard:monthly:YYYY-MM. When the period expires, create a new key — the old one remains for history. TTL on old keys: 30 days for weekly, 90 for monthly.

Why the 'Around Me' Leaderboard Boosts Engagement?

The most useful type for the average user. Not 'top-100', but 'you are at position 4573, here are 5 people above and 5 below'. Motivates those who will never make the top.

Implementation on Redis: ZREVRANK to get user rank, then ZREVRANGE(rank-5, rank+5) for neighboring positions. An additional query to PostgreSQL to get display name and avatar by user_id from the result.

Social Leaderboards

Leaderboard among friends often motivates more than global. Implementation is trickier: there's no point in a global sorted set for a list of 50 friends.

Option 1: When opening the screen, query PostgreSQL: SELECT user_id, score FROM user_scores WHERE user_id IN (:friends_list) ORDER BY score DESC. Works for a small number of friends (up to 200).

Option 2: A separate sorted set for each user leaderboard:user:<user_id>:friends — update whenever any friend's score changes. More memory expensive in Redis (about 1.5x), but instant reads.

Display and UX

Highlighting the current user's position in the list is a must. Animated rank update when getting new scores (ScrollTo + highlight). Growth/decline arrows next to position — 'you rose 12 places today'. Historical rank curve for the period.

On Flutter: AnimatedList for smooth updates. On iOS: UITableView with performBatchUpdates. On Android: RecyclerView with DiffUtil. Don't reload the entire list on update — only changed cells (3-5 on average).

Avatars in the leaderboard — cache aggressively. SDWebImage (iOS) / Glide (Android) / cached_network_image (Flutter) with disk cache (up to 50 MB). Don't show leaderboard without names and avatars — only skeleton during loading.

Turnkey Leaderboard Development Process

1. Analysis and architecture: study requirements, choose stack (Redis + PostgreSQL), design API.
2. Backend implementation: configure Redis Sorted Sets, develop endpoints for rank and top.
3. Client side: integrate on iOS (Swift), Android (Kotlin) or Flutter with animations and caching.
4. Integration with authentication system: link to existing user database.
5. Documentation and testing: load testing (up to 10,000 RPS), check real-time performance.
6. Deployment and support: deploy on servers, one month of free maintenance.

What's Included

• Architecture and API documentation
• Access to repository with source code
• Deployment and setup instructions (including Redis configs)
• Team training on leaderboard operation
• One month of technical support after launch

Our Experience

We have been developing mobile applications with gamification for over 5 years. Our portfolio includes 50+ projects, including leaderboards for fintech, edtech, and gaming apps. We guarantee stable operation under load up to 10 million users. — Mobile Development Team

# redis.conf
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Timeline Estimates

Basic leaderboard with weekly/monthly period and user rank — 2–3 days (client) + 2–3 days (backend on Redis). With social leaderboard, 'around me', rank history, and real-time updates — 1–2 weeks. Cost is estimated individually after analysis. Contact us to discuss implementing a leaderboard in your app.

Mobile App Analytics: Firebase, Amplitude, AppsFlyer and Attribution

Our team regularly encounters projects where analytics is already "set up" but yields no real insights. A typical example is a startup with 50k DAU: tracking dozens of events without a single answer to the question "why don't users reach payment?". In two weeks we built a basic funnel and found that 70% of users drop off at the phone number verification screen. After fixing the bug, retention increased by 12%. The takeaway: analytics should start with specific questions, not tracking everything indiscriminately.

Why Event Taxonomy is the Foundation of Mobile App Analytics?

Firebase Analytics, Amplitude, Mixpanel — technically similar. The difference lies in what you put into them. A common mistake: events like screen_view, button_tap_1, button_tap_2 without context. A month later, no one remembers what button_tap_2 means.

Proper taxonomy: object + action + context. product_viewed, checkout_started, payment_completed with parameters product_id, category, price, source. This allows building funnels, cohort analysis, and retention without additional tracking.

We document the naming convention in a tracking plan — a document (Google Sheet or Amplitude Data Catalog) describing every event, its parameters, and triggering conditions. The tracking plan is synced with the analytics team before development begins, not after. This approach ensures that data remains interpretable months later and doesn't become a dump. Experience from 50+ projects confirms: without a tracking plan, analytics maintenance costs increase 2-3 times due to rework.

What Should You Choose for Mobile App Analytics: Firebase, Amplitude, or Mixpanel?

The table below highlights key differences between the three popular platforms. Choice depends on budget, traffic, and tasks.

Firebase Analytics — free, deep integration with Google Ads, BigQuery export for raw data. Limitations: data latency up to 24 hours, limited funnels. For startups with Google Ads traffic, it's the first choice.

Amplitude — product analytics focused on cohorts and user journeys. Journeys (formerly Pathfinder) shows actual paths between events — not assumed funnels but real routes. Session Replay records sessions for UX analysis. The free tier up to 10M events/month is enough for most products at launch.

Mixpanel — close to Amplitude, stronger in real-time segmentation. Insights, Funnels, Retention cover 90% of product analysts' tasks.

How to Solve Multi-Channel Attribution with AppsFlyer?

Knowing where a user came from is a separate task. Firebase Attribution works only within the Google ecosystem. For multi-channel attribution (Facebook Ads, TikTok, Apple Search Ads, programmatic), an MMP (Mobile Measurement Partner) is needed.

AppsFlyer is the market leader. OneLink — universal deep link working on iOS and Android, correctly attributing installs from any channel. Protect360 — built-in fraud protection (fake installs, click injection on Android). Adjust and Branch are competitors with similar features. Branch excels in deep linking; Adjust is popular in gaming.

According to Apple, with iOS 14.5, apps must obtain user permission via ATT before collecting IDFA for tracking. AppsFlyer uses probabilistic matching (IP + user agent + timing) for these users — accuracy is lower but better than nothing. SKAdNetwork and Privacy Preserving Attribution provide aggregated data from Apple with a 24-72 hour delay.

How to Set Up Crash Analytics to Not Miss Bugs?

Firebase Crashlytics is the standard for crash reporting. It automatically groups crashes by stack trace, shows affected users %, and sends velocity alerts when crash rate increases by more than 10% per hour.

Important: symbolication. On iOS, .dSYM files must be automatically uploaded with each build — via Fastlane upload_symbols_to_crashlytics or Xcode Cloud built-in. Without symbols, crashes in Crashlytics appear as memory addresses. This happens more often than expected when switching to a new CI — in one project with 500k users, we found that 40% of crashes remained unsymbolicated due to a missing CI/CD step. After automation, bug response time dropped from 3 hours to 15 minutes.

For React Native and Flutter, @sentry/react-native and sentry_flutter provide additional context: breadcrumbs, network requests before the crash, Redux/Provider state.

Below is a comparison of popular crash analytics tools to choose according to your needs.

Environment Setup

Three environments with separate Firebase projects: dev, staging, production. Mixing analytics from test sessions and production is a common mistake that skews all metrics. On iOS via GoogleService-Info.plist per scheme, on Android via google-services.json in each flavor folder.

Timelines: basic analytics with Firebase + Crashlytics — 3-5 days. Full tracking plan + Amplitude/Mixpanel with funnels and cohorts — 2-3 weeks. Attribution via AppsFlyer with deep linking and fraud protection — 1-2 weeks. Cost is calculated individually based on integration complexity.

What Is Included in Our Work

As part of analytics implementation, we provide:

• Development and approval of a tracking plan with product and marketing teams.
• SDK integration (Firebase, Amplitude, Mixpanel, AppsFlyer) considering your stack (Swift/Kotlin/Flutter/React Native).
• Setup of funnels, cohorts, dashboards, and alerts.
• Automation of symbolication and .dSYM upload via Fastlane.
• Documentation of events and parameters.
• Team training on the analytics platform.
• Two weeks of post-release support and tracking adjustments.

Our experience: 7 years of analytics implementation and over 80 successful projects in mobile development. We guarantee data correctness and transparency at every stage.

Contact us for a consultation on setting up analytics for your app. Request an audit of your current analytics — and we will show you which metrics you are losing.