Los equipos inmobiliarios no quieren gestionar infraestructura de scraping. Quieren saber dónde está subiendo la oferta, dónde se están recortando precios, qué piden las propiedades comparables y cuánto tiempo permanece el stock disponible. La capa de recopilación es un medio para conseguirlo, y para muchos equipos una web scraping API es la forma más directa de obtenerla sin contratar personal para automatización de navegadores y operaciones con proxies.
Qué recopilar y cómo modelarlo una vez recopilado se trata en otros artículos de este blog: valoraciones, alquileres y datos hipotecarios, un feed de datos del mercado inmobiliario en tiempo real, y agregación de anuncios entre portales. Este artículo trata sobre la propia capa de recopilación: por qué los portales inmobiliarios empujan a los equipos hacia una API, cómo se corresponde la API con las páginas inmobiliarias y cómo funciona la economía.
Por qué los portales inmobiliarios son difíciles de recopilar
Cuatro características de los sitios inmobiliarios los hacen más difíciles que la mayoría.
Están construidos para mapas y desplazamiento, no para páginas. Los resultados de búsqueda se cargan mediante JavaScript a medida que se mueve un mapa o se desplaza una lista, por lo que una solicitud HTTP simple a menudo devuelve una estructura vacía.
Los resultados están paginados y basados en cursores. Pasar de la página uno a la página dos frecuentemente depende del estado del lado del servidor, lo que rompe la obtención página por página ingenua.
Están localizados. Los portales sirven contenido por país y a veces por región, por lo que lo que se ve depende de dónde parece originarse la solicitud.
Están defendidos. El inventario de alto valor y actualización frecuente atrae tráfico automatizado, y los portales lo protegen en consecuencia.
Gestionar los cuatro puntos internamente implica navegadores headless, gestión de proxies, lógica de reintentos y ajuste de fingerprints. Una web scraping API agrupa todo esto en una sola solicitud.
Cómo se corresponde la API con las páginas inmobiliarias
Con la Shifter Web Scraping API, cada problema de portal tiene un control directo.
Vistas de mapa y lista. render_js=1 ejecuta la página en Chrome headless sin coste adicional de créditos, y wait_for_css retiene la captura hasta que las tarjetas de anuncios se hayan renderizado realmente. Las instrucciones de JavaScript pueden desplazarse o hacer clic en un control de “cargar más” antes de la captura. Véase renderizado de JavaScript.
Tarjetas de resultados. extract_rules con un tipo de lista devuelve cada tarjeta de anuncio de una página como JSON, un objeto por anuncio, sin necesidad de un analizador HTML en tu lado.
Paginación. session_id mantiene las cookies, el estado del navegador y la IP de origen a través de las solicitudes, de modo que un conjunto de resultados basado en cursores puede recorrerse en orden. Las sesiones caducan tras 10 minutos de inactividad, y el país debe mantenerse igual durante toda la vida de una sesión. Véase sesiones y proxies.
Localización. country acepta un código ISO alpha-2 por solicitud. La geolocalización global y el pool residencial mediante premium_proxy=1 están disponibles en los planes Growth y superiores.
Evidencia. screenshot=1 captura la página renderizada, útil cuando importa el estado de un anuncio en un momento determinado, como un recorte de precio o una retirada.
Renderizados largos. webhook=<URL> entrega la respuesta a tu endpoint cuando está lista en lugar de mantener una conexión abierta.
Una solicitud de resultados de búsqueda para un mercado tiene este aspecto:
curl "https://scrape.shifter.io/v1?api_key=YOUR_API_KEY\
&url=https%3A%2F%2Fportal.example.com%2Fsearch%3Fcity%3Dlyon\
&render_js=1&wait_for_css=.listing-card\
&country=fr&premium_proxy=1&session_id=lyon-walk-03\
&extract_rules=%7B%22listings%22%3A%7B%22selector%22%3A%22.listing-card%22%2C%22type%22%3A%22list%22%2C%22item%22%3A%7B%22price%22%3A%7B%22selector%22%3A%22.price%22%2C%22output%22%3A%22text%22%7D%2C%22area%22%3A%7B%22selector%22%3A%22.area%22%2C%22output%22%3A%22text%22%7D%2C%22link%22%3A%7B%22selector%22%3A%22a%22%2C%22output%22%3A%22%40href%22%7D%7D%7D%7D"La URL de destino está codificada en formato URL porque lleva su propia cadena de consulta, que de otro modo se interpretaría como parámetros de la solicitud a la API. La respuesta es un único objeto JSON con un array listings. Un campo cuyo selector no encuentra nada vuelve como null, lo que importa para la monitorización, como se explica más abajo.
Cómo la usan diferentes equipos
Los equipos de adquisiciones e inversión vigilan submercados objetivo en busca de nueva oferta y reducciones de precio, y utilizan el momento de los recortes como señal de negociación. Lo que necesitan es detección de eventos al día siguiente en un conjunto definido de áreas, no un rastreo nacional.
Las agencias inmobiliarias hacen seguimiento de su cuota de anuncios frente a competidores por área, y de la rapidez con la que se mueven los anuncios de la competencia. Conviene mantener esto a nivel de agencia: los datos de contacto de los agentes en los anuncios son datos personales y rara vez son lo que necesita el análisis.
Los productos PropTech construyen comparables y feeds de anuncios para sus propios usuarios. Aquí la API es una entrada más en un pipeline de normalización, y las definiciones de campos varían según el portal y el país.
Los operadores de alquiler monitorizan las rentas solicitadas y las concesiones en sus submercados. Las concesiones a menudo se encuentran en el texto de la descripción en lugar de en un campo de precio, por lo que las reglas de extracción deben capturar la descripción, no solo la renta principal.
Los prestamistas y aseguradoras siguen las condiciones del mercado en las áreas donde tienen exposición. El límite es la información de mercado publicada, nunca información individual de prestatarios u ocupantes.
La economía: diseñar en torno al crédito
Un crédito compra una solicitud exitosa, sea lo que sea que devuelva esa solicitud. El renderizado, las reglas de extracción, las capturas de pantalla y los propios reintentos de la API están incluidos, y las solicitudes fallidas o los errores del destino no se cobran.
Eso tiene una consecuencia directa de diseño para el sector inmobiliario. Una página de resultados de búsqueda que devuelve cuarenta tarjetas de anuncios cuesta el mismo único crédito que una página de detalle que devuelve un anuncio. Así que el patrón eficiente es recopilar desde las páginas de resultados siempre que la tarjeta lleve los campos que necesitas, precio, superficie, habitaciones, enlace, y obtener una página de detalle solo cuando un anuncio es nuevo o su tarjeta ha cambiado.
Para un mercado con unos pocos miles de anuncios activos, esa diferencia suele suponer un orden de magnitud en créditos. También mejora la frescura, porque puedes revisitar las páginas de resultados con más frecuencia por el mismo gasto.
Dos palancas de coste más. Actualiza con una cadencia que se ajuste a la velocidad con la que se mueve cada mercado, ya que diariamente suele ser suficiente para la mayoría de superficies de anuncios. Y vigila los créditos gastados en filas que se han analizado correctamente, porque un selector roto sigue consumiendo un crédito por cada respuesta exitosa pero inútil.
Vigilar las roturas silenciosas
Los portales se rediseñan, y un selector modificado no hace que la solicitud falle. Devuelve null, la solicitud tiene éxito y el crédito se gasta.
Haz seguimiento de la tasa de nulos por campo, por portal y por país en una ventana móvil, y activa una alerta cuando salte respecto a su línea base. Versiona tus reglas de extracción para que una corrección pueda rastrearse, y guarda las respuestas en bruto antes de analizarlas para que una regla corregida pueda reprocesarse sin pagar por obtenerla de nuevo. El patrón de carga se describe en trasladar datos de una web scraping API a SQL.
Cuándo una API es la capa de recopilación adecuada, y cuándo no
Elige la API cuando el renderizado y el manejo de anti-bot son la principal carga, cuando el equipo es pequeño o está centrado en datos en lugar de en infraestructura, y cuando la facturación predecible por éxito importa más que el menor coste unitario posible.
Elige proxies autogestionados cuando necesites flujos de navegador totalmente personalizados, operes a una escala en la que sea más económico poseer la pila, o ya cuentes con ingenieros de scraping. El enfoque basado en proxies se trata en proxies para datos inmobiliarios.
Elige primero un feed con licencia siempre que exista uno para tu mercado. La cobertura y la calidad de los campos suelen ser mejores, y las condiciones son claras. Usa la recopilación para lo que una licencia no proporciona.
Mantenerse dentro de los límites
Respeta los términos de cada portal y mantén los volúmenes de solicitudes proporcionados. Trata los datos de propietarios, agentes y ocupantes como datos personales por defecto y elimínalos en la ingesta cuando el análisis no los necesite. Usa las capturas de pantalla como evidencia de lo que mostraba un anuncio, no como material para republicar. El enfoque más amplio está en proxies residenciales y cumplimiento del RGPD.
Preguntas frecuentes
¿Necesito renderizado de JavaScript para los portales inmobiliarios?
Para la mayoría de los portales modernos, sí, porque los resultados de anuncios se cargan después de la página inicial. Cuesta el mismo crédito que una obtención estática, así que hay pocas razones para no activarlo cuando los resultados se renderizan en el lado del cliente.
¿Puede una sola API cubrir portales en varios países?
Sí, estableciendo country por solicitud y una sesión por mercado. La geolocalización global requiere un plan Growth o superior.
¿Cómo recorro de forma fiable los resultados de búsqueda paginados?
Usa un session_id por búsqueda, mantén el país constante dentro de ella, y mantén el recorrido en marcha, ya que las sesiones caducan tras 10 minutos de inactividad.
¿Es más económico hacer scraping de páginas de detalle o de páginas de resultados?
Las páginas de resultados, siempre que la tarjeta del anuncio lleve los campos que necesitas. Un crédito devuelve muchos anuncios, y las páginas de detalle pueden reservarse para anuncios nuevos o modificados.
En resumen
Para la mayoría de los equipos inmobiliarios, la parte difícil de la inteligencia de mercado no es decidir qué medir. Es obtener datos fiables de portales construidos para mapas, desplazamiento y visitantes humanos. Una web scraping API convierte el renderizado, la paginación, la localización y los reintentos en parámetros de solicitud, y cobra solo cuando llegan los datos.
Diseña en torno al crédito recopilando primero desde las páginas de resultados, recorre las búsquedas con sesiones por mercado, vigila las tasas de nulos para detectar roturas silenciosas, y opta por un feed con licencia siempre que exista uno. El producto está en la página de Web Scraping API, con planes en la página de precios, y el caso de uso más amplio en la página de inmobiliario.