Cómo comparamos proveedores SMS: el método detrás de la matriz
Las matrices de comparación solo sirven si cada celda es rastreable. Esta página explica cómo construimos la matriz de tarifas publicadas: qué significa cada celda, qué fuentes aceptamos, qué nos negamos a inventar y cómo un lector puede reproducir el ejercicio con un pequeño plan de pruebas propio.
Qué significa cada celda de la matriz
Cada celda no vacía de una matriz de tarifas publicadas en este sitio cita una cifra o afirmación que aparece en la página pública del propio proveedor en el momento en que la recuperamos. La celda no es una estimación, una cotización de partner ni un coste interno combinado. Es una cita: el proveedor dijo X, en la página Y, a fecha de recuperación Z.
Cuando un proveedor publica una tarifa mínima, una banda de destino o una tabla de precios unitarios, registramos el valor exactamente como se muestra y adjuntamos la URL de la fuente y la fecha de recuperación. Si la página enumera varios tramos, indicamos a qué tramo se refiere la celda (por ejemplo, tramo de registro frente a tramo de volumen) para que el lector no compare un mínimo público con una tarifa de contrato privada. Si la página es ambigua, la celda permanece en blanco o lleva una nota breve en lugar de un número inventado.
Las reglas de confianza de enlaces son sencillas. Preferimos páginas primarias bajo el dominio del propio proveedor: precios, docs de SMS API, cobertura o registro. No tratamos listados de marketplaces, blogs de afiliados ni capturas sin fecha como fuentes. Si una página exige inicio de sesión para ver cualquier precio, no raspamos más allá de la puerta; la matriz marca la tarifa como restringida a cuenta o deja la celda vacía. Las copias archivadas pueden respaldar una disputa de corrección, pero la página en vivo en el momento de la recuperación es la autoridad de la instantánea publicada.
Las tarifas cambian. Una matriz es una instantánea fechada, no un feed en vivo. Cuando actualizamos una fila, actualizamos la fecha de recuperación junto con la celda. Los lectores que comparen dos proveedores deben comprobar que las fechas son lo bastante cercanas para su decisión; una celda del trimestre pasado y una de esta semana no son el mismo tipo de evidencia.
La matriz de comparación de SMSRoute enlaza cada celda con su fuente y una fecha de recuperación.
Qué comparamos y qué nos negamos a comparar
Comparamos tres clases de material público. Primero, tarifas publicadas: precios por mensaje o por segmento, reglas de destino y cualquier mínimo declarado que el proveedor ponga en una página pública. Segundo, afirmaciones publicadas: soporte de canal declarado (HTTP API, SMPP), funciones documentadas como callbacks de informes de entrega, y restricciones de registro o liquidación que el proveedor describe en lenguaje claro. Tercero, requisitos de registro: si se ofrece registro autoservicio, qué pasos de identidad o facturación muestra el flujo público, y si el proveedor documenta registro solo con email o liquidación en cripto cuando esas opciones aparecen en sus propias páginas.
Rechazamos categorías que exigen mediciones que no hemos realizado o cifras que tendríamos que inventar. No clasificamos la calidad de entrega, la colocación en bandeja de entrada ni el cruce de filtros a partir de textos de marketing. No publicamos cuota de mercado. No rellenamos lagunas con medias del sector, márgenes inferidos ni tasas de fallo «típicas». Si la página de un proveedor omite un destino, esa celda se omite o se marca como no disponible en materiales públicos; no se completa con la tarifa de otro proveedor.
La matemática de segmentos, cuando la mencionamos, sigue las reglas públicas de codificación SMS que los lectores ya usan: cuerpos GSM-7 de hasta 160 caracteres en una sola parte y 153 por parte cuando van concatenados; cuerpos UCS-2 de hasta 70 en una sola parte y 67 por parte cuando van concatenados. Los campos de dirección se tratan en términos E.164, con el máximo habitual de 15 dígitos sin caracteres de presentación. Esas cifras son anclas de especificación, no promesas de rendimiento. Los códigos de respuesta HTTP que referenciamos en la metodología son los ordinarios que los desarrolladores ya gestionan: 200 para rutas de éxito, 429 para respuestas de límite de tasa, 500 para fallos del servidor; y el comportamiento de sesión SMPP se discute solo en términos de la máquina de estados documentada, no como afirmación de que una ruta concreta esté sana.
La posición propia de SMSRoute en las páginas de comparación es acotada e intencionada. Competimos en tarifas mínimas publicadas, registro solo con email y liquidación en cripto. Las páginas dicen solo lo que respaldan las fuentes citadas. No reclaman superioridad en ejes no medidos ni disfrazan una tarifa mínima como un coste total aterrizado para cada ruta.
Por qué las afirmaciones a nivel de ruta necesitan pruebas, no folletos
Una tarifa publicada te dice lo que te facturarán si el mensaje se acepta bajo esa tarifa. No te dice si un informe de entrega es honesto, si el identificador de remitente que enviaste es el que muestra el terminal, o si el mensaje que salió de tu API es el que llegó. Esos son comportamientos a nivel de ruta. Las páginas de marketing los comprimen en adjetivos. El trabajo de ingeniería tiene que descomponerlos en comprobaciones.
La honestidad del informe de entrega es la primera división. Un proveedor puede emitir un acuse de entrega o callback que refleje una aceptación upstream, un evento a nivel de terminal o solo un estado de cola interna. La documentación pública a veces describe el esquema del callback sin vincular cada estado a un hito del mundo real. Hasta que envíes tráfico controlado y concilies los callbacks con una confirmación independiente, estás leyendo un vocabulario, no una medición. Los resúmenes de latencia, cuando los calculas tú mismo, deben expresarse como tu propio p50 y p95 sobre una muestra definida, no como el eslogan de un proveedor reutilizado sin ventana ni población.
La preservación del Sender-ID es la segunda división. La sustitución, las identidades de salida compartidas o las anulaciones específicas por país pueden ser política legítima de red y aun así romper la asunción del producto de que el campo from que enviaste es el from que vio el usuario. El lenguaje de folleto sobre «branding» no sustituye una comparación lado a lado del payload de la solicitud y la pantalla del terminal.
La confirmación en el terminal es la tercera división. La aceptación en una puerta de enlace API (por ejemplo un HTTP 200 al enviar) no es llegada. Tampoco lo es un submit_sm_resp de SMPP que solo demuestra que el SMSC tomó custodia bajo una ruta de estado de mensaje dada. Confirmación significa que un dispositivo o endpoint controlado por el abonado en el que confías registró el cuerpo, el remitente mostrado y la hora. Ese trabajo es lento y específico por destino; también es la única forma de dar sentido a las afirmaciones a nivel de ruta. Esta página de metodología se detiene en las reglas de fuentes para las matrices publicadas. El clúster de pruebas cubre cómo diseñamos esas comprobaciones cuando las ejecutamos, sin tratar una celda no probada como un resultado en verde.
El registro de correcciones de SMSRoute documenta cada error publicado y su corrección: la misma política se aplica a estas páginas de comparación.
Haz tu propia comparación con una pequeña matriz de pruebas
Un lector no necesita un programa grande para someter a presión una lista corta. Construye una hoja con una fila por proveedor en consideración y un conjunto reducido de columnas que puedas rellenar de verdad. Columnas sugeridas: mínimo público o banda para cada destino que te importe; fecha de recuperación y URL de la fuente; ruta de registro según documentación; métodos de liquidación según documentación; superficie de API que usarás (HTTP, SMPP o ambas); si los callbacks de entrega están documentados; y tres columnas de resultado vacías reservadas para tus propias pruebas: aceptación del envío, estado de callback observado, llegada confirmada en terminal.
Mantén el primer pase solo con hechos publicados. Rellena tarifas y afirmaciones desde páginas primarias el mismo día para que las marcas de tiempo coincidan. Donde un precio esté restringido a cuenta, márcalo como restringido en lugar de pegar un número de memoria o de un chat comercial. Donde falte un destino, déjalo en blanco. Resiste la tentación de calcular un ganador con columnas incompletas; el punto de la hoja es mostrar qué decisiones se basan en citas y cuáles en trabajo que aún te debes a ti mismo.
Para las columnas de prueba, elige una forma de tráfico mínima: un puñado de destinos que importen a tu producto, cuerpos GSM-7 y UCS-2 si envías ambos, y cuerpos cerca de los límites de segmento (160/153 y 70/67) si la concatenación importa a la facturación. Registra identificadores de solicitud, marcas de tiempo, estados HTTP o respuestas SMPP, payloads de callback y observaciones del terminal en la misma fila. Si resumes latencia, publica p50 y p95 de tu muestra e indica el tamaño de la muestra en lenguaje claro (número de mensajes), no como una calificación universal de ruta.
Interpreta los huecos como huecos. Un proveedor con un mínimo público claro y poca prueba de ruta es un perfil de riesgo distinto de un proveedor sin mínimo público y adjetivos elogiosos. Tu matriz debe hacer visible esa diferencia sin inventar valores de relleno. Si más adelante firmas una tarifa de contrato, mantén la fila del mínimo público como referencia para ver qué cambió entre la página abierta y el acuerdo.
| Columna | Qué debe contener |
|---|---|
| Tarifa publicada | Mínimo o banda de la página del propio proveedor, copiado literalmente |
| Fuente y fecha | URL primaria más fecha de recuperación de esa celda |
| Registro y liquidación | Solo los pasos y métodos que describe el flujo público o la documentación |
| Tu comprobación de envío | Resultado de aceptación que observaste (por ejemplo HTTP 200 frente a 429/500) |
| Tu comprobación de DLR | Campos de callback o recibo recibidos, mapeados a tus definiciones |
| Confirmación en el terminal | Cuerpo, remitente mostrado y hora que observaste de forma independiente |
Política de correcciones y cómo aparece SMSRoute en la matriz
Proveedores y lectores encontrarán celdas obsoletas, mal acotadas o simplemente erróneas. Envía correcciones a ops@smsroute.cc con el nombre de la matriz, las coordenadas de la celda o la fila del proveedor, la URL que consideres autorizada, el texto o cifra tal como lo leíste y la fecha en que lo obtuviste. Si eres el proveedor, basta un enlace a la página de precios o documentación que sustituya nuestra captura; no hace falta narrativa de marketing.
Revisamos las correcciones con las mismas reglas de fuentes usadas para construir la matriz: las páginas públicas primarias prevalecen sobre comentarios secundarios. Cuando cambiamos una celda, actualizamos la fecha de obtención y registramos la edición en un registro público de correcciones para que los lectores vean qué cambió y por qué. Se rechazarán las disputas que pidan publicar una tarifa contractual no publicada, un SLA privado o una puntuación de calidad de entrega no medida; esas solicitudes piden un artefacto distinto de una matriz de tarifas publicadas.
SMSRoute aparece bajo las mismas restricciones que todos los demás. Nuestras comparativas citan tarifas base publicadas y los hechos públicos en los que elegimos competir (alta solo con email y liquidación en cripto) cuando figuran en nuestros propios materiales. No rellenamos las filas de SMSRoute con afirmaciones de entrega no medidas ni omitimos la tarifa base pública de otro proveedor para agudizar un contraste. Si una celda no se puede documentar, queda vacía. Vacío es más honesto que un número decorativo.
El método detrás de la matriz es deliberadamente aburrido: citar páginas primarias, fechar la cita, separar tarifa de comportamiento de ruta y dejar sin marcar las cualidades no medidas. Lo aburrido hace la cuadrícula usable para desarrolladores que deben defender la elección de un proveedor con enlaces en lugar de adjetivos.
Preguntas frecuentes
- ¿Cómo obtenéis las tarifas de la matriz de comparación de proveedores SMS?
- Cada celda de tarifa cita la página pública del propio proveedor, con la URL de origen y una fecha de obtención. Usamos páginas primarias de precios o documentación, no recopilaciones de afiliados. Si un precio está tras inicio de sesión o ausente, lo marcamos como restringido o dejamos la celda vacía en lugar de inventar una cifra.
- ¿Por qué no clasificáis los proveedores SMS por calidad de entrega?
- La calidad de entrega requiere comprobaciones de envío controladas, conciliación de informes de entrega y confirmación en el terminal. Las páginas de marketing no aportan esa evidencia. La matriz de tarifas publicadas se ciñe a tarifas publicadas, afirmaciones publicadas y requisitos de alta documentados; el comportamiento de ruta corresponde a pruebas aparte, no a una puntuación sin fuente.
- ¿Cómo puedo corregir un error en la matriz de comparación?
- Envía un email a ops@smsroute.cc con la matriz y la celda, la URL autorizada, lo que muestra la página y tu fecha de obtención. Aplicamos las mismas reglas de fuente primaria y, cuando cambiamos una celda, actualizamos la fecha de obtención y anotamos la edición en el registro público de correcciones.