Los equipos de PropTech tienden a describir su necesidad de datos como “datos de propiedades”, como si las valoraciones, los alquileres y los tipos hipotecarios fueran tres columnas de una misma tabla. Son tres problemas distintos. Proceden de fuentes diferentes, conllevan restricciones de licencia y privacidad distintas y, lo más importante, significan cosas diferentes.
Los fallos que se derivan de tratarlos como un único conjunto de datos no son fallos de recopilación. Son fallos de etiquetado, y salen a la luz mucho después, cuando un usuario cuestiona una cifra que tu producto presentó como un hecho.
Tres tipos de datos, tres realidades de sourcing
Antes de escribir un colector, ten claro cuál de estos estás obteniendo en realidad, porque la respuesta determina tanto el método como lo que puedes afirmar.
| Tipo de dato | Fuente autorizada | Lo que te da la web | Lo que no es |
|---|---|---|---|
| Precios de transacción | Registros públicos: registro de la propiedad, escrituras, padrones catastrales | Precios de venta, fechas de transferencia, atributos de la parcela | No es el valor de mercado actual |
| Valores catastrales | Padrones catastrales | Una valoración a efectos fiscales | No es una valoración de mercado |
| Estimaciones de portal | El modelo propio del portal | El resultado de un modelo propietario | No es una tasación, no es un hecho |
| Alquileres solicitados | Anuncios activos | Lo que los arrendadores piden hoy | No es lo que pagan los inquilinos |
| Alquileres efectivos | Conjuntos de datos con licencia, datos de operadores | Rara vez públicos | No se puede derivar de los anuncios |
| Tipos hipotecarios | Páginas de tipos de los prestamistas, series estadísticas oficiales | Tipos publicados por producto y tramo | No es el tipo que obtuvo ningún prestatario en concreto |
La disciplina más útil en los datos de PropTech es mantener “observado”, “tasado”, “solicitado” y “estimado” en columnas separadas y no dejar nunca que colapsen en un único campo llamado value.
Empieza por las fuentes pensadas para ese uso
Recorre este orden y solo llega al último nivel para lo que las capas anteriores realmente no cubren.
Primero, las fuentes oficiales y a granel. Los registros de la propiedad, las oficinas catastrales y las agencias estadísticas suelen publicar ficheros o APIs a granel. Son autorizadas, están permitidas y contienen un histórico que no puedes reconstruir externamente. Para precios de transacción y atributos de parcela, esto suele ser toda la respuesta que necesitas.
Segundo, los feeds con licencia. Los datos de corredores y de listados múltiples suelen estar disponibles bajo licencia. Cuando tu producto necesita cobertura completa de anuncios con campos fiables, una licencia sale más barata que la exposición técnica y legal de la alternativa.
Por último, la observación pública de la web, para lo que las dos primeras no aportan: alquileres solicitados y sus concesiones, inventario en vivo, tablas de tipos publicadas por prestamistas, y cómo difiere todo esto según el mercado.
Saltar directamente al último nivel es el error más común y más caro de esta categoría. El lado de los anuncios de ese trabajo se trata en proxies para datos inmobiliarios.
Valoraciones: nunca presentes un modelo como una medición
Las estimaciones de los portales son resultados de un modelo entrenado con datos que no puedes ver, con distribuciones de error que el portal puede publicar o no. Son útiles como una variable dentro de tu propio modelo y no son una valoración.
Tres reglas mantienen esto defendible. Guarda la estimación con su fuente y la fecha en que se observó, nunca como un número desnudo. No la reetiquetes: una estimación es una estimación, no “valor de mercado”. Y si tu propio producto genera una valoración, publica un intervalo de confianza junto a ella, porque una estimación puntual presentada sin él se leerá como una precisión que no tienes.
Para cualquier cosa que se acerque a una valoración formal, los datos recopilados son un insumo de un proceso profesional, no un sustituto de él.
Alquileres: lo solicitado no es lo conseguido, y la concesión está en el texto
Los alquileres de los anuncios son alquileres solicitados. En un mercado blando, quedan por encima de lo que realmente pagan los inquilinos, y ahí es donde viven las concesiones: un mes gratis, tasas condonadas, una plaza de aparcamiento incluida, un plazo más corto a otro precio.
Esas concesiones suelen estar en la descripción de texto libre en lugar de en un campo estructurado, lo que significa que una serie de alquileres solicitados construida solo a partir del campo de renta es sistemáticamente incorrecta precisamente en las condiciones que más interesa medir. Analiza la descripción en busca de lenguaje de concesión y guárdalo como campo propio, aunque lo único que puedas extraer sea un indicador y la frase en bruto.
Dos consideraciones prácticas más. Normaliza a una unidad comparable, típicamente renta por periodo y por número de dormitorios o por superficie, ya que una mediana sobre tipos de unidad mixtos mide tanto la mezcla como el mercado. Y mantén separadas las observaciones a nivel de unidad y a nivel de edificio, porque un edificio que anuncia una unidad no es un edificio alquilando a ese precio.
Datos hipotecarios: los tipos son una matriz, no un número
Los tipos publicados por los prestamistas varían según el producto, el plazo, el tramo de loan-to-value, el nivel del prestatario, la región y a veces el canal. Un scraper que guarda “el tipo” de la página de un prestamista ha capturado una sola celda de una matriz y ha descartado los ejes.
Registra el producto, el plazo, el tramo de LTV, cualquier condición del prestatario declarada, puntos o comisiones, si la cifra es un tipo nominal o una TAE, la fecha de vigencia que indica el prestamista y la fecha en que tú lo observaste. La distinción entre nominal y TAE es la que causa más confusión posterior, porque las dos no son comparables y ambas aparecen en la misma página.
Las series estadísticas oficiales de bancos centrales y agencias de vivienda son la referencia contra la que contrastar tu recopilación. Cuando tu media recopilada diverge de la serie publicada, lo que suele haber cambiado es la recopilación.
Un límite que no es negociable: recopila tipos y condiciones publicados, nunca datos a nivel de prestatario. Las solicitudes individuales, los expedientes de crédito y los datos financieros personales no son datos de la web pública, y nada en una hoja de ruta de PropTech justifica ir a por ellos.
La capa de recopilación
Dos propiedades de estas fuentes hacen que el punto de vista forme parte del método.
Las tablas de tipos de los prestamistas y el contenido de los portales están regionalizados, así que el tipo o el anuncio que ves depende de desde dónde parece originarse la solicitud. Y los tipos, en particular, pueden diferir por estado o región dentro de un mismo país, lo que significa que un único punto de vista nacional informa silenciosamente de los tipos de una región como si fueran los del mercado.
Con el gateway de Shifter, el punto de vista y la sesión van en las credenciales frente a p.shifter.io:443:
customer-USERNAME-country-us-state-tx-sid-rates-tx-11-ttl-600:PASSWORDcountry-us y state-tx sitúan la solicitud en el mercado cuyos tipos estás leyendo, sid-rates-tx-11 mantiene una única salida durante todo un recorrido de la tabla de tipos para que cada celda de una instantánea provenga de la misma sesión, y ttl-600 conserva esa dirección durante diez minutos. ttl solo hace algo junto con sid; sin un identificador de sesión, el gateway rota en cada solicitud, lo cual es correcto para consultas independientes e incorrecto para una tabla paginada. El compromiso se explica en proxies residenciales fijos frente a rotativos.
Añade strict-true cuando una coincidencia regional exacta importe más que obtener una respuesta, para que el gateway devuelva un 502 en lugar de servirte silenciosamente una región cercana.
La cadencia debe seguir la rapidez real con la que se mueve cada serie. Los tipos hipotecarios justifican una recopilación diaria y, a veces, intradía. Los anuncios y los alquileres solicitados son diarios. Los registros públicos se actualizan según su propio calendario, a menudo semanal o mensual, y recopilarlos más rápido de lo que se publican solo produce filas duplicadas. Mantén las tasas de solicitud ordinarias con un backoff real, como en limitación de tasa y estrangulamiento de solicitudes.
El esquema que te mantiene honesto
Cada registro debe llevar, junto al número en sí: el tipo de observación de la tabla anterior, la fuente, la fecha de vigencia que indica la fuente, la fecha en que tú lo observaste, el mercado y la ubicación de salida desde la que lo observaste, y un indicador de confianza o validación.
La fecha de vigencia y la fecha de observación son campos distintos, y confundirlas es un error real. Una hoja de tipos de un prestamista con vigencia del martes pasado, recopilada hoy, es un tipo del martes. Un índice construido sobre fechas de observación mostrará un movimiento que no ocurrió cuando tu rastreador llegó tarde.
El argumento general para registrar dónde y cuándo se hizo una observación está en el caso a favor de un estándar de punto de vista.
Privacidad y cumplimiento
Los datos de propiedades están más cerca de las personas que la mayoría de los datos web comerciales, y las normas varían enormemente según la jurisdicción.
Los registros públicos nombran a los propietarios en algunos países; en otros, esa información está restringida. Trata los nombres de propietarios, los datos de contacto y cualquier elemento que identifique a un ocupante como datos personales por defecto, recópilos solo cuando tengas una base para ello, y elimínalos en la ingesta cuando tu producto no los necesite. Un índice de alquileres no necesita el nombre de un inquilino.
Respeta los términos de cada fuente, mantén los volúmenes proporcionados y, cuando una licencia sea la vía prevista, opta por la licencia. El planteamiento general está en proxies residenciales y cumplimiento del RGPD y en proxies residenciales éticos para la recopilación de datos de IA.
Preguntas frecuentes
¿Puedo usar las estimaciones de los portales como valoraciones en mi producto?
No como valoraciones. Como una variable, o como una estimación de terceros claramente atribuida, sí, sujeto a los términos del portal. Lo que importa es el etiquetado.
¿Cómo obtengo alquileres efectivos en lugar de alquileres solicitados?
Generalmente mediante conjuntos de datos con licencia o acuerdos con operadores. Los anuncios no los contienen, e inferirlos a partir de los alquileres solicitados es modelado, lo cual debería declararse como tal.
¿Es necesario hacer scraping de registros públicos si existen ficheros a granel?
No, y los ficheros a granel son mejores: autorizados, completos y permitidos. Usa la web solo para lo que no se publica a granel.
¿Por qué nuestros tipos hipotecarios no coinciden con la media nacional publicada?
Normalmente porque has recopilado una sola región, un solo tramo de LTV o un solo nivel de prestatario y has calculado la media sobre una mezcla no representativa. Registra los ejes y la discrepancia suele explicarse sola.
La conclusión
Las valoraciones, los alquileres y los tipos hipotecarios son tres problemas de recopilación que comparten un vocabulario y nada más. Los equipos que construyen datos de PropTech fiables acuden primero a las fuentes oficiales y con licencia, usan la web pública para el resto, y mantienen observado, tasado, solicitado y estimado como campos separados y etiquetados con una fecha de vigencia y una fecha de observación.
Recopila cada mercado desde ese mercado, mantén las sesiones coherentes a lo largo de una tabla o un conjunto de resultados, y no dejes nunca que el resultado de un modelo se guarde como un hecho. Convertir esas observaciones en una serie de mercado en vivo se trata en construcción de un feed de datos del mercado inmobiliario en tiempo real. La perspectiva de producto está en la página de proxies residenciales para la recopilación de datos, con las tarifas en la página de precios.