Metodologia de screeners

O universo padrão do screener é "todas as ações ordinárias e ETFs listados nos EUA com listagem primária na NYSE, NASDAQ, NYSE-American ou Cboe BZX, mais os 200 pares cripto principais por volume spot rolling de 30 dias na Binance e Coinbase". O usuário pode restringi-lo ao S&P 500, Nasdaq 100, Russell 2000, ETFs setoriais ou a uma watchlist personalizada.

Filtros que usam dados de preço/volume são atualizados a cada corrida e leem a última barra fechada na resolução escolhida (padrão: 1D). Filtros que usam fundamentals (P/L, market cap, setor, indústria) são atualizados toda noite a partir do snapshot de fundamentals da Polygon. Filtros que usam sinais derivados (RSI, breakouts, gaps) são recomputados a cada corrida a partir do OHLCV subjacente — não são cacheados em nível de valor.

Filtros de preço — último preço entre US$ X e Y, gap intraday ≥ X%, retorno nos últimos N dias ≥ X%. Calculados a partir de /history. Não há ajuste de sobrevivência nos filtros ao vivo, pois o universo ao vivo, por definição, não contém deslistados.

Filtros de volume — volume médio em dólares dos últimos N dias ≥ US$ X, volume de hoje ≥ X× a média de N dias. Os limiares em volume em dólares são preferíveis aos limiares em volume em ações, pois lidam corretamente com ações de preço alto (BRK.A) e baixo (penny stocks).

Filtros de indicadores — RSI(14) ≤ X (sobrevenda) ou ≥ Y (sobrecompra), cruzamento de sinal MACD, SMA 50 vs 200, ATR(14) ≥ X% do preço (regime de volatilidade). Todos os indicadores usam fórmulas de Wilder onde aplicável; veja a página de metodologia de sinais para definições exatas.

Filtros fundamentalistas — market cap, P/L, P/VP, dividend yield, crescimento de EPS YoY, setor, indústria. Fonte: fundamentals da Polygon na data do último trimestre fechado.

Uma corrida de screener é um POST sem estado para /screener/run carregando o payload de filtros codificado em JSON. A API de dados resolve cada filtro contra slices OHLCV em cache no Redis (TTL 60 s na barra mais recente, 5 minutos em barras anteriores), computa sinais derivados em tempo real, intersecciona os conjuntos de símbolos e retorna uma lista de tickers deduplicada, ordenada por liquidez (volume em dólares decrescente).

A UI do screener dentro do app e as páginas SSR públicas /screeners/{slug} chamam o mesmo endpoint com o mesmo conjunto canônico de filtros, portanto o que aparece na página pública é bit a bit o mesmo que apareceria ao abrir o screener no terminal naquele instante (modulo a janela de cache de ~60 s).

Páginas públicas de screener mostram apenas os 50 melhores resultados, ranqueados por liquidez. O conjunto completo está disponível no terminal.

Screeners que usam resoluções intraday durante o pregão regular podem produzir resultados inconsistentes entre rodadas dentro do mesmo minuto, pois a barra em formação é excluída mas seu volume é monotonicamente crescente. É proposital — cotar a barra em formação geraria look-ahead em qualquer alerta do usuário construído em cima do screener.

Screeners cripto excluem pares com menos de 14 dias de histórico, mesmo se passarem tecnicamente nos filtros do usuário. Isso evita artefatos de "pump por novo listing".

O catálogo canônico de screeners (src/lib/seo/screener-catalog.ts) lista os screeners com URL pública estável. Adicionamos um slug apenas se (a) os filtros subjacentes forem inequívocos e independentes de idioma, (b) o conjunto de resultados teve pelo menos um match em cada pregão dos últimos 90 dias, e (c) o conceito da estratégia está documentado em um artigo Learn.

Screeners que dependem do contexto de um usuário específico (sua watchlist, indicadores próprios, notas privadas) não recebem slug público.