Bloquear clics publicitarios inválidos mientras la campaña sigue activa

Los anunciantes pagan por cada clic. Algunos de esos clics proceden de bots, VPN, proxies y centros de datos, y un informe que llega semanas después solo documenta la pérdida. ClickFortify es un proyecto independiente que diseño y opero por mi cuenta. Su tarea es detectar el tráfico inválido y excluirlo mientras la campaña sigue gastando.

La forma del problema

Tres propiedades determinan casi todas las decisiones de diseño:

• Nunca se detiene. Los clics llegan de forma continua, a todas horas, en distintas zonas horarias.
• Cada anunciante es un inquilino. Cada uno tiene sus propias cuentas, reglas y datos, y nunca deben filtrarse entre sí.
• La acción ocurre en otro lugar. Detectar un clic malicioso es solo la mitad del trabajo. La exclusión debe escribirse de vuelta en la cuenta publicitaria de Google Ads o Meta del anunciante a través de sus API, que tienen cuotas y a veces fallan.

Orientado a eventos, a propósito

Recopilar clics, puntuarlos y sincronizar exclusiones tienen perfiles de carga muy distintos. La recopilación llega en picos y debe seguir siendo rápida. La puntuación depende de la CPU. La sincronización está limitada por la API de otro. Ponerlos en un solo proceso permitiría que la parte más lenta marcara el ritmo de todas las demás.

Por eso cada responsabilidad es su propio servicio, conectado mediante eventos en NATS. Un clic se recopila y se publica; la puntuación se suscribe, decide y publica una decisión; la sincronización recoge las decisiones que requieren una exclusión. Cada servicio escala por sí mismo, y una API lenta de una plataforma publicitaria nunca atasca la recopilación.

Puntuar un clic

Ninguna señal por sí sola demuestra que un clic es inválido, así que la puntuación combina varias: señales de comportamiento, huella digital del dispositivo y filtrado del tráfico de VPN, proxies y centros de datos. Mantener la puntuación separada de la recopilación permite cambiar las reglas sin tocar la parte que debe seguir en funcionamiento.

Escribir de vuelta sin saturar las API

La escritura de vuelta es la parte que falla de formas interesantes. Las exclusiones pasan por colas de trabajos de Redis Bull para que cada sincronización tenga reintentos con espera progresiva, y una ráfaga de decisiones se convierte en un flujo constante de llamadas a la API en lugar de un pico.

// Illustrative: one queued exclusion per tenant, platform and IP
await exclusions.add(
  'exclude-ip',
  {tenantId, platform, ip},
  {
    jobId: `${tenantId}:${platform}:${ip}`, // idempotent: the same IP is never queued twice
    attempts: 5,
    backoff: {type: 'exponential', delay: 30_000},
    removeOnComplete: true
  }
);

Un identificador de trabajo estable hace que la operación sea idempotente: si la misma IP se marca diez veces en un minuto, se sincroniza una sola vez.

Multiinquilino y una migración en vivo

Como cada anunciante tiene una base de datos de inquilino aislada, los cambios grandes pueden planificarse inquilino por inquilino en lugar de como un único cambio arriesgado. Así es como realicé una migración de bases de datos en producción en vivo en más de 500 bases de datos de inquilinos con un tiempo de inactividad prácticamente nulo.

Lo que le diría a alguien que construya lo mismo

1. Trate la escritura de vuelta en la plataforma publicitaria como la parte difícil, no la detección.
2. Separe los servicios por perfil de carga, no por sustantivo.
3. Haga que cada efecto secundario externo sea idempotente antes de necesitar reintentarlo.