Appearance
BRIEF: User flow + analytics architecture for Creative AdBundance
For: Eric Mann, Kyle Fenerty (Creative AdBundance) From: Taha Abbasi, Ian Friend (AskFlorence) Date: 2026-05-11 Status: Shareable. Pre-Stage-1 handoff. Tracks: ENG-280Stage 1 target: Mid July 2026
TL;DR
You bring whatever performance-marketing stack you want (Meta CAPI, Google EC, LinkedIn, TikTok, Reddit, A/B testing, heatmaps, email/audience tools, etc.). You send us the list of what you plan to wire. We do a 24-48 hour compliance check on our side and the tools go live. There is exactly one architectural rule you need to know about, and we handle it for you: the moment a user starts the enrollment process, third-party scripts stop loading and our backend takes over conversion forwarding. You never have to instrument the portal.
The user flow
Apex carries PII at most (email, ZIP, age, income range, NPN, name). Any tool you bring is fair game on apex, subject to a one-shot compliance check. Client-side pixels load here; server-side mirrors (Meta CAPI etc.) also fire here.
Portal carries PHI (SSN, DOB, income docs, enrollment records). HIPAA + EDE Phase 3 apply. Zero third-party scripts; first-party self-hosted analytics only (OpenPanel + GlitchTip, self-hosted on our AWS). Conversion attribution back to your ad platforms fires from our backend, server-side, with hashed PII.
The cut is enforced by being on a separate subdomain. Cookies set on askflorence.health cannot follow a user into app.askflorence.health. The browser drops them at the boundary. This is the rule and it is enforced by physics, not by policy or runtime checks.
What this means in practice
Where your tools run
| Surface | Your tools | How |
|---|---|---|
Apex marketing (askflorence.health and everything pre-cut) | Anything you bring, after the 24-48h compliance check | Client-side or server-side, your choice |
Portal (app.askflorence.health and everything post-cut) | None ever | Architecturally blocked via CSP |
You do not need to think about which routes are "safe" and which aren't. The subdomain split decides it for you. Anything you wire goes on the apex; nothing you wire ever goes on the portal.
Two configuration choices we ask about for tools you bring
Both are configuration choices in standard tools, not bans:
- Session-replay with input recording on the calculator — the calculator captures household income. Not technically PHI, but adjacent enough that we'd rather not record keystrokes. If you bring Hotjar, FullStory, Microsoft Clarity, or similar, please ship them with input masking ON. Heatmaps + click tracking are fine.
- Cookie domain scope — any cookie you set should be scoped to apex (
Domain=askflorence.health), not wildcarded (.askflorence.health). Most tools default to apex. We confirm at review time.
That's it. Everything else is yours to pick.
How conversion attribution works without you instrumenting the portal
The conversion event you care about is "enrollment submitted." That happens inside the portal where no third-party pixel can fire. We solve this server-side from our backend so you do not have to think about it.
Your deliverable for this to work: pixel IDs + ad account access + conversion event names. That is it. The pipeline is ours.
What we need from you
A short list. Per tool you plan to wire, please share:
- Tool name + vendor (e.g. "Meta Pixel + Conversions API")
- What data flows to it (e.g. "PageView, Lead event with hashed email")
- Where it loads (apex always; never portal)
- BAA status if applicable (most ad-tech vendors do not offer BAAs because they do not need to; we just want it on the registry)
- Cookie domain scope if it sets cookies
Send the list any way you want. We turn it into a registry row, run a one-shot review, and reply within 24-48 hours with approval or a specific configuration ask. Once a tool is on the registry, you do not get asked about it again.
Timeline
| Window | Status |
|---|---|
| Done | Privacy policy + Terms of Service published (v2026.04). Unsubscribe flow shipped with CAN-SPAM compliant List-Unsubscribe headers. |
| Mid May → Mid June | First-party analytics floor (self-hosted OpenPanel + GlitchTip) replaces our current PostHog setup. Cookie consent banner shipped if your tool list includes anything that drops third-party cookies. |
| Mid June → Early July | Click-ID capture + server-side CAPI pipeline built as part of the member portal work. Subdomain app.askflorence.health provisioned. |
| Early July | Dry-run with internal spend to validate the full attribution loop. |
| Mid July | Stage 1 ($500-$2K validation spend) unlocks. |
If you have tools picked before mid-June, send the list and we will start the review loop early. Nothing about the timeline blocks you from sharing your plan now.
What this is not
- Not a list of approved tools. The list is whatever you bring.
- Not a list of banned tools. We do not pre-ban categories. Per-tool review on the configuration you propose.
- Not a process burden. One review per tool, then the tool is on the registry and you never hear from us about it again.
- Not a constraint on apex marketing. Everything you would normally do for a regulated-but-not-HIPAA vertical (consumer finance, fintech, lending) you can do here.
Contact
- Compliance review loop, technical wiring, anything ambiguous: Taha —
taha@askflorence.health - Partnership ops, ad account access, contracts: Ian —
ian@askflorence.health - Internal ref doc (the control side of this brief, for your compliance reviewer if you have one):
docs/security-compliance/marketing-vs-portal-analytics.mdin the AskFlorence repo. We will share the rendered version on request.
Reply with your tool list when you have it. We will move.
