Multi-SIM User
Detection
The hardest part was not the model — it was building the label. No reliable ground truth existed for Multi-SIM behavior. The project built the target from scratch: behavioral hypotheses → unsupervised discovery → cluster profiling → rule extraction → supervised monthly scoring system.
Architecture
The Problem
Identify subscribers who use multiple SIM cards across different operators — a behavior that is economically significant (lost revenue from shared traffic) but invisible in any single database column. There was no labeled dataset. No flag existed. The project had to construct the target variable before any modeling could begin.
The real challenge: Most ML workflows assume a labeled dataset exists. Here, the label had to be built from behavioral traces — through six stages of applied data science before a single classifier was trained.
Pipeline at a Glance
Behavioral Hypothesis Design
Define what Multi-SIM behavior should look like in telecom traces before any data is pulled. Six behavioral hypotheses: asymmetric in/out call behavior, low TT community share, selective service use, recharge instability, small isolated community, dual-SIM capable handset.
Multi-Source ABT Construction
Fuse four data domains into one Analytical Base Table: usage behavior (MOU by operator, service type, on/offnet), social graph via CLA (community size, operator mix, degree in/out), handset & SIM type (dual-SIM capability score 0–5), and geolocation (cell-tower footprint, urban/rural flag).
Unsupervised Phenotype Isolation
Run iterative K-means segmentation not to partition the full base, but to isolate the one cluster that best matches the hypothesized Multi-SIM behavioral profile. Seven variable-set iterations (A–G), each profiled to check whether the candidate cluster appears cleanly.
Call-Center Validation
Cross-validate the discovered cluster against call-center confirmed lists — agents who directly spoke with subscribers and confirmed Multi-SIM status. This was the closest available ground truth, used for validation rather than training.
Rule Extraction and Supervised Assignment
Assign cluster membership as a supervised label. Augment across multiple months. Train a decision tree, extract splitting rules, round to business-readable thresholds (validated with CVM teams), and deploy for monthly scoring on the full subscriber base.
Key Engineering Decisions
Clustering as a Search Tool, Not a Taxonomy
Standard segmentation asks: "is this a good partition of the whole base?" This project asked: "does this partition reveal the pattern I am looking for?" That reframing changes the evaluation criteria. You do not need all clusters to be optimal — you need one of them to clearly match the target phenotype.
Hypotheses as First-Class Design Inputs
Each of the six behavioral hypotheses directly determined which variables entered the ABT, what a "good" candidate cluster should show when profiled, and which tree splits to prioritize during rule extraction. Hypotheses that could not be translated into measurable features revealed missing data sources — and prompted data joins that would otherwise not have been attempted.
/* Hypothesis: asymmetric in/out call behavior */ Outgoing_Incoming_Duration_TT = Outgoing_MOU / Incoming_MOU Degree_In_Out_Ratio = Incoming_Degree / Outgoing_Degree Active_Day_In_Out_Ratio = Days_Calls_Incoming / Days_with_Calls /* Hypothesis: low TT community engagement */ TT_Community_Share = (TT_Members - 1) / (Community_Size - 1) /* Hypothesis: selective service use */ Voice_Share_Total = Total_Call_Duration / Outgoing_MOU Voice_Share_Ooredoo = Ooredoo_Call_Duration / Outgoing_MOU
Business-Adjusted Rule Thresholds
Raw decision tree splits produce precise but unreadable thresholds (e.g., TT_Community_Share < 0.187). These were rounded to business-meaningful values (0.20) and validated with CVM teams. The goal shifted: from preserving exact cluster membership to producing a stable, interpretable assignment rule that works at monthly scale.
/* Manual rules from cluster profiling */ where Role_Rank <= 2 /* peripheral community role */ and Degree_In_Out_Ratio <= 0.8 /* outgoing dominates incoming */ and Community_Size <= 4 /* small community */ and TT_Community_Share <= 0.2 /* < 20% TT in social group */ and Outgoing_Traffic_Freq >= 5.3 /* high outgoing frequency */ /* Business-adjusted decision tree output: */ if TT_Community_Share < 0.20 and Outgoing_Traffic_Freq > 5.30 → Multi-SIM (rounded from raw splits of 0.187 / 5.28)
Four Data Domains, One Behavioral Question
A subscriber with low outgoing MOU might be inactive, or splitting traffic across a Ooredoo SIM. Usage alone cannot distinguish the two. But if the same subscriber also has a competitor-dominated community, a dual-SIM-capable handset (score 4), and an urban location — the interpretation changes completely. No single domain was sufficient; the signal emerged from their intersection.
Where This Pattern Generalizes
The same pipeline applies anywhere a latent behavior must be discovered before it can be labeled and scored:
- Banking — detecting account-sharing or proxy-use without ground truth
- Insurance — identifying undisclosed household structures from claims behavior
- E-commerce — spotting shared-account usage across multiple real users
- Healthcare — surfacing care-avoidance patterns before labeling dropout
The reusable pattern: when no label exists, build it. Use domain hypotheses to guide discovery. Use discovery to construct a definition. Use the definition to train an assignment system that works at scale.