Números semilla en A2P SMS: pruebas controladas para evaluar rutas con prudencia
Cómo diseñar un programa de números semilla para observar aceptación, DLR, latencia y comportamiento de rutas A2P SMS sin confundir una prueba sintética con una garantía de entregabilidad.
Qué es un número semilla y qué representa
Un número semilla es un número de destino controlado o utilizado con autorización demostrable para ejecutar pruebas de mensajería en condiciones definidas. En un programa A2P SMS, se asigna a una combinación concreta de país, red móvil, dispositivo, tipo de remitente y caso de uso legítimo.
Conviene almacenar o normalizar el número en formato E.164 para disponer de una referencia internacional coherente del destino. También debe mantenerse un inventario que identifique la red prevista, el estado operativo del número, la titularidad o autorización, el estado de consentimiento cuando corresponda y el historial de cambios.
Una semilla no equivale a una muestra representativa de usuarios finales. Permite observar una combinación controlada de variables, no demostrar cómo responderán todos los terminales, todos los abonados ni todas las condiciones de red. Su principal valor es la repetibilidad: detectar cambios, incoherencias y degradaciones en las condiciones que el equipo ha definido.
- Úsela como instrumento de observabilidad de una ruta concreta.
- No la presente como una garantía comercial de entrega.
- Conserve por separado el resultado de la API, el DLR y la observación en el dispositivo.
- Documente cualquier cambio de SIM, dispositivo, operador, ubicación operativa o política de prueba.
Preguntas operativas que una prueba controlada sí puede responder
Una prueba bien instrumentada puede comprobar si la plataforma acepta una solicitud de envío, si asigna un identificador trazable, si recibe actualizaciones de estado y si existe consistencia entre los eventos disponibles. También puede medir intervalos observados entre la creación de la prueba, la aceptación del envío, los cambios de estado y la evidencia independiente registrada en el dispositivo.
La terminología de estado debe interpretarse con precisión. Las plataformas de mensajería suelen distinguir fases como encolado, envío, aceptación por un carrier upstream, entrega confirmada y no entrega. La aceptación de una solicitud por una API, o la asignación de un identificador de mensaje, no demuestra por sí misma que el terminal de destino haya recibido el SMS.
Cuando el equipo dispone de acceso al dispositivo semilla, puede registrar una observación independiente de recepción. En determinados casos, una señal posterior verificable y vinculada al mensaje, como el uso de un código OTP en un entorno de prueba controlado, también puede aportar evidencia adicional. Esta evidencia debe etiquetarse como distinta del DLR.
- ¿La solicitud fue aceptada y quedó asociada a un identificador único?
- ¿Se recibieron eventos de estado y son coherentes con el flujo esperado?
- ¿Qué tiempo transcurrió entre los eventos observados?
- ¿El mensaje apareció en el dispositivo controlado?
- ¿El remitente y el contenido se comportaron como se esperaba en esa combinación específica?
- ¿La prueba estuvo disponible en el periodo programado?
Lo que las semillas no pueden demostrar por sí solas
Un resultado positivo en una semilla no prueba la entregabilidad global de una ruta. Las condiciones de entrega pueden variar por filtrado del carrier, disponibilidad del terminal, comportamiento del dispositivo, tipo de remitente, contenido, momento de envío y condiciones de tráfico que no estén presentes en la prueba.
Un DLR de no entrega tampoco debe atribuirse automáticamente a un problema de ruta. Puede responder, entre otros factores, al filtrado de contenido por parte del carrier o a la falta de disponibilidad del terminal de destino. La investigación debe partir de la evidencia disponible y evitar conclusiones causales que la prueba no permite sostener.
La llegada tardía de un DLR requiere un tratamiento especialmente prudente. Como ejemplo de una ventana documentada por un proveedor, AWS advierte que los DLR generados por carriers pueden recibirse hasta 72 horas después. Por ello, el momento de recepción del DLR por la plataforma no debe utilizarse como prueba de que el envío saliente se retrasó durante el mismo intervalo. Si no llega un evento final, el resultado debe permanecer como desconocido o pendiente conforme a la política documentada del programa.
- No infiera recepción en terminal únicamente a partir de la aceptación de API.
- No equipare un DLR con una observación independiente cuando esta no existe.
- No convierta una prueba aislada en una conclusión sobre toda una red o país.
- No interprete el retraso de llegada de un DLR como retraso de entrega sin evidencia adicional.
- No atribuya todos los fallos a la ruta sin revisar contenido, terminal y contexto de prueba.
Diseñe una matriz mínima y explícita de números semilla
La matriz debe construirse a partir de las decisiones que el equipo necesita tomar. En vez de acumular números sin estructura, defina cada celda como una combinación de destino, red móvil esperada, tipo de remitente, perfil de contenido y caso de uso legítimo. Añada un identificador de versión para saber qué configuración estaba vigente en cada prueba.
Empiece con una cobertura que sea operativamente mantenible. Amplíe la matriz cuando exista una hipótesis concreta: una diferencia entre remitentes, una duda sobre un operador, un cambio de comportamiento por codificación o una incidencia que requiera contraste. La expansión debe aumentar la capacidad de discriminación de la prueba, no solo el volumen de mensajes.
La red prevista en el inventario debe tratarse como un atributo verificable y sujeto a revisión, no como una propiedad permanente deducida solo del prefijo.
- País o destino normalizado en formato E.164.
- Red móvil esperada y fecha de última verificación.
- Número semilla y estado operativo.
- Tipo de remitente utilizado en la prueba.
- Perfil de contenido y codificación prevista.
- Caso de uso legítimo: OTP de prueba, aviso transaccional de prueba u otro flujo autorizado.
- Dispositivo y método de observación independiente, si existe.
- Versión de la matriz y responsable de su mantenimiento.
Seleccione y mantenga las semillas con control de autorización
Solo incorpore números bajo titularidad del equipo o con autorización demostrable para participar en el programa. Si los mensajes tienen naturaleza comercial o están sujetos a requisitos locales de consentimiento, identificación y baja, el programa debe conservar la evidencia aplicable. La responsabilidad de demostrar el consentimiento puede recaer en el remitente según la jurisdicción.
El inventario debe registrar, como mínimo, el identificador del número, la base de autorización, la fecha y método de obtención cuando aplique, el estado de consentimiento, la fecha de alta, el responsable interno, el estado del dispositivo y la fecha de la última comprobación. Mantenga además un historial de modificaciones y bajas.
Establezca reglas de sustitución. Un número debe revisarse o reemplazarse si pierde acceso al dispositivo, deja de estar autorizado, cambia de estado operativo, presenta observaciones recurrentes imposibles de interpretar o deja de representar la celda de matriz para la que fue incorporado. La sustitución no debe borrar el historial del número anterior.
- Restrinja el acceso al inventario y a los dispositivos semilla.
- Separe autorización de uso, estado técnico y resultado de pruebas.
- Registre bajas, revocaciones y acciones resultantes.
- Revise periódicamente disponibilidad del dispositivo y vigencia de la autorización.
- Mantenga trazabilidad entre una prueba histórica y la versión del inventario utilizada.
Diseñe mensajes de prueba que permitan interpretar el resultado
El mensaje de prueba debe ser reconocible, legítimo y suficientemente estable para permitir comparación entre ejecuciones. Incluya un identificador de prueba no sensible cuando sea necesario para correlacionar la observación en el dispositivo con el registro de envío. Evite contenido que contenga datos personales innecesarios, credenciales reales o información que no sea imprescindible para el objetivo técnico.
Registre la codificación y la longitud del cuerpo. Son variables relevantes porque el número de segmentos transportados depende de la codificación y de la longitud. Como referencia técnica habitual, los textos GSM-7 superiores a 160 caracteres y los UCS-2 superiores a 70 caracteres se segmentan para intentar su reensamblado. La documentación del proveedor advierte que no todos los carriers y terminales soportan ese reensamblado de forma uniforme.
Pruebe de forma separada los perfiles que necesite comparar. Por ejemplo, un mensaje de un segmento en GSM-7, un caso UCS-2 autorizado y un caso multipartes si es relevante para el tráfico legítimo que opera el equipo. No cambie remitente, contenido, codificación y ruta al mismo tiempo si el objetivo es identificar la causa de una diferencia.
- Identificador interno de prueba sin datos personales.
- Texto estable y fácil de reconocer en el dispositivo.
- Codificación prevista y longitud del mensaje.
- Número de segmentos esperado y observado cuando esté disponible.
- Tipo y valor de remitente autorizado.
- Objetivo técnico de la prueba y variables que se mantienen constantes.
- Prohibición de usar secretos, OTP reales o datos sensibles en el contenido de prueba.
Registre eventos, evidencia y tiempos por mensaje
Cada envío debe poder reconstruirse de principio a fin. Conserve un identificador interno de ejecución y el identificador devuelto por la plataforma o proveedor cuando exista. Registre las marcas de tiempo de creación, envío, actualizaciones de estado, recepción de DLR y observación independiente en el dispositivo.
Diferencie el tiempo medido en cada tramo. El intervalo entre la creación y el evento de aceptación o envío describe una parte de la cadena. El momento recibido en un DLR puede reflejar una fecha incluida por el carrier, mientras que la recepción del DLR por la plataforma refleja otro instante. No fusione estos campos en una única métrica de latencia sin conservar su procedencia.
Guarde los códigos de error, el estado bruto cuando esté disponible, los cambios de estado y la evidencia de observación. Si el dispositivo muestra el mensaje, anote el método de comprobación y el momento de observación. Si se usa una señal posterior verificable, registre qué señal fue, cómo se vinculó al mensaje y qué limitaciones tiene.
- ID interno de prueba y ID externo de mensaje.
- Versión de ruta o configuración, si está disponible internamente.
- Destino semilla, celda de matriz y versión de inventario.
- Contenido o huella de contenido permitida por la política de privacidad.
- Codificación, longitud y segmentos.
- Remitente y caso de uso.
- Estados recibidos, códigos de error y DLR bruto cuando proceda.
- Marcas de tiempo con zona horaria y fuente de cada marca temporal claramente distinguida. La observación en dispositivo puede clasificarse como sí, no, no disponible o no verificable. Registre también el resultado final clasificado y el nivel de evidencia.
Trate DLR tardíos, duplicados y contradicciones sin exagerar la evidencia
Defina una máquina de estados interna antes de ejecutar pruebas a escala. Debe admitir eventos tardíos, eventos repetidos y cambios de estado que lleguen fuera del orden esperado. Conserve el historial completo; no reemplace un evento anterior sin dejar rastro de la secuencia recibida.
Si llega un DLR final después del periodo operativo de observación, regístrelo como evento tardío y actualice la clasificación según la política, pero preserve la primera evaluación y sus marcas de tiempo. Si aparecen DLR duplicados, manténgalos para auditoría y deduplique solo en la capa analítica mediante reglas explícitas.
Cuando un DLR y la observación del dispositivo no coincidan, no fuerce una explicación. Clasifique el caso como inconsistente, revise la correlación de identificadores, el reloj del dispositivo, el contenido y el método de observación. Si no puede establecerse una correspondencia fiable, no afirme recepción independiente ni fallo de ruta.
- Pendiente: no existe aún un evento final conforme a la ventana definida.
- Final informado: existe un DLR o estado final recibido.
- Observado en dispositivo: existe evidencia independiente documentada.
- Inconsistente: las fuentes disponibles no permiten una interpretación única.
- Desconocido: no se dispone de evidencia final suficiente tras la ventana aplicable.
- Tardío: el evento llegó después de la ventana operativa y debe conservarse separado.
Preguntas frecuentes
¿Un DLR delivered demuestra que el SMS fue visto por el usuario?
No necesariamente. Un DLR es una señal de estado recibida a través de la cadena de mensajería. Debe distinguirse de una observación independiente en el dispositivo o de otra señal posterior verificable vinculada al mensaje. La evidencia disponible y su origen deben quedar registrados por separado.
¿Cuántos números semilla necesito por operador?
No existe un número universal verificable. Defina la cantidad según las combinaciones que deba observar: destino, red móvil esperada, remitente, contenido y caso de uso legítimo. Empiece con una matriz mantenible y amplíela cuando una hipótesis operativa requiera mayor discriminación.
¿Puede una prueba semilla medir la latencia de entrega real?
Puede medir intervalos observados entre eventos, pero debe identificar la fuente de cada marca de tiempo. La llegada de un DLR a la plataforma no prueba por sí sola el momento de entrega en el terminal ni un retraso de la entrega saliente.
¿Por qué debo registrar la codificación y los segmentos?
Porque GSM-7 y UCS-2 tienen umbrales de segmentación distintos, y los mensajes largos pueden requerir reensamblado. La documentación del proveedor advierte que este comportamiento no está soportado de forma uniforme por todos los carriers y terminales.
¿Un HLR Lookup confirma que un número puede recibir un SMS?
No. Un HLR Lookup no demuestra consentimiento, identidad, titularidad ni entrega garantizada. Debe tratarse como una fuente de información distinta de la autorización de uso, los eventos de envío y la observación de recepción.
¿Qué debe desencadenar una investigación de ruta?
Una discrepancia repetida frente a una línea base definida, una pérdida de consistencia entre DLR y observación independiente, cambios persistentes por celda de matriz o una degradación que no pueda explicarse por la disponibilidad del dispositivo, el contenido o un cambio documentado de configuración. Antes de atribuir causa a la ruta, repita pruebas controladas y amplíe la muestra de forma dirigida.
Fuentes consultadas
- E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)
- AWS End User Messaging SMS User GuideAmazon Web Services
- Messages resourceTwilio
- Frequently Asked Questions about Canada's Anti-Spam LegislationCanadian Radio-television and Telecommunications Commission (CRTC)
- From Canada’s Anti-Spam Legislation (CASL) Guidance on Implied ConsentCanadian Radio-television and Telecommunications Commission (CRTC)