TMA Analytics — Master Implementation Brief

1. RevenueCat → Integrations → AppsFlyer → connect (dev key + app ids). The $appsflyerId attribute is already there, so purchases will post server-side with the correct media source.
2. Enable the events: af_start_trial, af_purchase, af_subscribe — each carrying revenue + currency.
3. One nuance: dormant users (last active before ~June) have no $appsflyerId. That's fine — purchases come from active users, so postbacks will attribute correctly going forward.

1. Open the Amplitude integration you already configured.
2. In the event list, enable every remaining lifecycle event: rc_trial_started, rc_trial_converted, rc_trial_canceled, rc_renewal, rc_uncancellation, rc_non_subscription_purchase, rc_subscription_paused, rc_expiration, rc_billing_issue, rc_product_change, rc_transfer, rc_web_purchase_redeemed, rc_experiment_enrollment.
3. Keep the rc_ prefix and the exact names above (they're the locked taxonomy — don't use RevenueCat's verbose defaults like rc_renewal_event).
4. Identity gap found 10 Jul: no customer profile carries $amplitudeUserId. RevenueCat's events will therefore attach to RC's own ids, not to the Amplitude user ids the rest of our product events use — so an rc_initial_purchase can't be joined to that same person's onboarding or workouts. Until Task 17 (T4) ships, set the RevenueCat subscriber attribute $amplitudeUserId so the two systems agree on who the user is.
5. Once af_purchase is fixed (Task 5), accept Amplitude's merge suggestion for purchase + rc_initial_purchase — but leave af_purchase out of the merged view until then, or it poisons the metric.

1. (Steps 1–4 = the original GA4-import route — SUPERSEDED by Nic's independent GTM tag, 20 Jul. Keep for reference; if ever enabled alongside the GTM tag, the imported action must be SECONDARY.) GA4 → Admin → Product links → Google Ads links → link account 690-916-9207.
2. GA4 → Admin → Events → mark purchase as a key event.
3. Google Ads → Goals → Conversions → Import → Google Analytics 4 → select purchase.
4. Set it as the campaign's conversion goal. (Do this after Task 9 fixes the purchase event, or you'll import a broken signal.)

1. Every active campaign → objective OUTCOME_SALES (not Leads, not App Installs).
2. Ad set → optimisation event = Purchase — i.e. the fb_mobile_purchase app event mapped in Task 2 (only once Tasks 2 & 3 are verified — never optimise to an event that isn't arriving). Not Subscribe — see the note below.
3. Exclude existing subscribers and active app users from all cold audiences.
4. Meta app-install campaigns stay permanently off. They are not being restructured; they are retired.

The four segments to stamp on each user:

1. Compute each user's furthest funnel step (from the backend's own event/state data — no need to query GA4).
2. Write it to a Customer.io / ActiveCampaign contact attribute, e.g. funnel_stage = survey_unfinished | no_workout | no_trial | paywall_seen, plus last_seen_at.
3. Refresh nightly.

1. Ensure UTMs survive the landing → quiz navigation (don't strip query params on redirect).
2. Confirm sessionSource / firstUserSource are populated on the quiz page-view and screen events.
3. Set GA4 user_id once the email is captured, so web and app join later.

The number, so nobody re-asks: web trial→paid = 30.0% — 24 paid of 80 real-email trials, phantom mints excluded (measured 6 Aug from Stripe). App trial→paid = 62% (RevenueCat, low volume). The web funnel converts trials at roughly half the app’s rate — that gap is the CRO target, and every paid-scale model should use 30%, not the app number.

1. Do not restart UAC until Tasks 5 and 8 are verified.
2. Rebuild UK/US only, optimisation event = trial start.
3. Collect a 200-install baseline; scale only if install→trial ≥5%.

1. Confirm OneLink is on the AppsFlyer plan (most paid tiers include it; if not, add the standalone "Deep Linking Suite"). 5-minute dashboard check.
2. Build the OneLink template — the smart link carrying deep_link_value + a per-link web fallback URL.
3. Complete AppsFlyer's ESP integration for Customer.io (and ActiveCampaign) so their link-wrapping doesn't break the deep link. Register the OneLink + ESP click domains — and hand those exact domains to the RN team for Task 24.
4. Hand off: the route map (deep_link_value → screen) ↗ to the RN team; the OneLink URL pattern to the email team.

1. Pick the canonical id: the backend user id (the one the web quiz will also set as GA4 user_id).
2. On login and on signup, set it everywhere:
   • RevenueCat: Purchases.logIn(userId)
   • Amplitude: amplitude.setUserId(userId)
   • AppsFlyer: setCustomerUserId(userId)
3. Set the RevenueCat subscriber attributes $amplitudeUserId and $appsflyerId (from AppsFlyer.getAppsFlyerUID()) so the server-side connectors can attach correctly.
4. Handle logout / account switching so ids never leak between users.

1. Initialise and identify the native Amplitude SDK on both platforms, using the Task 17 id.
2. Fire the already-named events from the Event Catalog at the right moments (workout started/completed, auth, key product actions). You're not designing events — 53 are already named and dormant.
3. Also add push + review measurement (new — folded into this task in the RN brief): push_permission_*, push_received/push_opened, app_opened with source, in_app_review_prompted. These make re-engagement measurable and give D1/D7/D30 a denominator.
4. Defer the onboarding-screen and paywall-screen events until the signup redesign ships — those screens are being rebuilt.

1. Upgrade the RevenueCat SDK to a Paywalls-capable version; add RevenueCatUI.
2. Render the paywall from the remote Offering + Paywall config (never hardcoded product ids) so Experiments can assign variants without a build.
3. Keep firing the existing checkout events (subscription_checkout_screen_opened, payment_initiated, subscription_checkout_confirmed) so the funnel stays continuous.
4. Confirm in the RN brief's confirm-pass: does the app already render the current Offering? current RC SDK version? (both size the work).

1. Stitch (RN‑6 core): persist the full AppsFlyer conversion payload for all sources; on register/login set setCustomerUserId + RC/AF attributes + POST {user_id, email, appsflyer_id, media_source, utm_*} to the TMA endpoint.
2. ➕ Deep-link add-on: wire the OneLink deep-link listener → the existing DeepLinkService (today it only console.logs); route on deep_link_value to the mapped screen, handling deferred (first-launch) as well as direct.
3. ➕ Register domains: add the OneLink subdomain AND the ESP (Customer.io/AC) click domain to iOS Associated Domains + Android App-Links (the ESP wraps links, which breaks a plain Universal Link unless both are registered — this is why it needs a binary).
4. ➕ Route map: implement TMA's deep_link_value → screen table (the route map ↗ — workout · resume_assessment · upgrade · update_payment · today); unknown → home.