Telecom Data Analytics Software: The Categories, the Vendors, and How to Choose

Telecom data analytics software is the set of tools that take what a network and its business systems produce, call and event detail records, RAN performance counters, packet probe output, IP detail records, mediation and billing feeds, roaming files, care tickets and device telemetry, and turn it into answers about service quality, subscriber behaviour, revenue and fraud. There is no single product that does all of it. The market splits into five buying categories, and most operators run at least three of them at the same time.

The short answer, by category: service assurance and network performance (NetScout nGeniusONE, VIAVI NITRO, Mycom OSI, Infovista, EXFO, Anritsu, RADCOM, Elisa Polystar, plus vendor-native stacks like Ericsson Expert Analytics, Nokia AVA and Huawei SmartCare); revenue assurance and fraud management (Subex, Mobileum, Araxxe); BSS and customer analytics (Amdocs, Netcracker, CSG, SAS); independent network measurement (Ookla Speedtest Intelligence and Cell Analytics, Opensignal, Keysight Nemo, Rohde & Schwarz, umlaut); and the data platform underneath everything (Teradata, Cloudera, Databricks, Snowflake, ClickHouse, Apache Druid, Vertica). If you are shopping without a fixed category in mind, the platform layer is usually the decision that matters most, because the specialist tools are in the end structured views over the same underlying records.

The category map

What makes telecom data different from ordinary analytics data

Three properties break tools that work fine elsewhere.

Volume with high cardinality. A mid-size mobile operator generates hundreds of millions of usage records a day, each carrying a subscriber identifier, a cell identifier, a timestamp and a dozen dimensions. The natural queries are per-subscriber and per-cell time series, which means group-by cardinality in the millions. Row-oriented warehouses and general BI extract layers struggle here, which is why column stores designed for wide scans (ClickHouse, Druid, Vertica, Teradata historically) show up so often in telecom stacks.

Vendor-specific semantics. A "drop call rate" is not one metric. Ericsson, Nokia, Huawei and ZTE expose different PM counters with different names, different aggregation windows and different edge-case handling, even where 3GPP defines the underlying concept. Multi-vendor RAN normalisation is a large, unglamorous part of any assurance deployment, and it is the single most common reason a proof of concept looks great on one region and falls apart nationally.

Retention rules that are legal, not technical. Detail records are personal data. In the EU, the Court of Justice invalidated the Data Retention Directive in 2014 and has since restricted general and indiscriminate retention in further rulings, so retention windows are set by national law and by your DPO, not by storage cost. Design assuming that raw records expire on a schedule and that aggregates outlive them.

Where the simple answer breaks

"One platform for everything" rarely survives contact with the org chart. Assurance data belongs to network operations, billing data to finance, CRM data to commercial. A unified analytics layer is a governance project first and a technology project second. The teams that succeed usually unify the storage and the identifiers, then let each function keep its specialist front end.

Identity resolution is the hidden work. IMSI, MSISDN, IMEI, account number, billing account and household are five different keys with five different lifetimes. A number ports, a SIM is swapped, a business account has 400 lines under one contract. Churn models and customer experience scores are only as good as the join, and a bad join produces confident, wrong answers.

Latency and depth pull in opposite directions. Match the tool to the decision, not to the largest number in the datasheet.

Dashboards are not the deliverable. Assurance suites ship thousands of prebuilt KPIs. The number of dashboards nobody opens in a typical NOC is not a vendor failing, it is a workflow failing. The useful question in an evaluation is: when this tool detects something, what happens next, and who is holding the pager.

Three worked examples

A cell site degrading before anyone complains. PRB utilisation on a sector climbs past 80 percent during evening peak, RRC setup success drops two points and average user throughput halves. Counter-based assurance sees all three, but it cannot tell you whether it matters commercially. Joining the cell to the subscribers homed on it, and those subscribers to their ARPU and contract end dates, turns a network ticket into a prioritised one. That join crosses OSS and BSS, which is exactly the boundary most tools do not span on their own.

Revenue leakage in a new product launch. A converged bundle goes live. Usage flows, mediation rates it, but a rating rule for one roaming zone was never configured, so those records fall into a suspense file. Nobody notices because the suspense file is a technical artefact, not a report. Classic revenue assurance works by reconciliation: count records at the network switch, at mediation, at rating and at invoice, and prove the counts tie. The leak shows up as a gap between stages, and the fix is a configuration change, not a model.

International revenue share fraud. A compromised PBX starts dialling premium-rate destinations at 3am. The signature is not one call, it is a change in the distribution: unusual destinations, unusual hour, unusual call duration clustering, from an account with no prior international traffic. Threshold rules catch the crude version, and behavioural baselining per account catches the rest. This has to run on the streaming path, because the loss accrues every minute the calls stay up, and the settlement is owed to the terminating carrier whether or not you collect from the customer.

Build, buy, or both

The honest split most operators land on: buy the fraud and revenue assurance system, because the rule libraries and carrier settlement knowledge are genuinely hard to reproduce. Buy independent measurement, because you cannot crowdsource competitor data yourself. Buy assurance if you are multi-vendor RAN and your NOC needs it in production next quarter. Build the analytical layer on a general data platform, because that is where the questions change monthly and where a schema you control beats a schema you licence.

A reasonable evaluation checklist: does it read your actual counter set from every RAN vendor you run, not a demo subset; what is the query cost of a per-subscriber year of history; can identifiers be pseudonymised without breaking the joins; is there an API that returns records rather than only rendered dashboards; and what happens to your models when a vendor upgrades software and renames a counter.

The evidence that never reaches the warehouse

One structural limit is worth naming, because it applies to every tool listed above. BI and analytics platforms connect to databases and modelled sources. They are good at that, and modern ones answer questions in plain language perfectly well. What they cannot see is evidence that exists only as a sentence: the field engineer who noted in Slack that the site was on generator power for two days, the vendor email confirming a planned upgrade window, the Zendesk ticket where a customer described the fault more precisely than any counter did. When a KPI dips and the explanation lives in a message thread, the analytics stack shows the dip and stops.

Skopx sits across both. It connects to nearly 1,000 SaaS tools alongside direct database connections including PostgreSQL, ClickHouse and Snowflake, so a question asked in chat can pull the cell-level metric and the ticket that explains it in one answer, with citations back to each source. For teams that want the result as a standing screen rather than a conversation, the same connections back a read-and-act console described on the Internal Apps page.