La Web Necesita un Estándar de Punto de Vista: Por Qué los Conjuntos de Datos de la Web Pública Deben Registrar Dónde se Observaron los Datos

La procedencia de los datos ha respondido tradicionalmente a una pregunta fundamental: ¿de dónde proceden estos datos?

Para un registro de base de datos, eso puede significar el sistema de origen. Para datos de investigación, puede significar el experimento, el instrumento o el investigador que los generó. Para un conjunto de datos web, normalmente significa la página, el dominio, la API o la URL desde la que se recopiló la información.

Pero la web moderna plantea otra pregunta que se está volviendo igual de importante: ¿dónde se observaron los datos?

Un resultado de búsqueda visto en Londres puede diferir de la misma consulta en Nueva York. Un minorista puede mostrar un precio, un estado de inventario, una moneda o un vendedor diferentes según la ubicación del visitante. Un anuncio visible a través de un ISP puede no aparecer nunca a través de otro. Un visitante móvil puede recibir una página diferente a la de un visitante de escritorio.

Sin embargo, muchos conjuntos de datos de la web pública registran el resultado sin registrar las condiciones bajo las cuales se observó. Creemos que eso debe cambiar.

Para los datos web variables geográfica y contextualmente, creemos que el punto de observación debería convertirse en una parte estándar de la procedencia de los datos. Utilizamos el término procedencia de punto de observación para describir este contexto de observación.

Conclusiones clave

• La procedencia de datos tradicional a menudo registra el origen de los datos web sin registrar las condiciones bajo las cuales se observaron.
• La misma URL puede devolver precios, resultados de búsqueda, anuncios, inventario o contenido diferentes según la geografía, la identidad de red, el dispositivo y el estado de sesión.
• Un estándar útil de punto de observación puede comenzar con marca de tiempo, punto de observación solicitado, país y ciudad de salida validados, ASN u operador de red, contexto de cliente o dispositivo, estado de sesión, URL de destino y estado de validación.
• La configuración de proxy residencial puede formar parte del registro de procedencia porque ayuda a definir el entorno en el que se realizó una observación.
• Un perfil de procedencia específico para la web puede construirse sobre W3C PROV-O y alinearse con el énfasis de los principios FAIR en una procedencia detallada, en lugar de sustituir los marcos existentes.

La procedencia de los datos tiene un punto ciego: el contexto de observación

El concepto de procedencia de datos ya está bien establecido. El NIST Research Data Framework define la procedencia como el historial documentado de un activo de datos, incluyendo dónde, cuándo, cómo y por quién fue generado, adquirido o procesado. Los materiales de trabajo para el perfil de gobernanza y gestión de datos en desarrollo del NIST también enumeran la gestión de metadatos, la procedencia de datos y el linaje de datos entre sus actividades nocionales de gestión del ciclo de vida de los datos.

Este es un trabajo importante. La procedencia permite a las organizaciones establecer confianza, investigar errores, reproducir procesos y entender cómo ha cambiado la información. Pero la recopilación en la web pública introduce una distinción inusual.

Existe el origen de la información y existe la observación de la información. Supongamos que un conjunto de datos registra https://example.com/product/123 como fuente del precio de un producto.

Eso nos dice de dónde procede la información. No nos dice si el recopilador accedió a la página desde Chicago, París o Singapur. No nos dice si la solicitud se realizó a través de un ISP residencial o de un centro de datos en la nube. No nos dice si la página se visualizó como usuario móvil, si ya se había establecido una sesión, o si la respuesta fue la página esperada en lugar de una redirección de localización o un desafío de bot.

Para los datos web modernos, ese contexto puede afectar de manera material a la observación.

La procedencia de origen nos dice de dónde procede la información. La procedencia de punto de observación añade las condiciones bajo las cuales se hizo observable. Necesitamos ambas.

La misma URL no siempre significa la misma web

La suposición de que una URL se corresponde con una única representación universal de la información está cada vez más desfasada. Los sitios web modernos adaptan sus respuestas utilizando una amplia gama de señales.

La geografía puede afectar a precios, disponibilidad, idioma, resultados de búsqueda, vendedores, publicidad, avisos regulatorios o flujos de consentimiento, y al acceso a contenido con licencia. La identidad de red puede influir en los controles antifraude y en los sistemas antibot. El tipo de dispositivo puede cambiar el diseño de la página e incluso qué información se muestra. Las cookies y el historial de sesión pueden afectar a las recomendaciones, la personalización y el estado de autenticación.

Consideremos algunas tareas ordinarias de recopilación de datos:

• Una plataforma de inteligencia de precios consulta un minorista desde Estados Unidos y desde Alemania. La URL es idéntica, pero el precio del producto, el estado de existencias, las opciones de envío y el vendedor disponible pueden diferir.
• Una plataforma de SEO mide un resultado de Google desde Miami y desde Londres. La consulta es idéntica, pero los resultados orgánicos, los paquetes locales, los anuncios y otras funciones de la SERP pueden cambiar.
• Una plataforma de verificación de anuncios comprueba una campaña desde varias ciudades. La página del anunciante no ha cambiado, pero el anuncio servido puede depender de la ubicación y la red del espectador.

Estos no son casos extremos. Son propiedades de la web tal como existe hoy. Un conjunto de datos que simplemente registra la URL más el resultado puede, por tanto, conservar el contenido mientras pierde parte de la evidencia necesaria para interpretarlo.

Qué debería registrar un estándar de procedencia de punto de observación

La respuesta no necesita ser un esquema de metadatos enorme adjunto a cada solicitud. Un estándar útil podría comenzar con un pequeño conjunto de campos que capturen las condiciones con mayor probabilidad de afectar a una observación de la web pública.

Campo	Qué registrar	Por qué importa
Marca de tiempo	Cuándo se produjo la observación, preferiblemente utilizando una marca de tiempo UTC estandarizada.	El contenido web cambia constantemente. Sin el tiempo, incluso un registro de procedencia por lo demás completo resulta difícil de reproducir.
Punto de observación solicitado	La geografía y los selectores de red solicitados a la infraestructura de recopilación, cuando corresponda.	Los parámetros solicitados describen el contexto de observación previsto y distinguen la intención de recopilación de la salida realmente utilizada.
Geografía de salida validada	El país y, cuando esté disponible, la ciudad asociados a la IP de salida real observada para la solicitud.	La salida vista por el destino puede diferir de la ubicación solicitada si se permite un comportamiento de repliegue. El contexto de salida validado es lo que la observación realmente representa.
ASN / operador de red	El ASN asociado a la IP de salida y, cuando esté disponible, el ISP u operador de red correspondiente.	El país por sí solo puede no ser suficiente. El contexto de ASN u operador ayuda a describir el entorno de red desde el que se realizó la observación.
Contexto de cliente / dispositivo	Características de cliente relevantes, como el perfil móvil o de escritorio, la familia o el motor del navegador, el perfil del sistema operativo, la ventana gráfica, o el perfil de navegador normalizado utilizado por el sistema de recopilación.	El contexto de cliente y dispositivo puede cambiar el diseño de la página y, en algunos casos, qué información se muestra.
Estado de sesión	Si la solicitud utilizó una sesión nueva, persistente o autenticada, y si se conservaron cookies o estado de sesión. Registrar la clasificación, no las credenciales ni los valores de cookies en bruto.	Las condiciones de sesión pueden alterar fundamentalmente la página devuelta por un sitio web, a la vez que se evita almacenar material de autenticación sensible.
URL de destino	La URL exacta solicitada, incluyendo los parámetros relevantes.	El recurso de destino forma parte del contexto de origen necesario para interpretar y reproducir una observación.
Estado de validación	Si la respuesta devuelta se validó como el contenido previsto.	Una respuesta HTTP exitosa puede seguir siendo un CAPTCHA, una redirección, una página de consentimiento, una página de bloqueo, una respuesta vacía o una localización inesperada.

Juntos, estos campos producen un modelo más útil:

Observación = Contenido + Origen + Tiempo + Punto de observación + Contexto de cliente/sesión + Validación.

Ese es el nivel en el que creemos que la procedencia de la web pública debería operar cada vez más.

Los proxies residenciales deberían formar parte del registro de procedencia, no solo de la infraestructura de recopilación

Los proxies residenciales normalmente se tratan como infraestructura. Un recopilador necesita datos de Alemania, así que el tráfico se enruta a través de una IP alemana. Un flujo de trabajo necesita identidad persistente, así que utiliza una sesión sticky. Un conjunto de datos requiere resultados a nivel de ciudad, así que el sistema de recopilación solicita una ciudad concreta.

Esa descripción es técnicamente correcta, pero incompleta. Si el proxy determina dónde y a través de qué red se realiza una observación, entonces su configuración relevante forma parte del entorno de medición.

Los investigadores científicos documentan las condiciones experimentales porque esas condiciones pueden influir en sus resultados. La recopilación de datos de la web pública debería adoptar la misma mentalidad.

Con nuestra red de proxies residenciales, las solicitudes pueden dirigirse por país, región, ciudad o ASN, mientras que los sistemas de recopilación pueden elegir entre rotación por solicitud y sesiones sticky. El geo-targeting de Shifter se configura por solicitud, y puede utilizarse una coincidencia estricta cuando importa la geografía exacta solicitada. El comportamiento de sesión es igualmente una elección por solicitud.

Esos controles normalmente se consideran parámetros de recopilación. Nosotros creemos que cada vez más deberían considerarse también parámetros de procedencia. Eso no significa que un proxy demuestre que una observación es correcta. Significa que la configuración ayuda a explicar las condiciones bajo las cuales se obtuvo la observación.

Nuestros benchmarks de proxies muestran por qué importa el punto de observación

Podemos ver el mismo principio en los benchmarks de proxies. Cuando comparamos redes residenciales, no nos basamos únicamente en el tamaño total del pool que anuncian los proveedores. Nuestros benchmarks miden las direcciones IP que están activas y son alcanzables en el momento de la prueba, y los resultados se desglosan por mercados individuales. La disponibilidad de IP residenciales cambia continuamente, por lo que el tiempo y la geografía forman parte de lo que el benchmark realmente representa.

Nuestra metodología también controla condiciones de recopilación importantes. El programa de benchmarks utiliza volúmenes de solicitudes fijos, el mismo destino, una configuración de concurrencia fija y la misma máquina o servidor para ejecuciones comparables. Las páginas de benchmarks comparativos también recomiendan utilizar la misma hora al reproducir una prueba.

También medimos la dispersión de red, no simplemente el recuento de direcciones. Proveedores con números similares de IP alcanzables pueden aun así diferir de manera material en el número de sistemas autónomos representados dentro de un país.

Esa metodología ilustra un principio más amplio: una medición se vuelve más significativa cuando se conocen las condiciones bajo las que se realizó. Los conjuntos de datos de la web pública merecen la misma disciplina.

Una mejor procedencia de datos significa conjuntos de datos web más reproducibles y auditables

Hacer que el punto de observación forme parte de la procedencia de datos crearía beneficios prácticos en todo el ecosistema de datos.

• Para la reproducibilidad, otro equipo podría intentar recrear no solo la URL y la marca de tiempo, sino el entorno aproximado desde el que se produjo la observación.
• Para la auditoría, los analistas que investigan registros contradictorios podrían determinar si dos observaciones se recopilaron desde países, redes, dispositivos o sesiones diferentes antes de asumir que una de ellas era errónea.
• Para la calidad de los datos, las diferencias regionales podrían separarse de los fallos de extracción.

Las implicaciones se vuelven aún más significativas para la IA. Los conjuntos de entrenamiento, las canalizaciones de recuperación y los conjuntos de datos de evaluación dependen cada vez más de información web en vivo. Pero la cobertura geográfica importa. Nuestra guía sobre recopilación de datos para IA y machine learning ya refleja esta realidad: los modelos y agentes pueden necesitar recopilar información tal como la encuentran realmente los usuarios en distintas regiones, con recopilación multirregional y evaluación frente a datos de referencia de la web en vivo.

Sin metadatos de punto de observación, el desequilibrio geográfico puede volverse invisible una vez que la información entra en un conjunto de datos. Con ellos, los equipos pueden formular preguntas mucho mejores.

¿Qué porcentaje de este conjunto de datos se observó desde Estados Unidos? ¿Qué ASN estuvieron representados? ¿La recopilación móvil y de escritorio produjo resultados diferentes? ¿Las incoherencias aparentes son en realidad variaciones regionales? Eso no es solo procedencia. Es mejor gobernanza de datos.

Un estándar de punto de observación puede extender los marcos existentes de procedencia de datos

No hay necesidad de reinventar la procedencia desde cero. El estándar W3C PROV-O ya proporciona un marco para representar e intercambiar información de procedencia entre distintos sistemas. Es importante destacar que el W3C diseñó PROV-O de manera que sus clases y propiedades puedan especializarse para detalles de procedencia específicos de aplicaciones en distintos dominios.

Los principios de datos FAIR apuntan en la misma dirección. Para que los datos sean reutilizables, sus metadatos deberían describirse de forma rica, asociarse con una procedencia detallada y alinearse con estándares comunitarios relevantes para el dominio. La oportunidad, entonces, no es sustituir los estándares de procedencia existentes.

Es definir un perfil de procedencia específico para la web dentro de ese ecosistema más amplio. Dicho perfil podría estandarizar campos como el punto de observación solicitado, la geografía de salida validada, el ASN u operador de red, el contexto de cliente, las condiciones de sesión, el recurso de destino, la marca de tiempo y el estado de validación.

Una vez que esos campos se vuelven predecibles, resulta más fácil para las plataformas de scraping, los almacenes de datos, las canalizaciones de IA y los editores de conjuntos de datos conservarlos e intercambiarlos.

La industria de datos web debería convertir el punto de observación en un campo de primera clase

Los datos de la web pública se utilizan cada vez más para tomar decisiones de gran importancia. Impulsan la inteligencia de precios, la analítica publicitaria, la protección de marca, la investigación financiera, las plataformas de SEO, los sistemas de IA, la inteligencia de mercado y los agentes autónomos.

Los estándares que rodean a esos datos deberían reflejar cómo funciona realmente la web. Las API de scraping podrían exponer metadatos de observación junto al contenido devuelto. Los proveedores de proxies podrían facilitar la captura automática del contexto de red y geográfico relevante. Las canalizaciones de datos podrían conservarlo junto a cada registro en lugar de descartarlo tras la recopilación. Los editores de conjuntos de datos podrían documentar la distribución de puntos de observación utilizados para construir sus corpus.

Conclusión

Nada de esto requiere almacenar cada detalle técnico de cada solicitud HTTP. Requiere reconocer un principio importante: dónde se vio algo puede formar parte de lo que hace significativa a la observación.

Un proxy residencial, por tanto, no siempre debería tratarse como una tubería invisible entre el recopilador y el sitio web. Cuando la geografía, la identidad de red o el comportamiento de sesión pueden afectar a la información devuelta, la configuración de proxy relevante y el contexto de salida validado pasan a formar parte del registro de procedencia.

La web se ha vuelto variable geográfica, temporal y contextualmente. Nuestros conjuntos de datos necesitan reconocer esa realidad.

La próxima generación de datos web debería registrar no solo qué se vio y de dónde procedía, sino dónde se encontraba el observador cuando lo vio.

Fuentes y referencias

• NIST, Research Data Framework (RDaF) Version 2.0. Definición de procedencia y marco del ciclo de vida de datos de investigación.
• NIST, Data Governance and Management Profile Working Session 2. Actividades nocionales del ciclo de vida de datos, incluyendo metadatos, procedencia de datos y linaje de datos.
• W3C, PROV-O: The PROV Ontology. Marco de intercambio de procedencia y especialización para dominios específicos de aplicación.
• GO FAIR, FAIR Principles Overview. Datos reutilizables, metadatos ricos, procedencia detallada y estándares comunitarios relevantes para el dominio.
• Shifter, Residential Proxies geo-targeting documentation. País, región, ciudad, ASN, coincidencia estricta y comportamiento de repliegue.
• Shifter, Residential Proxies sessions documentation. Rotación por solicitud y comportamiento de sesión sticky.
• Shifter, 15 Residential Proxy Providers, Ranked on One Identical Test, 13 de agosto de 2026. Metodología de benchmark, volúmenes de solicitudes fijos, concurrencia, destino y medición de dispersión de red.
• Shifter, Shifter vs Evomi Residential Proxy Benchmark. Metodología comparativa, medición de IP en vivo y ASN, y guía de reproducibilidad.