“Dados imobiliários em tempo real” soa como um problema de latência, e não é. O mercado imobiliário não tem cotação de preço. As transações são esparsas, negociadas individualmente e registradas em cartórios públicos semanas ou meses depois de concluídas. Nada no mercado subjacente se move em segundos.
O que se move rapidamente é a superfície de anúncios: um imóvel aparece, seu preço muda, ele entra em proposta, é retirado, volta a aparecer. Esses eventos acontecem diariamente e antecedem o registro da transação por uma margem larga. Um feed imobiliário em tempo real é, portanto, um sistema de detecção de eventos, e sua função é perceber mudanças nessa superfície rápido o suficiente para ser útil e de forma consistente o suficiente para ser confiável.
Os dois problemas difíceis não são a velocidade de coleta. São a identidade do imóvel e a estabilidade da cobertura.
Modele o ciclo de vida do anúncio como eventos
Armazenar um snapshot noturno de cada anúncio diz o que está no mercado. Não diz o que aconteceu, e o que aconteceu é o sinal.
Derive eventos a partir de observações consecutivas e armazene-os como registros próprios:
| Evento | Por que importa |
|---|---|
| Novo anúncio | Nova oferta, o indicador antecedente mais precoce da cadeia |
| Redução ou aumento de preço | Profundidade e frequência são a leitura mais clara do momentum local |
| Mudança de status para em proposta ou vendido sujeito a contrato | Demanda, e muito antes do registro |
| Retirada | Frequentemente um sinal de mercado fraco, e facilmente confundido com uma venda |
| Reanúncio | Frequentemente o mesmo imóvel retornando, ponto onde a integridade dos dados falha |
| Vendido, conforme registro público | O resultado oficial, que chega tarde |
Cada evento precisa da observação que o abriu, da observação que o fechou, e de metadados de confiança suficientes para dizer se o limite foi observado ou apenas delimitado pelo seu intervalo de amostragem. Se você coleta diariamente, sabe que um preço mudou dentro de um dia, não quando mudou.
A identidade do imóvel é o sistema inteiro
O mesmo imóvel aparece em vários portais, sob números de referência diferentes, com endereços formatados de maneira diferente, às vezes com o identificador de unidade em um campo diferente ou ausente. Com o tempo, ele aparece de novo, meses depois, como um anúncio novo.
Se a resolução de identidade falha, duas coisas quebram ao mesmo tempo. O inventário infla, porque um imóvel conta como três. E o tempo no mercado desmorona, porque um imóvel reanunciado parece novo.
Esse segundo ponto merece atenção especial, porque reanunciar para zerar o tempo no mercado é uma prática deliberada em alguns mercados. Um feed que trata todo reanúncio como nova oferta vai subestimar sistematicamente por quanto tempo o estoque permanece parado, exatamente nos mercados em que esse número mais importa.
Uma estratégia de identidade viável, em ordem de confiabilidade: um identificador de parcela ou título quando a jurisdição disponibiliza um; um endereço normalizado mais identificador de unidade, geocodificado para uma coordenada com tolerância estreita; depois correspondência de atributos por área útil, número de quartos e tipo de imóvel para desempatar. Mantenha a referência própria de cada portal vinculada ao seu imóvel canônico, e mantenha um registro de episódio de anúncio para que um imóvel possa ter vários episódios ao longo do tempo sem perder seu histórico.
Meça sua taxa de correspondência revisando manualmente uma amostra, e publique isso. Um número de inventário sem uma taxa de erro de deduplicação conhecida é um número que ninguém consegue dimensionar.
Estabilidade de cobertura supera amplitude de cobertura
Um índice imobiliário é lido como uma série temporal, o que significa que qualquer mudança no que você consegue enxergar registra como uma mudança no mercado.
Adicione um portal no meio da série e a oferta parece saltar. Perca um por um bloqueio e a oferta parece cair. Comece a coletar páginas mais profundas e o inventário sobe. Nada disso é o mercado imobiliário, e tudo isso parece exatamente com ele.
Então fixe o painel antes de começar: um conjunto definido de portais, uma geografia definida, um conjunto definido de consultas, e uma profundidade definida por consulta, cada uma coletada integralmente ou explicitamente marcada como incompleta. Versione o painel, carimbe a versão em cada linha, e trate qualquer mudança nele como uma quebra de metodologia documentada, não como uma melhoria silenciosa.
Essa é a mesma disciplina que rege qualquer painel web longitudinal, e o argumento completo está em dados de portais de emprego e inteligência de mercado de trabalho. Ele se aplica diretamente aqui.
A geografia faz parte da observação
Portais localizam conteúdo. Os resultados de busca, os imóveis apresentados e às vezes os campos exibidos dependem de onde a requisição parece vir, e portais que atendem vários países podem retornar um site inteiramente diferente.
Para um feed que reporta mercados regionais, a coleta precisa vir das regiões que ele reporta. Com o gateway da Shifter, o ponto de vantagem e a sessão vão nas credenciais contra p.shifter.io:443:
customer-USERNAME-country-gb-city-manchester-sid-feed-mcr-04-ttl-600:PASSWORDcountry-gb usa o código ISO alpha-2, city-manchester restringe ao mercado, sid-feed-mcr-04 mantém uma saída ao longo de uma busca completa incluindo sua paginação para que o conjunto de resultados seja internamente coerente, e ttl-600 mantém esse endereço por dez minutos. Uma sessão por consulta em vez de por requisição é o que impede que a página quatro pertença a um ponto de vantagem diferente da página um.
Mantenha os sinais de localidade consistentes com a saída, já que uma incompatibilidade muda o que alguns portais retornam; isso é abordado em compatibilizando geo, fuso horário e localidade do proxy. Mantenha as taxas de requisição comuns com backoff real, como em limitação de taxa e controle de requisições.
Cadência por série, não uma configuração global única
A coleta diária é suficiente para quase tudo na superfície de anúncios, porque os anúncios não mudam a cada hora e uma passagem diária dá detecção de eventos no dia seguinte.
Uma cadência mais rápida se justifica em dois casos: uma pequena lista de observação em um mercado aquecido onde o status de em proposta muda dentro de horas, e a janela de lançamento de novos empreendimentos. Os dados de registro público atualizam segundo sua própria agenda, e coletá-los com mais frequência do que são publicados só produz duplicatas.
O que importa mais que a frequência é a regularidade. Colete no mesmo horário todos os dias, porque uma passagem que oscila da manhã para a noite move os limites de eventos que você está medindo.
As métricas que resultam disso
Com eventos e identidade estabelecidos, as saídas são diretas, e cada uma precisa ter sua ressalva declarada no produto.
Nova oferta e inventário, ambos dependentes da qualidade de deduplicação. Tempo no mercado, com a política de reanúncio divulgada, já que o número muda substancialmente dependendo de se os episódios estão encadeados. Frequência e profundidade de mudança de preço, a leitura de momentum mais limpa disponível a partir dos anúncios. Taxa de retirada, útil mas facilmente confundida com vendas. Índices de preço pedido, que não são índices de preço de transação e nunca devem ser rotulados como se fossem. A distinção entre números observados, avaliados, pedidos e estimados está exposta em coletando avaliações, aluguéis e dados de hipoteca. Relação lista-venda e absorção, que precisam dos dados de registro e, portanto, atrasam.
Duas regras de publicação mantêm o feed confiável. Publique a métrica de cobertura ao lado do índice, para que o leitor consiga distinguir um movimento de mercado de um movimento de coleta. E suprima células pequenas: uma mediana calculada sobre nove anúncios em um código postal é ruído com uma casa decimal, e é o número mais provável de ser capturado em print.
O contrato de atualidade
Cada linha deve carregar seu horário de observação, e cada consumidor deve aplicar seu próprio limite de obsolescência em vez de confiar que a tabela está atual. Essa única decisão de design é o que impede que uma coleta atrasada se transforme silenciosamente em uma mudança de mercado reportada. É o mesmo contrato descrito em construindo um feed de preços competitivos em tempo real, e ele se aplica aqui sem alterações.
Acompanhe sua própria coleta junto com os dados: taxa de sucesso por portal por mercado, e resultados retornados contra resultados esperados. Quando a oferta parece cair, a primeira pergunta é se o mercado mudou ou se sua cobertura mudou. O método para estabelecer essa linha de base está em testando velocidade, taxa de sucesso e precisão de localização do proxy.
Perguntas frequentes
O quão em tempo real os dados imobiliários podem realmente ser?
Detecção de eventos no dia seguinte a partir de uma passagem diária é alcançável e suficiente para quase todos os usos. Intradiário só vale a pena para uma pequena lista de observação. O registro de transação sempre vai atrasar em semanas ou meses, independentemente de como você coleta.
Por que nossa contagem de inventário excede os números dos próprios portais?
Quase sempre duplicação entre portais. Um imóvel anunciado com três corretores é um imóvel. Meça sua taxa de correspondência antes de confiar em qualquer número de inventário.
Reanúncios devem contar como nova oferta?
Escolha uma regra, documente-a e aplique-a em todo o histórico. Encadear episódios a um único imóvel costuma ser mais honesto, já que preserva o tempo real no mercado.
Podemos publicar um índice de preço pedido como um índice de preço de imóveis?
Não. Preços pedidos antecedem e divergem dos preços de transação, particularmente quando o mercado vira. Rotule-o pelo que é e o índice se torna genuinamente útil.
Conclusão
Um feed imobiliário em tempo real é um pipeline de eventos sobre um mercado lento. A velocidade é a parte fácil. O que determina se alguém pode confiar nele é resolver imóveis para uma identidade estável, manter o painel fixo para que mudanças de cobertura não se disfarcem de movimentos de mercado, e rotular honestamente os sinais de preço pedido em relação aos dados de transação que chegam tarde.
Colete cada mercado a partir daquele mercado, mantenha as sessões coerentes ao longo de um conjunto de resultados, anexe um horário de observação a cada linha, e publique sua cobertura ao lado do seu índice. A visão do produto está na página de pipelines de coleta de dados, com preços na página de preços.