Tutto ciò che vale la pena sapere, niente di superfluo.
Ciò che ognuno cattura
Un CDR (Call Detail Record) è strutturato secondo uno schema di fatturazione definito dall'operatore: identità dell'abbonato (IMSI/MSISDN), destinatario, durata o numero di messaggi, timestamp di inizio/fine, elemento di rete, classificazione di addebito. I CDR sono la fonte di riferimento per i ricavi. Un EDR (Event Data Record) è definito dall'applicazione: cattura l'intero ciclo di vita di un evento dal punto di vista della piattaforma, ad esempio, per un SMS, elementi come l'ora di invio, la validità, l'ID del mittente, la classificazione del contenuto, l'ID del modello, il tempo di permanenza in coda per ogni hop, l'ora di ricezione DLR (Demand-Received Logistics), il numero di tentativi, lo stato di consegna finale e il codice di errore. Gli EDR sono la fonte di riferimento per le analisi operative e le dashboard rivolte al cliente.
Perché questa distinzione è importante dal punto di vista commerciale
Gli operatori pagano i sistemi di fatturazione per l'elaborazione dei CDR (Call Detail Record); hanno bisogno di piattaforme di analisi per l'elaborazione degli EDR (Electronic Data Record). Confondere i due aspetti porta a decisioni errate: cercare di risolvere i problemi operativi dai CDR di fatturazione è estremamente limitato (il CDR non indica il motivo del fallimento del messaggio, ma solo che è stato recapitato). Cercare di generare entrate dai semplici EDR non consente di effettuare la riconciliazione con la fatturazione, elemento fondamentale per la realizzazione dei CDR. La suite ESME CDR Intelligence di BroadNet (/platforms/esme-cdr) correla i flussi EDR provenienti dalla piattaforma di messaggistica con i flussi CDR provenienti dal sistema di fatturazione dell'operatore per riconciliare i dati fatturati con quelli effettivamente consegnati.
Angolo di latenza, scala e conformità
I CDR vengono in genere raggruppati e consegnati alla fatturazione/mediazione con un ciclo di 5-15 minuti; gli EDR vengono solitamente trasmessi in streaming continuo in un archivio di serie temporali. Scala: un operatore di livello 1 genera miliardi di CDR al mese, spesso decine di volte di più di EDR (perché la piattaforma crea EDR per ogni invio, ogni tentativo di ripetizione, ogni DLR, ogni cambio di stato). Conformità: la conservazione dei CDR è imposta dalle autorità di regolamentazione (5-7 anni per le imposte/vendita all'ingrosso; più a lungo in alcuni mercati); la conservazione degli EDR è scelta operativamente, in genere 12-24 mesi.
Considerazioni in materia di privacy e conformità
Sia i CDR che gli EDR sono dati personali una volta associati a un MSISDN. Le piattaforme più mature conservano i record originali in un archivio crittografato e con accesso controllato, dotato di registrazione degli eventi, e forniscono dashboard aggregate da un archivio pseudonimizzato separato. L'esportazione transfrontaliera di CDR/EDR è soggetta alla legge PDPL dell'Arabia Saudita, alla legge federale sulla protezione dei dati degli Emirati Arabi Uniti e al Regolamento generale sulla protezione dei dati (GDPR) dell'UE (Schrems II); la residenza dei dati viene generalmente imposta a livello di archiviazione.
CDR vs. EDR in sintesi
| CDR (Call Detail Record) | EDR (Event Detail Record) | |
|---|---|---|
| Scopo principale | Fonte di riferimento per fatturazione / ricavi | Fonte di riferimento per l'analisi operativa |
| Schema | Schema di fatturazione dell'operatore | Ciclo di vita degli eventi definito dall'applicazione |
| Generato da | Elemento di rete (MSC / SMSC / OCS) | La piattaforma di messaggistica |
| Dati registrati | I dati dell'evento addebitabile | Ciclo di vita completo + metadati della piattaforma |
| Trasmissione | A lotti (ciclo di 5–15 min) | In streaming continuo |
| Conservazione | Imposta dal regolatore (5–7 anni) | Scelta operativa (12–24 mesi) |