Datos y contexto: fuentes, permisos, sesgos y diseño de la recopilación

Tipos de datos y qué implican para tu análisis

Antes de pedir “los datos”, conviene identificar qué forma tienen y qué esfuerzo requerirá convertirlos en una tabla analizable. En la práctica, el tipo de dato condiciona herramientas, costos, calidad y riesgos.

Datos estructurados

Viven en tablas con filas/columnas y tipos definidos (número, fecha, categoría). Suelen ser los más fáciles de consultar y auditar.

• Ejemplos: ventas (ticket_id, fecha, producto, precio), inventario, pagos, catálogo de clientes.
• Ventajas: consistencia, validaciones, joins, trazabilidad relativamente alta.
• Riesgos típicos: claves mal definidas, duplicados, cambios de esquema sin aviso.

Datos semiestructurados

Tienen estructura flexible (campos opcionales, anidados). Se almacenan como JSON, XML, eventos con propiedades variables.

• Ejemplos: eventos de analítica web/app, respuestas de APIs, documentos JSON en bases NoSQL.
• Ventajas: capturan contexto rico (propiedades del evento, dispositivo, campaña).
• Riesgos típicos: campos faltantes, versiones mezcladas, nombres inconsistentes (e.g., userId vs user_id).

Datos no estructurados

No encajan naturalmente en filas/columnas: texto libre, imágenes, audio, video, PDFs. Su análisis suele requerir extracción (NLP, visión, OCR) y un diseño cuidadoso de etiquetas/metadatos.

• Ejemplos: tickets de soporte, reseñas, correos, grabaciones de llamadas, fotos de productos.
• Ventajas: contienen señales cualitativas valiosas (motivos, emociones, temas).
• Riesgos típicos: privacidad, dificultad para estandarizar, sesgos por idioma/estilo de escritura.

Fuentes típicas de datos (y qué preguntas responden mejor)

Bases transaccionales (ERP/POS/pagos)

Registran hechos operativos: compras, devoluciones, movimientos. Suelen ser la “fuente de verdad” para métricas financieras y operativas.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

• Útiles para: ingresos, frecuencia de compra, cohortes por primera compra, devoluciones.
• Precaución: una “venta” puede tener estados (autorizada, capturada, cancelada). Define qué estado cuenta.

Logs y eventos (web/app/servidor)

Capturan comportamiento: páginas vistas, clicks, errores, latencia, eventos de producto.

• Útiles para: funnels, activación, retención, análisis de journeys.
• Precaución: ad blockers, pérdidas de eventos, duplicados por reintentos, cambios de instrumentación.

CRM y atención al cliente

Información de relación: contactos, oportunidades, segmentación, interacciones, tickets.

• Útiles para: churn, satisfacción, motivos de contacto, performance comercial.
• Precaución: campos manuales con valores inconsistentes; “estado” puede ser subjetivo.

Encuestas

Capturan percepciones y atributos no observables en transacciones (intención, satisfacción, motivos).

• Útiles para: NPS/CSAT, drivers de satisfacción, investigación de mercado.
• Precaución: sesgo de respuesta, preguntas mal formuladas, muestras no representativas.

APIs (internas o externas)

Permiten enriquecer: geocodificación, clima, datos demográficos, catálogos, redes publicitarias.

• Útiles para: features adicionales, validación cruzada, automatización de ingestión.
• Precaución: límites de uso, cambios de contrato, licencias, latencia, costos por llamada.

Criterios para evaluar viabilidad del dato (checklist práctico)

Antes de comprometer un análisis, evalúa si el dato es accesible, legalmente utilizable y suficientemente bueno para responder la pregunta. Esta revisión evita proyectos que se caen por permisos, privacidad o calidad.

1) Acceso (técnico)

• ¿Dónde vive? base SQL, data warehouse, archivos, herramienta SaaS.
• ¿Cómo se consulta? credenciales, VPN, API key, conectores.
• ¿Hay entorno de análisis? sandbox, vistas, límites de extracción.

2) Permisos (organizacionales)

• Dueño del dato: quién autoriza el uso (Finanzas, Producto, Legal, Seguridad).
• Propósito permitido: analítica interna, marketing, automatización, entrenamiento de modelos.
• Principio de mínimo privilegio: solicita solo lo necesario (campos y periodo).

3) Privacidad y cumplimiento

• Datos personales: identifica PII (email, teléfono, documento, IP, ubicación precisa).
• Base legal/consentimiento: ¿se recolectó con el consentimiento adecuado para este uso?
• Minimización: usa seudonimización (IDs), hashing, agregación, o elimina campos sensibles.
• Retención: cuánto tiempo se puede almacenar y quién accede.

4) Representatividad

• ¿A quiénes incluye/excluye? solo usuarios logueados, solo clientes activos, solo quienes responden encuestas.
• Cobertura: regiones, canales, dispositivos, segmentos.
• Riesgo: conclusiones que no generalizan al universo objetivo.

5) Periodicidad y frescura

• Frecuencia: tiempo real, diario, semanal, mensual.
• Latencia: retraso entre evento y disponibilidad (e.g., 24–72h).
• Estabilidad: ¿cambia la definición o el pipeline con frecuencia?

6) Trazabilidad y auditabilidad

• Linaje: de dónde viene cada campo y cómo se transforma.
• Versionado: cambios de esquema y definiciones (por ejemplo, “usuario activo”).
• Calidad: reglas de validación, tasas de nulos, duplicados, outliers.

Plantilla rápida de evaluación (tabla)

Sesgos desde el origen: cómo aparecen y cómo mitigarlos

Muchos sesgos no se “arreglan” con modelos: nacen en la forma en que se recolectan los datos. Identificarlos temprano evita insights engañosos.

Sesgo de selección

Ocurre cuando la muestra disponible no representa al universo que quieres estudiar.

• Ejemplos: encuesta respondida solo por clientes muy satisfechos o muy molestos; análisis de uso basado solo en usuarios logueados; datos de churn solo para quienes cancelan por la web (no por call center).
• Señales: tasas de respuesta bajas; segmentos ausentes; diferencias fuertes entre “observados” y “no observados”.
• Mitigación: diseñar muestreo (estratificado por segmento), combinar fuentes (web + call center), ponderar por distribución real, documentar el alcance (“aplica a usuarios logueados”).

Sesgo de medición

El dato existe, pero está mal medido: definiciones ambiguas, instrumentación incompleta, errores sistemáticos.

• Ejemplos: evento purchase se dispara antes de confirmación; “edad” autodeclarada con valores extremos; tiempos de sesión inflados por pestañas abiertas.
• Señales: saltos bruscos tras releases; valores imposibles; discrepancias entre sistemas (ventas en ERP vs analítica web).
• Mitigación: definir eventos con criterios claros, pruebas de instrumentación (QA), reconciliación entre fuentes, reglas de validación (rangos, unicidad), monitoreo de métricas de calidad.

Sesgo de supervivencia

Analizas solo a quienes “sobreviven” en el proceso y excluyes a quienes abandonan antes, distorsionando conclusiones.

• Ejemplos: evaluar satisfacción solo en usuarios activos; medir tiempo a conversión solo en quienes compraron; analizar desempeño de vendedores solo con quienes permanecen en el equipo.
• Señales: métricas “demasiado buenas”; ausencia de registros de abandono; cohortes incompletas.
• Mitigación: incluir eventos de abandono (drop-off), definir cohortes desde el inicio del funnel, usar ventanas de observación consistentes, tratar censura (usuarios aún no han tenido tiempo de convertir).

Diseño de la recopilación: guía paso a paso

Cuando el dato no existe (o existe incompleto), necesitas diseñar cómo se recolectará. El objetivo es capturar lo mínimo necesario con calidad, trazabilidad y permisos claros.

Paso 1: Traducir la pregunta a entidades y eventos

• Entidades: usuario, cuenta, pedido, sesión, ticket, dispositivo.
• Eventos: registro, login, vista de producto, agregar al carrito, compra, cancelación, contacto a soporte.
• Regla práctica: si no puedes dibujar el flujo de eventos, es difícil instrumentarlo.

Paso 2: Definir variables necesarias (y evitar “por si acaso”)

Clasifica variables en: identificadores, timestamps, atributos, contexto y resultado.

• Identificadores: user_id, order_id, session_id.
• Timestamps: event_time (con zona horaria), created_at, updated_at.
• Atributos: plan, país, canal, categoría de producto.
• Contexto: dispositivo, campaña, versión de app, fuente de tráfico.
• Resultado/label: compra, cancelación, resolución de ticket, satisfacción.

Paso 3: Elegir granularidad correcta

La granularidad es el “nivel de detalle” (por evento, por sesión, por usuario-día, por pedido). Elegir mal genera agregaciones irreversibles o datasets gigantes innecesarios.

• Regla práctica: recolecta al nivel más bajo útil (normalmente evento) y agrega después, siempre que privacidad y costo lo permitan.
• Ejemplo: para un funnel, necesitas eventos; para un reporte mensual, quizá basta usuario-mes.

Paso 4: Definir ventanas temporales y criterios de inclusión

• Ventana de observación: periodo para medir comportamiento (e.g., 30 días desde alta).
• Ventana de resultado: periodo para observar el outcome (e.g., churn en 60 días).
• Evita fuga de información: no uses variables que ocurren después del resultado para “predecirlo”.
• Consistencia: cohortes comparables (mismo tiempo de exposición).

Paso 5: Definir eventos de forma inequívoca

Un evento debe tener nombre, condición de disparo, propiedades y reglas anti-duplicado.

• Nombre: checkout_completed (mejor que purchase ambiguo).
• Condición: “se dispara cuando el pago está capturado y el pedido está confirmado”.
• Propiedades: order_id, amount, currency, payment_method.
• Idempotencia: incluir event_id único para deduplicar reintentos.

Paso 6: Crear un diccionario de datos (mínimo viable)

El diccionario reduce malentendidos y acelera análisis. Debe vivir cerca del dato (repositorio, wiki interna) y versionarse.

Paso 7: Gobernanza mínima para que el dato sea confiable

• Owner: responsable del dataset (aprueba cambios y responde dudas).
• SLAs: frecuencia de actualización y latencia esperada.
• Control de cambios: versionado de esquema y eventos; changelog.
• Calidad: tests automáticos (nulos, unicidad, rangos, volumen esperado).
• Accesos: roles y auditoría; separación entre datos crudos y curados.

Ejemplos: requisitos de datos derivados de una pregunta

Ejemplo 1: “¿Qué factores se asocian a la recompra en 30 días?”

Traducción a datos: necesitas identificar la primera compra, observar comportamiento posterior y marcar si hubo recompra dentro de 30 días.

• Entidades: usuario, pedido.
• Fuente principal: transaccional (pedidos) + logs (comportamiento) + CRM (segmento).
• Variables mínimas:
  • user_id, order_id, order_time, order_status, amount, product_category
  • first_order_time (derivada)
  • repurchase_30d (label derivada: 1 si existe otro pedido en (first_order_time, first_order_time+30d])
  • Contexto: acquisition_channel, country, device_type, app_version
• Granularidad: pedidos (para label) y eventos (para features como visitas, add_to_cart).
• Ventanas: features en 0–7 días post primera compra; label en 0–30 días.
• Sesgos a vigilar: supervivencia (usuarios con menos de 30 días de antigüedad), selección (solo canal app si faltan datos web).

Ejemplo 2: “¿Dónde se cae el funnel de checkout y por qué?”

Traducción a datos: necesitas eventos ordenados y consistentes para reconstruir el funnel y segmentar por contexto.

• Fuente principal: logs/eventos de producto.
• Eventos requeridos (definidos):
  • checkout_started (cuando se abre la pantalla de checkout)
  • shipping_submitted (cuando se valida dirección)
  • payment_submitted (cuando se envía pago)
  • checkout_completed (cuando el pedido queda confirmado)
  • checkout_error (con error_code)
• Propiedades clave: session_id, user_id (si aplica), cart_value, payment_method, device_type, country, app_version, network_type.
• Granularidad: evento.
• Reglas anti-duplicado: event_id único; deduplicación por (event_name, session_id, ventana de 5s) si no hay event_id.
• Sesgos a vigilar: medición (eventos faltantes por pérdidas), selección (usuarios con bloqueadores), definición (qué cuenta como “completado”).

Ejemplo 3: “¿Qué motivos impulsan los contactos a soporte?”

Traducción a datos: necesitas tickets con etiquetas consistentes o texto para clasificar, más metadatos de contexto.

• Fuentes: CRM/tickets + texto no estructurado (descripción) + transacciones (pedido asociado).
• Campos mínimos: ticket_id, created_at, channel (email/chat/phone), category (si existe), description_text, resolution_status, user_id seudonimizado, order_id (si aplica).
• Privacidad: aplicar redacción/mascarado de PII en texto (emails, teléfonos, direcciones) antes de análisis.
• Sesgos a vigilar: selección (solo ciertos canales registrados), medición (categorías manuales inconsistentes).

Mini-procedimiento operativo para pedir datos (lista de verificación)

1. Define el universo: ¿qué población y periodo?
2. Lista entidades y claves: ¿cómo se unen las tablas/eventos?
3. Especifica campos mínimos: IDs, timestamps, outcome, contexto.
4. Declara granularidad: evento/sesión/pedido/usuario-día.
5. Establece ventanas temporales: observación y resultado.
6. Revisa permisos y privacidad: minimiza PII; solicita accesos por rol.
7. Exige diccionario y definiciones: estados, eventos, reglas de negocio.
8. Planifica calidad: checks de nulos, duplicados, volumen, consistencia entre fuentes.
9. Documenta supuestos: qué queda fuera y qué sesgos pueden persistir.