Monitoramento de preços de concorrentes: como montar um pipeline com API, PLP e PDP
Quer testar? Acesse o dashboard e ganhe 100 créditos grátis para começar.
Ir para o DashboardMonitorar preço de concorrente parece simples até o processo sair da planilha.
No começo, alguém abre Mercado Livre, Amazon, Shopee, Magalu, Casas Bahia ou Netshoes, pesquisa o produto, tira print, copia o preço e coloca tudo em uma aba do Excel. Isso funciona para 20 SKUs, uma vez por semana, em uma categoria pequena.
O problema aparece quando o negócio precisa responder perguntas de verdade:
- Qual concorrente mudou preço nas últimas 24 horas?
- O menor preço está vindo do varejista principal ou de um seller terceiro?
- O produto ficou indisponível ou só mudou de anúncio?
- O frete alterou a competitividade do preço final?
- A oferta patrocinada está distorcendo a visão da categoria?
- O preço caiu em uma plataforma, mas não caiu nas outras?
Nesse ponto, monitoramento de preços de concorrentes deixa de ser uma tarefa operacional e vira um pipeline de dados. E pipeline de dados não deveria depender de captura manual, print ou scraper frágil.
Este guia mostra como estruturar esse pipeline usando uma API de monitoramento de preços, com dois movimentos centrais: PLP para descobrir o mercado e PDP para enriquecer cada item relevante.
TL;DR
Para montar um monitoramento de preços em produção, você precisa separar a coleta em duas etapas:
- PLP, ou página de listagem, para buscar produtos por keyword, categoria, URL ou página.
- PDP, ou página de detalhe, para enriquecer cada produto com preço, seller, disponibilidade, atributos, avaliações, frete e URL canônica.
Com a GeckoAPI, o fluxo fica padronizado em um único endpoint:
https://api.geckoapi.com.br/v1/extract
Você troca target e type conforme a fonte e o tipo de extração:
mercadolivre.com.brcomplpoupdpamazon.com.brcomplpoupdpshopee.com.brcomplpoupdpmagazineluiza.com.brcomplpoupdpcasasbahia.com.brcomplpoupdpnetshoes.com.br,aliexpress.com,temu.come outras fontes suportadas
O resultado é um JSON que pode alimentar BI, pricing, CRM, catálogo, alertas, workflows internos e agentes de IA.
O erro mais comum: monitorar só uma URL
Muitos projetos de web scraping de preços começam com uma lista fixa de URLs de produto.
O raciocínio é compreensível: se você quer acompanhar um notebook, uma cafeteira, um tênis ou um suplemento, basta salvar a URL do produto e consultar essa página todos os dias.
Só que esse modelo quebra rápido.
Em marketplaces, o concorrente real nem sempre está na mesma URL. O preço vencedor pode aparecer em outro anúncio, em outro seller, em um produto equivalente, em uma variação diferente ou em uma oferta com frete mais agressivo. A página monitorada também pode sair do ar, perder estoque, mudar a URL canônica ou deixar de representar a melhor oferta da busca.
Monitorar só PDP responde:
“O que aconteceu com este anúncio específico?”
Mas o time de pricing normalmente precisa responder:
“O que aconteceu com o mercado para este produto ou categoria?”
Essa segunda pergunta exige PLP.
PLP e PDP: a base do monitoramento sério
Na GeckoAPI, usamos dois tipos de extração para e-commerce:
| Tipo | O que faz | Quando usar |
|---|---|---|
| PLP | Extrai resultados de busca ou listagem | Descobrir produtos, anúncios, sellers e posições por keyword, categoria ou URL |
| PDP | Extrai a página de detalhe de um produto | Enriquecer um item com preço atual, atributos, disponibilidade, seller, avaliações e dados completos |
Pense em PLP como radar e PDP como ficha técnica.
A PLP mostra quais itens aparecem para uma busca como iphone 16, creatina, notebook gamer, air fryer ou tenis corrida masculino. Ela ajuda a entender ranking, amplitude da oferta, menor preço, sellers presentes e produtos novos.
A PDP aprofunda os itens que importam. Ela captura campos que muitas vezes não cabem no card da busca: preço regular, preço à vista, parcelamento, estoque, seller principal, outros sellers, atributos técnicos, variações, avaliações, imagens e disponibilidade.
Um pipeline maduro usa os dois.
Arquitetura recomendada
Um fluxo pragmático para monitoramento de preços concorrentes costuma seguir esta ordem:
- Definir SKUs, categorias, marcas ou keywords monitoradas.
- Executar PLP nas fontes relevantes.
- Normalizar e deduplicar os resultados encontrados.
- Selecionar os itens que merecem enriquecimento.
- Executar PDP nas URLs priorizadas.
- Salvar um snapshot com timestamp.
- Comparar com o snapshot anterior.
- Gerar alertas, dashboards ou recomendações de ação.
Na prática, isso vira algo assim:
keywords e categorias
-> PLP por marketplace
-> dedupe por URL, SKU, seller, título e atributos
-> PDP dos itens relevantes
-> histórico de preço, estoque e seller
-> alertas e dashboards
Essa separação evita dois extremos ruins:
- consultar PDP demais e gastar crédito com produto irrelevante;
- consultar PLP apenas e tomar decisão com dados superficiais.
Exemplo 1: descobrir ofertas com PLP
Para buscar produtos no Mercado Livre por keyword, você pode usar o endpoint de extração com target: "mercadolivre.com.br" e type: "plp".
curl -X POST "https://api.geckoapi.com.br/v1/extract" \
-H "Authorization: Bearer SUA_CHAVE" \
-H "Content-Type: application/json" \
-d '{
"target": "mercadolivre.com.br",
"type": "plp",
"keyword": "notebook gamer",
"page": 1
}'
A resposta de PLP traz uma lista de itens com campos úteis para triagem, como:
items[].nameitems[].urlitems[].priceitems[].currencyitems[].sellerNameitems[].sellerIditems[].aggregateRatingtotalResultsnextPage
Documentação técnica: Mercado Livre PLP.
Esse passo é bom para descobrir quem aparece na busca, quais anúncios estão competindo, qual faixa de preço domina a primeira página e quais URLs devem ir para PDP.
Exemplo 2: enriquecer produto com PDP
Depois de escolher uma URL retornada pela PLP, você pode buscar o detalhe do produto:
curl -X POST "https://api.geckoapi.com.br/v1/extract" \
-H "Authorization: Bearer SUA_CHAVE" \
-H "Content-Type: application/json" \
-d '{
"target": "mercadolivre.com.br",
"type": "pdp",
"url": "https://produto.mercadolivre.com.br/MLB-1234567890-produto-exemplo-_JM"
}'
A resposta de PDP aprofunda o item com campos como:
namepriceregularPricecashPriceavailabilitystockQuantitysellerNamesellerIdsellerLevelfreeShippingsoldCountaggregateRatingbrandadditionalPropertiesotherSellers
Documentação técnica: Mercado Livre PDP.
É esse enriquecimento que permite separar preço de vitrine, preço real, seller competitivo, estoque, reputação e sinais de conversão.
O que salvar no histórico
Um erro comum é salvar só price.
Preço isolado é pouco. Para explicar uma mudança competitiva, você precisa preservar o contexto do snapshot. No mínimo, salve:
| Campo | Por que importa |
|---|---|
source | Permite comparar Mercado Livre, Amazon, Shopee, Magalu e outras fontes |
keyword ou category | Mostra de qual busca aquele item veio |
url ou canonicalUrl | Mantém rastreabilidade do anúncio |
name | Ajuda em auditoria humana e matching |
sellerName e sellerId | Separa varejista principal de seller terceiro |
price, regularPrice, cashPrice | Diferencia preço promocional, preço de referência e preço à vista |
freeShipping ou frete | Afeta o preço final percebido |
availability e stockQuantity | Evita tratar ruptura como estratégia de preço |
aggregateRating e reviewCount | Ajuda a comparar ofertas com qualidade percebida diferente |
extractedAt | Permite histórico, variação e alertas |
Para BI, o mais simples é tratar cada coleta como um snapshot imutável. Você não atualiza a linha antiga. Você insere uma nova linha com timestamp e calcula variações depois.
Alertas que realmente ajudam
Monitoramento de preços só cria valor quando vira ação. Alguns alertas úteis:
- Queda de preço abaixo do seu piso: concorrente rompeu um limite definido.
- Mudança de seller vencedor: o menor preço saiu do seller oficial e foi para marketplace.
- Ruptura de estoque: concorrente ficou indisponível e abriu espaço para campanha.
- Entrada de novo seller: um novo vendedor começou a competir na categoria.
- Mudança de frete: preço do produto não mudou, mas o custo final mudou.
- Aumento de reviews ou vendas: sinal de tração em um produto concorrente.
- Produto patrocinado recorrente: um concorrente está comprando visibilidade de forma agressiva.
O objetivo não é disparar alerta para qualquer centavo. O objetivo é separar ruído de movimento comercial relevante.
Como usar múltiplas fontes sem virar bagunça
Cada marketplace expõe dados de um jeito diferente. O nome do seller, o preço original, a disponibilidade, a avaliação e o identificador do produto podem variar bastante.
É aqui que uma API pronta ajuda: seu sistema consome o mesmo endpoint e recebe JSON estruturado, mesmo quando a fonte muda.
Exemplos de fontes úteis para monitoramento de e-commerce:
- API para Mercado Livre
- API para Amazon
- API para Shopee
- API para Magazine Luiza
- API para Casas Bahia
- API para Netshoes
- API para AliExpress
- API para Temu
Você ainda precisa definir sua modelagem interna, mas deixa de escrever um scraper separado para cada fonte.
Uma estrutura mínima para normalização pode ser:
{
"source": "mercadolivre.com.br",
"query": "notebook gamer",
"productUrl": "https://produto.mercadolivre.com.br/...",
"title": "Notebook Gamer 16GB SSD 512GB",
"sellerName": "Loja Exemplo",
"price": 4299.9,
"regularPrice": 4799.9,
"currency": "BRL",
"available": true,
"freeShipping": true,
"rating": 4.8,
"reviewCount": 182,
"collectedAt": "2026-05-21T12:00:00-03:00"
}
Essa camada normalizada é o que o dashboard, o time comercial e o modelo de IA devem consumir. O payload bruto continua útil para auditoria, mas a operação diária precisa de campos previsíveis.
Por que não manter scraper próprio?
Construir scraper de preço parece barato no primeiro teste. Um requests.get, um seletor CSS e alguns produtos salvos em JSON dão a sensação de progresso.
O custo aparece depois:
- o HTML muda;
- o preço passa a carregar via JavaScript;
- a paginação muda;
- o site devolve CAPTCHA;
- o IP começa a ser bloqueado;
- o campo vem vazio sem erro explícito;
- a busca retorna produtos patrocinados misturados com orgânicos;
- o mesmo produto aparece com variações diferentes;
- cada fonte exige um parser, um retry e uma normalização diferente.
Para aprendizado, scraping manual é válido. Para uma operação de pricing, BI ou inteligência competitiva, ele tende a virar um produto interno caro.
Se quiser comparar as duas abordagens em mais detalhe, veja também: Web Scraping vs API Pronta. Para o contexto jurídico de dados públicos, veja Web Scraping é Legal no Brasil?.
Onde a GeckoAPI entra
A GeckoAPI resolve a camada de extração e entrega dados públicos estruturados por API.
Você não precisa manter um scraper por marketplace. Seu time chama o mesmo endpoint, ajusta target, type e os parâmetros da busca, e recebe JSON para alimentar seu pipeline.
Isso é especialmente útil para:
- times de pricing, que precisam acompanhar preço e posição competitiva;
- e-commerces e marcas, que monitoram sellers, ruptura e paridade de canal;
- marketplaces e ERPs, que querem oferecer inteligência de mercado dentro do produto;
- BI e revenue operations, que precisam de histórico confiável;
- agentes de IA, que precisam consultar dados reais antes de responder.
Para casos mais avançados, também é possível combinar APIs e workflows. Um fluxo pode começar em uma PLP, abrir PDPs, consolidar sellers, enriquecer empresas e gerar um artifact final para CRM ou BI.
Checklist de implementação
Antes de começar, defina:
- Fontes: quais marketplaces realmente influenciam sua decisão.
- Keywords e categorias: quais buscas representam o mercado.
- Frequência: horário e recorrência por criticidade.
- Critério de matching: como comparar produtos equivalentes.
- Campos obrigatórios: preço, seller, disponibilidade, frete e URL são o mínimo.
- Histórico: onde salvar snapshots e por quanto tempo.
- Alertas: quais variações merecem ação humana.
- Auditoria: como voltar ao payload e à URL original.
Com isso definido, a parte técnica fica mais simples: PLP descobre, PDP enriquece, seu banco guarda histórico e seus alertas apontam o que mudou.
Conclusão
Monitoramento de preços não é só extrair preço. É entender o movimento do mercado com contexto suficiente para agir.
Se você monitora apenas URLs fixas, perde descoberta. Se monitora apenas listagens, perde profundidade. O modelo PLP + PDP resolve essa divisão: primeiro você encontra o mercado, depois aprofunda os itens que importam.
Com uma API pronta como a GeckoAPI, seu time não precisa manter browser automation, proxy, parser e normalização para cada site. Você ganha uma camada de dados estruturados para transformar concorrência, preço, seller, estoque e disponibilidade em decisão.
Para começar pela prática, veja a documentação de Mercado Livre PLP, Mercado Livre PDP, Shopee PLP ou explore a lista completa de APIs disponíveis.
Quer testar?
Acesse o dashboard e ganhe 100 créditos grátis para começar. Sem cartão de crédito.
Criar conta grátis