Dos teléfonos, misma config, mismo texto, misma base - resultados distintos. Una cuenta seis meses; la otra muere día tres. Esto rompe a operadores: no hay qué arreglar si todo parecía igual. Aquí por qué pasa y qué hacer.
«Misma config = misma supervivencia» no aplica. El scoring de Meta pesa muchos factores - la mayoría invisibles y no controlables directo.
No es aleatorio - es opaco y multifactor. Entradas iguales no garantizan salidas iguales: «iguales» nunca lo son de verdad.
En WABA oficial, calidad del número = reacciones usuarios 7 días. Señales: reportes, bloqueos, feedback negativo. Eventos recientes pesan más.
Quality Rating: 🟢 High / 🟡 Medium / 🔴 Low. Por número - dos números en un mismo WABA se puntúan aparte.
Meta no publica fórmulas ni umbrales exactos. Operadores: observación, foros, pools.
Factor más pesado y más controlable. Split 50/50 random puede dejar un lado con 5–10% más inactivos, usuarios sin abrir WhatsApp hace tiempo o que reportan mucho.
Calidad del número = reacción audiencia → composición distinta → resultado distinto, mismo texto y volumen.
Menos riesgo: guardar destinatarios en agenda antes de enviar - señal de legitimidad.
Al repartir base entre cuentas, segmentar por sentido, no por fila.
Primeros reportes pegan más fuerte en cuenta nueva. Split random a usuarios que reportan → esa cuenta degrada antes. La otra termina en segmento más leal.
Estadística, no «suerte del algoritmo».
Dos devices en una red: IPs internas/externas distintas. Puertos proxy con historial distinto - alguien spameó antes por ese puerto.
Práctica: máx. tres devices enviando en una conexión; no dos blasts paralelos en un device. Cuenta = entorno aislado. Ver errores de proxy.
Pausa entre envíos: 30 seg – 5 min con random. Delays fijos idénticos = automatización.
Fingerprint único: seriales, MAC, módulos. Teléfono con historial automation o bans previos arranca distinto que uno «limpio».
Operadores: historial device afecta resiliencia. Cuánto guarda Meta - no confirmado oficialmente.
Con decenas/centenas de cuentas: parte de bans es estadísticamente inevitable. Debug de cada ban suelto a menudo no concluye - combo no reproducible.
Enfoque correcto - métricas del pool, no un número. Pool OK y una quemada ≠ esquema roto. Varias seguidas = auditoría sistémica.
Dos Xiaomi, misma estantería, puertos proxy distintos, un spintax, base random. Cuenta #1: 45 días, 4500 msgs. Cuenta #2: día 3, msg 120.
Auditoría: puerto de #2 usado hora antes por tercero spameando Instagram - IP en stop lists. Puerto #1 sin esa historia.
Observación operadores, no experimento verificado. Infra «igual» para ti ≠ igual para el sistema.
Una vive más - aislar variables:
| Factor | Qué revisar |
|---|---|
| Base | ¿Mismo segmento? ¿Misma actividad? |
| Device | Historial, «limpieza» hardware |
| Red | IP compartida, historial puerto proxy |
| Plantilla | ¿Variantes distintas a audiencias distintas? |
| Número | Historial, edad, restricciones previas |
Sin aislar - causa del ban = adivinar.
«Si uno aguantó, el segundo también» - historial y audiencia pueden diferir.
«Siempre hay una causa única» - combo de factores, no reproducible exacto.
«Mismo esquema = límite seguro» - Meta no publica límites garantizados.
¿Una del pool quemó antes? Historial puerto proxy 24 h pre-launch + composición base: % inactivos, último contacto. Dos variables más controlables.
Regla práctica:
El scoring de Meta no es ruleta ni tabla de multiplicar. Entradas iguales no dan la misma respuesta - porque entradas realmente iguales no existen.
