Cómo comparar proveedores A2P SMS con un modelo de evidencia

Por qué el precio y un DLR declarado no bastan

Comparar proveedores A2P SMS únicamente por precio, cobertura declarada o un porcentaje agregado de entrega introduce riesgo operativo. Esos indicadores pueden ocultar diferencias entre países, redes móviles, identidades de origen, tipos de tráfico y condiciones de operación.

Una ruta puede aceptar un envío en la API y devolver una respuesta inicial correcta sin que ello describa el resultado final comunicado por la red. Del mismo modo, un estado final de entrega comunicado por un proveedor no debe presentarse como una comprobación independiente de que el destinatario vio el mensaje en su terminal.

La decisión de sourcing debe separar el coste de la evidencia. Una oferta solo es comparable cuando se conoce qué destinos cubre realmente, qué tráfico acepta, qué identidad de origen admite, cómo comunica sus estados y qué restricciones aplica.

• No trate la aceptación inicial de una API como prueba de entrega.
• No consolide resultados de países o redes diferentes en un único porcentaje.
• No asuma que un Sender ID es compatible o visible en todos los destinos.
• No acepte una afirmación de cobertura sin condiciones operativas asociadas.

El modelo de evaluación: declaración, documentación y observación

Un modelo útil distingue tres niveles de información. El primero es la declaración del proveedor: cobertura, tipos de mensaje, capacidad, identidad de origen y estados disponibles. Sirve para la precalificación, pero no es evidencia suficiente para producción.

El segundo nivel es la evidencia documental: condiciones de servicio, restricciones por destino, especificación de API o SMPP, catálogo de estados, política de Sender ID, límites aplicables y mapeo de errores. Esta documentación permite convertir una promesa comercial en requisitos verificables.

El tercer nivel es la observación independiente. Incluye pruebas controladas, registros propios de envío y, cuando sea viable y autorizado, observación de recepción o visualización en terminales de prueba. Esta observación no prueba que un destinatario haya leído el mensaje; solo registra lo observado en el dispositivo de prueba bajo esas condiciones. Debe estar ligada a un destino, una red, un contenido, una identidad de origen y una ventana temporal concretos.

• Declaración: lo que el proveedor afirma poder hacer.
• Documentación: cómo define, limita y comunica ese servicio.
• Observación: qué ocurrió en una prueba identificable y reproducible.
• Decisión: qué uso queda autorizado, con qué límites y hasta qué fecha se mantiene válida la evidencia.

Cuatro dimensiones que deben evaluarse por separado

La comparación resulta más fiable cuando se divide en cuatro dimensiones. Cada una responde a una pregunta distinta y requiere una evidencia distinta.

Primero, legalidad y restricciones: determine qué tráfico legítimo acepta la ruta, qué requisitos existen para remitentes, plantillas, preregistros o registros locales y qué condiciones aplican al país de destino. El soporte de Sender ID y sus requisitos no son universales; algunos mercados requieren preregistro y otros no muestran el Sender ID al destinatario. Los requisitos aplicables también pueden variar según el tipo de remitente, la entidad que envía, el contenido, el registro y la relación contractual. Confirme las condiciones locales con fuentes regulatorias, operadores o asesoría competente.

Segundo, conectividad y operación: valide el método de conexión disponible, los campos obligatorios, la gestión de identificadores, los estados asíncronos, la consulta de mensajes y la documentación de errores. En SMPP, los errores de red o SMSC pueden ser específicos de cada red o implementación, por lo que el proveedor debe explicar su mapeo.

Tercero, capacidad y continuidad: diferencie la aceptación del envío, el tiempo de permanencia en cola y el resultado final. Una plataforma puede registrar estas dimensiones por separado; ninguna de ellas, aislada, demuestra que la capacidad será representativa para todos los destinos o escenarios de producción.

Cuarto, calidad observable: mida resultados segmentados, secuencia de estados, latencia y comportamiento del contenido y del remitente. Como metodología de evaluación, segmente por país, red de destino cuando esté disponible e identidad de origen cuando sea pertinente. La evaluación debe reflejar lo que se ha observado, no extender una muestra limitada a una garantía general.

• Legalidad y restricciones: caso de uso, consentimiento o base autorizante aplicable, origen y requisitos locales.
• Conectividad y operación: HTTP o SMPP, callbacks, consulta de estados, correlación y errores.
• Capacidad y continuidad: aceptación, cola, disponibilidad e incidencias.
• Calidad observable: estados, tiempos, segmentos, comportamiento por red y observación independiente cuando se realice.

Información mínima que solicitar antes de probar una ruta

Antes de iniciar pruebas, solicite una ficha de precalificación por destino. Como práctica de normalización interna, registre el destino en formato E.164 y asócielo, cuando sea posible, al país y a la red móvil informada por la plataforma, la red o la instrumentación de prueba. Ese dato no siempre está disponible y puede no representar el operador efectivo en escenarios de portabilidad. La interfaz o el flujo del proveedor pueden requerir transformaciones o un formato distinto, por lo que debe confirmarse su requisito técnico. Esta normalización evita mezclar resultados que no son comparables.

Pida que el proveedor describa qué tipos de tráfico legítimo admite: por ejemplo, OTP, transaccional o marketing consentido. También debe indicar las identidades de origen permitidas, las restricciones de Sender ID, los requisitos de preregistro, las plantillas aplicables y cualquier condición específica del mercado.

Solicite el catálogo de estados de mensaje, el significado de cada estado, el canal de entrega de eventos asíncronos o mecanismo de consulta, los identificadores disponibles y el mapeo de códigos de error. Si el proveedor informa límites operativos, deben quedar asociados al destino y al tipo de tráfico al que aplican.

• País de destino y números de prueba normalizados internamente en E.164.
• Tipo de tráfico aceptado y casos de uso excluidos.
• Identidad de origen permitida y condiciones de Sender ID.
• Requisitos regulatorios, registros o plantillas aplicables.
• Estados DLR, semántica de cada estado y método de consulta o callback.
• Identificador del proveedor, identificador de correlación y mapeo de errores.
• Condiciones operativas y fecha de vigencia de la información.

Cómo diseñar pruebas controladas sin convertir una muestra en una garantía

Una prueba debe responder a una pregunta acotada. Por ejemplo: si un remitente concreto se admite para tráfico OTP legítimo hacia una red determinada, si se reciben estados finales correlacionables o si un mensaje de varias partes conserva el comportamiento esperado. No intente demostrar la calidad global de una ruta con una única campaña de prueba.

Defina previamente el conjunto de destinos, el periodo de observación, los casos de uso, las identidades de origen, los contenidos autorizados y los terminales de prueba. Mantenga constantes los elementos que no esté evaluando. Si cambia contenido, remitente y destino a la vez, no podrá atribuir el resultado.

Incluya mensajes de una y varias partes y registre la codificación utilizada. En SMPP, data_coding identifica el esquema de codificación. La segmentación y los límites efectivos también dependen de elementos como UDH o SAR, el alfabeto empleado, la interfaz del proveedor, la implementación del SMSC y la red. Por ello, una prueba de contenido corto no valida por sí misma mensajes segmentados o con otra codificación.

Para OTP, establezca una ventana temporal de evaluación explícita y prepare una contingencia operativa. Los recibos de entrega son asíncronos y la entrega puede retrasarse si el terminal no está disponible. Un DLR tardío no debe interpretarse automáticamente como una señal suficiente para un caso de uso sensible al tiempo.

• Formule una hipótesis concreta por prueba.
• Segmente por país, red, caso de uso e identidad de origen.
• Pruebe una y varias partes, con codificación registrada.
• Use contenido legítimo, autorizado y representativo del caso de uso.
• Defina una ventana de observación antes de enviar.
• No extrapole la muestra a destinos, redes o volúmenes no probados.

Qué registrar en cada prueba

La trazabilidad depende de poder reconstruir la historia de cada mensaje. Conserve tanto el identificador asignado por el proveedor como un identificador interno de correlación. En SMPP, puede usarse una referencia asignada por el ESME y el recibo de entrega puede incluir el identificador que el SMSC asignó al mensaje original. El uso y la devolución efectiva de estas referencias o campos dependen de la implementación del SMSC o proveedor.

Registre las marcas temporales de aceptación del envío, cambios de estado, estado final y recepción observada cuando se haya realizado. El formato de recibo de entrega descrito en SMPP incluye submit date y done date, aunque el formato concreto puede variar según el SMSC o proveedor. Done date indica cuándo el mensaje alcanzó un estado final. Estos tiempos permiten separar la aceptación técnica, la evolución del mensaje y la evidencia independiente disponible.

El registro debe preservar el contexto. Sin el destino, la red informada por la plataforma, la red o la instrumentación de prueba cuando esté disponible, el remitente, el contenido o huella de contenido, la codificación, el número de segmentos y el caso de uso, no es posible interpretar correctamente un estado ni comparar pruebas posteriores. La evidencia de consentimiento o de otra base autorizante debe conservarse conforme a la normativa, la finalidad y la jurisdicción aplicables.

• ID interno de correlación.
• ID de mensaje del proveedor o SMSC.
• Número de destino normalizado internamente en E.164.
• País y red de destino informada por la plataforma, la red o la instrumentación de prueba cuando esté disponible.
• Caso de uso y evidencia de consentimiento o base autorizante aplicable, conservada conforme a la normativa, finalidad y jurisdicción aplicables.
• Contenido probado o huella que permita identificarlo sin exponer datos innecesarios.
• Sender ID o identidad de origen.
• Codificación y número de segmentos enviados y observados cuando se exponga ese dato, si corresponde a la prueba realizada; no convierta una prueba de una parte en evidencia de mensajes segmentados o con otra codificación. (La especificación SMPP hace explícita la relación entre data_coding, límites de payload y comportamiento dependiente de red/SMSC.)

Cómo interpretar DLR, latencia y disponibilidad

Los DLR son señales operativas valiosas, pero su significado depende de la interfaz y del proveedor. SMPP define, entre otros, estados finales como DELIVRD, EXPIRED, UNDELIV y REJECTD, y contempla también DELETED y UNKNOWN. El formato concreto del recibo puede ser específico del proveedor de SMSC. La ficha de evaluación debe documentar cómo se traduce cada estado y cada código a una causa operativa.

No confunda estados distintos. Por ejemplo, en una nomenclatura específica de proveedor, un estado de aceptación puede representar la aceptación por un proveedor aguas arriba, mientras que un estado de entrega puede depender de la confirmación disponible desde el carrier y, cuando exista, desde el terminal de destino. Esta no es una definición universal de SMPP ni de todos los DLR: la nomenclatura y su semántica son específicas de cada proveedor y deben verificarse en su documentación. Incluso cuando se documente una confirmación desde el carrier o el terminal, no equivale a una observación independiente del dispositivo realizada por el equipo evaluador ni prueba que el destinatario haya leído el mensaje. Ningún estado debe sustituir la observación independiente cuando esta sea necesaria para validar una hipótesis de prueba.

Mida la latencia por etapas: momento de envío, aceptación, último estado recibido, estado final y recepción observada si aplica. Reportar un único promedio puede ocultar retrasos relevantes para un flujo OTP. Para marketing consentido, los criterios temporales pueden ser diferentes, pero también deben quedar definidos antes de la prueba.

La disponibilidad debe observarse junto con las incidencias y la recuperación. Registre rechazos, fallos de conexión, pérdidas o retrasos de eventos, cambios de semántica y diferencias entre consulta y callback. Una ruta que parece disponible pero no ofrece trazabilidad suficiente puede no ser apta para un caso de uso que requiere auditoría.

• Clasifique cada métrica por etapa del ciclo de mensaje.
• Conserve la secuencia de cambios de estado, no solo el último estado.
• Solicite el mapeo documentado de errores y estados específicos del proveedor.
• Analice los resultados por segmento de destino, no únicamente en agregado.
• Diferencie evidencia de estado comunicado y recepción observada.

Ficha de evaluación de proveedor y criterios de decisión

La ficha de evaluación debe convertir la comparación en una decisión revisable. Para cada pregunta, indique qué evidencia se acepta, quién la valida internamente, cuándo se obtuvo y cuándo caduca. Una afirmación no verificada debe permanecer marcada como declaración, no como capacidad aprobada.

Defina una salida por caso de uso y destino: aprobado, aprobado con restricciones, pendiente de evidencia o rechazado. Evite un “aprobado” genérico para todo el proveedor. Una misma contraparte puede ser apta para un flujo transaccional en un destino y no estar validada para Sender ID, marketing consentido o tráfico OTP en otro.

La evidencia debe revisarse periódicamente. Los parámetros de callback y los conjuntos de propiedades de eventos pueden evolucionar, y las restricciones operativas también pueden cambiar. Diseñe integraciones tolerantes a parámetros adicionales y mantenga una fecha de caducidad para la documentación y las pruebas.

• Pregunta: ¿qué destino, tipo de tráfico e identidad de origen están evaluados?
• Evidencia aceptable: documentación vigente, registros de prueba y estados correlacionados.
• Resultado: aprobado, restringido, pendiente o rechazado.
• Condiciones: límites de uso, requisitos de remitente, contenido o registro.
• Control: fecha de revisión y responsable interno.
• Seguimiento: incidencias abiertas, cambios detectados y pruebas de regresión necesarias.