Data flow

A high-level view of what data the test collects, where it goes, and what stays in the user’s browser.

Overview

The hearing test supports two data-capture flows. The primary flow is the PDF flow, where a full PDF report is generated at the end and user data is pushed to the CRM via webhook. The secondary flow is a lighter Klaviyo-only lead-capture variant used when a full report is not required.

flowchart LR P["Parent site
(any origin)"] U["User's browser"] A["Hearing test app
(iframe)"] subgraph primary ["Primary — PDF flow"] DB["App database
(profile + answers)"] PDFGEN["PDF generated client-side
(jsPDF + html2canvas)"] S["App storage
(/uploads)"] W["CRM webhook
(email automation)"] DL["PDF downloaded
to user"] end subgraph secondary ["Secondary — Klaviyo lead capture"] K["Klaviyo
(lead storage)"] end P -- "embeds iframe" --> A U -- "interacts with" --> A A ==> |"POST /api/save-profile"| DB A ==> |"render audiogram
& interpretation"| PDFGEN PDFGEN ==> |"POST /api/upload-pdf"| S S ==> |"report link + user data"| W PDFGEN ==> DL A -. "alternative lead form
(name, email, consent)" .-> K classDef ext fill:#ecfeff,stroke:#06b6d4,color:#0f172a; classDef app fill:#eef2ff,stroke:#6366f1,color:#0f172a; classDef own fill:#dcfce7,stroke:#16a34a,color:#0f172a; classDef client fill:#fef9c3,stroke:#ca8a04,color:#0f172a; class K,W ext class A app class DB,S own class PDFGEN,DL client

Solid arrows show the primary PDF flow; the dotted arrow is the secondary Klaviyo-only alternative. Green = app-owned storage, yellow = client-side only, blue = third party.

Primary flow — PDF flow

  1. User fills the profile form (name, surname, email, phone, province) and a short questionnaire (phone use, hearing problem, hearing-aid use, terms).
  2. Profile + answers are posted to /api/save-profile and stored in the app’s database (one row per user + one row per answer).
  3. User completes the tone test; thresholds are captured in-browser.
  4. On the results page, the user clicks Download PDF. The audiogram and interpretation panels are rasterised with html2canvas and composed into a three-page PDF with jsPDF (profile + questionnaire, audiogram, interpretation).
  5. The PDF is uploaded to the app’s own storage via /api/upload-pdf. The public URL is returned to the browser and cached in localStorage for re-downloads.
  6. The browser POSTs the formatted user data plus report_link to the CRM webhook, which fans out to the email automation.
  7. The browser then triggers a download of the PDF to the user’s device.

Secondary flow — Klaviyo lead capture

When the deployment does not need a full PDF report (for example a pure lead-gen landing page), the profile step is replaced with a Klaviyo-hosted form. The form’s submission is handled entirely by Klaviyo: name, email and consent are stored as a lead, and the user’s first name is mirrored to localStorage so the rest of the test can greet them by name. Nothing is saved to the app’s own database and no PDF is produced in this flow.

What is collected

Flow Data Where it goes Why
Primary Name, surname, email, phone, province, questionnaire answers, terms App database (/api/save-profile) Lead record & PDF personalisation
Primary Tone thresholds per ear / frequency Browser memory → rendered into PDF Audiogram & interpretation in the report
Primary Generated PDF file App storage (/public/uploads), public URL Re-downloadable report + attached to CRM record
Primary Formatted user data + report_link CRM webhook → email automation Follow-up flow for the lead
Secondary First name, email, consent Klaviyo (via embedded form) Lightweight lead capture & email list
Both First name Browser localStorage Personalising the test and results screen

Third parties

Online Hearing Test user guide · Generated for internal reference.