Separate event, lead, and outcome records
Case Growth Solutions' warehouse uses different records for controlled funnel events, delivered leads, and later business outcomes. Step views, answer IDs, disqualification reasons, and submit states can be analyzed without placing names, contact details, or free-text narratives in the event stream. Contact data stays with the lead record, while signed status belongs to the assignment and outcome history.
- Use session IDs for funnel progression
- Use lead and assignment IDs for delivery and outcome joins
- Do not turn an analytics event into a copy of the intake record
Normalize platforms without hiding their differences
The implemented campaign dashboards shape Meta and TikTok rows into a shared view for spend, leads, cost per lead, click-through rate, cost per thousand impressions, date range, and campaign status. Separate and blended views use the same selected window, while TikTok can also expose creative-level rows and Meta can expose placement and demographic breakdowns.
- Label the platform and reporting window on every view
- Keep the platform's source definition for a lead visible
- Treat a blended total as a reporting convenience, not a new source of truth
Make missing data and partial failure visible
Cross-platform fetches are settled independently so one provider error does not blank the other provider's data. The interface distinguishes demo, unconfigured, live, stored-sync, and error states. Lead Intel similarly separates CRM failure, needs review, conversion API status, and postback status instead of collapsing them into one generic warning.
- Show when spend exists but no warehouse leads join to it
- Display the last fetched or synced time
- Keep provider errors beside the affected data rather than silently substituting zero
Add downstream quality without copying the case file
Lead Intel joins campaign identifiers to delivered leads and can show qualified, needs-review, and signed counts, plus cost per qualified lead and cost per signed case when spend and outcome data are available. Those calculations use status projections and campaign identifiers; the dashboard does not need a case narrative to answer the operating question.
- Define every denominator before publishing a ratio
- Show unattributed and missing-source records
- Keep signed-event time distinct from lead-created time
Limit access by purpose
The dashboard project defines a read-only database role limited to the columns needed for aggregate and delivery triage views. The default lead table is PII-light, while a contact export is a separate explicit workflow. Production access also fails closed when dashboard authentication is not configured.
- Give reporting views the minimum database privileges they require
- Keep raw contact exports out of routine screen views
- Protect operational dashboards from indexing, framing, and unauthenticated access