Lifecycle, adoption, support, engagement, feedback, and renewal evidence are interpreted in separate systems.
SignalPath
I designed SignalPath to explore how lifecycle, product, support, engagement and customer-feedback signals could support earlier human investigation of renewal risk.
What to know before reading the full case study.
Designed the evidence model, synthetic-data methodology, interpretable ranking experiment, responsible-use controls, and browser experience.
Case study, frozen Candidate 10 experiment, interactive prototype, and a separate AWS demo with a read-only API.
Working synthetic case study and live demo with fictional customer records.
Customer-journey analysis, analytics, explainable modeling, responsible AI, UX design, API integration, and technical implementation.
Customer evidence is distributed across the lifecycle.
Lifecycle progress, product adoption, support friction, communications, education, customer feedback and renewal context are often interpreted in separate systems. SignalPath explores how those signals can be brought into one evidence trail without turning a predictive score into an automatic customer treatment.
What is happening across the customer lifecycle, who is affected, why is it happening, and what should the organization investigate next?
MeridianLoop, a configurable workflow SaaS company.
The design scenario uses a fictional mid-market and enterprise B2B SaaS company with annual subscription contracts, implementation/onboarding work, named Customer Success coverage and a full path from sale through renewal and expansion. No employer, client or customer data is used.
Journey first, prediction second.
The experience deliberately starts with systemic lifecycle patterns, touchpoint response and segment differences before moving to an individual account. Observed evidence, model contribution, counter-signals, data quality and human interpretation are kept separate.
How to read the analytical language in this project.
- Lifecycle evidence
- Information showing where a customer is in the relationship and what has happened so far.
- Eligible renewal snapshot
- A fixed view of an account 120 days before a contractual renewal, using only information available at that time.
- Censored outcome
- A renewal whose result is not yet observable. It is excluded instead of being incorrectly counted as retained.
- Risk ranking
- A relative ordering used to decide what deserves human review first, not a precise probability that an account will leave.
- Calibration
- How closely model scores align with observed synthetic outcomes. Imperfect calibration is why exact-looking probabilities are not shown.
- Model contribution
- How a signal influenced the model’s ranking within this experiment. It does not prove that the signal caused the outcome.
4,000 accounts over 24 months, generated locally.
The development population is entirely synthetic. Renewal opportunities originate from actual synthetic contract boundaries. The prediction point is 120 days before contractual renewal and the feature observation window is the trailing 12 months ending at that point. Accounts without an observable eligible outcome are censored rather than treated as retained.
| Design element | Candidate 10 setting |
|---|---|
| Primary outcome | Logo churn / non-renewal |
| Secondary outcome | Contraction / downgrade, modeled separately |
| Designed prevalence | Approximately 15%; synthetic design choice, not an industry benchmark |
| Public account sample | 60 curated fictional profiles; not statistically representative |
The generated development data, model matrix, partitions and raw prediction snapshots remain local and are not part of the public prototype.
An interpretable ranking baseline, with visible limitations.
SignalPath uses logistic regression to rank eligible accounts by relative non-renewal risk using only information available at the prediction point. Raw feedback text and the separate implementation/adoption rule scores are excluded from the baseline model.
| Final-test measure | Candidate 10 |
|---|---|
| Eligible accounts | 410 |
| ROC-AUC | 0.647 |
| PR-AUC | 0.301 |
| Precision at frozen 20% setting | 28.7% |
| Recall at frozen 20% setting | 42.9% |
| Accounts flagged | 94 |
| Retained accounts also flagged | 67 |
| Churn events missed | 36 |
Calibration is imperfect. Candidate 10 is useful as a prioritization experiment, not as a precise individual churn probability or autonomous prediction system.
Validation failures shaped the final analytical controls.
Earlier synthetic candidates were deliberately invalidated when distribution drift, lifecycle sequencing, pre-activation production usage and renewal-eligibility defects appeared. Candidate 10 carries those lessons forward through stronger fixtures, relationship-aware intervals, contract-authoritative renewal boundaries and repeated feature-lineage checks. Earlier candidates' model metrics were not reused to optimize Candidate 10.
Pattern → journey → segment → account → intervention → validation.
The prototype is not structured as a generic executive dashboard or CRM. Portfolio Pulse surfaces lifecycle conditions; Journey Explorer connects touchpoints to lifecycle stages; Segments & Signals combines quantitative and qualitative evidence; Account 360 creates a deliberate boundary between pre-prediction evidence and later outcomes; Intervention Lab supports hypotheses only; Model Quality makes false positives, false negatives, calibration and segment suppression visible.
Human review is a product requirement, not a disclaimer.
- Renewal risk is a relative band and Candidate 10 global percentile, never an exact individual churn probability.
- Model contributors describe conditional model behavior and are not causal drivers.
- Implementation risk is shown as transparent status and drivers, not a calibrated score.
- Adoption risk keeps risk drivers, protective signals and data sufficiency separate.
- Segment performance is suppressed below 40 total examples, 8 churn events and 20 retained examples.
- Intervention scenarios are hypothetical model responses and cannot initiate customer treatment.
A static case study with a separate serverless live demo.
The case study remains a static portfolio page. Its companion demo uses semantic HTML, CSS, and vanilla JavaScript served from the existing S3 and CloudFront site, then calls a public GET-only Amazon API Gateway endpoint backed by a Python 3.12 AWS Lambda function.
Responsive browser interface with filters, an account-evidence table, and accessible account-detail dialogs.
API Gateway routes summary, account-list, account-detail, health, and model-reference requests to one Lambda function.
A bundled read-only SQLite file contains 4,000 fictional accounts and precomputed reference_v1.1.0-logistic scores. No managed database or live model training is used.
Site-restricted CORS, GET-only routes, request throttling, CloudWatch logs, and alarms support a small public demo.
The Candidate 10 metrics in this case study belong to the frozen local analytical experiment. The live demo is a separate deployed implementation with newly generated synthetic data and its own model artifact; its scores and metrics are not Candidate 10 results.
The hard part is not producing a risk number.
The stronger portfolio evidence comes from defining eligibility correctly, preventing leakage, making missingness explicit, comparing a model with simple operating rules, exposing capacity tradeoffs and building an interface that keeps observed evidence separate from predictive interpretation.
Try the live demo
The companion build turns the case-study concepts into a live customer-lifecycle investigation backed by a read-only AWS API. All organizations and customer records are fictional and synthetic.