Allin — lifecycle marketing data flow

Green = confirmed working as intended. Amber = a real, evidenced gap. Detail on every box below.

This is the single biggest practical constraint on lifecycle email today, independent of whether the pipeline is wired correctly — even a perfectly-wired system can only email 6.5% of the base. It also directly undercuts the "send a consent opt-in email campaign" plan flagged on the CRM wiki: an email send can only ever reach the same 6.5%. If push also can't be relied on (see below), there's no external channel that reaches the other 93.5% — the only reliable path to them is inside the app itself, next time they open it.

AnalyticsClient.identify(userId, email) is called from 5 places — initial sign-in, cached-session restore, sign-in success, and the point analytics consent is first granted. Every call sends one Segment identify(), which Segment fans out to every enabled destination from a single payload — there's no way for the app to send email to Customer.io but not Amplitude from one call. That's exactly why the Amplitude email fix was done as a Segment-dashboard mapping (a destination-level filter dropping the email trait for Amplitude specifically) rather than removing email from the app's call — confirmed by reading identify() directly, it still sends email unconditionally today, so Customer.io's copy of every identify call is untouched by that fix.

Moment	Event(s)	Source
Onboarding	onboarding_started, onboarding_step_viewed, onboarding_completed, onboarding_skipped	OnboardingFlow.swift
Sign-in / account	sign_in_succeeded, sign_in_failed, sign_out, account_deleted, consent_granted	AuthenticationManager.swift, AppView.swift
Check-in	checkin_started, checkin_completed	AppView.swift
Plan	plan_step_started, plan_step_completed, plan_block_completed	AppView.swift
Audio session	audio_session_started, audio_session_completed, audio_session_paywalled	AudioSession.swift
Paywall / subscription	paywall_viewed, paywall_continued_free, paywall_restore_tapped, paywall_dismissed, subscribe_clicked, subscribe_succeeded, subscribe_failed, subscribe_cancelled	PaywallView.swift, SubscriptionManager.swift
Notifications / deep links	notification_opened, deeplink_opened	AppDelegate.swift, AppView.swift
Referral	referral_share_presented	AppView.swift

Every one of these is gated by the client-side consent check (below) before it fires — but see the audit-trail gap for why that gate's real-world coverage is uncertain.

recommend-plan sends plan_block_generated plus a Customer.io identify() carrying real selected life-areas and 1–10 ratings, on every plan generation. revenuecat-webhook forwards every subscription lifecycle event (started, renewed, cancelled, billing issue, expired). Both run entirely server-side — triggered by an HTTP call or RevenueCat's own webhook — so the app's on-device consent flag never applies to them at all.

AnalyticsClient.hasAnalyticsConsent is checked before configure()/identify()/track() — that part works. The problem is what it's checking: a local UserDefaults flag, with no server-side record of whether that flag reflects a real, provable grant. Checked live just now: the user_consents table still doesn't exist in production, and record_consent_granted's live version still only writes a single blanket timestamp with no argument for which consent was actually chosen. So the gate that decides whether any of this fires is real, but unaudited — there's no way to demonstrate, for any given user, that their current device-local flag matches an actual choice they made.

A shared _shared/consent.ts helper is written and wired into both recommend-plan and revenuecat-webhook, fail-closed (no consent row, or a lookup error, resolves to "don't send"). Checked live just now: both functions are still at the exact same versions as before this was built (recommend-plan v33, revenuecat-webhook v5) — the gate exists on a branch, not in production. Every plan generation and every subscription event is still forwarded to Segment unconditionally today.

Customer.io's Segment integration only reads a push token from context.device.token when it's already set on one of three specific events — Application Opened, Application Installed, or Application Uninstalled. Segment's SDK only sets that field once registeredForRemoteNotifications(deviceToken:) is called (confirmed directly in the analytics-swift source — it writes to context.device.token via a dedicated plugin).

In AllinApp.swift, AnalyticsClient.shared.configure() starts the SDK, which fires Application Opened automatically, essentially at launch. In AppDelegate.swift, requesting the push token requires a real network round-trip to Apple's servers before the token is known — structurally slower than a same-run-loop event. The two paths are independent, unsynchronized Tasks. On a cold launch, Application Opened almost certainly fires — and is sent to Customer.io — before the token exists to attach to it. This isn't a first-install-only problem: Application Opened fires on every cold launch.

Confirmed there's no fallback: only analytics-swift (Segment), purchases-ios-spm (RevenueCat), facebook-ios-sdk, and supabase-swift are linked in the project — no Customer.io native SDK exists in this app at all. The fragile Segment-context mechanism above is the only path a device token has to reach Customer.io, and it's the one racing.

Everything above about which event names trigger Customer.io's device-token or identify mapping comes from Customer.io's own public documentation, not a look at the actual configured mapping for the "Allin iOS" source — that lives in Segment's web dashboard, which needs a login this environment doesn't have (the same access gap as the missing SEGMENT_ACCESS_TOKEN, already known). Worth two minutes: Customer.io (Actions) destination → mappings → confirm what's actually wired for email and device.token, rather than relying on what's typical.

This audit traces data into Customer.io — it can't see what's configured to happen once data arrives, since that needs Customer.io's own App API (a different credential from the Track API key already confirmed working in Supabase secrets), which isn't available here. Worth a direct look: which campaigns/journeys are live, what triggers each, and whether any assume a device token or email that (per above) may not actually be arriving reliably.

1. Decide the push-token fix — native Customer.io SDK vs. a careful Segment-only workaround. Real, live gap affecting push for effectively every user today.
2. Reconsider the consent opt-in campaign's channel — an email send reaches at most 6.5% of users; push can't be relied on either per above. The only channel that reliably reaches the other ~93.5% is inside the app itself (a banner or modal on next open), not an external send.
3. Confirm the Segment → Customer.io mapping live — 2 minutes, closes the biggest remaining unknown in this whole trace.
4. Deploy what's already built — the server-side consent gate and the consent audit trail, both sitting on a branch, both confirmed still not live.
5. Check what campaigns actually exist in Customer.io directly, since this audit can trace the data in but not what happens to it once there.

Decide the push-token fix approach (native SDK vs. workaround) · check the Segment → Customer.io destination mapping live · check what Customer.io campaigns/journeys actually exist and what they assume · decide the consent opt-in approach given the 6.5% email-reach constraint · approve deploying the server-side consent gate + consent audit trail