Maite se registró ayer en su nuevo gym. Bajó la app, completó sus datos, le asignaron el plan. Hoy a la tarde recibe dos notificaciones consecutivas, separadas por menos de un minuto: una le da la bienvenida, la otra le dice "¡Te extrañamos! Hace más de 2 semanas que no venís". Maite mira el celular, frunce el ceño, y empieza a desconfiar del sistema. "¿Cómo me van a extrañar si recién me registré?"

Este es un caso real de un cliente nuestro la semana pasada — y es exactamente la clase de bug silencioso que erosiona la confianza del socio sin que el dueño del gym se entere hasta meses después, cuando la app empieza a tener críticas en el Play Store. Lo arreglamos esta semana, y la solución es interesante porque demuestra una idea más profunda: los pushes automáticos no son inocuos — un push mal disparado vale menos que cero, vale -1.

Por qué un push erróneo cuesta más de lo que parece

El push de re-engagement está diseñado para retener: detectar al socio que dejó de venir y darle un empujoncito antes de que se borre. Bien usado, recupera entre el 5% y el 15% de los inactivos según la categoría del gym. Mal usado, hace exactamente lo contrario:

Cada uno de estos casos no genera un disgusto enorme — genera una pequeña fricción. Pero la fricción se acumula. Y a diferencia de un cobro mal hecho, que el operador puede reembolsar, un push automático mal disparado no se puede deshacer: ya lo viste, ya pensaste mal del sistema, ya bajaste un escalón en tu confianza.

Lo que estaba mal en nuestra query

El bug que motivó este post era simple en la superficie y profundo en sus implicancias. La consulta de re-engagement seleccionaba todos los socios cuya última asistencia (last_visit) fuera NULL o anterior a 14 días. La intención era clara: "socios que llevan dos semanas sin venir". El problema: last_visit IS NULL también incluye a quien nunca asistió porque recién se registró.

La condición técnica era correcta, pero la regla de negocio estaba incompleta. Faltaba el contexto humano: "alguien que nunca vino" puede ser un socio antiguo que dejó de venir o un socio nuevo que todavía no fue por primera vez. Tratarlos igual te dispara el push contra ambos.

Cuatro filtros que cambian todo

La solución que aplicamos no es más código — es más reglas alineadas con el sentido común. Cuatro filtros que la query ahora respeta antes de mandar el push:

1. Antigüedad del socio

El socio tiene que tener al menos 14 días de antigüedad. m.created_at <= NOW() - 14 days. Si se registró hace menos, simplemente no califica para re-engagement — no importa que last_visit sea NULL. Un socio nuevo que aún no asistió está en su período natural de onboarding, no en período de abandono.

2. Antigüedad de la membresía

La membresía activa también tiene que tener al menos 14 días. mm.start_date <= NOW() - 14 days. Si el socio renovó la semana pasada o cambió de plan ayer, dejarlo respirar. Renovar es la forma más fuerte de "compromiso" — recibir "te extrañamos" justo después es contradictorio.

3. Sin bienvenida reciente

Si el socio recibió el push de bienvenida en los últimos 14 días, no le mandes re-engagement. Es la regla que evita el caso de Maite — la combo absurda "Bienvenido" + "Te extrañamos" en el mismo día. Suena obvio cuando lo decís, pero es exactamente el tipo de borde que las queries genéricas no contemplan.

4. Cooldown semanal, no diario

Si el socio ya recibió re-engagement en los últimos 7 días, no le mandes otro. La versión vieja chequeaba DATE(pl.created_at) = CURDATE() — solo evitaba el duplicado en el mismo día. Resultado: un socio inactivo durante un mes recibía 30 pushes idénticos. Eso no es retención, es spam, y termina con el socio silenciando la app.

Una vez por semana es suficiente para mantener el recordatorio sin agotar al socio. Si el push tipo "te extrañamos" no funciona en la primera semana, mandar otros seis idénticos no va a funcionar tampoco.

El toggle global por gym sigue ahí

Estos cuatro filtros aplican cuando el toggle "Push de re-engagement" del Configurador está prendido (default: ON). El dueño del gym puede apagarlo entero si prefiere otra estrategia de retención (chat directo, llamado del recepcionista, email manual). Los filtros nuevos no quitan ese control — solo previenen que cuando el push se manda, se mande con criterio.

Por qué esto es trabajo de producto, no de marketing

En la mayoría de los sistemas de gym, los pushes automáticos son una decisión de la planilla de marketing: "quiero mandar un mensaje a los inactivos". Lo que casi nunca se piensa es qué pasa con los falsos positivos — los socios que entran al filtro pero no deberían. Un sistema de pushes que tiene 30% de falsos positivos genera más daño que beneficio, aunque la otra 70% del tiempo recupere socios.

Nuestro principio es el inverso: preferimos no mandar un push antes que mandarlo mal. Si la query no puede distinguir con certeza al socio que merece re-engagement del socio nuevo que aún no fue, no manda nada. Mejor 100 pushes precisos que 300 con 100 falsos positivos.

Un push automático mal disparado no se puede deshacer. Ya lo viste, ya desconfiaste un poco del sistema. La precisión de los disparos importa más que el volumen.

Cooldown vs spam: la diferencia que el socio percibe

Hay un detalle de UX que vale destacar: el cambio del cooldown diario al semanal es probablemente más importante que cualquiera de los otros tres filtros. Un push que llega siete veces en una semana se transforma en ruido — el socio aprende a ignorarlo. Un push que llega una vez por semana mantiene su carácter de mensaje, no de notificación de fondo.

Es la misma lógica de las apps que mandan resumen diario vs resumen semanal: el primero termina silenciado, el segundo se lee. Aplicar esa lógica al re-engagement de gym fue un cambio de una línea de código y un cambio enorme en cómo el socio percibe la app.

Auditoría: el dueño puede ver cuándo se mandó cada push

Cada push enviado queda registrado en una tabla aparte (push_log) con: a quién, cuándo, qué tipo, cuántos dispositivos llegaron, cuántos fallaron. El dueño del gym puede revisar ese log para entender el comportamiento del sistema — cuántos socios recibieron re-engagement esta semana, cuántos abrieron la app después, cuántos finalmente vinieron.

Las decisiones de la query (qué socios califican, cuáles no) quedan implícitas — pero los resultados son medibles. Si el dueño cree que el filtro es muy estricto y deja afuera a socios que sí debería recuperar, puede pedirnos ajustar el threshold (de 14 días a 10, por ejemplo). Si cree que aún manda demasiado, ídem en la otra dirección.

Lo que sigue

Este fix es la versión 1.0 de algo más grande. El roadmap natural de "pushes inteligentes":

La idea es siempre la misma: el sistema sugiere, el dueño decide. Y cuando el sistema sugiere mal, mejor que no sugiera. La precisión vale más que el volumen.

Pushes que retienen, no que irritan

Notificaciones automáticas con criterio: bienvenida, vencimiento, re-engagement, cumpleaños — todo configurable, todo auditable. Probá GymFlow 30 días gratis, sin tarjeta de crédito.

Probar gratis 30 días →

Artículos relacionados