Tudo o que vale a pena saber, nada do que não vale.
O que cada um captura
Um CDR (Registo de Dados de Chamada) é estruturado de acordo com o esquema de faturação definido pela operadora: identidade do assinante (IMSI/MSISDN), destinatário da chamada, duração ou contagem de mensagens, carimbos de data/hora de início e fim, elemento de rede e classificação de tarifação. Os CDRs são a fonte de verdade para fins de receita. Um EDR (Registo de Dados de Eventos) é definido pela aplicação: ele captura todo o ciclo de vida de um evento da perspetiva da plataforma — para um SMS, informações como horário de envio, validade, ID do remetente, classificação de conteúdo, ID do modelo, tempo de permanência na fila por salto, horário de receção do DLR (Registo de Entrega de Dados), número de tentativas, status final de entrega e código de erro. Os EDRs são a fonte de verdade para análises operacionais e painéis de controlo voltados para o cliente.
Porque essa distinção é importante comercialmente
As operadoras pagam aos sistemas de faturação pelo processamento de CDRs; elas precisam de plataformas de análise para o processamento de EDRs. Confundir os dois leva a decisões ruins: tentar solucionar problemas operacionais a partir de CDRs de faturação é extremamente limitado (o CDR não sabe porque a mensagem falhou, apenas que falhou). Tentar gerar receita a partir de EDRs brutos ignora a conciliação de faturação que os CDRs fornecem. O ESME CDR Intelligence Suite da BroadNet (/platforms/esme-cdr) correlaciona os feeds de EDR da plataforma de mensagens com os feeds de CDR do sistema de faturação da operadora para conciliar as contagens faturadas e entregues.
Latência, escala e ângulo de conformidade
Os CDRs são normalmente agrupados e entregues para faturação/mediação num ciclo de 5 a 15 minutos; os EDRs geralmente são transmitidos continuamente para um armazenamento de séries temporais. Escala: uma operadora de nível 1 gera milhares de milhões de CDRs por mês, frequentemente dezenas de vezes mais EDRs (porque a plataforma cria EDRs para cada envio, cada nova tentativa, cada DLR e cada mudança de estado). Conformidade: a retenção de CDRs é obrigatória por lei (5 a 7 anos para fins fiscais/Grossista; períodos mais longos em alguns mercados); a retenção de EDRs é definida operacionalmente, normalmente de 12 a 24 meses.
Considerações sobre privacidade e conformidade
Tanto os CDRs quanto os EDRs são dados pessoais quando vinculados a um MSISDN. Plataformas consolidadas armazenam os registos brutos num sistema encriptado com controlo de acesso e registo de auditoria, e disponibilizam painéis agregados a partir de um repositório pseudonimizado separado. A exportação internacional de CDRs/EDRs está sujeita à Lei de Proteção de Dados Pessoais da Arábia Saudita (KSA PDPL), à Lei Federal de Proteção de Dados dos Emirados Árabes Unidos e ao Regulamento Geral de Proteção de Dados da UE (RGPD) Schrems II; a residência dos dados é geralmente aplicada na camada de armazenamento.
CDR vs EDR em resumo
| CDR (Call Detail Record) | EDR (Event Detail Record) | |
|---|---|---|
| Objetivo principal | Fonte de verdade de faturação / receita | Fonte de verdade da análise operacional |
| Esquema | Esquema de faturação da operadora | Ciclo de vida de eventos definido pela aplicação |
| Gerado por | Elemento de rede (MSC / SMSC / OCS) | A plataforma de mensagens |
| Dados registados | Os dados do evento tarifável | Ciclo de vida completo + metadados da plataforma |
| Transmissão | Em lotes (ciclo de 5–15 min) | Em streaming contínuo |
| Retenção | Exigida pelo regulador (5–7 anos) | Definida operacionalmente (12–24 meses) |