← all sprint docs

Message to Nic — Google installs: retargeting decision + measurement wiring

From Aga (drafted by the growth fleet) · 9 Jul 2026 · HISTORICAL BRIEF — all figures are as-of 9 Jul 2026; live numbers live on the Growth Cockpit · companion: RC_AMPLITUDE_EVENT_TAXONOMY.md (Docs tab on the cockpit)

Nic — we ran the full growth fleet on the "should we retarget the Google installs with a different offer" question. Here's the decision and the why, plus the wiring list with the "does this need an app release?" answer for each piece.

The decision (grounded in the RN app's real flow + this week's GA4 data)

The RN flow is: install → sign up → short survey (no fundamentals placement) → dashboard with mock data → 3 free workouts → paywall. So the retarget message is NOT "come back to the assessment" (there isn't one) — it's matched to where each user actually dropped, which the new GA4 events now show us (7d, users, by first-user source — first week of this wiring, treat as directional):

Funnel step Google FB/IG Organic/direct
app_installed 978 489 422
AppOnboarding_started 217 (22%) 67 (14%) 145 (34%)
AppOnboarding_completed 193 (89% of starters) 60 127
workout_started 36 10 173
premium_offer_viewed 74 13 90
trial_started 7 0 8
in_app_purchase 2 0 0
app_remove (uninstall) 545 279 134

What this says: 1. The big leak is install → onboarding start: 78% of Google installs never begin the survey (either never open the app, or bounce at signup). That's a traffic/campaign-quality problem, not an offer problem — no retarget reaches people who never signed up. 2. The survey is NOT the leak — 89% of starters finish it. The mid-survey pool exists but is small (~24 Google users/wk; ~65/wk all sources). Still retarget it (cheap, warm): "finish setup — 2 minutes." 3. The dashboard→workout step is the biggest addressable drop: 193 completers → only 36 start a workout. ~150 Google users/wk (≈500/wk all sources) signed up, finished onboarding, and never used their 3 free workouts. This is THE retarget segment, and the hook writes itself: "your 3 free workouts are waiting." Unused free value, email-addressable, zero cost. 4. Google traffic is NOT producing zero: 7 of this week's 15 non-FB app trial starts and 2 in_app_purchase events are google-first-source. Tiny n, and GA4's in_app_purchase badly undercounts (3 events/7d vs RC's ~6 renewals/day) — but it kills the "Google = 0, write it all off" claim. The wiring below makes this number trustworthy. 5. FB/IG app installs look worse than Google on every step (0 trials from 489 installs) — worth the same lens later.

The retarget ladder (all free channels — email + push; segment by last event):

Segment Size (7d, Google / all) Message Offer
A. Signed up, survey unfinished ~24 / ~65 "Finish setup — 2 min" deep-link into the survey none yet
B. Survey done, 0 workouts ~157 / ~500 "Your 3 free workouts are waiting" deep-link to workout 1 none — let the free value convert
C. Workout(s) done, no trial ~30 / ~90 "Here's what week 2 looks like" → trial 7-day free trial
D. Saw paywall, no trial ~67 / ~180 72h later: step-down $9.99/30-day (offer test 17b)
E. Installed, never signed up ~760/wk Google unreachable by email; one push if token exists, else write off

Never the $297/lifetime to any of these. No paid retargeting audiences — the pools are hundreds, not thousands.

Cadence suggestion: D+1 after drop (A/B), D+3 (C), D+3 and D+7 (D). All automatable in Customer.io/AC once the backend can emit "last funnel step" per user — or as a v1, a weekly batch export from GA4/backend is fine.

Why the wiring below still matters

The funnel above is directional (first week of events, GA4 undercounts real purchases ~10×). The RC→AppsFlyer postback + conversion feed make the trial/purchase columns trustworthy, feed Google's algorithm so UAC stops buying 78%-never-open traffic, and let us finally judge the channel on real numbers.

The wiring list — and whether it needs an app release

# Task Release needed?
1 RC → AppsFlyer S2S purchase postback (RC dashboard → Integrations → AppsFlyer). Sends every real subscription purchase server-side — fixes Google AND Facebook measurement in one move. Dashboard-only IF RC already holds each user's AppsFlyer ID ($appsflyerId subscriber attribute). 2-min check: open any RC customer profile → Attributes. If it's there → no release. If missing → one SDK line (Purchases.setAppsflyerID(...)) = normal app update, and until then S2S events land unattributed.
2 Google conversion feed — GA4 ↔ Google Ads link + import the purchase event (check if Firebase's auto in_app_purchase is already in GA4 — if yes this is ~10 min) as a conversion action, then select it in the campaigns. No release. Pure console (GA4 admin + Ads console). The Ads API route can wait for the dev-token approval — not a blocker.
3 RC → Amplitude (T2) — you've enabled it; our API still sees zero rc_* events in the project our dashboards read. No release. Just confirm which Amplitude project it's connected to (name/ID) so we read the right one. Naming: canonical rc_* per the locked taxonomy doc.
4 GA4 source-segmented funnel dashboard (AppOnboarding_Started → workout_started → premium_offer_viewed by firstUserSource) — gives us install→paywall visibility per channel while #1/#2 land. Also tells us, for the first time, whether Google installs actually reach the paywall. No release. Reporting only. Claude can build the pull; your GA4 events from 8 Jul already power it.
5 Geo exclusions going forward — ET/TZ/NG/BD excluded from all paid; AP/SA/LATAM stay off/floor until #1+#2 are live and we can see what they actually produce. No release. Ads console.
6 The re-engagement send itself — segment: signed-up, no trial, last 60 days. From the backend/CIO; copy comes from us (assessment-first, free trial, $9.99 step-down at 72h). No release. Email now; push if tokens exist.

Bottom line on releases: everything is console/server-side except possibly #1's identity link — and that has a 2-minute check before we know. Nothing here waits on an App Store/Play review cycle unless that check fails.

Sequencing

  1. Check #1's $appsflyerId attribute (2 min) → flip the RC→AppsFlyer integration.
  2. 2 GA4 conversion import (console).

  3. 3 confirm the Amplitude project ID.

  4. We ship the re-engagement send (#6) in parallel — it doesn't depend on 1–3.
  5. Once ≥30 real purchase events are visible in the pipeline, we sit down and make the actual keep/kill/scale call on UAC with real numbers. Until then, no verdict.