Communitygithub.com

Auditoría de Conversión

Audita un embudo de principio a fin y regresa con la UNA fuga que vale la pena corregir, más la prueba que la demuestra: instrumenta los pasos, mide la conversión paso a paso con benchmarks reales, encuentra dónde pierdes usuarios, separa un problema de tráfico de uno de producto, y diseña un experimento con un número de éxito predefinido.

¿Qué es Auditoría de Conversión?

Esta habilidad 'oinoa/skills' (Auditoría de Conversión) es una herramienta de análisis profundo para equipos de producto y crecimiento. Su propósito no es reportar números, sino terminar cada auditoría con una decisión clara: la fuga más costosa, el cambio exacto a implementar y el número que ese cambio debe superar. A diferencia de herramientas de dashboarding o SDKs de analítica, esta habilidad opera en la capa de 'decidir qué corregir' sobre los datos existentes. El flujo de trabajo consta de cuatro pasos: 1) Dibujar el embudo como eventos, no páginas, segmentando por fuentes de tráfico para evitar sesgos. 2) Medir paso a paso y clasificar el peor paso como problema de motivación, fricción o ajuste (fit). 3) Identificar métricas vanidosas y reemplazarlas por indicadores con denominador y horizonte temporal, eligiendo una única estrella del norte. 4) Diseñar un experimento con un solo cambio, un objetivo numérico predefinido y una duración de al menos dos semanas completas. La habilidad es útil para múltiples escenarios: 'las suscripciones están estancadas', 'el tráfico sube pero los ingresos no', abandono en checkout/paywall, conversión de prueba a pago, rendimiento de landing pages, y diseño o lectura de tests A/B (incluyendo declarar un test como muerto). También ayuda a eliminar métricas vanidosas y definir una estrella del norte verdadera. El entregable final son cuatro líneas concisas: la fuga, el diagnóstico (motivación/fricción/ajuste), el cambio a implementar y el número que debe superar (con fecha límite o se revierte). Si no se puede completar la cuarta línea, se tiene una opinión, no una recomendación. La habilidad referencia benchmarks de conversión, reglas de tamaño de muestra y plantillas de auditoría en un documento complementario.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/oinoa/skills/tree/HEAD/skills/conversion-audit

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿Qué hace Auditoría de Conversión?

Tu trabajo no es reportar números. Es terminar cada auditoría con una decisión: la única fuga que cuesta más, el único cambio que enviarías y el número que ese cambio debe superar. Un gráfico que no cambia lo que alguien hace a continuación fue una pérdida de tiempo para todos.

La única regla que lo gobierna todo

Arregla la fuga más grande, no la más fácil. La conversión es multiplicativa: un embudo que va 100 → 40 → 36 → 34 tiene un paso catastrófico y tres pasos buenos. Duplicar el paso 36 → 34 (un paso del 94%) vale casi nada; mover el paso 100 → 40 a 55 eleva todo el embudo ~38%. Siempre clasifica los pasos por usuarios absolutos perdidos, no por porcentaje ni por lo molesto que te parezca el paso. La página más fea rara vez es la más costosa.

Paso 1: dibuja el embudo antes de mirar cualquier dato

Escribe los pasos reales por los que pasa un usuario, en orden, como eventos — no como páginas. "Llegó → vio precios → inició registro → verificó email → completó configuración → hizo la acción principal → volvió el día 7." Si no puedes nombrar el paso, no puedes medirlo, y si dos recorridos diferentes se colapsan en un solo paso, cada número aguas abajo es una mentira.

Dos cosas que rompen silenciosamente cualquier auditoría de embudo:

  • Poblaciones mezcladas. El tráfico pago, orgánico y las invitaciones convierten a tasas muy diferentes. Promediarlas oculta tanto la buena como la rota. Segmenta por fuente antes de concluir algo.
  • El denominador se movió. Una tasa de conversión que "bajó" suele ser un cambio en la mezcla de tráfico, no una regresión de producto. Verifica si el recuento en el paso superior cambió de forma antes de ir a cazar un bug de producto.

Paso 2: mide paso a paso, luego clasifica por usuarios perdidos

Para cada paso: entró, completó, % y caída absoluta. Ordena por caída absoluta. Esa lista ordenada es la auditoría — todo lo demás es comentario.

Luego, solo en el peor paso, haz las tres preguntas de diagnóstico:

  • ¿Es un problema de motivación? Los usuarios no entienden o no quieren el siguiente paso. Síntoma: se van sin interactuar. La solución está en copy, pruebas, claridad de precios.
  • ¿Es un problema de fricción? Los usuarios lo quieren y el flujo les lucha. Síntoma: inician el paso y lo abandonan a medio camino (formularios que se empiezan y no se envían, reintentos, errores). La solución está en menos campos, menos decisiones, mejores valores por defecto, manejo de errores.
  • ¿Es un problema de ajuste (fit)? Los usuarios que llegan nunca iban a convertir. Síntoma: el paso convierte bien para una fuente y terriblemente para otra. La solución está aguas arriba en la segmentación, no en la página.

Equivocarse en esta clasificación es la forma más común en que una auditoría produce meses de trabajo inútil: no puedes hacer un A/B test para salir de un problema de ajuste.

Paso 3: nombra las métricas vanidosas en voz alta

Una métrica es vanidosa si puede subir mientras el negocio va mal. Páginas vistas, registros sin activación, "engagement", recuentos de seguidores en bruto, totales acumulados (que solo pueden subir). Reemplaza cada una con la versión que tiene denominador y un límite de tiempo: no "10k registros" sino "registro → activado en 7 días, por cohorte".

Elige exactamente una estrella del norte: la métrica que solo se mueve cuando un usuario obtiene valor real, que el equipo puede influir realmente, y que lidera los ingresos en lugar de rezagarlos. Todo lo demás es una métrica de apoyo o una barrera de contención. Consulta la referencia para los rangos de referencia con los que verificar un paso antes de declararlo roto.

Paso 4: diseña la prueba que lo demuestra

Cada recomendación incluye un experimento y un número predefinido:

  • Un cambio por prueba. Agrupa tres cambios y una victoria no te enseña nada sobre cuál funcionó, y una pérdida te enseña menos.
  • Establece el objetivo y la duración antes de empezar. "El paso 2 pasa del 40% al 48%, medido durante dos semanas completas." Decidir el listón después de ver los datos es cómo los equipos envían perdedores.
  • Ejecuta semanas completas. El tráfico de días laborables/fines de semana difiere; una prueba de 4 días es un estado de ánimo.
  • Poco potenciado es peor que ninguna prueba. Si el paso solo recibe unos pocos cientos de usuarios por semana, un pequeño aumento no es medible — o prueba algo lo suficientemente grande como para aparecer, o simplemente envía la versión obviamente mejor y sigue adelante. No disfraces una suposición con estadísticas falsas.
  • Decláralo muerto a tiempo. Una prueba que no ha alcanzado el objetivo en su fecha de finalización perdió. Extenderla hasta que gane no es una prueba, es una búsqueda de ruido.

El entregable

Cuatro líneas, en este orden, cada vez:

  1. La fuga — qué paso, usuarios absolutos perdidos, % de la pérdida total.
  2. El diagnóstico — motivación / fricción / ajuste, con la evidencia que lo dice.
  3. El cambio — una cosa para enviar.
  4. El número — lo que debe superar, para cuándo, o se revierte.

Si no puedes completar la línea 4, aún no tienes una recomendación — tienes una opinión.

Consulta references/funnel-benchmarks-and-test-design.md para rangos de referencia paso a paso, las reglas de tamaño de muestra, la tabla de intercambio de métricas vanidosas a reales, y las plantillas de auditoría y experimento.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Skills relacionados