TempoLife — acquisition & activation

Generated Sat 24 Oct 2026 13:28:02 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.
1048
Durable users
98,952 to goal
6
Signups today
4 finished setup · 2 stuck
50
Signups last 7d
44 finished setup · 88.0% completion
2
Email-verified 7d
40.0% of submits · 12 via Google
819
Completed setup
78.1% of durable
192
Ever logged a meal
23.4% of completers
70
Logged 2+ days
6.7% of durable
0
Active guests
guest mode off · 7d fuse

Guest pipeline (idea 54 — created · converted · swept per day)

A guest = a real row, 7-day fuse, convertable in place (data kept). Created* counts rows minted that day that are STILL guests (converted/swept rows leave this count); converted counts rows flipped durable that day (guest_converted_at); swept counts rows hard-deleted by the sweep cron — no sweeps logged yet.
DayCreated*ConvertedSweptConversion
2026-10-24 00:00:00+02 0 0 0 —
2026-10-23 00:00:00+02 0 0 0 —
2026-10-22 00:00:00+02 0 0 0 —
2026-10-21 00:00:00+02 0 0 0 —
2026-10-20 00:00:00+02 0 0 0 —
2026-10-19 00:00:00+02 0 0 0 —
2026-10-18 00:00:00+02 0 0 0 —
2026-10-17 00:00:00+02 0 0 0 —
2026-10-16 00:00:00+02 0 0 0 —
2026-10-15 00:00:00+02 0 0 0 —
2026-10-14 00:00:00+02 0 0 0 —
2026-10-13 00:00:00+02 0 0 0 —
2026-10-12 00:00:00+02 0 0 0 —
2026-10-11 00:00:00+02 0 0 0 —
Totals: 0 guest rows still active · 14 converted ever. Age of ACTIVE guests: 0 ≤1d · 0 1–3d · 0 3–5d · 0 5–7d · 0 >7d (fuse overdue — sweep cron should catch these).

Data integrity — 3 FAILING

CheckResultEvidence
Daily signups reconcile with a direct head-count PASS table sums to 92 · direct count 92 (14d)
Setup funnel is monotonic PASS durable 1048 >= started 1004 >= completed 819
Retention is a subset of activation PASS ever logged 192 >= logged 2+ days 70
Snapshot agrees with live durable count PASS snapshot 1048 <= live 1048
Counter steps never exceed their parent step FAIL google_return(45) > google_start(0) [30d]
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: 772 / 913 stamped
Signups today: how many completed setup PASS 6 signups today, 4 finished setup (66.7%)
Rendered counter totals equal the table PASS table 356632 · rendered 356632 (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: net:fast, net:unknown, idea:96, idea:94, fam:sleep, fam:fasting, fam:steps
Every rendered dim cell meets the k≥5 floor PASS 126 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 seen19837
·
Tapped a landing CTA33
0.2%
Saw the sign-in screen11837
—
Email signup submitted5
0.0%
Verification code sent3
60.0%
Email verified — account OK2
66.7%
Google sign-in started0
0.0%
Google sign-in OK12
—
Setup screen seen55
—
Setup completed0
0.0%
First meal logged12
—
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 tap33 / 19837−19804bounced within 5s: 38 · scrolled past 25%: 38
Auth → email submitted5 / 11837−11832login tab shown (returning users): 15 · switched to login: 2
Setup seen → completed0 / 55−55validation errors: 57
Submitted → code sent3 / 5−2email taken (returning user!): 1
Code sent → verified2 / 3−1no reason counters fired
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

5
submitted
→60.0%
3
code sent
→66.7%
2
verified
Why codes failCount Time from send to verifyCount DeliverabilityCount
Wrong code0 < 30 s0 Resends requested0
Expired / no code0 30 s – 2 min0 Retries after fail1
Too many attempts0 2 – 10 min1
any failure0 10 min + (spam rescue?)1
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
other 3 2 66.7%

Auth screen — tabs, dwell, first field

Which tab greeted themCount Tab switchesCount First field focusedCount Dwell before leavingCount
Register tab84 → login (the returning-user signal)2 Email (register)0 0 – 5 s (bounce)18
Login tab15 → register3 Name4 5 – 30 s35
Password0 30 s +34
Login form3
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%38 Tapped within 3 s7 Direct15636
50%27 3 – 10 s15 Google search12
75%22 10 s + (readers)11 Google Ads click1
100% (bottom)17 Left within 5 s (bounce)38 Social0
Other341
7d, of 19837 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
English14809650.4%
Estonian342247.0%
Finnish364226.0%
Russian364256.9%
de3975413.6%
fr495418.3%
pt454306.6%
pp345133.8%
es483367.5%
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:001080744
04:001305497
05:001203589
06:001329599
07:00948626
08:00596775
09:00930406
10:001036449
11:00609493
12:00386487
13:00297496
14:00125323
15:00140314
16:00127374
17:00118374
18:00126350
19:00146377
20:00160326
21:00638705
22:002803729
23:002111585
00:001514374
01:00917365
02:001193480
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?

67
tapped button
→0.0%
0
POST reached us
→—
32
came back
→37.5%
12
signed in
Taps outrun the server: 67 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

126
opened, no session
→100.0%
126
saw sign-in
→1.6%
2
got an account
Counts android_app + android_wv. The largest drop between two numbers is the thing to fix next.

Who are they — platform mix

Platform groupEventsShare%Raw labels
Android — our app2441
1.9%android_app 2441
Android — WebView (?)30
0.0%android_wv 30
Android — PWA50
0.0%android_pwa 50
Android — browser3384
2.6%android_web 3351 · android_tablet 33
Android — in-app17
0.0%android_inapp 17
iOS4247
3.3%ios_web 4209 · ios_pwa 6 · ios_inapp 19 · ipad_web 13
Desktop53701
41.4%desktop_web 53701
Bots65734
50.7%bot 65734
Unclassified15
0.0%other 15
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 Store32
97.0%
Continue with Google0
0.0%
Sign up (generic)1
3.0%
Email link0
0.0%
Overall tap-through: 0.2% of 19837 landing views tapped something.

Setup wizard — where people quit

StepArrivalsRetention from prev%
Step 1 55
·
Step 2 (gender) 0
0.0%
Step 2b (body) 0
—
Step 3 0
—
Step 4 0
—
Step 5 0
—
Step 6 0
—
Setup completed (7d): 0 · end-to-end retention from step 1 → completion: 0.0%
Step friction (7d)122b3456
Validation errors shown 57 · · · · · ·
30 s+ dwell before advancing · · · · · · ·
Back-navigation total (7d): 0 — going back means that step wasn't quite right.

Registration failures — split by reason

ReasonCountShare of submits%
Email already registered (returning user!) 1
20.0%
Password too short 0
0.0%
Invalid name / email / country / alias 0
0.0%
1 "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_webios_inappios_pwaios_webipad_webother
Landing page seen19837·4·16717166142116156·130597
APP opened — no session7118124·414224886386·26513
Sign-in / register screen seen11837124·5145260810920·212613
Browser came BACK from Google32··2·1·126··2··
Google sign-in succeeded12··1·9··2·····
Email registration submitted55············
Verification code sent33············
VERIFIED — account usable22············
Existing user tried to log in63···3········
…wrong credentials52···3········
APP opened — signed in623578··517·184·1···
Setup screen seen (step 1 arrival)5543·1·10··1·····
FIRST MEAL LOGGED1211·1··········
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-10-246 40 0.0%
2026-10-237 72 28.6%
2026-10-2210 102 20.0%
2026-10-2110 83 37.5%
2026-10-204 41 25.0%
2026-10-194 32 66.7%
2026-10-187 61 16.7%
2026-10-173 31 33.3%
2026-10-162 20 0.0%
2026-10-154 30 0.0%
2026-10-144 41 25.0%
2026-10-1313 136 46.2%
2026-10-126 42 50.0%
2026-10-1112 103 30.0%

Daily durable total (snapshot)

DateDurableΔ
2026-10-241048 ·
2026-10-231037 +11
2026-10-221027 +10
2026-10-211018 +9
2026-10-201013 +5
2026-10-191007 +6
2026-10-181001 +6
2026-10-17998 +3
2026-10-16997 +1
2026-10-15991 +6
2026-10-14987 +4
2026-10-13976 +11
2026-10-12968 +8
2026-10-11956 +12
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 24083302508,24066573735,24285806619,24285807339,24285807342,24291236813,24291236816,24291237797,24291238040,24297019408,24297020062,24297020545,24306626770