Como Avaliar Fornecedores de Dados em Tempo Real

Há alguns anos, integrei um provedor de dados da Amazon em um serviço de precificação. A página de vendas dizia "dados em tempo real". A documentação dizia "alta taxa de sucesso". Ambos eram tecnicamente verdadeiros e ambos eram inúteis.

O que aprendi eventualmente: o serviço de precificação estava lendo de um cache atualizado uma vez por dia, e "alta taxa de sucesso" contava respostas HTTP 200, que incluíam um número significativo de páginas de captcha. Enviamos duas semanas de recomendações de preços construídas parcialmente com respostas de páginas bloqueadas, porque nosso cliente apenas verificou o código de status.

Este post é o teste que eu gostaria de ter feito primeiro. Leva uma tarde, são cerca de cem linhas de Python e transforma cada alegação vaga do fornecedor em quatro números que você pode colocar em um painel.

Os quatro números que realmente importam

Antes do código, as definições. Esses quatro são a diferença entre um provedor no qual você pode construir e um provedor que você precisa cuidar.

A definição da taxa de sucesso merece ênfase, porque é onde a maioria das verificações caseiras falha. Um HTTP 200 que retorna uma página de detecção de bot é uma falha, não um sucesso. Se seu cliente apenas olha para o código de status, esse registro ruim flui diretamente para o seu banco de dados e você descobre duas semanas depois, quando alguém pergunta por que o painel parece estranho.

Sobre p95: isso determina seu timeout. Se p95 é cinco segundos e você define um timeout de três segundos, você está descartando uma parte das requisições que teriam sido bem-sucedidas. Defina para dez segundos e você desacelera todo o pipeline. Um ponto de partida razoável é 1,5× p95, com um limite de retry de dois. Mais retries do que isso geralmente significa que você está sendo limitado, e tentar novamente em uma limitação piora a situação.

Por que a precificação por requisição é a unidade errada

Aqui está a parte que muda a forma como você lê uma página de preços.

Uma requisição falhada ainda cobra. Uma página bloqueada ainda cobra. Uma resposta faltando o campo que você precisa ainda cobra.

Então, a unidade que vale a pena comparar é o custo por mil registros utilizáveis:

custo por 1k registros utilizáveis = (gasto mensal ÷ registros parseados com sucesso com todos os campos obrigatórios) × 1000

Exemplo prático, porque a diferença é contra-intuitiva:

• Plano A: $1,20 por 1k requisições, 92% de sucesso, 88% de completude de campo. A parte utilizável é aproximadamente 81%, então o custo real é cerca de $1,48 por 1k registros utilizáveis.
• Plano B: $1,60 por 1k requisições, 99% de sucesso, 98% de completude de campo. A parte utilizável é cerca de 97%, então o custo real é cerca de $1,65 por 1k registros utilizáveis.

O Plano A parece 25% mais barato na tabela de preços. A verdadeira diferença é de cerca de 10%. Adicione as horas de depuração que o Plano A gerará e a classificação geralmente se inverte.

Portanto, a pergunta a fazer a um fornecedor nunca é "quanto por mil requisições". É: como você define a taxa de sucesso, qual é a sua completude de campo e as falhas são cobradas?

O pipeline de quatro camadas

Qualquer que seja o caminho que você escolha, a cadeia tem a mesma forma. O que difere é quais camadas você possui.

Amazon páginas públicas (produto / busca / revisão / mais vendidos / patrocinados)
        ↓
[Coleta]   anti-bot · renderização de navegador · proxies e geo · retries
        ↓
[Estruturação]  parsing · normalização de campo · contrato de tipo · semântica de falha
        ↓
[Entrega]     REST API   ── ou ──   ferramentas MCP
        ↓
Seu aplicativo / pipeline de dados / agente de IA

Quatro rotas, e como elas dividem a propriedade:

Escolher um caminho é realmente decidir quais camadas você deseja possuir. Mais camadas significam mais controle e mais responsabilidade.

Uma coisa que vale a pena afirmar claramente: se você só precisa de dados vinculados à sua própria conta de vendedor, use a API oficial SP e pule os terceiros completamente. Pedidos, inventário, suas próprias listagens. É o caminho mais compatível e barato, e recomendar qualquer coisa paga para esse trabalho seria desonesto.

A verdadeira bifurcação é se você precisa de fatos do mercado público — concorrentes, categorias, resultados de busca, colocações patrocinadas. É aí que as outras três rotas se tornam relevantes.

Construa o teste

Chega de teoria. Aqui está o script. Ele amostra em diferentes marketplaces e tipos de objetos, e depois relata todos os quatro números, além de uma divisão de quais campos estão faltando.

#!/usr/bin/env python3
"""
Teste de aceitação da API de Dados da Amazon.
Amostras N chamadas em diferentes marketplaces e tipos de objetos, e depois relata
latência mediana, latência p95, taxa de sucesso e completude de campo.
"""


import argparse
import os
import statistics
import time
from concurrent.futures import ThreadPoolExecutor, as_completed
from dataclasses import dataclass, field

import requests

API_BASE