Conectar la analítica a tu stack: 5 patrones de integración con la API

La analítica se vuelve exponencialmente más útil en el momento en que sale del panel de control y empieza a alimentar el resto de tu stack. Aquí tienes cinco patrones de integración concretos —desde un resumen diario con un solo script hasta un almacén de BI completo— con la estructura de código para cada uno.

El panel es el punto de partida, no el destino

Toda herramienta de analítica incluye un panel de control, y para la mayoría de los equipos ahí acaba el uso. Entras, miras los números, sales. Los datos quedan atrapados en la interfaz.

Es una oportunidad perdida. La analítica se vuelve significativamente más valiosa cuando deja de ser un lugar separado al que visitas y se convierte en una señal que fluye hacia los sistemas que ya usas: el Slack de tu equipo, los informes de business intelligence, tu CRM, las alertas operativas. El panel pasa a ser la vista por defecto, pero ya no es la única.

La clave es una API pública con autenticación sencilla por clave. Una vez que la tienes, cada uno de los patrones que siguen es un pequeño script de distancia.

Patrón 1: el resumen semanal de Slack del lunes por la mañana

La integración más sencilla y de mayor impacto. Cada lunes a las 9:00 un script extrae las estadísticas de la semana anterior, las formatea en un mensaje breve y lo publica en un canal de Slack.

#!/bin/bash
# weekly-digest.sh — run via cron Mondays 09:00

LOGLY_KEY=$LOGLY_KEY
SITE=my-blog
WEBHOOK=$SLACK_WEBHOOK

stats=$(curl -sH "Authorization: Bearer $LOGLY_KEY" \
  "https://app.logly.uk/api/sites/$SITE/stats?days=7")

pv=$(echo "$stats" | jq -r '.totals.pageviews')
prev=$(echo "$stats" | jq -r '.prev_totals.pageviews')
delta=$(awk "BEGIN { print (($pv - $prev) / $prev) * 100 }")

curl -X POST -H 'Content-Type: application/json' \
  -d "{\"text\":\"📊 Last 7 days: *$pv pageviews* (${delta}% vs prev week)\"}" \
  "$WEBHOOK"

Veinte líneas de bash, cero mantenimiento continuo, los datos llegan donde tu equipo ya está. Es el tipo de integración que se construye en 30 minutos y funciona de manera fiable durante años.

Por qué esto importa más de lo que parece

La mayoría de los equipos tienen el problema de "deberíamos mirar más la analítica". La solución no es más disciplina, sino poner los números relevantes delante de las personas de forma automática, en el canal que ya consultan. Un resumen del lunes en #marketing o #producto cambia la conversación de "debería entrar al panel" a "qué interesante que el tráfico subió, ¿alguien sabe por qué?". Ese pequeño cambio de comportamiento es lo que convierte la analítica de algo que tienes en algo que usas.

Patrón 2: combinar tráfico con ingresos en una hoja de cálculo

Tienes un producto SaaS y quieres saber qué canales de adquisición generan realmente clientes de pago: no solo registros, no solo pruebas, sino clientes de pago. Ningún panel puede responder esto porque los datos viven en tres lugares: el tráfico en tu analítica, los registros en tu base de datos de producto y las suscripciones en Stripe.

Una extracción programada en Google Sheets los une:

// Google Apps Script — runs daily, appends to a tab
function updateAnalyticsRow() {
  const url = "https://app.logly.uk/api/sites/my-saas/stats?days=1";
  const r = UrlFetchApp.fetch(url, {
    headers: { Authorization: "Bearer " + PropertiesService.getScriptProperties().getProperty('LOGLY_KEY') }
  });
  const data = JSON.parse(r.getContentText());
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Daily traffic');
  const today = Utilities.formatDate(new Date(), 'UTC', 'yyyy-MM-dd');
  sheet.appendRow([today, data.totals.pageviews, data.totals.sessions, data.totals.visitors]);
}

Añade extracciones similares para registros (desde tu exportación de BD) y suscripciones (desde la API de Stripe). Tres pestañas en una misma hoja, dos días de trabajo. Ahora tu actualización para inversores tiene un gráfico titulado "Ingresos por canal de adquisición" que ningún panel individual podría haber generado.

Patrón 3: almacén de BI con Metabase, Looker Studio o Superset

Cuando el enfoque de la hoja de cálculo empieza a crujir bajo su propio peso, el siguiente paso es un almacén en condiciones. Postgres, BigQuery, DuckDB o lo que prefiera tu equipo. El patrón es el mismo independientemente de la base de datos: programar una extracción diaria, añadir a una tabla y apuntar una herramienta de BI a ella.

# Python — runs daily, appends to Postgres
import os, requests, psycopg2, csv, io

LOGLY_KEY = os.environ['LOGLY_KEY']
DB = psycopg2.connect(os.environ['DATABASE_URL'])

r = requests.get(
    'https://app.logly.uk/api/sites/my-site/export',
    params={'type': 'daily', 'days': 2},
    headers={'Authorization': f'Bearer {LOGLY_KEY}'},
)
reader = csv.DictReader(io.StringIO(r.text))

with DB.cursor() as cur:
    for row in reader:
        cur.execute("""
          INSERT INTO analytics_daily (date, pageviews, sessions, visitors, avg_duration_s, bounce_rate)
          VALUES (%(date)s, %(pageviews)s, %(sessions)s, %(visitors)s, %(avg_duration_s)s, %(bounce_rate)s)
          ON CONFLICT (date) DO UPDATE SET
            pageviews = EXCLUDED.pageviews,
            sessions  = EXCLUDED.sessions
        """, row)
DB.commit()

El endpoint de exportación CSV hace el trabajo pesado: una sola petición HTTP, todos los agregados diarios, analizados con la librería estándar de Python. Una vez que los datos están en Postgres, cualquier herramienta de BI puede consultarlos. Ya no dependes de lo que el panel de analítica decida visualizar.

Patrón 4: definición programática de embudos para variantes de tests A/B

Realizas experimentos. Cada variante puede necesitar su propio embudo: "¿los usuarios de hero_v2 avanzaron de /pricing a /signup a una tasa mayor que los de hero_v1?". Crear estos embudos manualmente en el panel antes de cada test genera fricción. La API te permite automatizarlo.

// Node.js — creates one funnel per variant when a test starts
const variants = ['control', 'urgency', 'social_proof'];

for (const v of variants) {
  await fetch('https://app.logly.uk/api/sites/my-site/funnels', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.LOGLY_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      name: `Hero test — ${v}`,
      steps: [`/?variant=${v}`, '/pricing', '/signup', '/dashboard'],
    }),
  });
}

Combinado con el etiquetado de la variante en la URL o como evento personalizado, obtienes datos de embudo por variante sin configuración manual. Cuando el test termina, un segundo script puede obtener los resultados de los tres embudos, publicar el ganador en Slack y limpiar las definiciones de embudos.

Patrón 5: alertas operativas sobre anomalías de tráfico

Quieres saber si el tráfico cae un 50 % de la noche a la mañana, porque eso probablemente significa que tu sitio está caído, el DNS falló o el tracker dejó de funcionar. Un script de sondeo sencillo que comprueba la actividad reciente permite detectarlo automáticamente.

# Python — runs every 15 min via cron
import requests, os, sys

key = os.environ['LOGLY_KEY']
r = requests.get(
    'https://app.logly.uk/api/sites/my-site/active',
    headers={'Authorization': f'Bearer {key}'},
)
active = r.json()['active']

if active == 0:
    requests.post(os.environ['PAGERDUTY_WEBHOOK'], json={
        'incident_key': 'logly-zero-traffic',
        'description': 'Logly reports zero active visitors — possible site outage',
    })
    sys.exit(1)

Combínalo con un umbral de referencia (mediana de visitantes activos para esa hora de la semana) y tendrás detección básica de anomalías sin montar una infraestructura de monitorización real. Para la mayoría de los equipos pequeños, este es el nivel de visibilidad operativa adecuado: sin sobreingeniería, pero detecta los peores modos de fallo.

Qué hace buena a una API de analítica

No todas las afirmaciones de "tenemos API" son iguales. Vale la pena verificar antes de comprometerse con un stack:

1. Un único mecanismo de autenticación canónico. Una clave bearer de larga duración supera a OAuth o a los tokens rotativos para trabajos servidor a servidor. Deberías poder escribir una llamada curl en un minuto.
2. Los mismos endpoints que el panel. Si la API pública es un subconjunto separado de los datos que ve el panel, tienes dos productos que mantener sincronizados. Un backend compartido único significa que cualquier cosa que veas en la interfaz puedes extraerla mediante la API.
3. Formatos estándar de salida. JSON para consultas, CSV para datos masivos, marcas de tiempo ISO, códigos de país estándar. Sin serialización propietaria, sin XML, sin SDKs obligatorios.
4. Claves revocables con señal de uso. Deberías poder revocar una clave comprometida al instante y, idealmente, ver cuándo se usó por última vez para poder limpiar integraciones olvidadas.

Empieza por algo pequeño

La trampa de las integraciones es imaginarse la arquitectura completa antes de publicar la primera. No lo hagas. El camino que funciona para casi todos los equipos:

1. Semana 1: implementa el Patrón 1: un resumen semanal en Slack. Veinte líneas de bash.
2. Mes 2: añade el Patrón 2 si necesitas unir datos entre sistemas. Una hoja de Google con tres extracciones programadas.
3. Trimestre 2: migra al Patrón 3 si la hoja empieza a hacer aguas. Almacén + herramienta de BI.
4. Según se necesite: añade los Patrones 4 y 5 cuando casos de uso específicos lo justifiquen.

Cada paso se apoya en el patrón del anterior. El script de bash se convierte en un script de Python, que pasa a ser un job programado en tu plataforma de datos. Mismo endpoint, misma autenticación, sofisticación creciente.