Michael JohnsonÉ fácil comparar dois criadores do IG com base em um único retrato do perfil; entender quem publica conteúdo de forma consistente e quais publicações recebem reações ao longo do tempo é mais difícil. Verificações pontuais misturam publicações de idades diferentes, e uma planilha manual fica desatualizada rapidamente. Uma solução prática é coletar mídias públicas em intervalos regulares, armazenar cada resposta como uma observação separada e calcular as mudanças com os próprios dados.
A seguir, apresentamos um fluxo de trabalho para profissionais de marketing, analistas ou desenvolvedores que precisam comparar semanalmente contas públicas em um mesmo nicho. Para obter os dados, usamos a IG Scraper API da jsonscraper; o Python cuida do agendamento, da normalização e do armazenamento do histórico. Este artigo dá continuidade ao tema do monitoramento de perfis e publicações concorrentes, com foco em um modelo uniforme de observações, adequado para relatórios comparativos.
Primeiro, defina exatamente o que comparar
A tarefa costuma ser formulada de maneira ampla: “encontrar criadores eficazes”. Para que o monitoramento seja tecnicamente útil, vale a pena restringi-la a perguntas mensuráveis: com que frequência as publicações são feitas, quais formatos aparecem, quantas curtidas e comentários públicos estão visíveis no momento da consulta e como esses números mudam após a publicação. Esse conjunto ajuda a selecionar contas para análise manual ou preparar um resumo comparativo.
Os contadores públicos são registros do momento da consulta. Por isso, a principal decisão de arquitetura não é um modelo complexo, mas armazenar o horário da coleta junto com o valor. Se você consultar as informações da mesma mídia todas as noites e sobrescrever a linha anterior, perderá o histórico necessário para calcular o crescimento. Em vez disso, armazene as observações de forma imutável: uma linha por publicação e horário de coleta.
A comparação deve se limitar a períodos iguais e publicações comparáveis. Por exemplo, é possível analisar publicações detectadas pela primeira vez em um mesmo mês ou levar em conta a idade da publicação em cada registro. Caso contrário, um vídeo publicado ontem parecerá ter desempenho inferior ao de uma publicação antiga simplesmente porque teve menos tempo para acumular reações.
Pipeline: requisição, normalização e histórico
Na versão mínima, o processo tem quatro etapas: obter uma lista de mídias públicas dos perfis selecionados, converter a resposta para um esquema comum, gravar as linhas em um repositório e gerar um relatório conforme um cronograma. A página da IG Scraper API apresenta o endereço básico e o mapa de endpoints, incluindo a rota de usuário para obter publicações em partes. Antes da integração, confira os parâmetros de cada rota e os exemplos de resposta na coleção do Postman.
O endereço básico da API é https://ig.jsonscraper.com. Para uma verificação inicial, a documentação mostra uma requisição de perfil por nome de usuário: GET /v1/user/by/username, com os parâmetros username, license_key e cache_timeout no exemplo publicado. Para obter publicações, está indicada a rota GET /v1/user/medias/chunk. Consulte a documentação dessa requisição para obter os argumentos exatos, os campos de continuação e a estrutura da resposta; não transfira o esquema de uma rota para outra.
import os
import requests
BASE = "https://ig.jsonscraper.com"
KEY = os.environ["JSONSCRAPER_LICENSE_KEY"]
def get_profile(username: str) -> dict:
response = requests.get(
f"{BASE}/v1/user/by/username",
params={
"username": username,
"license_key": KEY,
"cache_timeout": 60,
},
timeout=30,
)
response.raise_for_status()
return response.json()
print(get_profile("example_account"))
Este breve exemplo reproduz a rota de perfil documentada e mostra como passar parâmetros por HTTP GET. O valor cache_timeout=60 aparece no exemplo publicado; use-o apenas nas rotas que oferecem suporte ao parâmetro e confira os detalhes na documentação. Armazene a chave em uma variável de ambiente, não no código nem em um aplicativo de navegador.
Adicione a coleta de publicações
Depois de verificar o perfil, adicione uma requisição à lista de mídias. A página da API lista GET /v1/user/medias/chunk; para processar o resultado, siga a lógica de divisão em partes prevista na documentação. Consulte a descrição atual dessa requisição no Postman para saber os nomes dos parâmetros e quando encerrar a paginação, em vez de deduzi-los pelo nome da rota.
A seguir está um esqueleto da chamada de transporte, não um contrato pronto do endpoint: antes de executá-lo, preencha params com os argumentos documentados. Depois de receber a resposta, o adaptador deve ler apenas os campos confirmados pelo JSON real da rota selecionada.
def fetch_media_chunk(username: str, params: dict) -> dict:
query = {
**params,
"username": username,
"license_key": KEY,
}
response = requests.get(
f"{BASE}/v1/user/medias/chunk",
params=query,
timeout=30,
)
response.raise_for_status()
return response.json()
Em seguida, escreva uma função adaptadora para converter a resposta para o formato interno. Para a análise, podem ser úteis o identificador estável da publicação, o autor, o link, a data de publicação, o tipo de mídia e os contadores públicos disponíveis. Verifique os nomes e tipos exatos dos campos na documentação e em um exemplo de JSON. Se uma métrica estiver ausente, armazene-a como valor nulo em vez de substituí-la por zero: zero representa um contador medido sem ocorrências; um valor nulo representa a ausência de dados.
def normalize_media(item: dict, username: str, observed_at: str) -> dict:
# Especifique as chaves apenas depois de verificar o JSON do endpoint escolhido.
return {
"username": username,
"media_id": item.get("DOCUMENTED_MEDIA_ID_KEY"),
"media_url": item.get("DOCUMENTED_MEDIA_URL_KEY"),
"published_at": item.get("DOCUMENTED_PUBLISHED_AT_KEY"),
"media_type": item.get("DOCUMENTED_MEDIA_TYPE_KEY"),
"likes": item.get("DOCUMENTED_LIKE_COUNT_KEY"),
"comments": item.get("DOCUMENTED_COMMENT_COUNT_KEY"),
"observed_at": observed_at,
}
Substitua os nomes provisórios pelas chaves exatas da resposta do endpoint específico e fixe o mapeamento com um teste baseado em uma amostra de JSON armazenada. Assim, uma mudança no esquema será percebida ao atualizar a integração, e o exemplo não apresentará nomes de campos supostos como um contrato confirmado.
Armazene observações, não apenas valores atuais
Um arquivo CSV pode servir para protótipos; para uso regular, prefira PostgreSQL, Supabase ou um repositório analítico. A tabela de observações pode conter os campos username, media_id, published_at, observed_at, likes, comments e o JSON bruto. O par media_id e observed_at define um registro único. Uma tabela separada de perfis armazena a lista de contas monitoradas e a data em que foram adicionadas ao monitoramento.
Guardar a resposta bruta é útil para depuração e reconstrução dos dados normalizados. Limite o período de retenção de acordo com o objetivo do projeto e as regras da organização, controle o acesso às tabelas e não colete informações desnecessárias para a análise escolhida. Para CRM e ações de marketing direto, determine separadamente a base legal aplicável: a disponibilidade técnica de dados públicos, por si só, não resolve essa questão.
CREATE TABLE media_observations (
username TEXT NOT NULL,
media_id TEXT NOT NULL,
media_url TEXT,
published_at TIMESTAMPTZ,
observed_at TIMESTAMPTZ NOT NULL,
media_type TEXT,
likes BIGINT,
comments BIGINT,
raw_json JSONB,
PRIMARY KEY (media_id, observed_at)
);
Adicione registros em lote após verificar a resposta com sucesso. Em execuções repetidas da mesma tarefa, a combinação da chave primária impede a criação acidental de um registro duplicado; no aplicativo, é possível usar uma inserção que ignore conflitos. Uma nova execução em outro horário salvará uma linha separada e dará continuidade à série temporal.
Calcule métricas que respondam à pergunta
A métrica básica do ritmo de publicação é o número de mídias únicas de uma conta em um intervalo escolhido. É fácil calculá-la com base em published_at, se esse campo estiver presente e for interpretado corretamente. Para avaliar a mudança nas reações públicas, compare duas observações do mesmo media_id: a variação absoluta de curtidas é o contador mais recente menos o anterior; a variação relativa é essa diferença dividida pelo valor anterior. O mesmo cálculo vale para comentários.
Se o valor anterior for zero ou estiver ausente, o crescimento relativo não está definido; mostre a diferença absoluta e indique claramente que não há uma base para calcular a porcentagem. Os contadores podem mudar entre as observações, portanto o relatório deve informar o intervalo entre os registros e o horário da coleta mais recente. Esses detalhes ajudam o leitor a interpretar os números corretamente.
def growth(previous, current):
if previous is None or current is None:
return {"delta": None, "rate": None}
delta = current - previous
rate = None if previous == 0 else delta / previous
return {"delta": delta, "rate": rate}
Não reduza as contas a uma única classificação sem pesos explicáveis. Em geral, um relatório prático apresenta lado a lado o número de publicações, a mediana de curtidas e comentários por publicação, a distribuição de formatos e a mudança nas reações em intervalos de idade equivalentes. A mediana reduz o efeito de uma publicação atípica; o número de publicações mostra o tamanho da amostra na qual a comparação se baseia.
Há duas maneiras de considerar a idade da publicação. A primeira é registrar os contadores regularmente, por exemplo, em intervalos iguais após a primeira detecção da mídia. A segunda é comparar publicações que se enquadrem em uma mesma faixa de tempo, usando observações de idades aproximadas. Se uma execução agendada não acontecer, não apresente a variação observada como um crescimento exato de um dia: calcule o intervalo com base nos registros de horário.
Automatize a execução e o controle de qualidade
Agende a coleta com cron, GitHub Actions ou um orquestrador de ETL. A sequência da tarefa é simples: ler a lista de contas, solicitar as partes necessárias, verificar o status HTTP e a estrutura da resposta, normalizar os dados, salvar o registro e registrar a execução. Para cada execução, anote o número de contas processadas, mídias, erros e a duração — isso ajudará a distinguir uma mudança real de atividade de uma falha na coleta.
Para erros temporários, use um número limitado de tentativas com pausas; se houver uma resposta de erro, salve o contexto da requisição sem a chave secreta. Não execute um loop infinito pelos cursores: a parada deve ocorrer de acordo com as condições de conclusão indicadas na resposta do endpoint. Se a documentação definir limites ou regras de uso, ajuste a frequência e o tamanho da amostra de acordo com eles.
O parâmetro cache_timeout está indicado na página da IG API para as rotas compatíveis. O cache é útil quando uma nova requisição em um curto intervalo não acrescenta valor; escolha o intervalo de coleta de acordo com a pergunta analítica. Por exemplo, um registro diário é mais adequado a uma análise semanal do que requisições repetidas e frequentes aos mesmos perfis sem um objetivo específico.
Antes de ativar o agendamento regular, teste uma pequena amostra. Salve um exemplo de resposta, confira os identificadores e as datas, compare os campos normalizados com o JSON original e verifique manualmente algumas linhas. Adicione testes para valores ausentes, listas vazias e formatos inesperados. Quando a API mudar, essas verificações detectarão o problema mais rapidamente do que um relatório inconsistente no fim da semana.
Onde a IA pode ser útil
A IA é adequada à etapa final: resumir brevemente os resultados já calculados. Envie ao modelo dados agregados e links para as publicações, em vez de todo o arquivo bruto; por exemplo, o número de mídias por semana, as reações públicas medianas e uma lista de publicações com as maiores variações em um intervalo definido. Peça ao modelo que formule observações e indique os identificadores dos registros que as fundamentam.
É melhor deixar o cálculo das métricas a cargo de código convencional, para que a mesma regra produza resultados reproduzíveis. O modelo pode preparar um resumo textual, agrupar legendas em temas previamente definidos ou sugerir perguntas para verificação manual. Para classificação temática, armazene o rótulo do modelo separadamente da legenda original e indique a versão da instrução ou do classificador, para que mudanças futuras não alterem o histórico sem que isso seja percebido.
Não transforme um relatório automático em uma decisão automática sobre contratação, contrato ou avaliação de uma pessoa específica. Use dados públicos para uma análise limitada de conteúdo e verifique as conclusões manualmente, sobretudo quando elas influenciarem decisões comerciais. Isso preserva a utilidade do monitoramento e separa os contadores mensuráveis da interpretação.
Como é o resultado
Depois de alguns ciclos de coleta, haverá uma tabela mostrando quando cada publicação foi detectada, quantas reações havia em cada observação e como as métricas mudaram. Um resumo semanal poderá responder a perguntas práticas: quem publicou com regularidade, quais formatos foram usados com mais frequência, quais publicações receberam reações entre registros comparáveis e onde ainda faltam dados para uma comparação confiável.
Esse processo ajuda a substituir verificações manuais esporádicas por uma análise reproduzível. Ele não substitui uma análise qualitativa do conteúdo: as métricas descrevem a frequência de publicação e as reações públicas disponíveis, enquanto o significado, o público e a adequação à marca exigem uma avaliação separada. Em contrapartida, um cronograma uniforme, um histórico preservado e uma lógica de cálculo explícita tornam essas avaliações verificáveis e úteis para a equipe.
Para começar, acesse a página da IG Scraper API, confira os parâmetros da rota de publicações na documentação do Postman, implemente o adaptador em uma conta de teste e salve o primeiro registro. Depois de confirmar o esquema, adicione o agendamento, o controle de erros e um relatório com as métricas escolhidas.