El pixel — tu medición, honesta
No es un canal de tráfico: es el instrumento que hace legibles a todos los demás. Un endpoint mínimo (view/click/sale/report) en tu landing, con estas propiedades no negociables:
Diseño honesto
- Por ángulo, no en bloque: cada producto-ángulo tiene sus vistas/clics/ventas — el criterio de 8 · Criterio de éxito antes de lanzar se evalúa por ángulo.
- La referencia vive en el reporte:
/reportpublica el umbral contra el que se mide (ventana, conversión mínima) — el instrumento recuerda el criterio. nullcuando no hay dato, nunca 0 inventado: "sin datos de ventas" es un estado distinto de "0 ventas".- Ventas de la casa etiquetadas desde antes de la primera venta real (Fase 3 · Venta).
- Fuente de cada vista (
porRefVista): sin esto no sabés qué canal trabaja. La medición real mostró que casi todo el tráfico era interno — dato incómodo y valiosísimo.
La grieta que sólo aparece al leer el reporte contra su propio código
El reporte puede publicar una referencia que no usa. /report publica ventanaDias: 7 junto a los números — pero computa sobre los contadores :total históricos, que nunca se acotaron a 7 días [testeado: auditoría del instrumento, 2026-08-30]. O sea: el criterio de éxito de 8 · Criterio de éxito antes de lanzar se estuvo evaluando contra todo el histórico, no contra la ventana declarada — el gate era inmedible tal como estaba definido, y nadie lo vio porque el reporte mostraba la referencia correcta al lado del número equivocado.
La lección es más incómoda que el bug: publicar la referencia junto al dato no garantiza que el dato se haya computado contra ella. Un instrumento que muestra su criterio se ve más honesto que uno que no — y esa apariencia es exactamente lo que impide que alguien lo verifique. Si publicás una ventana, que el probe demuestre que el número cambia cuando la ventana cambia.
Las grietas que enseñó (ver El registro de grietas)
- G5 — contaba el tráfico de QA como tráfico real: el equipo probando la landing inflaba las vistas. Fix: filtro de tráfico propio, con fecha desde la cual aplica (todo lo anterior queda contaminado y etiquetado).
- El filtro se puso en las vistas y NO en los clics — el cliente ni siquiera manda la marca de interno al endpoint de clic, y el endpoint no la leería
[testeado: clic marcado interno contó como real, 2026-08-30]. Media instrumentación se siente como instrumentación completa: la vista filtrada y el clic sin filtrar producen un CTR con numerador sucio y denominador limpio, que es peor que dos series sucias — el error no se cancela, se amplifica. Regla: un filtro se aplica a todos los eventos de la cadena o a ninguno. - G6 — el cero estructural:
clicks a etsy: 0publicado en el mismo formato que los ceros reales, cuando ninguna página podía disparar ese clic. Fix: un chequeo automático de "¿existe al menos una página capaz de disparar este evento?" — Test de rechazo aplicada a un contador.
Trampas de implementación medidas
- Cloudflare (y CDNs similares) devuelven 403 a requests sin User-Agent — tu propio probe puede parecer bot. El probe manda UA propio e identificable (medido: mismo GET, curl 200 / urllib sin UA 403).
- Timestamps del lado del cliente se desordenan bajo concurrencia — el orden lo pone el servidor. (Medido en la bitácora del nodo, no en el pixel: el pixel evita el problema usando contadores, sin timestamps por evento.)
- Contadores get+put sobre un KV no son atómicos, y la pérdida es brutal, no marginal. Se leyó primero en el código (
click.js::bump()hace get→sumar→put) y se midió después: 11 POSTs, 10 de ellos concurrentes, dejaron el contador en 2 — ~90% perdido en ráfaga, estable 4 minutos después, así que no es lag de propagación[testeado: click sintético concurrente contra producción, 2026-08-30]. Consecuencia para leer cualquier tablero: todo contador es una cota inferior, y cuanto más viral el tráfico (que es justo cuando querés medir), más subcuenta. No se parchea con cuidado: o el contador es atómico (Durable Object / D1) o el subconteo se declara al lado del número.