Coletar anúncios de um portal é um problema de scraping, e um bem compreendido. Coletá-los de trinta portais em uma dúzia de países e apresentar o resultado como um único inventário pesquisável é um trabalho totalmente diferente, e quase nenhuma da dificuldade está na coleta em si.
Ela está no fato de que dois portais descrevendo o mesmo apartamento vão discordar sobre seu tamanho, sua contagem de cômodos, seu preço e até mesmo que tipo de imóvel é, e todos estarão certos segundo sua própria convenção local.
Se você ainda está montando a coleta em si, proxies para dados imobiliários cobre esse terreno. Este guia é sobre o que acontece depois que os dados chegam.
Os campos que não significam o que dizem
Cinco categorias causam a maioria das falhas de agregação entre portais.
Área. Metros quadrados, pés quadrados e, em alguns mercados, unidades locais. Pior, a base de medição difere: interno bruto, interno líquido e, em vários países, um padrão de medição definido legalmente que exclui ou desconta partes de um imóvel. Converter unidades é trivial; reconciliar bases não é, e uma conversão direta mistura silenciosamente as duas.
Contagem de cômodos. Em grande parte da Europa continental, o número principal conta cômodos incluindo salas de estar em vez de quartos. Um “3 pièces” e um “3 quartos” não são o mesmo imóvel. Armazenar ambos em uma única coluna bedrooms produz um inventário que está errado de uma forma que só aparece quando alguém compara mercados.
Semântica de preço. Preço pedido, preço-guia, “ofertas acima de”, reserva de leilão, preço sob consulta e, em mercados de locação, se o valor inclui taxas de serviço, utilidades ou impostos locais. São quantidades diferentes vestindo o mesmo símbolo de moeda.
Regime de posse e propriedade. Propriedade plena (freehold), arrendamento de longo prazo (leasehold) com prazo remanescente, arranjos de condomínio ou strata, propriedade cooperativa. Um leasehold com prazo curto restante é um ativo materialmente diferente de um freehold pelo mesmo preço.
Taxonomias de tipo de imóvel. Cada portal tem a sua própria, e elas não se mapeiam de forma limpa. Decidir se uma maisonette, um duplex e um apartamento com escada interna são uma categoria ou três é uma decisão de produto que precisa ser tomada uma vez e aplicada em todo lugar.
O princípio que mantém isso administrável: armazene os valores originais da fonte literalmente, ao lado de seus valores normalizados, sempre. Quando você descobrir mais tarde que a base de área de um portal difere do que você supôs, os campos brutos permitem que você re-derive. Sem eles, você precisa recoletar, e os dados históricos simplesmente se perdem.
Construa o modelo canônico antes do segundo portal
A ordem importa. Equipes que integram o portal um e depois encaixam o portal dois em seu esquema acabam com um modelo canônico que é na verdade o modelo do portal um usando outro nome, e cada integração subsequente luta contra ele.
Um registro canônico funcional separa três camadas:
| Camada | Conteúdo | Por que separar |
|---|---|---|
| Bruta | Os campos da fonte exatamente como publicados, mais os metadados de coleta | Permite re-derivar quando suas suposições mudam |
| Normalizada | Suas unidades, sua taxonomia, sua semântica de preço, com a conversão registrada | O que o produto consulta |
| Derivada | Preço por unidade de área, índices calculados, pontuações | Recomputável, nunca a fonte da verdade |
Cada campo normalizado deve carregar uma nota de qual regra o produziu. Quando um cliente perguntar por que um imóvel mostra 68 metros quadrados na sua plataforma e 73 no portal, a resposta deve ser uma consulta, não uma investigação.
Moeda, e nunca armazenar apenas o valor convertido
Para inventários multi-país, armazene o valor original e seu código de moeda conforme publicado, mais a taxa de câmbio que você aplicou e a data dessa taxa.
Armazenar apenas um valor convertido destrói informação de forma irreversível. Taxas mudam, correções são emitidas, e um cliente vendo um anúncio histórico quer o preço que foi pedido, não esse preço reexpresso à taxa de hoje. Converta no momento da consulta a partir do valor original armazenado, ou armazene a conversão com sua taxa datada para que possa ser auditada e refeita.
Reconciliando o mesmo imóvel de vários portais
O mesmo imóvel aparece rotineiramente em vários portais, anunciado por corretores diferentes, com fotografias diferentes, descrições diferentes e às vezes preços diferentes. A resolução de identidade é o que transforma isso em um único registro, e é abordada em profundidade em construindo um feed de dados do mercado imobiliário em tempo real, já que a mesma engrenagem impulsiona a contagem de inventário ali.
O que é específico da agregação é o que você faz depois que os duplicados são agrupados: decidir qual valor prevalece.
Defina uma precedência de fonte por campo em vez de por portal. Um portal pode ter os números de área mais confiáveis enquanto outro tem melhores fotografias e um terceiro atualiza preços mais rápido. Uma classificação global única descarta isso.
Depois lide com a discordância explicitamente. Quando anúncios agrupados discordam sobre preço além de uma tolerância, isso é um sinal em vez de um erro: pode significar uma mudança de preço que um corretor ainda não refletiu, ou um agrupamento incorreto. Sinalize, mostre a faixa e mantenha as alternativas vinculadas. Escolher silenciosamente uma e descartar as demais é como um agregador perde confiança.
A disciplina geral de correspondência, incluindo medir e publicar sua taxa de correspondência, é a mesma descrita em lacunas de sortimento e catálogo de concorrentes.
Cobertura é nacional, não global
Não existe um mercado imobiliário global nem um conjunto global de portais. Cada país tem seus próprios portais líderes, seu próprio comportamento de corretores e suas próprias convenções sobre o que é publicado publicamente. Em alguns mercados, uma grande parcela das transações nunca aparece em um portal público.
Portanto, trate um inventário global como uma união de painéis nacionais, cada um com seu próprio conjunto definido de portais, e registre a cobertura por mercado em vez de agregada. Um único número principal em todos os países esconde o mercado onde você tem um portal e o mercado onde você tem seis.
Duas regras práticas. Não compare o inventário absoluto entre mercados a menos que a cobertura seja comparável, porque você estará medindo o seu próprio painel. E onde existirem feeds licenciados para um mercado, adote a licença: a cobertura e a qualidade dos campos costumam ser muito melhores do que a coleta pública, e a situação legal é mais simples.
A camada de coleta
Portais localizam intensamente. O que você vê, a moeda exibida, o idioma, às vezes o próprio site, depende de onde a requisição parece vir. Um agregador multi-país coletando a partir de um único ponto de vista receberá silenciosamente a visão de um país sobre vários mercados.
Com o gateway Shifter, o mercado e a sessão vão nas credenciais contra p.shifter.io:443:
customer-USERNAME-country-fr-sid-listings-fr-12-ttl-600:PASSWORD
country-fr usa o código ISO alpha-2, sid-listings-fr-12 mantém uma saída ao longo de uma busca completa incluindo paginação para que um conjunto de resultados seja internamente coerente, e ttl-600 mantém esse endereço por dez minutos. Sem sid o gateway rotaciona por requisição, o que é correto para consultas independentes e errado para uma busca paginada.
Mantenha os sinais de localidade consistentes com a saída, já que uma incompatibilidade muda o que alguns portais retornam, e mantenha as taxas de requisição comuns com recuo real, como em limitação de taxa e throttling de requisições. Acompanhe o sucesso da coleta por portal por mercado junto com os anúncios, porque um portal que silenciosamente passa a retornar menos resultados parece exatamente como um mercado com menos oferta.
Completude de campos é uma métrica de qualidade, não um detalhe
Os portais diferem enormemente em quão completamente preenchem campos opcionais. Um agregador que trata um campo ausente como inexistente em vez de não publicado vai relatar, por exemplo, que um mercado tem quase nenhum imóvel com classificações energéticas quando, na verdade, um portal simplesmente não as expõe.
Pontue a completude por portal por campo, publique isso internamente e use ao escolher a precedência de fonte. Isso também indica onde um feed licenciado realmente melhoraria o produto em vez de apenas custar dinheiro.
Perguntas frequentes
Devo normalizar na ingestão ou no momento da consulta?
Normalize na ingestão e mantenha os campos brutos. A normalização no momento da consulta é mais lenta e dificulta a indexação, mas sem os valores brutos você não consegue corrigir uma regra ruim retroativamente.
Como lidar com portais que publicam cômodos em vez de quartos?
Armazene ambos os conceitos como campos separados e preencha o que a fonte fornecer. Não infira quartos a partir de uma contagem de cômodos, e não deixe um filtro de produto consultar um campo que só é preenchido em alguns mercados.
Uma única taxonomia canônica de tipo de imóvel é realista entre países?
Uma superficial é. Mantenha o nível superior pequeno e portátil, e coloque a especificidade local em um campo secundário em vez de forçá-la na taxonomia principal.
Qual é a coisa de maior valor a corrigir primeiro?
Base de área e semântica de preço. Elas afetam toda métrica derivada, e erros nelas são invisíveis até que alguém compare dois mercados.
Conclusão
A agregação entre portais é um problema de normalização vestido com roupas de um problema de scraping. A coleta é a parte que já está resolvida.
Construa o modelo canônico antes da segunda integração, mantenha os valores brutos da fonte para sempre, armazene a moeda original com uma taxa datada, defina a precedência de fonte por campo em vez de por portal, trate a discordância como um sinal em vez de um erro, e registre a cobertura por mercado porque não existe painel global. A visão de produto está na página de coleta de dados em larga escala, com preços na página de preços.