Consulta repetida o dato nuevo: cómo separamos reintentos de demanda real
Una recarga no representa otro vehículo. Definimos una unidad estadística reproducible para agrupar reintentos sin conservar la patente ni inflar la demanda observada.
Por Marco Ferreiro ·
Una página puede registrar cinco solicitudes al servidor cuando una persona cree haber hecho una sola consulta. Puede haber una recarga, un reintento automático, un regreso desde otra pantalla y una nueva llamada a una fuente que demoró. Si sumáramos cada request, convertiríamos un problema técnico en demanda aparente.
También existe el error contrario: juntar búsquedas realmente distintas porque comparten una patente. Para evitar ambos extremos, primero definimos qué representa una fila de la estadística y qué evidencia permite agrupar eventos.
La unidad no es el request
Un request es una interacción técnica. Una consulta estadística es la sesión lógica que empieza cuando la persona confirma el dato y termina cuando el flujo concluye, se abandona o vence una ventana explícita.
Dentro de esa sesión puede haber varios intentos por jurisdicción. Los conservamos para medir estabilidad y cobertura, pero no los contamos como vehículos adicionales. Una respuesta parcial seguida de un reintento sigue perteneciendo a la misma unidad mientras conserve su identidad de sesión.
Esta distinción permite responder dos preguntas sin mezclarlas: cuántas consultas se iniciaron y cuánto trabajo técnico necesitó cada una.
Un identificador aleatorio, no la patente disfrazada
Al iniciar el flujo, el servidor asigna un identificador aleatorio. Su función es correlacionar los pasos de esa ejecución, de modo parecido a la propagación de contexto que describe la recomendación Trace Context del W3C. No contiene patente, DNI, resultado ni significado comercial.
No usamos un hash simple de la patente para reconocerla. Aunque un hash parezca anónimo, las combinaciones de un dominio vehicular son mucho menos numerosas que una contraseña robusta: alguien con el algoritmo puede generar candidatos y comparar resultados.
El token de sesión se crea con suficiente aleatoriedad, se limita al contexto necesario y vence. Si para una etapa se usa un resumen criptográfico, se aplica sobre ese identificador aleatorio con una clave rotativa, nunca directamente sobre el dominio.
Qué agrupamos como repetición
La regla sintética incluye estos eventos:
- doble envío causado por un botón presionado dos veces;
- recarga del navegador durante una ejecución en curso;
- reintento automático después de un timeout;
- reapertura del resultado dentro de la misma sesión;
- consulta a varias fuentes como parte de una única búsqueda.
Todos conservan el identificador original y no incrementan el contador de sesiones lógicas. Sí incrementan métricas operativas específicas, como intentos, latencia o recuperación.
Una nueva acción explícita de “consultar otra vez” crea una sesión nueva. Esa decisión evita suponer que la intención actual es igual a la anterior, incluso si el dato ingresado coincide.
Qué no intentamos unir
Si la persona vuelve días después, borra el almacenamiento del navegador o cambia de dispositivo, no existe evidencia suficiente para enlazar ambas visitas sin retener más información. Se cuentan como sesiones distintas.
Eso puede sobreestimar la cantidad de vehículos únicos. Lo declaramos como limitación en vez de ampliar silenciosamente el rastreo. La métrica se denomina “sesiones de consulta”, no “patentes únicas” ni “personas únicas”.
Tampoco unimos sesiones por IP, user agent o huella del dispositivo. Esos datos pueden ser compartidos, inestables e invasivos, y no prueban identidad de intención.
La ventana temporal debe quedar versionada
Una sesión no puede permanecer abierta para siempre. Definimos una ventana operativa basada en el flujo: mientras la ejecución esté activa y durante un margen corto para recuperar la vista, los eventos con el mismo identificador se agrupan.
La duración exacta forma parte de la versión de la regla. Cambiarla puede aumentar o reducir el total, por lo que no se comparan períodos calculados con versiones distintas sin recalcular la serie.
La zona horaria no decide la identidad, pero sí los cortes diarios. Para informes de Argentina, el límite se evalúa en America/Argentina/Buenos_Aires y queda registrado junto al período.
Una prueba con secuencias sintéticas
Antes de usar la regla sobre agregados, construimos fixtures sin datos reales. Un caso contiene inicio, dos requests duplicados, timeout, reintento exitoso y reapertura: debe producir una sesión y cinco eventos. Otro contiene dos inicios explícitos: debe producir dos sesiones.
También probamos eventos desordenados, identificadores vencidos, colisiones imposibles simuladas y pasos que llegan después del cierre. La salida publica sólo conteos esperados y la versión del algoritmo.
La prueba falla si un cambio en el código transforma un reintento en sesión nueva o une dos inicios independientes.
Cómo se publica un agregado
La tabla final se arma después de excluir bots, pruebas, shadow bans, errores administrativos y ejecuciones que nunca comenzaron realmente. Cada celda necesita al menos 100 sesiones válidas; por debajo de ese umbral se suprime, no se redondea ni se combina de manera oportunista.
La ficha metodológica acompaña período, criterios de inclusión, versión de regla, tamaño del denominador y exclusiones. No incluye patentes, identificadores de sesión, IP, correos ni payloads.
Si la unidad cambia, la nueva serie se presenta como una ruptura metodológica. Un porcentaje sin esa nota aparentaría una variación de mercado cuando quizá sólo cambió la deduplicación.
Demanda y carga técnica son métricas distintas
Una sesión con diez reintentos representa una unidad de demanda y una señal fuerte de inestabilidad. Por eso conservamos dos contadores separados en la capa agregada:
- sesiones lógicas válidas;
- eventos o intentos técnicos asociados.
La relación entre ambos ayuda a detectar fuentes degradadas sin inflar el número de búsquedas. Tampoco se interpreta automáticamente como diez costos facturables: esa definición pertenece a otro contrato.
Control de privacidad y retención
La Ley 25.326 obliga a pensar el tratamiento de datos más allá de la publicación. Reducir el resultado final no alcanza si el pipeline conserva identificadores innecesarios durante años.
Por eso el token vence, las claves rotan y los agregados se separan de los eventos crudos. El acceso operativo tiene una finalidad acotada y una retención definida. El reporte público no permite reconstruir una consulta individual.
Qué significa finalmente “una consulta”
En esta metodología, una consulta es una sesión lógica iniciada, no cada golpe al servidor ni un vehículo único para siempre. La definición acepta una limitación deliberada: no reconocer visitas separadas cuando hacerlo exigiría retener la patente o rastrear a la persona.
Ese límite vuelve la métrica más honesta. Permite analizar demanda realista, depurar reintentos y publicar agregados reproducibles sin transformar una medición editorial en un registro permanente de búsquedas.
Metodología
- Alcance
- Diseño y prueba de una regla de deduplicación con secuencias sintéticas de inicio, recarga, reintento técnico, reapertura y nueva búsqueda; no se publican resultados de producción.
- Unidad de análisis
- Una sesión lógica de consulta iniciada por el usuario, con todos sus intentos técnicos asociados dentro de la ventana definida.
- Cobertura
- Reglas verificadas con fixtures sintéticos, identificadores aleatorios y agregación que suprime cualquier celda con menos de 100 sesiones válidas.
Limitaciones
- Sin un identificador efímero vigente no intentamos vincular dos visitas, aunque hayan consultado el mismo vehículo.
- La elección de la ventana cambia el resultado y debe versionarse junto con cada agregado publicado.
- Esta nota describe la unidad estadística y no presenta una medición real de usuarios ni vehículos de Argentina.
Fuentes
- Trace Context — W3C Recommendation — W3C (consultada el )
- RFC 9562 — Universally Unique IDentifiers — RFC Editor (consultada el )
- Ley 25.326 de Protección de los Datos Personales — Argentina.gob.ar (consultada el )
Preguntas frecuentes
¿Dos consultas a la misma patente siempre se cuentan como una sola?
No. Se agrupan sólo los eventos de una misma sesión lógica dentro de una ventana definida. Si la persona inicia otra búsqueda o vuelve sin el identificador efímero, no afirmamos que sea el mismo caso.
¿Por qué no guardar un hash permanente de la patente?
Porque el espacio de patentes posibles es acotado y un hash simple puede probarse por fuerza bruta. La regla usa un identificador aleatorio de sesión que no se calcula a partir del dominio consultado.
¿Una recarga desaparece por completo de las métricas?
No. Puede medirse como evento operativo para estudiar errores o experiencia, pero no aumenta la cantidad de sesiones lógicas usada para estimar demanda de consultas.
Notas relacionadas
Cómo definimos una consulta completa antes de publicar estadísticas de multas.ar
Antes de convertir consultas operativas en porcentajes o rankings, exigimos cobertura identificable, respuestas comparables y controles que separen un resultado válido de un fallo técnico.
Qué campos demuestran que un portal terminó de responder
Una pantalla vacía puede ser un resultado, un paso intermedio o una carga truncada. Estado final, alcance, paginación, totales y hora de consulta permiten distinguir una respuesta completa de una apariencia de éxito.
Qué significa “última verificación” en una fuente de multas
La fecha indica cuándo se consultó una fuente y qué respuesta dio en ese momento. No es la fecha del acta, del pago ni una garantía de que no existan novedades en procesamiento.