I see, thanks for providing the context.
What I’m trying to achieve is to find out what kind of anomaly might contribute to churn. May be we did something wrong, like having a massive outage of SMS service in some region etc.
It sounds from this like you have some system metrics (outbound minutes, data traffic) but not direct outage metrics (seems unusual for a service provider!). If so, HTM could potentially be used to do feature engineering on your systems metrics, to help build a data set to represent potential outages.
A subscriber who is about to leave doesn’t dissappear all of a sudden, their traffic will have some anomalies (gradual declines).
This sounds like rather than outages, you’re looking at unusual usage patterns. Again, you could use HTM on each individual metric that relates to a customer’s use of your service, and generate an anomaly score to feed into your churn model.
But what really worries me in that approach is that the data we feed to algos is just a snapshot and doesn’t reflect dynamics.
There will naturally be some level of aggregation over a batch window, as a second-by-second or minute-by-minute anomaly activity would be highly unlikely to have meaning in this churn model. But regardless of granularity, each new anomaly score will still incorporate the historical data as the HTM network has been built on it.