Come confrontare i fornitori di SMS A2P con un modello basato sulle evidenze

Perché il prezzo e un DLR dichiarato non sono sufficienti

Confrontare i fornitori di SMS A2P soltanto in base al prezzo, alla copertura dichiarata o a una percentuale di consegna aggregata introduce rischi operativi. Questi indicatori possono nascondere differenze tra Paesi, reti mobili, identità del mittente, tipi di traffico e condizioni operative.

Una rotta può accettare un invio tramite API e restituire una risposta iniziale corretta senza che ciò descriva il risultato finale comunicato dalla rete. Allo stesso modo, uno stato finale di consegna comunicato da un fornitore non deve essere presentato come una verifica indipendente del fatto che il destinatario abbia visualizzato il messaggio sul proprio terminale.

La decisione di approvvigionamento deve separare il costo dall'evidenza. Un'offerta è confrontabile solo quando si conoscono le destinazioni effettivamente coperte, il traffico accettato, l'identità del mittente ammessa, le modalità di comunicazione degli stati e le restrizioni applicate.

• Non considerare l'accettazione iniziale di un'API come prova di consegna.
• Non aggregare i risultati di Paesi o reti differenti in un'unica percentuale.
• Non presumere che un Sender ID sia supportato o visibile in tutte le destinazioni.
• Non accettare un'affermazione di copertura priva delle relative condizioni operative.

Il modello di valutazione: dichiarazione, documentazione e osservazione

Un modello utile distingue tre livelli di informazione. Il primo è la dichiarazione del fornitore: copertura, tipi di messaggio, capacità, identità del mittente e stati disponibili. Serve per la prequalifica, ma non costituisce un'evidenza sufficiente per la produzione.

Il secondo livello è l'evidenza documentale: condizioni di servizio, restrizioni per destinazione, specifiche API o SMPP, catalogo degli stati, politica Sender ID, limiti applicabili e mappatura degli errori. Questa documentazione consente di trasformare una promessa commerciale in requisiti verificabili.

Il terzo livello è l'osservazione indipendente. Include test controllati, registri propri di invio e, quando fattibile e autorizzato, osservazione della ricezione o visualizzazione su terminali di test. Questa osservazione non dimostra che un destinatario abbia letto il messaggio; registra solo quanto osservato sul dispositivo di test in tali condizioni. Deve essere collegata a una destinazione, una rete, un contenuto, un'identità del mittente e una finestra temporale specifici.

• Dichiarazione: ciò che il fornitore afferma di poter fare.
• Documentazione: come definisce, limita e comunica il servizio.
• Osservazione: ciò che è accaduto in un test identificabile e riproducibile.
• Decisione: quale utilizzo è autorizzato, con quali limiti e fino a quale data l'evidenza rimane valida.

Quattro dimensioni da valutare separatamente

Il confronto diventa più affidabile quando viene suddiviso in quattro dimensioni. Ciascuna risponde a una domanda distinta e richiede un'evidenza diversa.

Primo, legalità e restrizioni: determinare quale traffico legittimo la rotta accetta, quali requisiti esistono per mittenti, template, preregistrazioni o registrazioni locali e quali condizioni si applicano al Paese di destinazione. Il supporto del Sender ID e i relativi requisiti non sono universali; alcuni mercati richiedono una preregistrazione e altri non mostrano il Sender ID al destinatario. I requisiti applicabili possono inoltre variare in base al tipo di mittente, all'entità che invia, al contenuto, alla registrazione e al rapporto contrattuale. Confermare le condizioni locali con fonti regolatorie, operatori o consulenza competente.

Secondo, connettività e operatività: convalidare il metodo di connessione disponibile, i campi obbligatori, la gestione degli identificatori, gli stati asincroni, la consultazione dei messaggi e la documentazione degli errori. In SMPP, gli errori di rete o dell'SMSC possono essere specifici di ciascuna rete o implementazione, pertanto il fornitore deve spiegarne la mappatura.

Terzo, capacità e continuità: distinguere tra accettazione dell'invio, tempo di permanenza in coda e risultato finale. Una piattaforma può registrare queste dimensioni separatamente; nessuna di esse, isolatamente, dimostra che la capacità sarà rappresentativa per tutte le destinazioni o gli scenari di produzione.

Quarto, qualità osservabile: misurare risultati segmentati, sequenza degli stati, latenza e comportamento del contenuto e del mittente. Come metodologia di valutazione, segmentare per Paese, rete di destinazione quando disponibile e identità del mittente quando pertinente. La valutazione deve riflettere quanto osservato, senza estendere un campione limitato a una garanzia generale.

• Legalità e restrizioni: caso d'uso, consenso o altra base autorizzativa applicabile, origine e requisiti locali.
• Connettività e operatività: HTTP o SMPP, callback, consultazione degli stati, correlazione ed errori.
• Capacità e continuità: accettazione, coda, disponibilità e incidenti.
• Qualità osservabile: stati, tempi, segmenti, comportamento per rete e osservazione indipendente quando effettuata.

Informazioni minime da richiedere prima di testare una rotta

Prima di avviare i test, richiedere una scheda di prequalifica per destinazione. Come pratica di standardizzazione interna, registrare la destinazione nel formato E.164 e associarla, quando possibile, al Paese e alla rete mobile comunicati dalla piattaforma, dalla rete o dalla strumentazione di test. Questo dato non è sempre disponibile e potrebbe non rappresentare l'operatore effettivo in scenari di portabilità. L'interfaccia o il flusso del fornitore possono richiedere trasformazioni o un formato diverso, pertanto occorre confermarne il requisito tecnico. Questa standardizzazione evita di mescolare risultati non confrontabili.

Chiedere al fornitore di descrivere quali tipi di traffico legittimo ammette: ad esempio OTP, transazionale o marketing basato sul consenso. Deve inoltre indicare le identità del mittente consentite, le restrizioni del Sender ID, i requisiti di preregistrazione, i template applicabili e qualsiasi condizione specifica del mercato.

Richiedere il catalogo degli stati del messaggio, il significato di ciascuno stato, il canale di consegna degli eventi asincroni o il meccanismo di consultazione, gli identificatori disponibili e la mappatura dei codici di errore. Se il fornitore comunica limiti operativi, questi devono essere associati alla destinazione e al tipo di traffico cui si applicano.

• Paese di destinazione e numeri di test normalizzati internamente in E.164.
• Tipo di traffico accettato e casi d'uso esclusi.
• Identità del mittente consentita e condizioni del Sender ID.
• Requisiti normativi, registrazioni o template applicabili.
• Stati DLR, semantica di ciascuno stato e metodo di consultazione o callback.
• Identificatore del fornitore, identificatore di correlazione e mappatura degli errori.
• Condizioni operative e data di validità delle informazioni.

Come progettare test controllati senza trasformare un campione in una garanzia

Un test deve rispondere a una domanda circoscritta. Ad esempio: se un mittente specifico è ammesso per traffico OTP legittimo verso una determinata rete, se vengono ricevuti stati finali correlabili o se un messaggio multipart conserva il comportamento atteso. Non cercare di dimostrare la qualità complessiva di una rotta con una sola campagna di test.

Definire in anticipo l'insieme delle destinazioni, il periodo di osservazione, i casi d'uso, le identità del mittente, i contenuti autorizzati e i terminali di test. Mantenere costanti gli elementi che non si stanno valutando. Se si modificano contemporaneamente contenuto, mittente e destinazione, non sarà possibile attribuire il risultato.

Includere messaggi a una parte e multipart e registrare la codifica utilizzata. In SMPP, data_coding identifica lo schema di codifica. La segmentazione e i limiti effettivi dipendono anche da elementi quali UDH o SAR, l'alfabeto utilizzato, l'interfaccia del fornitore, l'implementazione dell'SMSC e la rete. Per questo, un test con contenuto breve non convalida di per sé messaggi segmentati o con una codifica differente.

Per gli OTP, stabilire una finestra temporale di valutazione esplicita e predisporre una contingenza operativa. Le ricevute di consegna sono asincrone e la consegna può essere ritardata se il terminale non è disponibile. Un DLR tardivo non deve essere interpretato automaticamente come un segnale sufficiente per un caso d'uso sensibile al fattore tempo.

• Formulare un'ipotesi specifica per ciascun test.
• Segmentare per Paese, rete, caso d'uso e identità del mittente.
• Testare messaggi a una parte e multipart, con codifica registrata.
• Usare contenuti legittimi, autorizzati e rappresentativi del caso d'uso.
• Definire una finestra di osservazione prima dell'invio.
• Non estrapolare il campione a destinazioni, reti o volumi non testati.

Cosa registrare in ogni test

La tracciabilità dipende dalla possibilità di ricostruire la storia di ciascun messaggio. Conservare sia l'identificatore assegnato dal fornitore sia un identificatore interno di correlazione. In SMPP, può essere utilizzato un riferimento assegnato dall'ESME e la ricevuta di consegna può includere l'identificatore che l'SMSC ha assegnato al messaggio originale. L'uso e l'effettiva restituzione di questi riferimenti o campi dipendono dall'implementazione dell'SMSC o del fornitore.

Registrare i timestamp dell'accettazione dell'invio, dei cambiamenti di stato, dello stato finale e della ricezione osservata, quando effettuata. Il formato della ricevuta di consegna descritto in SMPP include submit date e done date, anche se il formato specifico può variare in base all'SMSC o al fornitore. Done date indica quando il messaggio ha raggiunto uno stato finale. Questi tempi consentono di distinguere tra accettazione tecnica, evoluzione del messaggio ed evidenza indipendente disponibile.

Il registro deve preservare il contesto. Senza la destinazione, la rete comunicata dalla piattaforma, dalla rete o dalla strumentazione di test quando disponibile, il mittente, il contenuto o l'impronta del contenuto, la codifica, il numero di segmenti e il caso d'uso, non è possibile interpretare correttamente uno stato né confrontare test successivi. L'evidenza del consenso o di un'altra base autorizzativa deve essere conservata in conformità alla normativa, alla finalità e alla giurisdizione applicabili.

• ID interno di correlazione.
• ID del messaggio del fornitore o dell'SMSC.
• Numero di destinazione normalizzato internamente in E.164.
• Paese e rete di destinazione comunicati dalla piattaforma, dalla rete o dalla strumentazione di test, quando disponibili.
• Caso d'uso ed evidenza del consenso o della base autorizzativa applicabile, conservata in conformità alla normativa, alla finalità e alla giurisdizione applicabili.
• Contenuto testato o impronta che consenta di identificarlo senza esporre dati non necessari.
• Sender ID o identità del mittente.
• Codifica e numero di segmenti inviati e osservati quando tale dato viene esposto, se pertinente al test effettuato; non trasformare un test a una parte in evidenza di messaggi segmentati o con altra codifica. La specifica SMPP esplicita la relazione tra data_coding, limiti di payload e comportamento dipendente dalla rete/SMSC.

Come interpretare DLR, latenza e disponibilità

I DLR sono segnali operativi di valore, ma il loro significato dipende dall'interfaccia e dal fornitore. SMPP definisce, tra gli altri, stati finali quali DELIVRD, EXPIRED, UNDELIV e REJECTD e contempla anche DELETED e UNKNOWN. Il formato specifico della ricevuta può dipendere dal fornitore dell'SMSC. La scheda di valutazione deve documentare come ciascuno stato e ciascun codice vengano tradotti in una causa operativa.

Non confondere stati diversi. Ad esempio, in una nomenclatura specifica del fornitore, uno stato di accettazione può rappresentare l'accettazione da parte di un fornitore a monte, mentre uno stato di consegna può dipendere dalla conferma disponibile dal carrier e, quando presente, dal terminale di destinazione. Questa non è una definizione universale di SMPP né di tutti i DLR: la nomenclatura e la semantica sono specifiche di ogni fornitore e devono essere verificate nella relativa documentazione. Anche quando viene documentata una conferma dal carrier o dal terminale, essa non equivale a un'osservazione indipendente del dispositivo effettuata dal team di valutazione né dimostra che il destinatario abbia letto il messaggio. Nessuno stato deve sostituire l'osservazione indipendente quando questa è necessaria per convalidare un'ipotesi di test.

Misurare la latenza per fasi: momento dell'invio, accettazione, ultimo stato ricevuto, stato finale e ricezione osservata, se applicabile. Riportare una sola media può nascondere ritardi rilevanti per un flusso OTP. Per il marketing basato sul consenso, i criteri temporali possono essere differenti, ma devono comunque essere definiti prima del test.

La disponibilità deve essere osservata insieme agli incidenti e al ripristino. Registrare rifiuti, errori di connessione, perdite o ritardi degli eventi, cambiamenti di semantica e differenze tra consultazione e callback. Una rotta che sembra disponibile ma non offre una tracciabilità sufficiente potrebbe non essere idonea per un caso d'uso che richiede audit.

• Classificare ciascuna metrica in base alla fase del ciclo di vita del messaggio.
• Conservare la sequenza dei cambiamenti di stato, non solo l'ultimo stato.
• Richiedere la mappatura documentata di errori e stati specifici del fornitore.
• Analizzare i risultati per segmento di destinazione, non soltanto in forma aggregata.
• Distinguere tra evidenza dello stato comunicato e ricezione osservata.

Scheda di valutazione del fornitore e criteri decisionali

La scheda di valutazione deve trasformare il confronto in una decisione riesaminabile. Per ogni domanda, indicare quale evidenza è accettata, chi la convalida internamente, quando è stata ottenuta e quando scade. Un'affermazione non verificata deve rimanere contrassegnata come dichiarazione, non come capacità approvata.

Definire un esito per caso d'uso e destinazione: approvato, approvato con restrizioni, in attesa di evidenza o respinto. Evitare un'approvazione generica per l'intero fornitore. Una stessa controparte può essere idonea per un flusso transazionale in una destinazione e non essere convalidata per Sender ID, marketing basato sul consenso o traffico OTP in un'altra.

L'evidenza deve essere riesaminata periodicamente. I parametri di callback e gli insiemi di proprietà degli eventi possono evolvere, e anche le restrizioni operative possono cambiare. Progettare integrazioni tolleranti a parametri aggiuntivi e mantenere una data di scadenza per la documentazione e i test.

• Domanda: quali destinazione, tipo di traffico e identità del mittente sono valutati?
• Evidenza accettabile: documentazione vigente, registri di test e stati correlati.
• Esito: approvato, limitato, in attesa o respinto.
• Condizioni: limiti d'uso, requisiti relativi a mittente, contenuto o registrazione.
• Controllo: data di revisione e responsabile interno.
• Monitoraggio: incidenti aperti, modifiche rilevate e test di regressione necessari.