Las clases de tráfico tienen requisitos incompatibles
Compartir una identidad de remitente y una ruta es simple, pero las clases que la comparten tienen plazos, bases de consentimiento, revisión de contenido y definiciones de éxito distintas. Cuando comparten ruta, el encolado de una campaña afecta a un código de autenticación y una revisión de contenido promocional afecta a la identidad que lleva ese código.
Cinco clases merecen separación explícita: autenticación, servicio, promocional, soporte y avisos operativos urgentes.
Qué debe diferir
- Identidad de remitente y registro. En EE. UU. el registro 10DLC incluye un caso de uso declarado que influye en el tratamiento del tráfico; confírmalo con tu proveedor para cada campaña. Compartir identidad traslada decisiones de contenido de una clase a otra.
- Consentimiento y supresión. Una baja de marketing no es un bloqueo global, y un bloqueo global debe respetarse. La supresión no debe bloquear un código solicitado por el usuario.
- Prioridad de cola y asignación de throughput por clase, o un envío grande consume la capacidad de lo demás.
- Política de ruta. Rutas e idealmente proveedores separados para autenticación y promocional. El tráfico promocional nunca hace failover a una ruta de autenticación.
- Reintentos y plazos. Un plazo útil por clase, con condición de parada en lugar de reintentos indefinidos.
- Gobierno de contenido y plantillas, con identidad, plantilla y estado de aprobación registrados.
- Líneas base de monitorización propias de cada programa y ruta, no umbrales universales.
- Respuesta a incidentes: por clase, quién recibe el aviso, primera acción y criterio de resolución.
Matriz de aislamiento
| Dimensión | Autenticación | Servicio | Promocional | Soporte | Urgente |
|---|---|---|---|---|---|
| Identidad | Dedicada y registrada | Dedicada o compartida con servicio | Dedicada para marketing | Bidireccional | Dedicada o de servicio |
| Ruta | Dedicada, latencia primero | Dedicada o compartida solo con asignación | Ruta y preferiblemente proveedor aparte | Con soporte de entrada | Dedicada con fallback propio |
| Prioridad | Máxima | Alta | Mínima, programada | Interactiva | Preferente |
| Consentimiento | Solicitado por el usuario | Evento de negocio | Consentimiento registrado | Conversación existente | Necesidad operativa |
| Supresión | Solo bloqueos globales | Solo bloqueos globales | Baja de marketing más global | Estado de conversación | Solo bloqueos globales |
| Plazo | El del flujo en vivo | El del evento | Ventana de campaña y horas de silencio | Sesión | Inmediato, con escalado |
| Failover | Otra ruta de autenticación | Ruta de servicio | Nunca a autenticación | Ruta con entrada | Camino independiente |
| Alertas | Distribución de latencia y verificación | Mezcla de estados finales | Throttling, rechazos, bajas | Entrada sin responder | Acuse de recibo |
Checklist de migración
- Clasifica el tráfico existente y etiqueta cada envío antes de cambiar nada.
- Registra las líneas base actuales por programa y ruta.
- Registra las nuevas identidades por mercado y espera confirmación.
- Provisiona rutas y asignaciones de throughput separadas.
- Implementa colas, prioridades, plazos y condiciones de parada por clase.
- Implementa semántica de supresión por clase y verifica que una baja de marketing no bloquea un código solicitado.
- Mueve primero la clase de menor riesgo, normalmente promocional.
- Mueve servicio y por último autenticación, manteniendo la ruta anterior caliente.
- Separa las alertas por clase, con responsable y acción.
- Recalcula líneas base y elimina el camino de fallback mixto.
Flowstates vende y opera rutas de mensajería, admite contratos propios del cliente (BYOV) y modelos híbridos. El aislamiento descrito es el mismo trabajo en cualquiera de esos modelos.