David Sánchez

Volver a las notas

Por qué guardo las métricas de Meta en mi propia base de datos

05.08.2026   Bases de datos

La primera versión de mi panel de campañas llamaba a la Graph API de Meta cada vez que alguien abría la página. Funcionaba perfectamente hasta que dejó de hacerlo.

Dos problemas, y el segundo es el grave.

El primero es la cuota. La API de Meta limita las llamadas, y un panel que consulta en cada carga la agota sin avisar. El día que más gente lo abre, que es justo el día de un lanzamiento, es el día que se cae.

El segundo es que sin histórico propio no puedes comparar. La API te da el estado de hoy. No te da el de hace una semana con los mismos filtros, ni te dice que el CPM lleva cinco días subiendo. Y casi todas las decisiones de pauta son comparaciones, no fotos fijas.

La solución es aburrida y es la correcta: un proceso que cada día baja las métricas y las escribe en PostgreSQL, una fila por anuncio y día. El panel ya no habla con Meta, habla con mi base de datos. Es instantáneo, no gasta cuota, y a partir del segundo día tengo una serie temporal que la plataforma no me daba.

Dos detalles que aprendí a base de romperlo. Uno: guarda el dato en crudo, no el porcentaje ya calculado. Si guardas el CTR y luego quieres el CTR de un rango de fechas, no puedes promediar porcentajes; necesitas los clics y las impresiones para sumarlos y dividir al final. Dos: Meta reajusta las cifras de los últimos días, así que el proceso no puede insertar y ya está. Tiene que reescribir los últimos tres días cada vez, con una clave única por anuncio y fecha para que el UPSERT no duplique.

Es la pieza más sosa de todo el sistema y es la que sostiene el resto.