User Churn Modeling & Retention Analysis
User Churn Modeling & Retention Analysis
User Churn Modeling & Retention Analysis
Product & Experimentation
A web application that scores trading customers on how likely they are to stop trading, and pairs every score with a suggested action for the retention team.
A web application that scores trading customers on how likely they are to stop trading, and pairs every score with a suggested action for the retention team.
A web application that scores trading customers on how likely they are to stop trading, and pairs every score with a suggested action for the retention team.
Why
After my internship at Monex I kept thinking about what the analysis would look like as something that is used within a company repeatedly. I wanted to find out whether I could take the same kind of customer data and turn it into a working tool, so I built the whole thing myself in PHP and SQL.
How it works
The scoring algorithm calculates a churn probability from three account metrics: initial margin, last equity, and profit and loss. The application segments customers by that probability and generates a tailored suggestion for each one, so whoever reads the score already knows what to do with it instead of having to interpret a number on their own.
Access and views
New users register with a code and returning users are validated against the database, so only verified people can see customer information. Beyond that there are four views: all data, a full table of every customer record; filtered, showing customers segmented by churn probability; search, for looking up an individual customer; and advanced, restricted by a separate code, which lets staff add customers to the database and email customer data by churn probability band.
Decisions
Splitting read access from write access is what made it usable. Everyone on a retention team benefits from seeing risk scores. Almost nobody should be able to add records or trigger outbound email. Two tiers let me put it in front of more people without making it dangerous. I also grouped customers into risk bands as well as showing a raw score, because a number like 0.73 does not tell you anything on its own.
What building it taught me
This was my first time working with a database directly, and most of what I learned came from the access side rather than the scoring. Registration requires a code, so people cannot sign themselves up. Sign in validates against the database and locks out after repeated failed attempts, so nobody can sit there guessing. The pages also check who you are before they load, which means typing a URL directly does not get you to the customer data.
Why
After my internship at Monex I kept thinking about what the analysis would look like as something that is used within a company repeatedly. I wanted to find out whether I could take the same kind of customer data and turn it into a working tool, so I built the whole thing myself in PHP and SQL.
How it works
The scoring algorithm calculates a churn probability from three account metrics: initial margin, last equity, and profit and loss. The application segments customers by that probability and generates a tailored suggestion for each one, so whoever reads the score already knows what to do with it instead of having to interpret a number on their own.
Access and views
New users register with a code and returning users are validated against the database, so only verified people can see customer information. Beyond that there are four views: all data, a full table of every customer record; filtered, showing customers segmented by churn probability; search, for looking up an individual customer; and advanced, restricted by a separate code, which lets staff add customers to the database and email customer data by churn probability band.
Decisions
Splitting read access from write access is what made it usable. Everyone on a retention team benefits from seeing risk scores. Almost nobody should be able to add records or trigger outbound email. Two tiers let me put it in front of more people without making it dangerous. I also grouped customers into risk bands as well as showing a raw score, because a number like 0.73 does not tell you anything on its own.
What building it taught me
This was my first time working with a database directly, and most of what I learned came from the access side rather than the scoring. Registration requires a code, so people cannot sign themselves up. Sign in validates against the database and locks out after repeated failed attempts, so nobody can sit there guessing. The pages also check who you are before they load, which means typing a URL directly does not get you to the customer data.
Why
After my internship at Monex I kept thinking about what the analysis would look like as something that is used within a company repeatedly. I wanted to find out whether I could take the same kind of customer data and turn it into a working tool, so I built the whole thing myself in PHP and SQL.
How it works
The scoring algorithm calculates a churn probability from three account metrics: initial margin, last equity, and profit and loss. The application segments customers by that probability and generates a tailored suggestion for each one, so whoever reads the score already knows what to do with it instead of having to interpret a number on their own.
Access and views
New users register with a code and returning users are validated against the database, so only verified people can see customer information. Beyond that there are four views: all data, a full table of every customer record; filtered, showing customers segmented by churn probability; search, for looking up an individual customer; and advanced, restricted by a separate code, which lets staff add customers to the database and email customer data by churn probability band.
Decisions
Splitting read access from write access is what made it usable. Everyone on a retention team benefits from seeing risk scores. Almost nobody should be able to add records or trigger outbound email. Two tiers let me put it in front of more people without making it dangerous. I also grouped customers into risk bands as well as showing a raw score, because a number like 0.73 does not tell you anything on its own.
What building it taught me
This was my first time working with a database directly, and most of what I learned came from the access side rather than the scoring. Registration requires a code, so people cannot sign themselves up. Sign in validates against the database and locks out after repeated failed attempts, so nobody can sit there guessing. The pages also check who you are before they load, which means typing a URL directly does not get you to the customer data.