Forex CRM Lead Management and Reporting: Funnel, Cohort and Attribution Architecture
Dashboards are only as reliable as the data model beneath them. Design lead management and reporting around defined stages, consistent identifiers and attribution rules, then build the views.
Define the funnel as a state model
Stages: lead, contacted, registered, verified, funded, active, retained. For each define entry criteria, timestamp, owner and permitted transitions. Store each transition with a timestamp so time-in-stage can be computed.
Attribution
Capture source, campaign and referrer at registration, store them on the client record and never overwrite them. Define the attribution model (first touch, last touch) and apply it consistently. See our Forex CRM guide.
Cohort retention
Group clients by registration or first deposit month and track activity at 30, 60 and 90 days. Cohorts show whether changes in acquisition or onboarding improve retention.
Core metrics
- Conversion rate by stage and source.
- Median time between stages.
- Cost per funded account by source.
- Net funding by cohort.
Define each metric once, in writing.
Data quality and access
Validate required fields, deduplicate clients and reconcile CRM balances with the trading server. Restrict access by role and log exports. See the revenue model.
Data quality checks to automate
- Required fields present at registration.
- Duplicate detection on identity and contact data.
- Daily reconciliation of balances against the trading server.
- Stage transitions without timestamps.
Alert on failures so bad data is fixed before it reaches a dashboard.
The funnel as a state model
Define the funnel as an explicit state machine: lead, contacted, registered, documents submitted, verified, funded, active, dormant. Each state has an entry condition, a timestamp and an owner. Metrics are then counts and conversion rates between states over a cohort, which avoids ambiguity about what a number means.
Store state transitions as events with timestamps and sources. Event data supports funnel, cohort and time-to-convert analysis without re-instrumenting later.
Metric definitions
| Metric | Definition | Denominator | Source |
|---|---|---|---|
| Lead to registration | Registered within 7 days of lead | Leads in cohort | CRM events |
| Registration to funded | First deposit within 14 days | Registrations in cohort | CRM and payments |
| Time to verify | Median hours from submit to verified | Verified clients | CRM events |
| 30-day retention | Active in days 23 to 30 | Funded in cohort | Platform activity |
| Cost per funded client | Spend divided by funded | Funded in cohort | Finance and CRM |
Publish definitions with each dashboard. Changing a definition requires a version note.
Attribution and data quality
Capture source parameters at first touch and at registration, store them immutably and map them to a controlled list. Decide the attribution rule (first touch, last touch or partner code priority) and document it.
Automate data quality checks: required fields at registration, duplicate detection, orphaned records, state transitions without timestamps and daily reconciliation of counts with the platform. Alert on failures so that bad data is fixed before it reaches a dashboard.
Access control and privacy
Dashboards expose personal data. Apply role-based access, aggregate views by default, mask identifiers where not required and log access to sensitive exports. Define retention and deletion rules.
See our security guide for access and logging practices.
Worked example: a cohort table
Group clients by registration week. For each cohort, compute the share funded within 14 days and the share active at day 30. A table of cohorts by week shows whether a change in onboarding improved conversion for later cohorts, without being confounded by seasonal mix.
Annotate the table with changes (new funding page, new verification flow) so that the cause of a step in the numbers is visible later.
Performance and scalability
Dashboards over large event tables need indexed queries, pre-aggregated daily tables and caching where freshness permits. Define freshness targets per dashboard and show the last refresh time.
Monitor query time, because a dashboard that takes minutes to load stops being used.
Experiment tracking and decision logs
Log every funnel experiment with hypothesis, change, population, duration, metric and result, and record the decision. Over time this log becomes a library of what works for your audience and prevents repeated tests.
Link log entries to dashboards with annotations so that changes in trend can be explained months later.
Frequently asked questions
Why model the funnel as states?
It makes metrics unambiguous and supports cohort analysis from event data.
What attribution rule should I use?
Choose one that fits your partner model, document it and apply it consistently.
How do I keep dashboards trustworthy?
Automate data quality checks and reconcile counts with the platform.
How should access be controlled?
By role, with aggregation, masking and access logs.