Comparar a dos creadores de IG a partir de una sola captura de sus perfiles es sencillo; averiguar quién publica contenido de forma constante y qué publicaciones reciben reacciones con el tiempo es más difícil. Las comprobaciones puntuales mezclan publicaciones de distintas edades y una hoja de cálculo manual queda obsoleta rápidamente. Una solución práctica consiste en recopilar medios públicos según un calendario, guardar cada respuesta como una observación independiente y calcular los cambios con datos propios.

A continuación se presenta un flujo de trabajo para profesionales del marketing, analistas o desarrolladores que necesitan comparar semanalmente cuentas públicas de un mismo nicho. Para obtener los datos se usa IG Scraper API de jsonscraper; Python se encarga de la programación, la normalización y el almacenamiento del historial. Este artículo amplía el tema del seguimiento de perfiles y publicaciones de la competencia, con el foco en un modelo unificado de observaciones que sirva para elaborar informes comparativos.
Primero, define qué quieres comparar
La tarea suele plantearse de forma amplia: «encontrar creadores eficaces». Para que el seguimiento sea técnicamente útil, conviene concretarla en preguntas medibles: con qué frecuencia se publican contenidos, qué formatos aparecen, cuántos «Me gusta» y comentarios públicos se observan al realizar la consulta y cómo cambian esas cifras después de publicar. Este conjunto ayuda a seleccionar cuentas para analizarlas manualmente o preparar un resumen comparativo.
Los contadores públicos son capturas del momento en que se realiza la consulta. Por eso, la decisión clave de arquitectura no consiste en usar un modelo complejo, sino en guardar la hora de recopilación junto con el valor. Si cada noche se recuperan los datos del mismo medio y se sobrescribe la fila anterior, desaparece el historial necesario para calcular el crecimiento. En su lugar, almacena las observaciones de forma inmutable: una fila por publicación y hora de recopilación.
La comparación debe limitarse a periodos iguales y publicaciones comparables. Por ejemplo, puedes analizar publicaciones detectadas por primera vez en un mismo mes natural o tener en cuenta la antigüedad de cada publicación en cada captura. De lo contrario, un reel de ayer parecerá tener menos rendimiento que una publicación antigua simplemente porque ha tenido menos tiempo para acumular reacciones.
Flujo de trabajo: solicitud, normalización e historial
En su versión mínima, el proceso consta de cuatro pasos: obtener una lista de medios públicos de los perfiles seleccionados, adaptar la respuesta a un esquema común, guardar las filas en un repositorio y generar un informe según un calendario. La página de IG Scraper API muestra la dirección base y el mapa de endpoints, incluida la ruta de usuario para obtener publicaciones por fragmentos. Antes de integrar cada ruta, comprueba sus parámetros y los ejemplos de respuesta en la colección de Postman.
La dirección base de la API es https://ig.jsonscraper.com. Para una comprobación inicial, la documentación muestra una solicitud de perfil por nombre de usuario: GET /v1/user/by/username con los parámetros username, license_key y cache_timeout en el ejemplo publicado. Para obtener publicaciones se indica la ruta GET /v1/user/medias/chunk. Consulta la documentación de esa solicitud para conocer sus argumentos exactos, los campos de continuación y la estructura de la respuesta; no traslades el esquema de una ruta a otra.
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 ejemplo reproduce la ruta documentada para perfiles y muestra cómo enviar parámetros mediante HTTP GET. El valor cache_timeout=60 aparece en el ejemplo publicado; úsalo solo en las rutas que admitan el parámetro y verifica los detalles en la documentación. Guarda la clave en una variable de entorno, no en el código ni en una aplicación de navegador.
Conecta la recuperación de publicaciones
Una vez comprobado el perfil, añade una solicitud a la lista de medios. La página de la API enumera GET /v1/user/medias/chunk; para procesar el resultado, utiliza la lógica de fragmentación que establece la documentación. Los nombres de los parámetros y la condición que indica el fin de la paginación deben obtenerse de la descripción actual de esta solicitud en Postman, no deducirse del nombre de la ruta.
A continuación se muestra la estructura básica de una llamada de transporte, no un contrato completo del endpoint: antes de ejecutarla, rellena params con argumentos documentados. Una vez recibida la respuesta, el adaptador debe leer únicamente los campos confirmados por el JSON real de la ruta seleccionada.
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()
Después, escribe una función adaptadora que convierta la respuesta al formato interno. Para el análisis pueden ser útiles un identificador estable de la publicación, el autor, el enlace, la fecha de publicación, el tipo de medio y los contadores públicos disponibles. Comprueba los nombres y tipos exactos de los campos en la documentación y en el ejemplo de JSON. Si falta una métrica, guárdala como valor vacío en lugar de asignarle cero: cero significa que se midió un contador sin actividad; un valor vacío, que no hay datos.
def normalize_media(item: dict, username: str, observed_at: str) -> dict:
# Indica las claves solo después de comprobar el JSON del endpoint seleccionado.
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,
}
Sustituye los nombres de marcador de posición por las claves exactas de la respuesta del endpoint correspondiente y fija el mapeo con una prueba basada en un ejemplo de JSON guardado. Así, cualquier cambio de esquema se detectará al actualizar la integración y el ejemplo no presentará nombres de campo hipotéticos como si fueran un contrato confirmado.
Guarda las observaciones, no solo los valores actuales
Para un prototipo basta un CSV; para un uso periódico, puedes recurrir a PostgreSQL, Supabase o un almacén analítico. Una tabla de observaciones puede incluir los campos username, media_id, published_at, observed_at, likes, comments y el JSON sin procesar. La combinación de media_id y observed_at identifica una captura única. Una tabla independiente de perfiles guarda la lista de cuentas monitorizadas y la fecha en que se añadieron al seguimiento.
Guardar la respuesta sin procesar resulta útil para depurar y volver a generar los datos normalizados. Limita el periodo de conservación según el propósito del proyecto y las normas de la organización, controla el acceso a las tablas y no recopiles información innecesaria para el análisis elegido. Si vas a usar los datos en un CRM o para acciones de marketing directo, determina por separado la base jurídica aplicable: que los datos sean técnicamente públicos no resuelve esta cuestión.
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)
);
Añade los registros por lotes, una vez que la respuesta haya superado las comprobaciones. Si se vuelve a ejecutar la misma tarea, la clave primaria impedirá que se creen duplicados de una captura; en la aplicación puedes usar una inserción que ignore los conflictos. Una nueva ejecución a otra hora guardará una fila independiente y ampliará la serie temporal.
Calcula métricas que respondan a la pregunta
La métrica básica del ritmo de publicación es el número de medios únicos de una cuenta durante el periodo elegido. Se calcula fácilmente con published_at, si el campo está presente y se ha interpretado correctamente. Para medir los cambios en las reacciones públicas, compara dos observaciones del mismo media_id: la variación absoluta de «Me gusta» es el contador más reciente menos el anterior; la variación relativa es esa diferencia dividida por el valor anterior. Se aplica el mismo cálculo a los comentarios.
Si el valor anterior es cero o no está disponible, no se puede determinar el crecimiento relativo; muestra la diferencia absoluta e indica claramente que no hay una base para calcular el porcentaje. Los contadores pueden cambiar entre observaciones, por lo que el informe debe especificar el intervalo entre capturas y la hora de la última recopilación. Estos detalles ayudan a interpretar las cifras correctamente.
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}
No reduzcas las cuentas a una sola clasificación sin explicar los pesos. Un informe práctico suele mostrar conjuntamente el número de publicaciones, la mediana de «Me gusta» y comentarios por publicación, la distribución de formatos y los cambios en las reacciones durante intervalos de antigüedad equivalentes. La mediana reduce la influencia de una publicación atípica; el número de publicaciones indica el tamaño de la muestra utilizada para la comparación.
Hay dos maneras de tener en cuenta la antigüedad de una publicación. La primera consiste en capturar los contadores periódicamente, por ejemplo, en intervalos iguales desde la primera detección del medio. La segunda es comparar publicaciones que hayan entrado en el mismo intervalo temporal utilizando observaciones de antigüedad similar. Si una ejecución programada no se realiza, no describas el cambio medido como un crecimiento exacto en 24 horas: calcula el intervalo a partir de las marcas de tiempo.
Automatiza la ejecución y el control de calidad
Programa la recopilación con cron, GitHub Actions o un orquestador ETL. La secuencia de tareas es sencilla: leer la lista de cuentas, solicitar los fragmentos necesarios, comprobar el estado HTTP y la estructura de la respuesta, normalizar los datos, guardar la captura y registrar la ejecución. En cada ejecución, anota el número de cuentas y medios procesados, los errores y la duración; así podrás distinguir un cambio real de actividad de un fallo en la recopilación.
Ante errores temporales, aplica un número limitado de reintentos con una pausa; si la respuesta contiene un error, guarda el contexto de la solicitud sin incluir la clave secreta. No ejecutes un bucle infinito con los cursores: el proceso debe detenerse según las condiciones de finalización que indique la respuesta del endpoint. Si la documentación establece límites o reglas de uso, ajusta la frecuencia y el tamaño de la muestra en consecuencia.
La página de IG API indica el parámetro cache_timeout para las rutas compatibles. La caché es útil cuando repetir una solicitud en un intervalo breve no aporta valor; elige una frecuencia de recopilación que se ajuste a la pregunta analítica. Por ejemplo, una captura diaria resulta más adecuada para un resumen semanal que las solicitudes repetidas a los mismos perfiles sin un objetivo concreto.
Antes de activar una programación periódica, prueba con una muestra pequeña. Guarda un ejemplo de respuesta, comprueba los identificadores y las fechas, compara los campos normalizados con el JSON original y revisa manualmente algunas filas. Añade pruebas para valores ausentes, listas vacías y formatos inesperados. Si cambia la API, estas comprobaciones detectarán el problema antes que un informe incoherente al final de la semana.
En qué puede ayudar la IA
La IA resulta apropiada en la última fase, para resumir brevemente los resultados ya calculados. Proporciona a un modelo datos agregados y enlaces a las publicaciones, no todo el archivo sin procesar: por ejemplo, el número de medios por semana, las reacciones públicas medianas y una lista de publicaciones con los cambios más importantes durante un intervalo determinado. Pide al modelo que formule observaciones e incluya los identificadores de los registros en que se basan.
Es mejor dejar el cálculo de las métricas en código convencional para que la misma regla produzca resultados reproducibles. El modelo puede preparar un resumen textual, agrupar los pies de foto según temas predefinidos o proponer preguntas para una revisión manual. Si clasificas temáticamente las publicaciones, guarda la etiqueta del modelo por separado del pie de foto original e indica la versión de la instrucción o del clasificador, para que los cambios posteriores no alteren el historial sin dejar rastro.
No conviertas un informe automatizado en una decisión automatizada de contratación, contratación de servicios o evaluación de una persona concreta. Utiliza los datos públicos para analizar el contenido de forma acotada y comprueba las conclusiones manualmente, sobre todo si influyen en decisiones comerciales. Así, el seguimiento sigue siendo útil y los contadores medidos se distinguen de su interpretación.
Qué aspecto tiene el resultado
Tras varios ciclos de recopilación, tendrás una tabla que indica cuándo se detectó cada publicación, cuántas reacciones tenía en cada observación y cómo cambiaron los indicadores. Un resumen semanal podrá responder a preguntas prácticas: quién publicó con regularidad, qué formatos se utilizaron más, qué publicaciones acumularon reacciones entre capturas comparables y dónde todavía faltan datos para una comparación fiable.
Este proceso ayuda a sustituir las comprobaciones manuales esporádicas por un análisis repetible. No reemplaza el análisis cualitativo del contenido: las métricas describen la frecuencia de publicación y las reacciones públicas disponibles, mientras que el significado, la audiencia y la adecuación a la marca requieren una evaluación independiente. En cambio, un calendario uniforme, un historial guardado y una lógica de cálculo explícita hacen que esas evaluaciones puedan verificarse y sean útiles para el equipo.
Para empezar, abre la página de IG Scraper API, comprueba los parámetros de la ruta de publicaciones en la documentación de Postman, implementa después un adaptador con una cuenta de prueba y guarda la primera captura. Cuando hayas confirmado el esquema, añade la programación, el control de errores y los informes basados en las métricas elegidas.