Come investigare le discrepanze DLR negli SMS A2P senza confondere la consegna con la ricezione da parte di una persona

La domanda corretta: che cosa dimostra realmente ogni evidenza?

Un'indagine sulle discrepanze DLR negli SMS A2P inizia separando fatti che spesso vengono riuniti in un unico campo di stato. L'accettazione dell'invio, l'avanzamento nella catena, lo stato comunicato da un SMSC e l'osservazione su un terminale non sono equivalenti.

In SMPP, una submit_sm_resp corretta indica che l'operazione di invio è stata elaborata o accettata sull'interfaccia SMPP e che è stato restituito un message_id. In un'API HTTP avviene qualcosa di analogo quando la risorsa viene creata o accettata e viene restituito un identificatore. Ciò attesta l'elaborazione tecnica in quel punto della catena, non la consegna alla destinazione.

Gli stati successivi arrivano in modo asincrono. In SMPP, una ricevuta dell'SMSC può essere ricevuta tramite deliver_sm o data_sm. Questo DLR esprime lo stato mantenuto o comunicato dall'SMSC. Non deve essere attribuito automaticamente al terminale, all'utente o a tutti i segmenti precedenti.

Un'osservazione indipendente — ad esempio, la ricezione registrata da un dispositivo di test controllato — è un'evidenza distinta. Può rafforzare o contraddire il DLR, ma non attesta da sola l'identità della persona che usa il dispositivo né consente di generalizzare il risultato a un'intera rotta.

• Accettazione API o submit_sm_resp: l'operazione è stata elaborata o accettata sull'interfaccia e ha restituito un identificatore.
• Stato temporaneo: indica avanzamento, coda o transito; non chiude necessariamente il ciclo.
• DLR finale: dichiarazione tecnica della catena secondo la semantica documentata per la connessione.
• Osservazione indipendente: segnale separato ottenuto al di fuori del flusso DLR; occorre documentarne metodo e ambito.
• Lettura da parte di una persona: non può essere dedotta universalmente da un DLR SMS.

Perché DELIVRD non prova lettura né identità

SMPP include DELIVERED tra i suoi stati, ma un DLR tradizionale può usare un testo con un formato specifico del provider dell'SMSC. Per questo occorre consultare la specifica applicabile e la documentazione ufficiale di ogni connessione prima di mappare valori come DELIVRD.

Il 3GPP distingue esplicitamente la ricezione da parte della stazione mobile dalla visualizzazione, lettura o comprensione da parte di una persona. Anche quando esiste una conferma della stazione mobile, non viene dimostrato che una persona abbia visto, aperto o compreso il messaggio. Inoltre, gli SMS non forniscono universalmente una ricevuta di lettura.

Lo stato comunicato come delivered può provenire dalla conferma di un operatore upstream e incorporare la conferma del terminale solo quando disponibile. L'origine esatta deve essere conservata in ogni evento, invece di trasformarla in un'affermazione più forte.

Non viene neppure dimostrata l'identità umana del destinatario. Una destinazione tecnica o un dispositivo può ricevere il messaggio senza dimostrare chi controlli il numero, chi abbia il terminale o chi visualizzi il contenuto. Un OTP deve essere trattato secondo l'intero modello di sicurezza del servizio, non come prova di identità basata soltanto sul DLR.

È inoltre opportuno evitare una confusione terminologica: il valore SMPP message_state ACCEPTED non significa lettura ordinaria né accettazione iniziale del trasporto. La specifica lo descrive come lettura manuale per conto dell'abbonato da parte dell'assistenza clienti. L'accettazione iniziale dell'invio viene registrata separatamente.

• Scrivere «DLR comunicato come DELIVRD» invece di «utente raggiunto» quando non esistono evidenze aggiuntive.
• Conservare provider, connessione e versione della mappatura che ha convertito il valore originale in uno stato interno.
• Non presentare DELIVRD come lettura, identità, consenso o garanzia universale di ricezione sul terminale.
• Mantenere separati delivered, osservazione sul dispositivo e read quando un canale supporta eventi di lettura.

Modello minimo di tracciabilità end-to-end

Una correlazione affidabile richiede una registrazione per messaggio logico, per segmento quando è presente concatenazione e per evento ricevuto. Occorre conservare l'identificatore interno insieme al message_id o all'identificatore assegnato da ciascun SMSC, API o partner. Il campo id del DLR SMPP fa riferimento all'identificatore che l'SMSC ha assegnato all'invio originale.

Non è opportuno correlare esclusivamente in base all'indirizzo dell'SMSC. Il 3GPP avverte che architetture di resilienza e bilanciamento del carico possono fare sì che un report provenga da un indirizzo diverso da quello usato per l'invio originale.

Normalizzate i record in uno schema comune, ma conservate l'evento originale e la relativa fonte. La normalizzazione agevola le query; il dato grezzo consente di verificare errori di parsing e modifiche di formato. La destinazione può essere conservata in una rappresentazione normalizzata basata su E.164, quando applicabile, insieme al valore originale ricevuto.

Ogni timestamp deve includere semantica, fonte e una relazione esplicita con UTC tramite Z oppure offset. Non sovrascrivete l'ora dichiarata dal provider con l'ora di arrivo del callback. Conservate inoltre l'osservazione indipendente come terzo istante. Prima di interpretare una sequenza impossibile, escludete orologi non allineati.

• Identificatore interno del messaggio logico e identificatore di ogni segmento.
• Identificatore della richiesta, message_id dell'SMSC o del provider e identificatore dell'evento o callback, se presente.
• Timestamp di invio locale, timestamp dichiarato dalla fonte, ricezione del callback e osservazione indipendente.
• Fuso orario o offset, precisione disponibile, sistema di origine e orologio che ha prodotto ciascun timestamp.
• Provider, connessione, attributo di instradamento disponibile, destinazione originale e normalizzata, operatore osservato o dichiarato e mittente.
• Contenuto normalizzato o impronta controllata, codifica, lunghezza e numero di segmenti, in base alla politica di conservazione applicabile.
• Stato ed errore originali, stato interno normalizzato e versione della mappatura applicata.
• Numero di tentativo, causa del retry, ambiente di test o produzione ed esclusioni analitiche.

Tassonomia riproducibile delle discrepanze

Un'etichetta precisa evita che problemi di osservabilità vengano attribuiti prematuramente alla rotta o al fornitore. Ogni caso deve prevedere una regola verificabile, una finestra temporale documentata e uno stato dell'indagine.

La tassonomia interna deve distinguere stati temporanei, finali e non conclusivi. SMPP definisce, tra gli altri, ENROUTE, DELIVERED, EXPIRED, DELETED, UNDELIVERABLE, ACCEPTED, UNKNOWN e REJECTED, ma la semantica effettiva deve essere verificata nella documentazione della connessione.

• Assenza: non esiste un DLR correlabile entro la finestra osservata. Non equivale automaticamente a un fallimento di consegna.
• Duplicazione: viene ricevuta più di una copia dello stesso evento o stato. Deduplicare per identificatore e finestra temporale prima dell'aggregazione.
• Ritardo: il DLR arriva dopo il tempo previsto per quel segmento operativo, senza modificare per questo il significato dello stato.
• Contraddizione: due fonti o eventi finali attribuiscono risultati incompatibili allo stesso messaggio o segmento.
• Non correlabile: esiste un DLR, ma il suo identificatore non si collega in modo sicuro all'invio originale.
• Sequenza non valida: una transizione viola la macchina a stati documentata oppure gli orari appaiono impossibili.
• Risultato parziale: quando l'implementazione, il provider o la connessione espongono risultati per segmento, un messaggio concatenato può contenere segmenti riusciti e falliti; non deve essere nascosto sotto un unico risultato semplificato.
• Tassonomia sconosciuta: compare uno stato o codice non previsto nella versione attiva della mappatura.

Procedura di indagine passo dopo passo

Per prima cosa delimitate l'incidente senza mescolare popolazioni diverse. Definite inizio e fine, caso d'uso, destinazione, operatore, mittente, provider, connessione, attributo di instradamento disponibile, tipo di traffico, codifica e condizione esatta di inclusione. Registrate anche la dimensione del campione e gli eventuali bias.

Successivamente, convalidate l'osservabilità. Verificate che l'endpoint dei callback fosse raggiungibile, persistesse la richiesta prima di rispondere, accettasse lo schema ricevuto e restituisse una risposta HTTP valida. Un controllo eccessivamente rigido dello schema può impedire l'acquisizione di campi inattesi; verificate questa possibilità nei log prima di attribuire una causa alla rotta. Esaminate code, errori di acquisizione, archiviazione, retry, deduplicazione e sincronizzazione degli orologi.

Ricostruite quindi la cronologia per messaggio e per segmento: richiesta, risposta iniziale, stati temporanei, DLR finale, retry tecnici e osservazione indipendente. Confrontate valori originali e trasformati, senza ordinare ciecamente eventi prodotti da orologi diversi.

Infine, assegnate il dominio più probabile: integrazione interna, osservabilità, mappatura degli stati, connessione del provider, attributo di instradamento disponibile, rete o destinazione. Se le evidenze non consentono di isolarlo, mantenete la classificazione come non determinata anziché forzare una causa.

• 1. Congelare ambito, query ed esclusioni affinché l'analisi sia riproducibile.
• 2. Selezionare esempi rappresentativi e conservarne i record originali.
• 3. Verificare ricezione, risposta e persistenza dei callback.
• 4. Riconciliare i messaggi in sospeso mediante il meccanismo ufficiale di consultazione, se la connessione lo offre.
• 5. Correlare tutti gli identificatori senza dipendere soltanto dalla destinazione o dall'indirizzo dell'SMSC.
• 6. Verificare timestamp, offset, disallineamenti degli orologi e semantica di ogni orario.
• 7. Applicare la versione corretta della mappatura e controllare le transizioni.
• 8. Separare integrazione, attribuzione di instradamento disponibile e destinazione; documentare incertezza ed evidenze mancanti.

Timeout, stati temporanei e chiusura operativa

Un timeout di API, connessione o callback non dimostra che l'SMS non sia stato consegnato. L'operazione potrebbe essere proseguita dopo la perdita della risposta. Cercate la ricevuta successiva e, quando esiste supporto ufficiale, riconciliate tramite una consultazione dello stato.

Gli errori temporanei e gli stati in transito non devono essere convertiti in fallimenti finali finché proseguono i tentativi del centro servizi o resta aperta la validità applicabile. Analogamente, uno stato pending non deve essere trasformato in delivered per completare un report.

Definite una finestra di chiusura legata al caso d'uso e alla validità configurata. Per un OTP, l'utilità può terminare presto, anche se lo stato tecnico arriva successivamente. Una notifica non urgente può ammettere un'altra finestra. Scadenza funzionale, chiusura analitica e stato tecnico sono campi distinti.

Anche il TP-Discharge-Time non deve essere sempre interpretato come orario di consegna riuscita: a seconda dello stato, può rappresentare la consegna, l'ultimo tentativo o la disposizione del messaggio da parte del centro servizi.

• Conservare lo stato tecnico originale dopo la chiusura operativa.
• Etichettare «senza DLR alla chiusura» invece di riclassificare automaticamente come failed.
• Consentire riconciliazioni tardive senza riscrivere silenziosamente report già emessi.
• Versionare la logica di chiusura e spiegarne il rapporto con validità e caso d'uso.

Test sintetici e traffico di produzione

I test sintetici permettono di controllare dispositivo, orario, contenuto, mittente e metodo di osservazione. Sono utili per riprodurre problemi e confrontare il DLR con la ricezione osservata. Tuttavia, un campione controllato non riproduce necessariamente la distribuzione di destinazioni, terminali, disponibilità, filtri e profili del traffico reale.

Il traffico di produzione offre scala e diversità, ma in genere fornisce minore controllo sul terminale e non deve essere usato per dedurre lettura o identità. Inoltre, deve essere trattato nel rispetto delle regole applicabili in materia di consenso, finalità e conservazione dei record.

BulkSMSMarket sta sviluppando una piattaforma interna di test progettata per eseguire controlli giornalieri secondo una metodologia interna su rotte, destinazioni e operatori. Le osservazioni previste includono consegna, coerenza dei DLR, latenza, disponibilità e comportamento di mittente e contenuto. Tali osservazioni sono segnali di qualità soggetti alla metodologia di test; non costituiscono una garanzia universale di ricezione, lettura, copertura o disponibilità.

Non mescolate test e produzione in un unico tasso. Contrassegnate separatamente il traffico sintetico, i retry tecnici e i messaggi concatenati. Se vengono confrontate fonti, documentatene le differenze di selezione, volume e metodo.

• Sintetico: maggiore controllo e migliore riproducibilità; minore rappresentatività universale.
• Produzione: maggiore diversità; minore certezza su quanto accaduto sul terminale.
• Utilizzare messaggi legittimi, basati sul consenso e conformi alla normativa applicabile.
• Non estrapolare un singolo dispositivo di test a un'intera rotta senza evidenze sufficienti.

Metriche utili senza creare una falsa certezza

Non riducete accettazione, copertura DLR, latenza e risultato a un unico punteggio. Sono dimensioni distinte. La copertura DLR può essere definita come la proporzione di messaggi idonei con almeno un evento correlabile; deve restare separata dalla proporzione comunicata come delivered.

Definite operativamente i messaggi idonei, la finestra di osservazione e il trattamento di DLR tardivi, duplicati e messaggi concatenati prima di applicare la formula. Senza tali definizioni, confronti tra periodi, provider o segmenti possono risultare fuorvianti.

Calcolate la latenza per percentili e per traguardi chiaramente definiti. Ad esempio, accettazione-ricezione del callback non è la stessa cosa di submit date-done date. Indicate la fonte di entrambi gli estremi, l'offset e il trattamento dei valori mancanti.

Prima di aggregare, deduplicate per identificatore del messaggio o dell'evento e finestra temporale. Escludete o contrassegnate separatamente test, retry e messaggi concatenati per evitare doppi conteggi. Per i concatenati, quando i dati disponibili espongono esiti per segmento, misurate anche segmenti riusciti e falliti.

Costruite baseline segmentate per destinazione, operatore, mittente, tipo di traffico, attributo di instradamento disponibile, fascia temporale comparabile e versione dell'integrazione. Analizzate cambiamenti sostenuti rispetto a variazioni isolate. Con volumi ridotti, mostrate dimensione del campione e incertezza anziché classifiche apparentemente precise. Riesaminate periodicamente la qualità dei dati stessi: callback persi, orologi disallineati, campi incompleti, identificatori riutilizzati, timestamp futuri, errori di acquisizione, salti impossibili e cambiamenti bruschi della tassonomia.

• Copertura DLR: messaggi idonei con almeno un DLR correlabile divisi per messaggi idonei, con finestra ed esclusioni documentate.
• Coerenza: proporzione di eventi che rispettano correlazione, tassonomia e sequenza definite.
• Latenza: percentili per coppia di traguardi e segmento comparabile, non soltanto una media.
• Anzianità dei messaggi in sospeso: distribuzione per intervalli dal traguardo scelto.
• Non correlati: proporzione e volume dei DLR senza collegamento sicuro all'invio.
• Contraddizioni e duplicati: volume prima e dopo la deduplicazione.
• Dashboard consigliata: distribuzione degli stati, andamento dei percentili, backlog per anzianità, copertura e qualità dei dati.
• Nota metodologica visibile: fonte, ambito, esclusioni, finestra, campione, versione della mappatura e limitazioni.