Monitoramento de preços de concorrentes: como montar um pipeline com API, PLP e PDP

21 de maio de 2026 · 11 min · Equipe GeckoAPI
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 Dashboard

Monitorar 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:

  1. PLP, ou página de listagem, para buscar produtos por keyword, categoria, URL ou página.
  2. 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.br com plp ou pdp
  • amazon.com.br com plp ou pdp
  • shopee.com.br com plp ou pdp
  • magazineluiza.com.br com plp ou pdp
  • casasbahia.com.br com plp ou pdp
  • netshoes.com.br, aliexpress.com, temu.com e 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:

TipoO que fazQuando usar
PLPExtrai resultados de busca ou listagemDescobrir produtos, anúncios, sellers e posições por keyword, categoria ou URL
PDPExtrai a página de detalhe de um produtoEnriquecer 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:

  1. Definir SKUs, categorias, marcas ou keywords monitoradas.
  2. Executar PLP nas fontes relevantes.
  3. Normalizar e deduplicar os resultados encontrados.
  4. Selecionar os itens que merecem enriquecimento.
  5. Executar PDP nas URLs priorizadas.
  6. Salvar um snapshot com timestamp.
  7. Comparar com o snapshot anterior.
  8. 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[].name
  • items[].url
  • items[].price
  • items[].currency
  • items[].sellerName
  • items[].sellerId
  • items[].aggregateRating
  • totalResults
  • nextPage

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:

  • name
  • price
  • regularPrice
  • cashPrice
  • availability
  • stockQuantity
  • sellerName
  • sellerId
  • sellerLevel
  • freeShipping
  • soldCount
  • aggregateRating
  • brand
  • additionalProperties
  • otherSellers

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:

CampoPor que importa
sourcePermite comparar Mercado Livre, Amazon, Shopee, Magalu e outras fontes
keyword ou categoryMostra de qual busca aquele item veio
url ou canonicalUrlMantém rastreabilidade do anúncio
nameAjuda em auditoria humana e matching
sellerName e sellerIdSepara varejista principal de seller terceiro
price, regularPrice, cashPriceDiferencia preço promocional, preço de referência e preço à vista
freeShipping ou freteAfeta o preço final percebido
availability e stockQuantityEvita tratar ruptura como estratégia de preço
aggregateRating e reviewCountAjuda a comparar ofertas com qualidade percebida diferente
extractedAtPermite 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:

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:

  1. Fontes: quais marketplaces realmente influenciam sua decisão.
  2. Keywords e categorias: quais buscas representam o mercado.
  3. Frequência: horário e recorrência por criticidade.
  4. Critério de matching: como comparar produtos equivalentes.
  5. Campos obrigatórios: preço, seller, disponibilidade, frete e URL são o mínimo.
  6. Histórico: onde salvar snapshots e por quanto tempo.
  7. Alertas: quais variações merecem ação humana.
  8. 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