Cinco anos em autopeças: o catálogo era parte do produto

Cinco anos antes da publicação deste texto, Ricardo Cabianca e eu fundamos a NVPC. A empresa começou com a proposta de aplicar inteligência, gestão e tecnologia ao varejo on-line do segmento automotivo, inicialmente em autopeças.

Entramos nesse mercado com pouca experiência no domínio. Por isso, antes de pensar em uma plataforma, tivemos de responder a uma pergunta básica: o que precisávamos saber sobre uma peça para representá-la corretamente?

Essa pergunta mudou o foco do trabalho. Uma autopeça não é apenas um nome, uma foto e um preço. Sua identidade depende de atributos técnicos, códigos, fabricante, aplicação em veículos, relações com peças equivalentes e condições comerciais. Se esses dados forem imprecisos, uma interface bem construída apenas apresentará o erro com mais eficiência.

O que aprendemos sobre o objeto

No trabalho de exploração do domínio, algumas dimensões apareceram de forma recorrente:

identidade: código da peça, marca, fabricante e referências equivalentes;
classificação: categoria e posição na hierarquia do catálogo;
aplicação: veículos, versões, motores, anos e eventuais restrições;
especificação: medidas, materiais e demais atributos técnicos;
comercialização: preço, disponibilidade, embalagem e garantia;
logística: peso, dimensões e condições de transporte;
proveniência: origem de cada dado e momento da última atualização.

Essa lista é uma síntese do problema, não um modelo universal. Categorias diferentes exigem atributos diferentes, e o significado de uma aplicação precisa ser validado com quem conhece a peça e o veículo.

Compatibilidade e descrição são problemas distintos

Uma das distinções mais úteis é separar a descrição do produto de sua aplicação.

A descrição responde perguntas como “qual é a marca?”, “quais são as medidas?” e “o que acompanha a embalagem?”. A aplicação responde “em quais veículos e configurações esta peça pode ser usada?”. Misturar as duas coisas em um campo de texto dificulta busca, comparação, atualização e validação.

Existem referências de mercado que tornam essa separação explícita. A Auto Care Association mantém o PIES para comunicação de informações de produto e o ACES para dados de aplicação. São padrões do mercado de reposição automotiva com origem e adoção predominante na América do Norte; portanto, devem ser avaliados antes de qualquer uso no contexto brasileiro. A menção aqui serve como exemplo externo de modelagem, não como registro de que os adotamos na NVPC.

Schema.org não é um catálogo interno

O texto original indicava AutomotiveBusiness, do Schema.org, como referência para compreender uma peça. Essa indicação era imprecisa: o tipo AutomotiveBusiness descreve um negócio automotivo, não uma autopeça.

O tipo Product é uma referência mais adequada para publicar dados estruturados de produto na web. Ainda assim, ele não substitui o modelo interno de um catálogo automotivo. A aplicação em veículos, as regras de equivalência, o histórico das fontes e as validações do negócio continuam exigindo estruturas próprias ou padrões especializados.

O catálogo precisa registrar incerteza

No início, é tentador tratar todo dado recebido como verdadeiro. Na prática, fontes podem divergir, códigos podem ser reutilizados e descrições podem chegar incompletas. Um catálogo precisa permitir que o time responda:

De onde veio este atributo?
Quando ele foi atualizado?
Quem o validou?
Há outra fonte em conflito?
Qual decisão deve ser revista se o dado mudar?

Essa rastreabilidade é tão importante quanto o valor do atributo. Sem ela, a correção de um erro vira investigação manual em planilhas, integrações e mensagens antigas.

Uma forma prática de começar

Minha recomendação para quem entra em um domínio técnico é começar com poucos casos reais e acompanhar o dado de ponta a ponta:

selecione uma categoria de peças;
reúna amostras de fontes diferentes;
identifique os atributos necessários para distinguir os itens;
modele separadamente produto, aplicação e oferta;
registre a origem de cada informação;
valide o modelo com especialistas do domínio;
só então amplie a cobertura do catálogo.

Essa sequência reduz uma classe comum de erro: criar primeiro uma taxonomia elegante e descobrir depois que ela não representa as decisões reais de compra, venda e compatibilidade.

Limites deste relato

Este é um registro retrospectivo do aprendizado descrito no texto publicado em

O material original não apresenta métricas de catálogo, conversão, devolução ou economia para clientes. Por isso, não uso esses resultados como evidência de sucesso e não tento atribuir ao trabalho um impacto que não foi documentado.

A conclusão que consigo sustentar é mais restrita: entrar no mercado de autopeças exigiu aprender primeiro a representar a peça. A plataforma vinha depois. Em produtos orientados por dados, compreender o objeto do domínio não é uma etapa preparatória; é parte da construção do próprio produto.