Tempi degli eventi A2P SMS: come riconciliare i timestamp della piattaforma, del provider e dei DLR
Una guida pratica per registrare, confrontare e verificare i tempi degli eventi SMS senza confondere la ricezione di un DLR con una conferma indipendente della consegna al terminale.
Perché gli orari registrati possono essere diversi
Un invio A2P può generare registrazioni in più sistemi: l'applicazione o la piattaforma di origine, il provider che riceve il messaggio e i sistemi che emettono o consegnano un rapporto sullo stato. Ogni registrazione può corrispondere a un momento diverso e utilizzare una fonte oraria, un fuso orario o una precisione differenti.
Perciò, due timestamp diversi non dimostrano di per sé che ci sia un errore. Per interpretarli, bisogna prima sapere quale evento intende rappresentare ciascun campo e quale sistema lo ha generato. La documentazione disponibile per questo articolo non consente di attribuire definizioni universali di timestamp o DLR a una specifica norma; concorda e documenta queste semantiche con ciascun provider.
- Non confrontare un orario di creazione con un orario di ricezione come se descrivessero lo stesso evento.
- Registra il sistema di origine e il significato dichiarato di ogni timestamp.
- Considera la precisione e la semantica di ciascun campo come proprietà da verificare, non da presumere.
Distingui creazione, invio, accettazione e ricezione del callback
Usa nomi espliciti per gli eventi. Come minimo, distingui quando è stato creato il record o la richiesta, quando la piattaforma ha tentato di inviarla, quando ha ricevuto una risposta di accettazione, quale orario dell'evento dichiara il provider e quando il callback è arrivato al tuo sistema. Non presumere che «accettato» significhi consegnato al terminale.
Mantieni separati l'orario dell'evento comunicato dal provider e quello in cui la piattaforma ha ricevuto tale comunicazione. Il primo è un'indicazione del sistema che ha generato l'evento; il secondo documenta la ricezione locale. Se il provider non specifica cosa rappresenti il suo timestamp, conservalo come dato di origine senza reinterpretarlo.
- Definisci un dizionario degli eventi con nome, sistema che li genera e significato.
- Salva separatamente il timestamp dichiarato dal provider e quello di ricezione locale.
- Non trasformare gli stati di accettazione o di ricezione di un rapporto in un'affermazione di consegna al dispositivo.
Normalizza per confrontare, ma conserva il dato originale
Per facilitare le ricerche e i confronti tra sistemi, adotta una rappresentazione oraria comune, ad esempio UTC, e una convenzione di serializzazione non ambigua. Prima di convertire un valore, identifica il relativo fuso orario o scostamento. Se non è disponibile, registra questa mancanza: non presumere che l'orario corrisponda al fuso del server o dell'operatore.
La normalizzazione non deve sovrascrivere il valore ricevuto. Conserva il testo o il valore originale, il fuso orario dichiarato, la fonte e il valore normalizzato derivato. In questo modo potrai verificare le conversioni, risolvere le discrepanze e ricostruire cosa ha comunicato ciascun sistema.
- Memorizza il valore originale senza modificarlo.
- Registra il fuso orario o lo scostamento; indica esplicitamente quando è sconosciuto.
- Salva il valore normalizzato in un campo distinto e documenta la regola di conversione.
- Non inventare una precisione: conserva quella disponibile e segnala se è sconosciuta.
Scarti, precisione diversa, duplicati ed eventi fuori sequenza
Un timestamp non basta per diagnosticare un orologio non sincronizzato. Confronta i campi solo quando ne conosci il significato e il fuso orario, e registra le differenze osservate come indizi, non come prova automatica della loro causa. Se il sistema fornisce informazioni affidabili sulla sincronizzazione o sulla qualità dell'orologio, salvale separatamente; non dedurle da una sequenza apparentemente insolita.
I callback possono arrivare dopo altri eventi o ripetersi. Progetta l'acquisizione in modo da conservare l'evento ricevuto, riconoscere i possibili duplicati tramite identificativi stabili quando disponibili e mantenere la cronologia delle modifiche. Se non esiste un identificativo adeguato, non dedurre che due rapporti rappresentino lo stesso evento solo perché hanno lo stesso stato e orario.
- Distingui l'orario dichiarato dell'evento dall'orario di ricezione locale.
- Registra la precisione dichiarata o disponibile; non aggiungere frazioni di secondo inesistenti.
- Conserva gli eventi tardivi e fuori sequenza invece di scartarli perché arrivano dopo.
- Usa gli identificativi del messaggio e dell'evento quando disponibili e documentane i limiti.
- Non eliminare i duplicati in modo irreversibile: conserva le evidenze della deduplicazione.
Regole di riconciliazione: priorità senza falsa certezza
Non esiste qui una regola universale documentata per ordinare tutti gli eventi A2P SMS in base alla priorità temporale. Definisci regole interne per tipo di evento e in base al contratto o alla documentazione tecnica del provider. Una risposta di accettazione, un evento di stato comunicato dal provider e la ricezione del callback devono restare fatti distinti.
Quando due fonti non concordano, evita di scegliere un solo orario come «quello vero» senza una motivazione documentata. Puoi stabilire un orario di riferimento operativo per i report, ma conserva tutte le osservazioni ed etichetta il criterio applicato. Se il significato o il fuso orario di un dato non sono chiari, contrassegna il confronto come non conclusivo.
- Definisci le priorità in base alla semantica dell'evento, non al nome generico del campo.
- Registra la regola applicata, la sua versione e le fonti coinvolte.
- Tieni separato lo stato calcolato dalla tua piattaforma dagli stati ricevuti da terzi.
- Segnala le discrepanze irrisolte invece di trasformarle in una conferma di consegna.
Campi minimi per un registro verificabile
Un registro utile deve consentire di ricostruire cosa è stato ricevuto, da chi e come è stato interpretato. Lo schema esatto dipende dall'integrazione, ma è opportuno separare i dati di correlazione, i dati originali, gli orari normalizzati e le decisioni di riconciliazione.
Limita l'accesso ai dati identificativi e applica le politiche di conservazione e sicurezza previste dalla tua organizzazione. La verificabilità non richiede di trattare dati personali oltre quanto necessario per correlare gli eventi e risolvere le anomalie.
- Identificativo interno del messaggio e, se presente, identificativo assegnato dal provider.
- Tipo di evento e stato così come sono stati ricevuti, senza perdere il valore originale.
- Sistema o provider di origine e, quando disponibile, versione o riferimento dell'interfaccia.
- Timestamp originale, fuso orario o scostamento dichiarato e precisione disponibile.
- Timestamp di ricezione locale e timestamp normalizzato, memorizzati separatamente.
- Identificativo dell'evento o del callback, se presente, ed esito del rilevamento dei duplicati.
- Regola di riconciliazione applicata, risultato, motivazione e momento della decisione.
- Indicatore di incertezza quando non è possibile stabilire il significato, il fuso orario o la sequenza.
Esempio: DLR tardivo e stato finale incerto
Supponiamo che una piattaforma registri l'invio e, in seguito, riceva una risposta di accettazione. Successivamente registra un'altra transizione e infine riceve un callback il cui timestamp dichiarato sembra precedente all'orario di ricezione locale. La differenza può dipendere da un ritardo di trasmissione, da criteri diversi per i timestamp, da un fuso orario sconosciuto o da orologi non sincronizzati; senza altri dati non è possibile scegliere una causa.
La prassi prudente consiste nel conservare entrambi gli orari, associare il callback al messaggio solo tramite chiavi di correlazione adeguate e segnalare la sequenza per una verifica se contraddice le regole documentate. Il callback dimostra che la piattaforma ha ricevuto un rapporto con determinati contenuti. In assenza di documentazione che ne stabilisca semantica e ambito, non va presentato come verifica indipendente del fatto che il terminale abbia ricevuto l'SMS.
- Mantieni separati il timestamp dichiarato dal DLR e quello di ricezione.
- Non riordinare né cancellare la cronologia per farla apparire cronologica.
- Registra lo stato comunicato e ogni incertezza sul suo significato.
- Comunica l'esito come stato segnalato dal provider, non come prova indipendente della ricezione sul terminale.
Verifiche periodiche e limiti di un timestamp
Convalida il flusso con test controllati e legittimi nelle tue integrazioni. Verifica che i valori originali siano conservati, che la conversione del fuso orario sia riproducibile, che gli eventi tardivi non vadano persi e che i duplicati siano identificati senza cancellare la cronologia. Ripeti la verifica quando cambiano l'interfaccia, la configurazione o le regole del provider.
Un timestamp, da solo, non dimostra chi abbia ricevuto il messaggio, che l'orologio fosse sincronizzato, che l'evento sia avvenuto esattamente a quell'ora o che il contenuto sia stato visualizzato sul terminale. Le conclusioni dipendono dalla definizione dell'evento, dalla fonte e dalle evidenze tecniche disponibili. Documenta questi limiti nei report operativi e di riconciliazione.
- Prova i timestamp con e senza fuso orario e verifica che gli originali restino intatti.
- Includi casi di callback tardivi, ripetuti e fuori sequenza.
- Confronta l'interpretazione locale con la documentazione aggiornata di ogni integrazione.
- Verifica regolarmente gli scarti orari e gli esiti della riconciliazione, senza trasformarli in garanzie di consegna.
Domande frequenti
Un DLR ricevuto conferma che l'SMS è arrivato al terminale?
La ricezione del callback conferma che il tuo sistema ha ricevuto un rapporto. Il suo significato dipende dalla semantica documentata dalla fonte e, da sola, non equivale a una verifica indipendente della ricezione sul terminale.
Devo salvare tutti i timestamp in UTC?
Puoi mantenere un campo normalizzato in UTC per confrontare i sistemi, ma conserva anche il valore originale e il fuso orario o lo scostamento dichiarato. Se il fuso è sconosciuto, registralo invece di presumerlo.
Quale orario deve prevalere quando piattaforma e provider non concordano?
Non esiste una priorità universale applicabile a tutti i campi. Definisci regole per tipo di evento e in base alla documentazione dell'integrazione, conserva entrambe le osservazioni ed etichetta le discrepanze irrisolte.
Come gestisco un callback fuori sequenza o duplicato?
Conservalo con il relativo orario di ricezione e il timestamp dichiarato. Usa identificativi stabili per rilevare i duplicati quando disponibili, mantieni la cronologia e non scartare gli eventi solo perché arrivano in ritardo.
Che cosa dimostra una differenza tra due timestamp?
Dimostra che le registrazioni riportano valori diversi; da sola non ne identifica la causa. Possono esserci differenze di semantica, fuso orario, precisione o ritardo, oppure orologi disallineati. Per attribuire una causa servono ulteriori dati.
Fonti consultate
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA