Case Files

Cada caso cuenta solo tres cosas: dónde se trabó, qué hicimos y cómo cambiaron los números.

Una historia de éxito sin método ni evidencia, nosotros tampoco la creeríamos. Todos los números de abajo salen de registros de sistema auditables y paneles oficiales de las plataformas; los clientes están anonimizados, solo indicamos la industria.

GROUP A

Sistemas de automatización

AutomationiGaming / Gestión de jugadores

Bot de LINE para jugadores: check-in, pago de premios, vinculación de cuenta y sorteos, todo automático

Las promos dependían de puro trabajo manual: check-ins anotados en planillas, premios conciliados uno por uno por soporte, identidades de LINE que no cuadraban con las cuentas de juego. Con varias promos activas, se acumulaban omisiones y errores.

  • Vinculación de LINE con la cuenta de juego: una sola vinculación asigna la cuenta; después, cada interacción se asocia automáticamente a la identidad del jugador
  • Check-in diario con premio, sorteos con resultado automático y pago de premios automático: al acreditarse el premio sale la notificación push al instante, sin conciliación manual en todo el flujo
  • Broadcast de promos y consultas por comando (bonos, progreso); soporte solo atiende excepciones
  • Desplegado en la nube de GCP: autoarranque con systemd + autorecuperación ante crashes, alertas externas de caída y backup off-site automático de la base de datos cada 6 horas
Check-in / pagos / vinculación / sorteos: 4 funciones 100% automáticas Backup off-site de la DB cada 6 horas 24/7 alertas de caída + autorecuperación

Fuente: registros de despliegue y ejecución del sistema (migrado a la nube 2026-05)

AutomationiGaming / Operación de comunidades

Bot de ambiente para grupos: chat grupal multi-persona automatizado que no suena a máquina

Un grupo donde nadie habla es un grupo muerto, y pagar gente por turnos para animarlo sale caro y es difícil de controlar: el discurso se desalinea, los horarios no se cubren y nadie recuerda qué se dijo.

  • Varios personajes fijos, cada uno con personalidad y memoria de largo plazo: qué recomendó ayer y su historial de aciertos y fallos quedan en un libro de registro; al día siguiente hacen recap automático y se contestan entre sí, sin romper el personaje
  • Todo el contenido sale de datos reales: fixtures, cuotas y resultados conectados a fuentes reales, prohibido inventar — un partido mal cantado y la confianza del grupo se termina
  • Ritmo de envío humanizado: cuentas intercaladas con intervalos aleatorios de 10–15 minutos, como gente real cada uno en lo suyo, no bots haciendo fila para spamear
  • Cada mensaje enviado se captura en pantalla y se verifica que entró de verdad al grupo destino; si salió o no salió, hay registro consultable
4 personajes fijos con libro de memoria de largo plazo Intervalo entre mensajes 10–15 min aleatorio humanizado Cada envío verificado con captura dentro del grupo

Fuente: registros de ejecución del sistema de envío y captura de pantalla de cada mensaje

AutomationDatos deportivos / Medios de contenido

Sitio de contenido deportivo con más de 400 páginas: el pipeline de actualización completo, automático

Más de 400 páginas de contenido de partidos que cambian todos los días: mantener a mano tablas, marcadores y fixtures es imposible de sostener.

  • Todo el sitio en una VM de GCP; el pipeline «captura de datos → validación → composición → rebuild → deploy» corre solo 4 veces al día
  • Guard numérico integrado: puntos, diferencia y partidos jugados se cruzan automáticamente para verificar consistencia; si no cierra, se aborta — jamás se despliega un dato malo
  • Reintentos automáticos si la fuente externa se cae (backoff exponencial 15/30/60 segundos); ante fallo conserva la versión anterior y alerta proactivamente
402 páginas generadas automáticamente Actualización automática 4 veces al día 0 datos erróneos publicados (guard con aborto)

Fuente: registros de ejecución y de despliegue del sistema

AutomationOperación de datos

Backup off-site diario de datos críticos, con tres defensas contra el «espejo que borra la copia buena»

Lo peor de un backup no es no tenerlo: es que el origen se corrompa y el backup en espejo borre también los datos buenos.

  • Backup incremental diario programado a almacenamiento off-site; identifica el destino por archivo marcador y no por letra de unidad — sobrevive a cambios de puerto
  • Protección anticolapso: si el conteo de archivos de origen cae de forma anómala, se rechaza la corrida entera; borrado lógico con retención de 30 días; 30 snapshots conservados
  • Alertas de Telegram de tres estados (abortado / fallo / recuperado); en días normales no hace ruido
283 archivos comparados uno a uno por SHA256, 0 omisiones Backup incremental en ~1.3 s 8/8 pruebas negativas de las defensas aprobadas

Fuente: registros de ejecución y verificación del sistema de backup

AutomationMedios de contenido / Datos deportivos

Backoffice de contenido que publica desde el celular: un toque y en 10 segundos está en línea

El equipo de contenido necesitaba publicar rápido desde el celular y salir en línea con un toque, sin tocar código ni comandos de deploy.

  • Backoffice minimalista: login con protección anti fuerza bruta, CSRF en todos los formularios, snapshots de versiones, imágenes convertidas a WebP con EXIF removido automáticamente
  • VM de GCP + systemd con autoarranque y autorecuperación ante crashes; los fallos alertan solos por Telegram
  • Publicación real con un toque: presionar → exportar → rebuild → deploy, end-to-end sin intervención
Publicación end-to-end en ~10 s Proceso matado, autorecuperado en ~6 s Pruebas negativas de seguridad todas aprobadas

Fuente: mediciones reales del sistema y registros de pruebas de seguridad

AutomationConsumo / Marketing de eventos

Landing de sorteo blindada contra registros basura, con la lista real reconstruida después

Lo que más teme una página de registro: bots y la misma persona inflándola con entradas repetidas, y después no hay forma de distinguir quiénes son reales.

  • Cinco capas anti-abuso: bloqueo de duplicados, rate limit por IP, claves únicas, hash de fingerprint y verificación humana
  • Limpieza multidimensional: patrón del número, colisiones de nombre, distancia entre números, clustering por prefijo IPv6 y por fingerprint, todo cruzado
  • Contrastando cortes temporales y seeds de prueba, el total de registros se redujo a una lista confiable
Registros totales: 142 Reales tras auditoría: ~118

Fuente: base de datos del sistema de registro y registros de auditoría de limpieza

GROUP B

Publicidad y tracking

Paid MediaE-commerce / Agro y frescos

Marca que cierra ventas fuera del sitio: recuperamos el Purchase con CAPI

El cliente entra por el anuncio, pero la compra ocurre en una página de pedidos de terceros fuera del sitio: el píxel no ve la conversión y el algoritmo nunca aprende quién compra de verdad.

  • Endpoint propio de Meta CAPI: el Pixel del navegador y el servidor envían el mismo event_id por partida doble y se deduplica automáticamente
  • Las ventas off-site se reinyectan como Purchase; todas las claves de matching se normalizan y hashean del lado del servidor, y los valores malos se descartan solos
  • Los eventos offline van sin IP/UA, para no meter señales falsas que bajen la calidad de matching
Deduplicación por event_id verificada en real Calidad de matching EMQ ~6–7 7 ventas off-site reinyectadas

Fuente: mediciones en el Administrador de eventos de Meta y registros de reinyección

Paid MediaTráfico en industria de alta competencia

Sin creerle al panel de la plataforma: contador de tráfico propio que separa el origen de cada conversión

La plataforma de anuncios se atribuye conversiones que no vienen de anuncios, y los registros del backoffice no tienen campo «origen»: imposible separar paid, orgánico y social.

  • Un Cloudflare Worker registra cada impresión y cada clic de CTA, sin pasar por la plataforma de anuncios y sin que lo afecten los bloqueadores
  • Atribución privacy-first: solo se guardan hashes, nunca la IP cruda; cada registro nuevo se cruza contra el historial de clics
  • Reporte diario + flash cada dos horas, empujados automáticamente a Telegram
Comprobado: 3 registros en un día, 2 de ads / 1 no-ads Consistencia de hashes entre sistemas verificada Tests unitarios 11/11

Fuente: base de datos del contador propio y registros de matching

GROUP C

Desarrollo web y SEO

Web / SEOE-commerce / Agro y frescos

Sitio de marca para un productor local: sin tocar los pagos, solo sumando confianza

El negocio ya tenía sistema de pedidos y LINE; le faltaba un sitio de marca que lo hiciera visible y confiable, y no quería montar una pasarela de pagos propia.

  • One-page de marca hecho a mano sobre Cloudflare Pages; los pedidos siguen en el sistema existente, cero integración de pagos
  • Fotos reales convertidas a WebP en todo el sitio; datos estructurados, sitemap y canonical resueltos de una sola vez
  • Perfil de Negocio de Google enlazado al sitio, catálogo de productos publicado, verificación y envío en GSC
Peso de imágenes 38MB → 2.3MB (−94%) CTR 9% a 28 días del lanzamiento Posición promedio 10.1

Fuente: Google Search Console (captura 2026-07) y registros de implementación

Web / SEOTráfico en industria de alta competencia

Sitio nuevo en un mercado hipercompetitivo: tráfico orgánico creciendo desde cero

Hacer crecer desde cero el tráfico de búsqueda orgánica de un sitio nuevo, en un único mercado de altísima competencia.

  • Sitio estático en Cloudflare Pages, GA4 + GSC conectados de punta a punta; las conversiones se acreditan con eventos de clic saliente
  • Producción de contenido long-tail + balanceo de enlaces internos, remedio directo del «descubierta: sin indexar»; deduplicación de plantillas para no ser marcado como redundante
  • Comparativa semanal de resultados empujada automáticamente a Telegram
Impresiones en 28 días 724 → 4,730 (~6.5x) Clics 68 → 191 (~2.8x) Tasa de indexación ~88% (153/173 páginas)

Fuente: Google Search Console (captura 2026-07, contra mayo del mismo año)

Web / SEOTráfico en industria de alta competencia

Cirugía de canibalización de keywords: 35 términos peleándose en 6 páginas, reordenados a una keyword por página

El mismo grupo de keywords core repartido en 6 páginas que se robaban el ranking entre sí: el término head rankeaba en 23.7 sin ninguna página dedicada a capturarlo; la página con más anchors (33 enlaces internos) tenía apenas 8 impresiones y posición 37 — porque el título ni siquiera llevaba el término.

  • Mapa de canibalización con datos reales query×page de las últimas 4 semanas de GSC; se reasignó el rol de cada página: término head, términos ganadores y términos de calculadora, uno por página, sin tocar el terreno de la página que factura
  • Palanca de anchors detectada: el texto ancla de las tarjetas de artículos relacionados = el título de la página; cambiar 1 título = reparar 26 anchors internos de una sola vez (0 → 26/26 con el término objetivo)
  • Estrategia de lastmod honesto: campo updatedAt nuevo, solo las páginas realmente modificadas actualizan su fecha — nada de refrescar todo el sitio para engañar a Google
  • Balanceo de páginas huérfanas: una página con ranking pero 0 referencias pasó de 1 → 11 enlaces entrantes; 7 páginas peleándose el término de marca (3,088 impresiones por solo 6 clics) reordenadas por intención
Anchors internos 0 → 26/26 con término objetivo Entrantes a página huérfana 1 → 11 Auditoría de 174 páginas: 0 títulos duplicados / canonical faltante

Fuente: Google Search Console (captura 2026-08) y mediciones reales del build

Web / SEOSitio de reseñas en industria de alta competencia

SEO técnico para un sitio que reseña 61 operadores: de quemar crawl budget a indexar todo el sitio

Contenido había de sobra, pero la parte técnica hacía agua: cualquier URL rota devolvía 200 + el home completo (soft 404) quemando crawl budget, el lastmod del sitemap se refrescaba entero todos los días y Google lo ignoraba, y los enlaces internos estaban monopolizados por las páginas de plantilla del footer.

  • Soft 404 erradicado: las URLs rotas pasaron de «200 + home de 87KB» a un 404 correcto; el crawl budget se concentra en páginas reales
  • lastmod del sitemap migrado a una máquina de estados por hash de contenido: la fecha solo cambia cuando el contenido cambió de verdad; Google volvió a confiar en la señal de rastreo
  • Redistribución de enlaces internos: mediana de entrantes en páginas de reseña 5 → 12, mínimo 3 → 7; se rompió el monopolio de 66 entrantes de las páginas de plantilla
  • 27 títulos superaban el largo de truncado del SERP en chino tradicional (~30 caracteres de ancho completo) → todos comprimidos, 0 páginas fuera de norma; además, gate de enlaces muertos: antes de cada deploy se escanea cada enlace interno y se bloquea si apunta a la nada (probado con test negativo: sí bloquea)
  • Posicionamiento GEO / búsqueda con IA: llms.txt generado automáticamente, reconstruido con cada actualización de contenido
URLs rotas 200 → 404 (crawl budget recuperado) Mediana de enlaces internos 5 → 12 Títulos excedidos 27 → 0 páginas

Fuente: build y registros de medición en producción (2026-08)

Web / SEOSnapshots de fixes técnicos · acumulado multi-sitio

Bitácora de fixes rápidos de SEO: todas estas trampas las reparamos con nuestras propias manos

Muchos sitios no fallan por contenido: los mata un problema técnico invisible. Todo lo de abajo son casos reales, cada uno con mediciones de antes y después del fix.

  • Sitio nuevo con cero páginas indexadas → el canonical y el sitemap usaban formatos de URL en guerra (.html contra sin extensión, loop de redirecciones 308); se alinearon los cuatro puntos + reenvío del sitemap y quedó resuelto
  • 404 fantasma en GSC (/cdn-cgi/email-protection) → lo causaba la reescritura de ofuscación de emails de Cloudflare; se envolvió el código fuente con la anotación email_off y el escaneo de las 67 páginas del sitio dio 0 residuos
  • Páginas duplicadas canibalizándose → la misma marca escrita en dos páginas con puntajes contradictorios; 301 + fusión de contenido y las keywords dejaron de robarse ranking
  • Enlaces en secciones plegadas devaluados → se agregó al home un índice de texto plano de todo el sitio; las 16 «URLs no reconocidas» quedaron cubiertas en su totalidad
  • Falsa alarma de desplome de tráfico → SOP forense de caídas con 11 descartes: mirar datos semanales y no la línea diaria; la oscilación normal del CTR dejó de diagnosticarse mal

Fuente: GSC de cada sitio y mediciones antes/después de cada fix (2026)

Los clientes de estos casos están anonimizados; solo conservamos la industria y los indicadores técnicos auditables.
¿Quieres confirmar si podemos resolver tu problema? Descríbenos tu situación y te decimos directo si se puede o no.

Your Case Next

Tu caso probablemente ya lo resolvimos antes

Describe dónde estás trabado y te respondemos: cómo se resolvió el caso similar y qué hay que cuidar en tu escenario.

Hablar por Telegram
Evaluación y cotización sin costo · Te responde el ingeniero en persona
Hablar por TG