Bot farm infló 60% de las instalaciones pagadas en Google Ads

⏱️ Lectura: 14 min

Google le cobró a Nick Abe, creador del juego de rompecabezas Dayzle, instalaciones que su propio panel de administración nunca vio. En dos semanas de campaña gastó CA$220 en Google Ads y facturó 56 instalaciones, pero solo 13 correspondían a personas reales.

📑 En este artículo

1. TL;DR
2. Qué pasó
3. Contexto e historia: cómo opera una bot farm de instalaciones
4. Detalles técnicos y rendimiento
5. Cómo empezar a auditar tu propia campaña
6. Impacto y análisis
7. Qué sigue
8. Preguntas frecuentes
   1. ¿Qué es exactamente una bot farm en publicidad móvil?
   2. ¿Por qué Google no filtra esto automáticamente?
   3. ¿Cambiar el costo objetivo por instalación ayuda a filtrar bots?
   4. ¿Sirve para todas las categorías de apps, no solo juegos?
   5. ¿Qué evento de conversión es más difícil de falsificar?
   6. ¿Cómo reclamo instalaciones fraudulentas ante Google?
9. Referencias

El resto tenía la firma clásica de una bot farm: dispositivos que abren la app una vez, no tocan ninguna pantalla y desaparecen para siempre. El caso expone un riesgo que cualquier desarrollador indie en LATAM con presupuesto ajustado puede sufrir sin darse cuenta.

TL;DR

• Nick Abe gastó CA$220 en Google Ads durante dos semanas promocionando su app Dayzle en Android.
• Google facturó 56 instalaciones; el panel real de Nick solo confirmó 13 usuarios genuinos.
• 33 de esas instalaciones mostraban el mismo patrón: apertura de la app en 0 segundos y sin retorno jamás.
• En un solo día, 20 de 21 instalaciones correspondían a una versión de la app que Play Store ya no distribuía.
• Esas 20 instalaciones vinieron de 28 modelos de teléfono distintos repartidos en 19 estados.
• 7 instalaciones adicionales llegaron desde países fuera del objetivo geográfico de la campaña.
• Los 13 usuarios reales completaron 92 partidas de Dayzle en conjunto.
• Nick cambió el objetivo de conversión de “abrir la app” a “ganar un rompecabezas” para encarecer el fraude.

Qué pasó

Nick Abe corre Dayzle, un juego de rompecabezas para Android, y activó una campaña de Google Ads con un presupuesto de CA$40 diarios apuntando a instalaciones. Con un costo por instalación objetivo de US$1,50, Google apenas gastaba el presupuesto: el sistema no encontraba suficientes instalaciones a ese precio.

Como prueba, Nick quitó el límite de costo objetivo. El gasto se duplicó de inmediato a CA$80 diarios y Google reportó 21 instalaciones ese día. El panel de administración de Dayzle, en cambio, marcaba una sola instalación real.

⚠️ Ojo: quitar el límite de costo por instalación no mejoró la calidad del tráfico: solo le dio más presupuesto a la bot farm para que siguiera generando instalaciones falsas más rápido.

Revisando los datos crudos de analítica, Nick encontró la explicación: esas 21 instalaciones correspondían a dispositivos Android nuevos, y 20 de ellos corrían una versión antigua de la app que Google Play había dejado de distribuir días antes. Eso es imposible si el instalador real fue Play Store: la única forma de tener esa versión es haberla instalado desde un archivo APK guardado de antemano.

Aun así, los 20 dispositivos reportaban a Google Play como fuente del instalador. Cada uno abrió la app una sola vez, no interactuó con ninguna pantalla y jamás volvió a abrirla. Entre esos 20 dispositivos había 28 modelos de teléfono distintos repartidos en 19 estados, una variedad enorme para un grupo que hizo exactamente lo mismo el mismo día.

Al cerrar las dos semanas de campaña, el balance fue: 56 instalaciones facturadas, 33 con ese mismo patrón fantasma, 7 más provenientes de países fuera de la segmentación geográfica de la campaña, y 13 personas reales. Esas 13 personas, en conjunto, completaron 92 partidas del juego, la única señal de que el producto sí funciona para quien lo usa de verdad.

Contexto e historia: cómo opera una bot farm de instalaciones

El fraude de clics existe desde que la publicidad programática empezó a pagar por evento en vez de por impresión. Lo nuevo del caso Dayzle es que el fraude migró del clic a la instalación: en campañas de costo por instalación (CPI), un bot que instala la app una vez cuesta menos de fabricar que un clic sostenido, y Google factura igual.

El mecanismo que describe Nick tiene una lógica perversa. Google Ads optimiza la entrega de anuncios hacia el objetivo que el anunciante define: si el objetivo es “instalaciones”, el sistema aprende qué inventario genera más instalaciones y le manda más presupuesto. Una bot farm que mira el video más corto del grupo de anuncios sin hacer clic, y luego instala la app desde una copia local en vez de descargarla de Play Store, genera una conversión válida a ojos del algoritmo. Cuantas más instalaciones logra la granja, mejor perfil de rendimiento le asigna Google, y más anuncios le envía. Es un bucle que garantiza que el presupuesto del anunciante chico se queme sin retorno.

flowchart TD
    A["Bot farm mira el video mas corto del grupo de anuncios"] --> B["Instala la app desde un APK guardado, no desde Play Store"]
    B --> C["Google Ads registra vista + instalacion como conversion valida"]
    C --> D["El algoritmo aprende y envia mas presupuesto a ese perfil"]
    D --> A

Este circuito explica por qué quitar el límite de costo por instalación empeoró las cosas en vez de mejorarlas: Google interpretó la falta de límite como luz verde para comprar más de lo que ya estaba funcionando, y lo que estaba funcionando era la granja de bots.

Detalles técnicos y rendimiento

La huella técnica de una instalación fraudulenta rara vez es sutil una vez que se cruzan las fuentes de datos correctas. En el caso de Dayzle, la señal más clara fue la versión de la app: los dispositivos sospechosos corrían un build que Play Store había retirado días antes, algo que solo ocurre si el APK se instaló manualmente (sideloading) en lugar de descargarlo de la tienda.

La segunda señal fue la atribución del instalador. El Install Referrer API de Android permite que cualquier proceso con acceso de shell (por ejemplo vía ADB o un dispositivo rooteado con Frida/Xposed) escriba un valor falso de referrer que declare a Google Play como origen, aunque la instalación real haya venido de un archivo compartido entre decenas de teléfonos de la granja.

La tercera señal fue el comportamiento de sesión: 0 segundos de uso, ninguna pantalla vista, cero retorno. Combinada con la diversidad artificial de 28 modelos de dispositivo en 19 estados el mismo día, la conclusión técnica es difícil de evitar.

Métrica	Usuario real	Instalación de bot farm
Tiempo en la app	Minutos a horas, sesiones repetidas	0 segundos, una sola apertura
Versión instalada	La última publicada en Play Store	Una versión que Play ya dejó de distribuir
Diversidad de dispositivos	Consistente con tu público real	Decenas de modelos distintos el mismo día
Atribución del instalador	Google Play Store legítimo	APK cargado a mano pero reportado como Google Play
Segmentación geográfica	Dentro del país objetivo de la campaña	Instalaciones desde países fuera del target

Para detectar el patrón sin depender solo de la intuición, sirve automatizar la comparación entre lo que Google Ads reporta y lo que tu propio backend o Firebase registró. Un Google Ads Script simple ya alcanza para el primer filtro:

function main() {
  var report = AdsApp.report(
    "SELECT CampaignName, Device, Conversions, AverageCost " +
    "FROM CAMPAIGN_PERFORMANCE_REPORT " +
    "WHERE CampaignName = 'Dayzle - Android Installs' " +
    "DURING LAST_14_DAYS"
  );
  var rows = report.rows();
  while (rows.hasNext()) {
    var row = rows.next();
    Logger.log(row.Device + ": " + row.Conversions + " conversiones a $" + row.AverageCost);
  }
}

Este script corre semanalmente dentro de la interfaz de Ads Scripts y lista las conversiones por tipo de dispositivo para una campaña puntual. Cualquier pico aislado en un solo modelo, franja horaria o país fuera de tu segmentación merece revisión manual antes de aumentar presupuesto.

Cómo empezar a auditar tu propia campaña

No hace falta ser una empresa grande para aplicar el mismo proceso que usó Nick Abe. Estos son los pasos concretos:

1. Exportá los eventos de instalación y sesión desde Firebase Analytics o tu SDK de analítica, con timestamp, modelo de dispositivo y duración de sesión.
2. Cruzá esa exportación contra el reporte de clics de Google Ads (click_view en la Google Ads API) usando el gclid como llave común.
3. Marcá como sospechoso todo registro con duración de sesión igual a cero, versión de app desactualizada, o país fuera de tu segmentación.
4. Si el patrón se repite, presentá el reclamo de tráfico inválido desde el centro de ayuda de Google Ads.
5. Cambiá el evento de conversión que optimiza tu campaña por algo que un script simple no pueda fingir barato, como completar un nivel o ganar una partida.

Para el paso 2 en un proyecto real, un script en Node.js que combine ambas fuentes se ve así:

const { GoogleAdsApi } = require("google-ads-api");
const admin = require("firebase-admin");

const client = new GoogleAdsApi({
  client_id: process.env.GADS_CLIENT_ID,
  client_secret: process.env.GADS_CLIENT_SECRET,
  developer_token: process.env.GADS_DEV_TOKEN,
});

async function flagSuspiciousInstalls(customerId, refreshToken) {
  const customer = client.Customer({ customer_id: customerId, refresh_token: refreshToken });

  const clicks = await customer.query(`
    SELECT click_view.gclid, segments.device, segments.date
    FROM click_view
    WHERE segments.date DURING LAST_14_DAYS
  `);

  const db = admin.firestore();
  for (const click of clicks) {
    const session = await db.collection("app_sessions").doc(click.click_view.gclid).get();
    const seconds = session.exists ? session.data().duration_seconds : 0;
    if (seconds === 0) {
      console.log(`Sospechoso: gclid=${click.click_view.gclid} device=${click.segments.device}`);
    }
  }
}

El script recorre los clics reportados por Google Ads en las últimas dos semanas y busca, para cada gclid, el documento de sesión correspondiente en Firestore. Una duración de 0 segundos repetida en distintos dispositivos es la misma huella que delató a la bot farm de Dayzle.

Si preferís trabajar con el histórico completo en SQL en lugar de recorrerlo fila por fila, podés exportar tu cuenta de Google Ads a BigQuery con la Google Ads API y la CLI de Google Cloud:

# Windows (PowerShell)
(New-Object Net.WebClient).DownloadFile("https://dl.google.com/dl/cloudsdk/channels/rapid/GoogleCloudSDKInstaller.exe", "$env:Temp\gcloud-installer.exe")
& "$env:Temp\gcloud-installer.exe"
gcloud init

# macOS
brew install --cask google-cloud-sdk
gcloud init

# Linux (Debian/Ubuntu)
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list
sudo apt-get update && sudo apt-get install -y google-cloud-cli
gcloud init

Con la exportación activa, confirmá que los datos llegan corriendo bq ls tu_proyecto:google_ads_dataset y verificando que la tabla p_ads_ClickStats_* tenga filas con la fecha de hoy antes de construir consultas encima.

💡 Tip: guardá el histórico de versión de app por dispositivo desde el día uno de tu campaña. Sin ese dato de referencia, no hay forma de detectar después que una instalación llegó con una versión que Play ya había retirado.

Impacto y análisis

El caso de Dayzle es pequeño en dinero (CA$220 en dos semanas) pero grande en proporción: si el 60% del gasto de un desarrollador indie se va a bots, cualquier decisión de negocio basada en ese costo por instalación queda distorsionada. Subir presupuesto, pausar canales que “no convierten” o calcular retorno de inversión con esos números lleva a conclusiones equivocadas.

Nick Abe razona que si una bot farm encontró rentable atacar un presupuesto tan chico, es probable que apps más grandes reciban mucho más de este tráfico sin notarlo, simplemente porque el volumen diluye el patrón. Un anunciante que gasta millones de dólares al mes rara vez audita instalación por instalación como hizo Nick con sus 56 conversiones.

La asimetría de costos es la raíz del problema: generar una instalación falsa por software es barato, mientras que verificarla exige cruzar varias fuentes de datos que casi ningún equipo pequeño tiene tiempo de mantener.

Qué sigue

Nick sigue esperando la respuesta de Google al formulario de tráfico inválido que presentó, y prometió reportar si recibe un reembolso. Mientras tanto, ya cambió el objetivo de optimización de su campaña de “abrir la app” a “ganar un rompecabezas”: un evento mucho más caro de fingir para un script, porque exige resolver contenido real dentro del juego.

La estrategia no elimina el fraude, solo lo encarece. Para una app del tamaño de Dayzle, hacer que sea más cara de atacar que la competencia vecina puede ser protección suficiente. Para apps más grandes, la inversión en verificación de eventos profundos probablemente ya vale la pena, aunque Nick no tiene forma de confirmarlo con sus propios datos.

📖 Resumen en Telegram: Ver resumen

Probalo vos: exportá las últimas dos semanas de instalaciones de tu campaña de Google Ads y cruzalas por duración de sesión antes de aprobar el próximo aumento de presupuesto.

Preguntas frecuentes

¿Qué es exactamente una bot farm en publicidad móvil?

Es una operación que usa muchos dispositivos, reales o emulados, para generar clics o instalaciones falsas que se facturan como conversiones legítimas dentro de una plataforma de anuncios como Google Ads.

¿Por qué Google no filtra esto automáticamente?

Google sí filtra parte del tráfico inválido detectado en tiempo real, pero el caso de Dayzle muestra que instalaciones con atribución falsa al Play Store y sin señales evidentes de automatización pueden pasar el filtro inicial y requerir una revisión manual posterior.

¿Cambiar el costo objetivo por instalación ayuda a filtrar bots?

No necesariamente. En el caso descrito, quitar el límite de costo duplicó el gasto diario y aumentó las instalaciones reportadas, pero la proporción de instalaciones fraudulentas no bajó.

¿Sirve para todas las categorías de apps, no solo juegos?

Sí. El mecanismo depende del tipo de evento de conversión que define la campaña, no del rubro de la app: cualquier CPI basado en un evento fácil de fingir (abrir la app, un clic) es un blanco atractivo para una bot farm.

¿Qué evento de conversión es más difícil de falsificar?

Eventos que requieren completar una acción con lógica de negocio real dentro de la app, como terminar un nivel, completar una compra o llegar a un paso avanzado de un flujo, son más caros de automatizar que simplemente abrir la app.

¿Cómo reclamo instalaciones fraudulentas ante Google?

Google Ads tiene un formulario de reporte de tráfico inválido accesible desde su centro de ayuda; hay que adjuntar la evidencia de la discrepancia entre lo facturado y lo registrado en tu propia analítica.

Referencias

• Dayzle Blog: I spent $220 on Google app ads. 60% of the installs were robots.: el artículo original de Nick Abe con el desglose completo del caso.
• Wikipedia: Click fraud: contexto histórico sobre el fraude publicitario digital.
• Google Ads API: documentación oficial para exportar y auditar reportes de campañas.
• Firebase Analytics: documentación oficial para registrar eventos de sesión y cruzarlos con campañas.
• Centro de ayuda de Google Ads: canal oficial para reportar tráfico inválido.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de NordWood Themes en Unsplash