Analytics API para uso y adopción

Módulo 7 · Administración y medición · Lección 2 de 6

Al terminar esta lección podrás extraer datos de adopción desde la Admin Console y el pipeline de OTel, evaluar el despliegue con cuatro métricas estándar y preparar un readout del día 30 (sesión de presentación de resultados) que resista el escrutinio en la sala.

Si no puedes medirlo, no puedes defenderlo.

La pila de medición

Dos herramientas. Una pregunta para cada una.

Claude Code genera dos tipos de datos distintos. La Admin Console ofrece señales de adopción sin necesidad de configuración. El pipeline de OTel ofrece métricas de ingeniería y anclas para el caso de negocio, pero requiere configuración previa.

La mayoría de los readouts del día 30 se hacen completamente a partir de la Admin Console. El pipeline de OTel cobra importancia cuando el cliente necesita los datos en sus propios dashboards, cuando necesitas métricas de resultado de código para construir un caso de ROI o cuando el despliegue es lo bastante grande como para que el seguimiento del costo por desarrollador importe a escala.

Admin Console (dashboard de adopción sin código)

Disponible para los Owner inmediatamente después del despliegue. Ve a Settings > Analytics. Muestra los usuarios activos diarios, la utilización de asientos y el gasto a nivel de organización. El costo por desarrollador requiere OTel. No requiere variable de entorno, backend ni archivo de configuración.

Mejor para: los readouts de los días 7, 14 y 30, los briefings para el champion y cualquier momento en que necesites datos de adopción en cinco minutos.

Qué puedes consultar:

• Usuarios activos diarios y semanales
• Sesiones por usuario a lo largo del tiempo
• Gasto a nivel de organización (el costo por usuario requiere OTel)
• Asignación de asientos y tasa de utilización

Pipeline de OTel (telemetría programática)

Define CLAUDE_CODE_ENABLE_TELEMETRY=1 en el entorno del desarrollador. Por defecto exporta a consola. Enruta a Prometheus, Grafana o cualquier backend compatible con OTLP para construir dashboards. Despliégalo en toda la organización mediante managed-settings.json.

Mejor para: métricas de ingeniería, modelos de ROI y despliegues grandes donde importa el seguimiento del costo por desarrollador.

Métricas clave disponibles:

• session.count y active_time.total
• lines_of_code.count y commit.count
• pull_request.count
• cost.usage y token.usage

Analytics Chat también está disponible en la Admin Console: una interfaz conversacional para consultar datos de uso sin redactar informes ni exportar CSV. Pregunta “¿qué equipos tuvieron más sesiones la semana pasada?” directamente en la consola. Muestra los mismos datos subyacentes que el dashboard de Analytics; lo que cambia es la interfaz.

flowchart LR
    CC["Claude Code en el equipo del desarrollador"] --> OT["Telemetría OTel"]
    OT --> CON["Consola (depuración)"]
    OT --> PROM["Exportador Prometheus (estándar)"]
    OT --> OTLP["Exportador OTLP (empresarial)"]
    PROM --> GRAF["Grafana u otro stack de Prometheus"]
    OTLP --> BK["Cualquier backend compatible con OTLP"]

Regla de trabajo

La Admin Console responde “¿Está funcionando?”. El pipeline de OTel responde “¿Está funcionando para el negocio?”.

Las cuatro métricas del scorecard

Cuatro números. Una sola historia.

Estas son las métricas que van al readout del día 30. Para cada una se indican la señal de alerta y la fuente de datos.

DAU (señal de adopción)

• Objetivo: 60% en la semana 3
• Qué vigilar: una meseta por debajo del 50% en la semana 2 es una señal de alerta temprana. Un DAU por debajo del 40% en la semana 4 indica que el despliegue tiene un problema de gestión del cambio, no de producto.
• Dónde encontrarla: Admin Console > Analytics > Active users.

Sesiones por usuario (profundidad de uso)

• Objetivo: 2 a 3 al día
• Qué vigilar: menos de 1,5 sesiones al día sugiere que los desarrolladores abren Claude Code pero no lo integran en su flujo de trabajo. Combina este número con active_time.total para tener una visión más completa.
• Dónde encontrarla: Admin Console o active_time.total de OTel.

Retención de la semana 2 (señal de permanencia)

• Objetivo: 80% o más después de la semana 2
• Qué vigilar: la caída después de la primera semana es habitual; a menudo refleja que la novedad se desgasta, no un fallo del producto. Una retención por debajo del 80% después de la semana 2 predice abandono al momento de la expansión.
• Dónde encontrarla: la vista de cohortes de la Admin Console.

Costo por desarrollador (ancla del caso de negocio)

• Seguimiento: semanal
• Qué vigilar: los picos de costo sin un aumento correspondiente en sesiones o en señales de resultado indican un uso desbordado o un límite de gasto mal configurado. Este número ancla la conversación sobre el ROI.
• Dónde encontrarla: Admin Console > Billing o cost.usage de OTel.

El patrón de superusuarios

En la mayoría de los despliegues, entre 10 y 15 desarrolladores generan una parte desproporcionada del costo y del resultado. Si el costo sube sin un aumento correspondiente en adopción, revisa primero el desglose por desarrollador, no el agregado. La palanca es el emparejamiento de modelos (model matching): los flujos de trabajo que no requieren la capacidad de un modelo de frontera pueden dirigirse a un modelo más ligero. Esa conversación pertenece al readout de la semana 4, no a una sorpresa en la factura.

Despliegue de OTel

Tres rutas de exportación. Elige la que encaje con la pila del cliente.

El pipeline de OTel envía la telemetría de Claude Code adonde quiera el cliente. El exportador que elijas depende de su infraestructura de observabilidad existente y de cuántos desarrolladores estén en el alcance.

1. Exportador de consola (depuración)

Es el valor por defecto. Define una variable de entorno y la telemetría se imprime en la terminal del desarrollador. No requiere backend. Úsalo para verificar que el pipeline funciona antes de comprometerte con una configuración de backend.

# Activar telemetría (exporta a consola por defecto)
CLAUDE_CODE_ENABLE_TELEMETRY=1

Solo para desarrolladores. Confirma que las métricas fluyen antes de que el equipo invierta tiempo en configurar un exportador de backend. Si session.count y cost.usage aparecen en la consola, el pipeline funciona.

2. Exportador Prometheus (estándar)

La ruta estándar para clientes que usan Grafana o una pila de Prometheus existente. Expone un endpoint de scraping en cada equipo de desarrollador. Es adecuada para equipos de ingeniería que ya operan su propia infraestructura de observabilidad.

CLAUDE_CODE_ENABLE_TELEMETRY=1
OTEL_METRICS_EXPORTER=prometheus
OTEL_EXPORTER_PROMETHEUS_PORT=9464

Requiere configuración por equipo salvo que se despliegue mediante un script de inicio o MDM. Para equipos de más de 20 desarrolladores, pasa a la ruta OTLP con managed-settings.json para un despliegue consistente.

3. OTLP empresarial

La ruta de despliegue en toda la organización. Configura el endpoint de telemetría en managed-settings.json y se aplica automáticamente a cada equipo de desarrollador. Es la preferida para despliegues de más de 50 desarrolladores o para cualquier proyecto en el que importen la consistencia y el control central.

// Añade esto a tu managed-settings.json
{
  "telemetry": {
    "enabled": true,
    "otlpEndpoint": "https://otel.your-backend.com"
  }
}

Despliégalo antes de que los desarrolladores instalen Claude Code. La configuración de telemetría en managed-settings.json no puede ser sobrescrita por los desarrolladores individuales. Es la ruta adecuada para cualquier despliegue de nivel empresarial.

El readout del día 30

Cuatro pasos desde los datos sin procesar hasta el briefing para el champion

El readout no es un volcado de datos. Es una conversación estructurada que responde a una sola pregunta: ¿justifica el despliegue la expansión? El orden de los pasos importa. Los datos sin encuadre pierden la sala.

flowchart LR
    R1["1. Fijar baselines (día 1 o antes del kickoff)"] --> R2["2. Extraer datos de la semana 4 de la Admin Console"]
    R2 --> R3["3. Estructurar el scorecard"]
    R3 --> R4["4. Informar al champion"]

1. Fijar baselines (día 1 o antes del kickoff)

Captura las métricas de velocidad de los desarrolladores antes de que comience el despliegue: tickets cerrados por sprint, PR por desarrollador y tiempo autorreportado en tareas repetitivas. Si pierdes esta ventana, anótalo en el readout y márcalo como recomendación para el próximo despliegue. Un readout sin baseline puede defender el caso, pero no puede construir la comparación antes/después.

2. Extraer datos de la semana 4 de la Admin Console

Ve a Settings > Analytics. Extrae el DAU, las sesiones por usuario y la cohorte de retención de la semana 2 del periodo de cuatro semanas. Exporta a CSV si el cliente necesita distribuir los datos internamente. Cruza cost.usage de OTel si el pipeline se desplegó para tener datos de costo por desarrollador.

3. Estructurar el scorecard

Califica cada una de las cuatro métricas como Verde (igual o por encima del objetivo), Ámbar (a menos de un 15% del objetivo) o Rojo (por debajo del umbral). Escribe una frase por métrica que explique qué significa el número y qué lo impulsa. No presentes números sin contexto: un champion que ve “DAU: 52%” sin más información no sabrá si es bueno o malo.

4. Informar al champion

Empieza con el titular: el estado general, Verde, Ámbar o Rojo. Continúa con la métrica que respalda con más fuerza la decisión de expansión. Guarda el detalle para las preguntas. Si alguna métrica está en Rojo, llega con un plan de remediación, no solo con un número. El champion debe salir de la sala sabiendo qué sigue, no solo qué pasó.

Comprueba tu comprensión

Escenario · El crunch del día 28

Día 28. El briefing para el champion es en dos días y los datos ya están listos. Hay cuatro decisiones que tomar antes de entrar a esa sala. Ocho puntos en total. Cada opción vale 2 puntos (mejor), 1 (parcial) o 0 (incorrecta). Elige una opción en cada decisión y compara tu criterio con la explicación.

Decisión 1 de 4 · Extraer datos de adopción

Necesitas las cifras de adopción de esta semana para el briefing. El pipeline de OTel no se desplegó. ¿A dónde vas primero?

• A. Admin Console > Analytics
• B. Pedir al líder de desarrollo un recuento de usuarios activos
• C. Configurar ahora el exportador Prometheus de OTel y extraer los datos de ahí

Ver respuesta

Mejor opción: A (2 puntos). Parcial: C (1 punto). Incorrecta: B (0 puntos).

A. Admin Console > Analytics (mejor, 2 puntos). El dashboard sin código disponible para todos los Owner. DAU, sesiones, costo y utilización de asientos están ahí sin configuración adicional.

Retroalimentación: Correcto. La Admin Console está disponible para todos los Owner de inmediato, sin necesidad de pipeline. Settings > Analytics es el camino más rápido hacia los datos de DAU, sesiones, costo y asientos para un readout que está a 48 horas.

B. Pedir al líder de desarrollo un recuento de usuarios activos (incorrecta, 0 puntos). El líder de desarrollo tiene una buena idea de quién usa Claude Code activamente en el equipo.

Retroalimentación: Los recuentos del líder de desarrollo son estimaciones, no datos. Un briefing para el champion basado en estimaciones no resistirá una pregunta del CFO. La Admin Console tiene datos de adopción verificados disponibles ahora mismo.

C. Configurar ahora el exportador Prometheus de OTel y extraer los datos de ahí (parcial, 1 punto). Tener el pipeline listo antes del readout significa que el cliente tendrá un dashboard permanente antes de la sesión.

Retroalimentación: Configurar OTel ahora es útil en dirección, pero es la prioridad equivocada a 48 horas de un readout. La Admin Console tiene todo lo que necesitas para este briefing. Guarda la configuración de OTel como recomendación para la fase de expansión.

Decisión 2 de 4 · Interpretar las cifras

La Admin Console devuelve DAU 48%, sesiones por usuario 1.6 al día, retención de la semana 2 84%. El pipeline de OTel devuelve costo por desarrollador $3.10 al día. Los objetivos eran 60% de DAU, 2 a 3 sesiones y 80% de retención. ¿Cómo lo describes en el scorecard?

• A. Ámbar en DAU y sesiones. Verde en retención y costo. Presenta un plan de impulso para las brechas.
• B. Verde en general. La retención es sólida y el costo es bajo. Las cifras cuentan una buena historia.
• C. Rojo. El DAU está 12 puntos por debajo del objetivo en la semana 4. Recomienda extender el piloto antes de expandir.

Ver respuesta

Mejor opción: A (2 puntos). Parcial: C (1 punto). Incorrecta: B (0 puntos).

A. Ámbar en DAU y sesiones. Verde en retención y costo. Presenta un plan de impulso para las brechas. (mejor, 2 puntos). Dos métricas están por detrás del objetivo, dos son sólidas. Nombra la brecha, explícala y llega con un plan para cerrarla antes de la expansión.

Retroalimentación: Lectura correcta. El DAU al 48% se queda 12 puntos por debajo del objetivo de 60%. Las sesiones con 1.6 quedan por debajo del rango de 2 a 3. Ambas son Ámbar. Pero la retención al 84% supera el umbral del 80% y el costo de $3.10 va bien encaminado. El scorecard honesto nombra las brechas y llega con un plan. Eso es lo que consigue la siguiente reunión.

B. Verde en general. La retención es sólida y el costo es bajo. Las cifras cuentan una buena historia. (incorrecta, 0 puntos). El piloto está sano. Lidera con lo que funciona y presenta el DAU como margen de crecimiento.

Retroalimentación: El instinto de proteger la narrativa es comprensible, pero el champion preguntará directamente por el DAU. Llamarlo Verde cuando está 12 puntos por debajo del objetivo daña la credibilidad más rápido que nombrar la brecha y presentar un plan de remediación.

C. Rojo. El DAU está 12 puntos por debajo del objetivo en la semana 4. Recomienda extender el piloto antes de expandir. (parcial, 1 punto). Perder el objetivo principal de adopción tan avanzado el piloto es una señal seria. Es mejor retrasar la expansión que escalar un despliegue que no está funcionando.

Retroalimentación: Un Rojo solo por el DAU exagera el problema. La retención es Verde y el costo es sano. Rojo implica que el piloto fracasó; este piloto tiene dos métricas sólidas y dos que necesitan un plan de impulso. Ámbar es la lectura precisa y defendible.

Decisión 3 de 4 · Baselines que faltan

El cliente no capturó métricas de velocidad de los desarrolladores antes del despliegue. El patrocinador pide una comparación antes/después. ¿Cómo lo gestionas?

• A. Presentar el progreso absoluto frente a los cuatro objetivos del scorecard. Señalar la falta de baseline y recomendar capturarlo en el próximo despliegue.
• B. Pedir a los desarrolladores que estimen su velocidad previa al despliegue y usar esas estimaciones como baseline.
• C. Retrasar el readout una semana para que los desarrolladores trabajen sin Claude Code y crear un baseline retrospectivo.

Ver respuesta

Mejor opción: A (2 puntos). Parcial: B (1 punto). Incorrecta: C (0 puntos).

A. Presentar el progreso absoluto frente a los cuatro objetivos del scorecard. Señalar la falta de baseline y recomendar capturarlo en el próximo despliegue. (mejor, 2 puntos). Los datos disponibles son fiables. Construye el readout en torno a lo que puedes defender y marca la recomendación de baseline como una mejora de proceso para la expansión.

Retroalimentación: El movimiento correcto. Un readout construido sobre datos del scorecard verificados es defendible. Reconocer el baseline que falta y recomendarlo para el próximo despliegue muestra madurez de proceso. Presentar estimaciones inventadas como baselines es peor que no tener baseline.

B. Pedir a los desarrolladores que estimen su velocidad previa al despliegue y usar esas estimaciones como baseline. (parcial, 1 punto). La memoria de los desarrolladores es imperfecta, pero es mejor que nada. Promediadas en el equipo, las estimaciones dan una aproximación razonable del punto de partida.

Retroalimentación: La memoria de los desarrolladores produce estimaciones con mucha varianza. Si esas estimaciones se presentan como baselines en una conversación con el CFO y se cuestionan, todo el readout pierde credibilidad. Usa datos verificados y anota la brecha.

C. Retrasar el readout una semana para que los desarrolladores trabajen sin Claude Code y crear un baseline retrospectivo. (incorrecta, 0 puntos). Un retraso de una semana es un costo pequeño para tener datos antes/después limpios. El champion lo valorará como rigor.

Retroalimentación: Retirar a los desarrolladores de Claude Code durante una semana para generar un baseline retrospectivo no es práctico y tampoco producirá datos limpios. La ventana para capturar un baseline previo al despliegue se cerró el día 1. Trabaja con lo que tienes.

Decisión 4 de 4 · La pregunta sobre el ROI

El champion pregunta: “Esto parece razonable, pero ¿cómo justifico el costo anual ante el CFO?” El DAU es 48%, las sesiones 1.6 al día y el costo $3.10 por desarrollador al día. ¿Cuál es tu enfoque?

• A. Anclar el costo por sesión frente al costo del tiempo de desarrollo. Con $3.10 al día y 1.6 sesiones, son menos de $2 por sesión de trabajo asistido por IA.
• B. Los desarrolladores que usan Claude Code 1.6 veces al día son más productivos. El costo se paga solo con las ganancias de velocidad.
• C. El ROI es difícil de medir con precisión en esta etapa. Necesitamos más datos antes de hacer un argumento de costo.

Ver respuesta

Mejor opción: A (2 puntos). Parcial: B (1 punto). Incorrecta: C (0 puntos).

A. Anclar el costo por sesión frente al costo del tiempo de desarrollo. (mejor, 2 puntos). Compara el costo con el costo por hora completamente cargado de un desarrollador. El CFO hará esa cuenta. Tu tarea es darle los insumos correctos, no la conclusión.

Retroalimentación: El encuadre correcto. Menos de $2 por sesión asistida por IA frente a una tarifa diaria de desarrollador que suele rondar los $400 a $800 totalmente cargada es una proporción con la que el CFO puede trabajar. Dales los insumos. La cuenta es lo bastante sencilla como para que la hagan ellos mismos, lo que resulta más persuasivo que hacerla tú por ellos.

B. Los desarrolladores que usan Claude Code 1.6 veces al día son más productivos. (parcial, 1 punto). La productividad es el encuadre adecuado. Claude Code reduce el tiempo dedicado a tareas repetitivas y acelera los ciclos de revisión de código y documentación.

Retroalimentación: La productividad es la categoría correcta, pero el argumento necesita números. Decir “se paga solo” sin un ancla le entrega al CFO la conclusión sin la evidencia. Relaciónalo con el costo por sesión frente al costo de tiempo del desarrollador para hacerlo concreto.

C. El ROI es difícil de medir con precisión en esta etapa. (incorrecta, 0 puntos). Ser riguroso sobre lo que podemos y no podemos afirmar generará más confianza en el CFO que exagerar el caso.

Retroalimentación: Aplazar la pregunta del ROI en la sala cuesta la decisión de expansión. Los datos que tienes son suficientes para plantear un argumento de costo por sesión. El champion pregunta porque necesita argumentos para el CFO, no porque dude de ti.

Ver debrief y texto de cierre

La fuente asigna un texto de cierre según la puntuación final, sobre un máximo de 8 puntos.

Listo para el readout (7 u 8 puntos). Acudiste a la fuente de datos correcta, leíste el scorecard con precisión, gestionaste el baseline que falta de forma adecuada y anclaste la conversación sobre el ROI en cifras defendibles. Así es un flujo de trabajo limpio para el readout del día 30.

Sólido, con exposición (4 a 6 puntos). El readout se sostendría, pero al menos una decisión dejó una brecha que el champion podría cuestionar. La precisión del scorecard y el encuadre del ROI son los dos puntos donde la vaguedad cuesta la conversación de expansión. Conviene revisar los temas en los que se perdieron puntos.

Conviene volver a repasarlo (0 a 3 puntos). Algunas decisiones que causarían problemas en el briefing para el champion. Revisa la pila de medición en el tema 1, la lógica del scorecard en el tema 2 y la secuencia del readout del día 30 en el tema 4, y luego repite el escenario.

Artefacto del curso · Aporte de la lección 2

OTel Configuration + Dashboard Spec

Ya conoces qué herramienta da datos de adopción sin configuración y qué métricas se incluyen en el scorecard del día 30. Este aporte es la especificación del dashboard: los paneles que tu cliente usará para el readout del día 30. La capa de costos se añade en la lección 6.

1. Define dos paneles: sesiones por desarrollador y número de desarrolladores activos. Para cada uno, indica la fuente de datos (Admin Console o pipeline de OTel), el atributo de agrupación y la ventana de reporte (diaria o semanal).
2. Añade un tercer panel para el volumen de tokens por modelo. Indica en qué atributo de modelo viaja la métrica y qué te dice sobre la distribución de la carga de trabajo.
3. Marca qué paneles requieren que OTel esté desplegado y cuáles están disponibles desde la Admin Console el día 1. El cliente necesita saber antes del kickoff si existe la brecha de datos.

Nota sobre la fuente de datos: la Analytics API de Anthropic expone datos de uso agregados de Claude en general (claude.ai). En los despliegues de Claude Code, las métricas de sesiones y de costo llegan a través del pipeline de OTel o de la Admin Console, no de la Analytics API. Usa OTel o la Admin Console como fuente en tu especificación de dashboard.

Ideas clave

Los datos están ahí. Ahora ve a por la sala.

• La Admin Console es la primera parada para datos de adopción sin configuración.
• Las cuatro métricas del scorecard del día 30 son DAU, sesiones por usuario, retención de la semana 2 y costo por desarrollador.
• Para desplegar OTel a escala de organización, usa OTLP con managed-settings.json.
• Estructura el readout con el estado general primero, la métrica que respalda la expansión después y un plan de remediación si algo está en Rojo.

Los datos de adopción están en el scorecard. La lección 3 cubre la infraestructura de registros de auditoría y de compliance que respalda las revisiones de seguridad, los cuestionarios de cumplimiento y los requisitos de residencia de datos.

Siguiente: Compliance API para auditoría y supervisión