Gamification metrics: DAU/WAU, participation, completion rate

Gamification works only where its effect is confirmed by numbers. Below is a system analysis of three basic metrics, without which it is impossible to manage missions, events and awards: DAU/WAU, participation rate (participation) and completion rate (completion).

1) DAU/WAU and stickiness

Definitions

DAU (Daily Active Users) - the number of unique users with a targeted action per day (login, client launch, bet/spin, mission completion, etc.).

WAU (Weekly Active Users) - Unique users with a targeted activity in the last 7 days.

DAU/WAU (Stickiness) - the proportion of "daily active" among "weekly."

[
\text{DAU/WAU} = \frac{\text{DAU}}{\text{WAU}} \quad (0\ldots1)
]

How to interpret

0.15-0.25 - basic "healthy" stickiness for recreational products with a non-daily pattern.

0.25-0.35 - a good level with regular missions and easy entry.

💡 0.35 - strong behavioral "stickiness," usually with daily tasks, streak'ax and motivating rewards.

Important: evaluate by segment (beginners, re-activated, paying, mid-core, high-value). The overall figure easily masks problems.

Frequent distortions

Inflation due to bonus days. A single "hype" event will raise DAU, but will not improve the DAU/WAU trend on the horizon of 4-8 weeks.

False multi-activity. Bot/duplicate accounts. Device-fingerprint deduplication + KYC signals are required.

Change of "target action." If you change the "who is considered active" rule, fix the date and build "metric 2. 0».

2) Participation rate

Definition

The proportion of users who entered the gamification cycle (event/mission/tournament) among the target audience.

Basic formulas:

[
\text{Participation (gross)}=\frac{# \text{users_with_event_open}}{# \text{eligible_audience}}
]

[
\text{Participation (net)}=\frac{# \text{users_started_progress}}{# \text{eligible_audience}}
]

Gross - everyone who saw the event and clicked "participate."

Net - those who really started the execution (for example, made the first X points/spins/quest steps).

Correct "denominator"

"Optional audience" is recorded in advance: for example, all users who are active ≥1 times in the last 14 days and fall into geo/rules.

Separately, read reach communications (push, in-app, email). Low participation often = low reach.

Standards and guidelines

Net participation 12-25% for mass light events.

5-12% for "hardcore" events with an entry threshold (deposit/level).

30% + is achieved in micro prints for warm segments (D1-D7 beginners, re-engaged).

3) Completion rate

Definition

Percentage of participants completing the mission/chain/event.

[
\text{Completion Rate}=\frac{# \text{users_completed}}{# \text{users_started}}
]

Versions

Per-task completion - completion of specific steps in the chain (T1, T2,...).

Full-chain completion - the completion of the entire line.

Time-bounded completion - completion to deadline.

Interpretation

The standards depend on the length and "price" of the tasks.

Simple single mission: 60-85%.

Chain of 3-5 steps: 35-60%.

Long quest 7-10 steps: 18-35%.

Reducing completion in late steps is not always a bad thing. It can be a conscious funnel of monetization/complexity. It is important that Net Uplift remains positive and RG metrics remain in the green zone.

4) A bunch of metrics: "saw → started → completed"

Build a single funnel:

1. Reach: saw the event.

2. Participation (gross/net): in/out.

3. Progression: proportion of T1/T2/.../Tn reached (with timings).

4. Completion: completed.

5. Value: ΔDAU/WAU, ΔRetention, ΔARPPU, ΔAvg Deposit, Bonus Cost%, Net Uplift.

This allows you to catch "leaks": low reach, entry barriers, bending over the complexity of steps 2-3, UX dips (poor visibility of progress).

5) Analіtika: segmentation and cohorts

Recommended sections:

Stage: beginners D0-D7, returned R7-R30, permanent P30.
Monetization: non-paying, new paying (NPP), re-paying (RPP), high-value.
Channel/Geo/Platform: web/iOS/Android, countries/regulations.
Content: mission type (XP, backs, deposit), game volatility, thresholds.

For each group, fix DAU/WAU, participation, completion, ARPPU, Bonus Cost per Active - before/during/after the event (D-window, W-window).

6) Experimental design: proving the increment

Holdout control: part of the audience does not see the event (or sees the "dummy").

Randomized Invitation: random distribution of invitations, fix reach.

Geo/Channel Split: if random is prohibited - neat matching.

Measurement window: effect "during" and post-event tail (7-14 days).

Final metrics: Δ DAU/WAU, Δ Participation/Completion, Δ ARPPU (net of bonus), Retention D7/D30, Net Uplift.

7) DWH/events: minimal data schema

Events (example):

`session_start {user_id, ts, platform}`
`mission_view {user_id, mission_id, ts}`
`mission_join {user_id, mission_id, ts}`
`mission_progress {user_id, mission_id, step, value, ts}`
`mission_complete {user_id, mission_id, ts}`
`purchase/deposit {user_id, amount, ts}`
`spin/bet {user_id, game_id, bet, win, ts}`

Reference books:

`missions {mission_id, type, start_at, end_at, rules, segment, min_requirement, reward_type}`
`users {user_id, geo, platform, signup_at, payer_flag, segments}`

8) Calculation examples (SQL sketches)

DAU for date d:

sql
SELECT DATE(ts) AS d, COUNT(DISTINCT user_id) AS dau
FROM session_start
WHERE DATE(ts) =:d
GROUP BY 1;

WAU for the week ending with date d:

sql
SELECT COUNT(DISTINCT user_id) AS wau
FROM session_start
WHERE ts >=:d - INTERVAL '6 day' AND ts <:d + INTERVAL '1 day';

DAU/WAU (stickiness):

sql
WITH dau AS (
SELECT COUNT(DISTINCT user_id) AS dau
FROM session_start
WHERE DATE(ts) =:d
), wau AS (
SELECT COUNT(DISTINCT user_id) AS wau
FROM session_start
WHERE ts >=:d - INTERVAL '6 day' AND ts <:d + INTERVAL '1 day'
)
SELECT dau::float / NULLIF(wau,0) AS dau_wau FROM dau, wau;

Participation (net) by mission:

sql
WITH elig AS (
SELECT user_id
FROM users
WHERE last_active_at >=:d - INTERVAL '14 day'
), started AS (
SELECT DISTINCT user_id
FROM mission_progress
WHERE mission_id =:m AND ts BETWEEN:start AND:end
)
SELECT COUNT(DISTINCT s. user_id)::float / NULLIF(COUNT(DISTINCT e. user_id),0) AS participation_net
FROM elig e
LEFT JOIN started s ON s. user_id = e. user_id;

Completion rate by mission:

sql
WITH started AS (
SELECT DISTINCT user_id
FROM mission_progress
WHERE mission_id =:m AND ts BETWEEN:start AND:end
), completed AS (
SELECT DISTINCT user_id
FROM mission_complete
WHERE mission_id =:m AND ts BETWEEN:start AND:end
)
SELECT COUNT(DISTINCT c. user_id)::float / NULLIF(COUNT(DISTINCT s. user_id),0) AS completion_rate
FROM started s
LEFT JOIN completed c USING (user_id);

9) Design affecting participation and completion

Visibility: banners above the "crease line," badge on the Mission icon, progress bar on the home screen.

Clarity of rules: 1 screen = 1 key goal, examples of "how to score X points."

Micro-rewards on the way: loot drops for T1/T2/T3 → support motivation.

Entry threshold: do not overstate the requirements in the first step; complicate as you progress.

Timing: short sprints (2-24 h) for hot segments, weekly arches for mass.

Dynamic hints: "120 points left before the award ≈ 8 rounds of 15."

10) Anti-distortion and data quality

Deduplication: device-fingerprint + KYC flags to combat multiaccounting.

Anomalies: bursts started without progress → tracking bugs; completion> started → duplicates.

Freeze schema: any changes to business rules - only through metric versioning.

Time debugging: store 'event _ time' and 'ingest _ time'; time zone shifts are a common cause of "holes."

11) Dashboard: what to show daily

1. Stickiness: DAU, WAU, DAU/WAU (trend 8 weeks, median by segment).

2. Event funnel: Reach → Participation gross/net → T1/T2/... → Completion.

3. Quality: failures (bounce), average time to T1/T2, tracking errors.

4. Value: Δ ARPPU (net of bonus), Δ Avg Deposit, Bonus Cost%, Net Uplift.

5. Segments: section by stage/geo/platform/payer-status.

6. Alerts: participation drop> X pp, completion failure in a step, DAU/WAU deviation from the seasonal model.

12) Frequent errors

Read participation on the "entire database," ignoring the optional filters.

Interfere with gross and net participation, drawing conclusions "on average."

Optimize only completion, overestimating complexity and cut engagement.

Blindly rejoice in the growth of DAU without checking whether stickiness (DAU/WAU) and post-effect have increased.

Ignore the value of bonuses/prizes by misinterpreting the ARPPU Δ.

13) Start-up and evaluation checklist

Events and denominators (optional audience) are defined.
Business rules for DAU/WAU/participation/completion (v1. 0).
Holdout/rand configured for increment.
Dashboard in sections of segments, platforms, geo.
Quality alerts and anti-fraud control.
Final score: Δ DAU/WAU, Δ Participation/Completion, Δ ARPPU (net), Net Uplift, post-effect 7-14 days.

DAU/WAU shows the habit and stickiness of the product, participation shows the ability of the event to engage the target audience, and completion shows the quality of the balance of complexity and rewards. Consider them according to the same rules, keep versions, check the increment and the price of growth. Then gamification will be a predictable tool, not a lottery.