TempoLife — acquisition & activation

Generated Sat 05 Sep 2026 14:07:01 EEST · refreshes every minute · aggregate counts only, no identifiers
durable = active + verified + non-guest + signup stamped
Reading the two "signups" cards: a signup = a durable account exists; finishing setup = the person made it through the onboarding wizard. The gap between them is the §7 waterfall drop — and the reason your admin panel and this dashboard can honestly disagree.
382
Durable users
99,618 to goal
15
Signups today
13 finished setup · 2 stuck
144
Signups last 7d
112 finished setup · 77.8% completion
6
Email-verified 7d
21.4% of submits · 2 via Google
243
Completed setup
63.6% of durable
55
Ever logged a meal
22.6% of completers
25
Logged 2+ days
6.5% of durable
1
Active guests
guest mode off · 7d fuse

Data integrity — 3 FAILING

CheckResultEvidence
Daily signups reconcile with a direct head-count PASS table sums to 311 · direct count 311 (14d)
Setup funnel is monotonic PASS durable 382 >= started 346 >= completed 243
Retention is a subset of activation PASS ever logged 55 >= logged 2+ days 25
Snapshot agrees with live durable count PASS snapshot 372 <= live 382
Counter steps never exceed their parent step FAIL google_return(15) > google_start(0) [30d] · setup_step_4(8) > setup_step_3(6) [today] · setup_step_5(10) > setup_step_4(8) [today]
All platform labels are known to this page PASS 18 labels mapped
New durable signups all carry a signup_platform FAIL since 2026-08-27: 100 / 243 stamped
Signups today: how many completed setup PASS 15 signups today, 13 finished setup (86.7%)
Rendered counter totals equal the table PASS table 172833 · rendered 172833 (30d)
Dim lenses never exceed their canonical step PASS 7 families within canonical rows (7d)
Verify-fail reasons are a subset of verify_fail PASS reasons 0 <= generic 0 (7d)
v2.60.0 counter pairs never exceed their parent PASS 5 new pairs hold (7d)
All dim values are known buckets FAIL unmapped: fam:sleep, fam:fasting, fam:steps
Every rendered dim cell meets the k≥5 floor PASS 77 dim cells folded to k≥5 (7d)
Each row re-derives a displayed number from tempolife with an independent query or asserts a funnel invariant. A FAIL means the number above it is wrong — investigate before acting on this page.

Signup journey — where they get stuck, in one table

StageCountShare of max% of parent
Landing page seen2862
·
Tapped a landing CTA10
0.3%
Saw the sign-in screen2703
Email signup submitted28
1.0%
Verification code sent11
39.3%
Email verified — account OK6
54.5%
Google sign-in started0
0.0%
Google sign-in OK2
Setup screen seen170
Setup completed21
12.4%
First meal logged5
23.8%
7-day window. The email and Google branches split after the auth screen; setup is fed by both. A >100% ratio renders as — rather than a lie (the parent and child were not instrumented over the same period).

Where do they get stuck — biggest drops, with reasons

DropCountLossWhat the reason counters say (7d)
Landing → CTA tap10 / 2862−2852bounced within 5s: 82 · scrolled past 25%: 139
Auth → email submitted28 / 2703−2675login tab shown (returning users): 437 · switched to login: 7
Setup seen → completed21 / 170−149validation errors: 182 · slow steps (30s+): 86 · went back a step: 40
Submitted → code sent11 / 28−17email taken (returning user!): 8 · invalid fields: 8
Code sent → verified6 / 11−5resends requested: 5
Top 5 by absolute drop. Reason counters only exist for the failure modes listed — a drop with no reasons is itself a finding (no failure instrumented there yet).

Email registration & verification

28
submitted
39.3%
11
code sent
54.5%
6
verified
Why codes failCount Time from send to verifyCount DeliverabilityCount
Wrong code0 < 30 s3 Resends requested5
Expired / no code0 30 s – 2 min3 Retries after fail14
Too many attempts0 2 – 10 min0
any failure0 10 min + (spam rescue?)0
By email-provider class — where codes are sent vs where accounts get verified. Cells under 5 are folded into other (k-anonymity floor).
Provider classCode sentVerifiedSent → verified
Gmail 7 6 85.7%
other 4 0 0.0%

Auth screen — tabs, dwell, first field

Which tab greeted themCount Tab switchesCount First field focusedCount Dwell before leavingCount
Register tab20 → login (the returning-user signal)7 Email (register)1 0 – 5 s (bounce)53
Login tab437 → register43 Name16 5 – 30 s91
Password1 30 s +117
Login form72
Client-side beacons on the auth page, 7d. A high auth_tab_switch_login share means people arrive believing they already have an account — a login/register clarity problem, not an acquisition problem.

Landing engagement — did the page work on them

Scroll depthCount CTA decision speedCount Referrer classCount
25%139 Tapped within 3 s0 Direct2368
50%115 3 – 10 s7 Google search59
75%106 10 s + (readers)10 Google Ads click4
100% (bottom)96 Left within 5 s (bounce)82 Social0
Other431
7d, of 2862 landing views. Scroll depth is cumulative (each visitor counts once per threshold). Referrer classes are closed buckets — the raw URL is never stored.

Password recovery — can locked-out users get back in

0
reset started
0
password reset
Rejected reset codes (7d): 0. Before v2.60.0 these users were indistinguishable from people who never signed up.

Language funnel — is the journey worse in some language

LanguageLanding viewsAuth screensLanding → auth
English26871124.2%
Estonian8133.7%
Finnish491836.7%
Russian45817.8%
7d, k≥5 folding applied. Languages without data are hidden by the fold.

Hour of day — when the funnel is awake

Hour (Europe/Tallinn)Landing viewsAuth screensActivity
03:007033
04:008423
05:006827
06:006931
07:006453
08:006714
09:009970
10:008448
11:0012866
12:00179817
13:00159116
14:00165120
15:00126170
16:00143120
17:0013892
18:00141117
19:007256
20:009562
21:00148138
22:00121109
23:00170190
00:00133124
01:0010668
02:0023339
7d. Hours are stored in server-local buckets (UTC) and this axis is shifted by the current Tallinn offset (UTC+3), so during a DST-change week one bucket can be ±1 h off. Hour is a closed bucket — minute-level timing is never stored.

Google sign-in — does the browser ever come back?

151
tapped button
0.0%
0
POST reached us
10
came back
20.0%
2
signed in
Taps outrun the server: 151 button taps never reached the POST. Either the network dropped, or the JS on the auth page never dispatched — check for a client error on the pages that host the button.
No Google sign-in has been started in this window. If auth_view is non-zero, people are seeing the screen and not tapping the button — a different problem from the OAuth wall.
7-day window. google_return is the decisive counter: it can only increment when the browser survives the round trip to accounts.google.com.

Android app — where installs give up

408
opened, no session
416
saw sign-in
1.4%
6
got an account
Counts android_app + android_wv. The largest drop between two numbers is the thing to fix next.
More sign-in screens than app boots. Two causes, both real: rows counted before the 2026-08-26 relabel called every Android WebView android_app, and app_boot_anon only fires via auth_check.php/index.php, so an app that opens straight onto auth.php is never counted as a boot. Trust this ratio from 2026-08-26 onward only.

Who are they — platform mix

Platform groupEventsShare%Raw labels
Android — our app3920
2.4%android_app 3920
Android — WebView (?)201
0.1%android_wv 201
Android — PWA1
0.0%android_pwa 1
Android — browser7400
4.5%android_web 7289 · android_tablet 111
Android — in-app5
0.0%android_inapp 5
iOS753
0.5%ios_web 547 · ios_pwa 180 · ios_inapp 21 · ipad_web 5
Desktop24924
15.1%desktop_web 24911 · desktop_pwa 13
Bots127985
77.5%bot 127985
Unclassified23
0.0%other 23
Reading the labels. android_app is our shell positively identified by its package name. android_wv is an Android WebView we could not attribute — before v2.58.0 every WebView, including Facebook's and Instagram's, was reported as our app, so any history above is an upper bound rather than an install count. web and inapp are the old coarse labels and only appear on rows counted before v2.58.0.

Landing-page CTAs — what actually gets tapped

CTATaps (7d)Share%
Play Store10
100.0%
Continue with Google0
0.0%
Sign up (generic)0
0.0%
Email link0
0.0%
Overall tap-through: 0.3% of 2862 landing views tapped something.

Setup wizard — where people quit

StepArrivalsRetention from prev%
Step 1 170
·
Step 2 (gender) 218
Step 2b (body) 193
88.5%
Step 3 120
62.2%
Step 4 83
69.2%
Step 5 69
83.1%
Step 6 65
94.2%
Setup completed (7d): 21 · end-to-end retention from step 1 → completion: 12.4%
Step friction (7d)122b3456
Validation errors shown 157 3 22 · · · ·
30 s+ dwell before advancing 77 · 5 2 2 · ·
Back-navigation total (7d): 40 — going back means that step wasn't quite right.

Registration failures — split by reason

ReasonCountShare of submits%
Email already registered (returning user!) 8
28.6%
Password too short 0
0.0%
Invalid name / email / country / alias 8
28.6%
8 "email already registered" in 7d — these are RETURNING users who thought they were signing up fresh. The right fix is a clearer login/register tab or a smarter "email exists, sign in?" flow, not more acquisition spend.

Full funnel — step × platform

StepAllandroid_appandroid_inappandroid_pwaandroid_tabletandroid_webandroid_wvbotdesktop_pwadesktop_webios_inappios_pwaios_webipad_webother
Landing page seen28622··41147962114676329321
APP opened — no session20533261·5341482213·8904752110
Sign-in / register screen seen27033291·5343287379·131741179110
Browser came BACK from Google10········3·61··
Google sign-in succeeded2··········2···
Email registration submitted2825···1···2·····
Verification code sent118···1···2·····
VERIFIED — account usable66·············
Existing user tried to log in9476···13···5·····
…wrong credentials2321·······2·····
…logged in15····13···2·····
APP opened — signed in1169964·1·41···9·11737··
Setup screen seen (step 1 arrival)170139···220··6·12··
Reached setup step 2 (gender)218217·········1···
Reached step 2b (body measurements)193192·········1···
Reached setup step 3120120·············
Reached setup step 48383·············
Reached setup step 56969·············
Reached setup step 66565·············
Setup completed2120·········1···
FIRST MEAL LOGGED55·············
Counting began 2026-08-25. Steps added later read zero for earlier days — that is missing instrumentation, not a missing user.

Durable signups — last 14 days

DaySignupsSetup doneLogged a mealActivation
2026-09-0515 132 15.4%
2026-09-0426 232 8.7%
2026-09-0317 131 7.7%
2026-09-027 50 0.0%
2026-09-0118 131 7.7%
2026-08-3121 163 18.8%
2026-08-3022 162 12.5%
2026-08-2961 508 16.0%
2026-08-2827 2113 61.9%
2026-08-2729 91 11.1%
2026-08-263 21 50.0%
2026-08-2519 72 28.6%
2026-08-2428 165 31.2%
2026-08-2318 85 62.5%

Daily durable total (snapshot)

DateDurableΔ
2026-09-05372 ·
2026-09-04351 +21
2026-09-03330 +21
2026-09-02320 +10
2026-09-01310 +10
2026-08-31263 +47
2026-08-30245 +18
2026-08-29214 +31
2026-08-28186 +28
2026-08-27145 +41
2026-08-26142 +3
2026-08-25133 +9
2026-08-24103 +30
2026-08-2375 +28
scripts/funnel_dashboard.php v2.60.0 · funnel_counters (migrations 0095 + 0097) + durable-user truth · dim lenses with k≥5 floor · ads guard enabled · campaigns 24066573735