Prepare el informe de los lunes con un conector de Meta Muse para informes de analítica

Un informe semanal es el único trabajo que un conector de Meta Muse para informes de analítica puede hacer sin cambiar nunca una cifra, porque todos los endpoints que necesita son de tipo GET. Muse escribe ese conector por su cuenta a partir de la especificación pública de la API de Flowsery. Parallel informó el 14 de septiembre de 2026 de que el trabajo ocurre en la máquina virtual en la nube que Meta da a cada cuenta de Muse; la redacción de Meta se queda en decir que esa VM tiene cómputo suficiente para hacer trabajo real. La configuración y las credenciales están en la guía del conector de Meta Muse para analítica web; este artículo empieza en el informe que usted hace cada lunes.

La versión corta: un informe semanal es GET /websites una vez, GET /overview dos veces, GET /timeseries para ver la forma, y luego GET /channels y GET /breakdown para nombrar la causa. Seis lecturas, cero escrituras, y un websiteId en cada una.

¿Qué llamadas necesita de verdad un informe semanal?

Un informe semanal de Flowsery son seis llamadas, y el orden importa más que el número. GET /websites entrega los IDs que llevan todas las llamadas posteriores. GET /overview se ejecuta dos veces, una por periodo. GET /timeseries convierte la variación en una forma, así que un solo martes malo deja de parecer una tendencia. Luego GET /channels y GET /breakdown nombran lo que se movió.

GET /countries, /devices, /browsers y /realtime pertenecen a la pregunta de seguimiento, no al informe programado. Dele igualmente la lista completa al conector: un endpoint que nunca llama no cuesta nada, y uno que necesita un martes y no tiene cuesta reconstruir el conector.

¿Cómo se pide una comparación entre periodos?

Nombre los dos rangos de fechas de forma explícita y nombre la zona horaria. Muse resuelve "la semana pasada" por su cuenta, antes de hacer la llamada, y Meta no publica nada sobre qué reloj usa. Flowsery agrupa después startAt y endAt según la zona horaria del sitio web salvo que la llamada nombre una. Dos resoluciones distintas, las dos silenciosas, las dos capaces de mover un informe un día entero.

Report on flowsery.com for the week of 8 to 14 September and the week of
1 to 7 September, timezone Europe/Berlin.
 
Call GET /websites on the first run only, then carry the saved websiteId
through every call.
Then GET /overview once per period.
If sessions or conversions moved more than 10%, call
GET /breakdown?dimension=channel for both periods and name the channel.
Numbers first. No recommendations. If nothing moved, say so and stop.

"Números primero, sin recomendaciones" se gana su sitio. Un agente al que se le pide análisis entrega análisis, y uno con veintidós endpoints de lectura y sin acceso a su hoja de ruta lo construye solo con el tráfico. La plantilla de Grok Bot para informes de analítica incluye la misma instrucción por la misma razón.

¿Por qué cada llamada necesita un selector de sitio web?

Un token de workspace de Flowsery cubre todos los sitios web del workspace, así que la API no puede adivinar a cuál se refiere. Cada llamada necesita websiteId o domain. Si deja fuera el selector, el token de workspace no tiene ningún sitio web que resolver, así que la llamada falla en lugar de devolver en silencio las cifras de un sitio cualquiera.

Dónde va el token flow_ws_ y por qué nunca debe acabar en el chat está en la guía principal. Lo que el informe sí tiene que manejar es su alcance: un solo token llega a todos los sitios web.

Dígale al conector que guarde los IDs de los sitios web tras la primera ejecución y los reutilice. Desde la segunda semana el informe son cinco llamadas, y volver a ejecutar GET /websites solo compensa cuando añade un sitio.

¿Qué puede cambiar un conector de informes?

Nada. Todos los endpoints de este artículo son GET, lo que convierte a un conector de informes en lo más seguro que puede darle a un agente: ninguna aprobación que configurar, ninguna escritura que supervisar, ningún deshacer que planificar.

Meta dice con todas las letras que no revisa los conectores personalizados ni cómo usan su información, y esa falta de revisión importa menos cuando todo el vocabulario del conector es de lectura.

¿Qué hace mal un informe redactado que un panel no hace?

Un agente que redacta un informe comete tres errores que un panel no puede cometer: escribe prosa sobre las cifras en lugar de dibujarlas.

Redondea y luego razona sobre el número redondeado. "Semana plana respecto a la anterior" se traga una caída del 9%. Pida las cifras en bruto junto a la frase.

Atribuye causas que nunca consultó. GET /breakdown?dimension=channel nombra el canal que se movió. Ningún endpoint de Flowsery devuelve un motivo, y el conector no tiene registro de versiones ni cola de tickets de donde leerlo. El agente pondrá un motivo igualmente salvo que se le diga que no.

Compara ventanas desiguales. Un festivo, una ventana de siete días contra una de seis, un cambio de zona horaria. Un panel se equivoca de formas que usted puede ver; un párrafo no.

La solución para los tres es GET /timeseries con interval=day. Las cifras por día bajo el total semanal permiten a quien lee contrastar la frase del agente con la forma, y por eso el panel sigue abierto al lado.

¿Cuánto cuesta un informe semanal que se ejecuta todas las semanas?

Muse lo mide todo contra una única asignación semanal de tokens, y las cifras de los planes están en la guía principal. Lo que cambia una tarea programada es la forma del gasto, no la tarifa: las mismas lecturas se ejecutan 52 veces al año, lea alguien la salida o no.

Seis lecturas y un párrafo de prosa son un gasto semanal pequeño. La versión que sale mal no lo es: un agente reintentando una llamada fallida veinte veces, cada lunes, para siempre, porque nadie le dijo que el selector era obligatorio.

La API está en los dos planes de Flowsery, así que la ejecución semanal no depende de en cuál esté.

¿Qué se rompe en los informes en concreto?

Cuatro cosas, y ninguna de ellas es la autenticación, que funciona en la primera llamada o no funciona.

La primera es la zona horaria, el fallo que sobrevive más tiempo porque el informe sigue llegando y sigue pareciendo correcto. startAt y endAt sin un timezone se agrupan según la zona horaria del propio sitio web, la que está configurada en Flowsery y no la del lugar donde vive quien pide el informe, así que "la semana pasada" cubre en silencio siete días distintos de los de su calendario.

La segunda es el websiteId que falta, que el agente intentará resolver reescribiendo la consulta en lugar de añadir el parámetro.

La tercera es la deriva de la skill guardada. Parallel informó el 14 de septiembre de 2026 de que Muse guarda una integración personalizada como una skill reutilizable que persiste entre conversaciones, lo que congela la lista de llamadas en el momento en que se construyó el conector. Meta no lo documenta, así que trate esa congelación como comportamiento observado y no como una garantía. Cuando la API cambie, la reparación de un solo mensaje de la guía principal se aplica sin cambios. Nadie está mirando cuando un informe programado se rompe, así que vuelva a leer la referencia con un recordatorio en el calendario en lugar de tras un fallo.

La cuarta es el informe que nadie lee. Uno que declara la variación, nombra el canal y se detiene se lee durante años; uno que editorializa se ignora para el tercer mes.

Preguntas frecuentes

¿Puede un conector de informes de Muse cambiar mis datos de Flowsery?

No, si lo construye solo con los endpoints de informes. Los trece que un conector de informes necesita de verdad son todos de lectura: GET /overview, /timeseries, /pages, /referrers, /channels, /campaigns, /countries, /devices, /browsers, /breakdown, /goals, /realtime y /websites. Las llamadas de escritura de Flowsery cubren objetivos, pagos y el estado de los problemas; a un conector de informes no se le cuenta nada de eso.

¿Por qué el segundo periodo vuelve vacío?

El segundo GET /overview lleva un startAt y un endAt que el conector escribió por su cuenta, así que compruebe qué envió en realidad: Flowsery pone startAt en hace treinta días y endAt en ahora siempre que falte alguno de los dos, y una ventana sin tráfico vuelve como ceros en lugar de como error. Dele a Muse los dos rangos como fechas literales en el mensaje en lugar de como "la semana anterior", y compruebe que las dos respuestas difieren antes de leer la variación.

¿Puede comparar más de dos periodos?

Sí. Cada periodo es su propia llamada a GET /overview o GET /timeseries con su propio startAt y endAt, así que cuatro trimestres cuestan cuatro llamadas. Dele a todas la misma zona horaria o la comparación abarcará límites de día distintos.

¿El informe semanal se ejecuta con la app cerrada?

Meta dice que Muse sigue trabajando después de cerrar la app y vuelve cuando algo cambia o necesita una aprobación. Su centro de ayuda documenta los recordatorios y las tareas programadas como una capacidad de Muse y no dice nada sobre un conector personalizado ejecutándose dentro de una (revisado el 20 de septiembre de 2026). Verifique una ejecución semanal desatendida durante un mes antes de depender de ella.

¿Debo usar Muse o la plantilla de Grok Bot para esto?

Elija según dónde tenga que aterrizar el informe. La plantilla de Grok Bot para informes de analítica se instala desde un enlace para compartir con el texto de la skill ya escrito y publica en el chat que su equipo ya lee; Muse escribe su propio conector a partir de la especificación pública y mantiene la salida en su propia app. Las dos leen la misma API de Flowsery, y cada endpoint que llama cualquiera de ellas es un GET.

¿Qué llama primero el conector?

Llama a GET /websites, una sola vez, en la primera ejecución. Eso devuelve los ID de sitio web que llevan todas las llamadas posteriores. Dile al conector que los guarde y los reutilice, y desde la segunda semana el informe son cinco llamadas.

¿Qué token usa un conector de informes de Muse?

Un token de espacio de trabajo flow_ws_, pegado en el aviso seguro de credenciales de Muse y nunca en el chat. Un token de espacio de trabajo abarca todos los sitios web de la cuenta, así que el conector puede llegar a todos. Por eso cada llamada sigue nombrando un websiteId.

¿Qué pasa cuando una llamada no lleva websiteId?

La llamada falla. Un token de espacio de trabajo no tiene un único sitio que resolver, así que la API no devuelve en silencio los números de un solo sitio. El agente intentará arreglarlo reescribiendo la consulta, por eso conviene decirle desde el principio que el selector es obligatorio.

¿Necesito un plan concreto de Flowsery para el informe semanal?

No. La API está en los dos planes de Flowsery, así que la ejecución semanal no depende de cuál tengas. La asignación semanal de tokens de Muse es un límite aparte.

¿Qué zona horaria usa un informe semanal de Flowsery?

La que nombres en la llamada. Si startAt y endAt llegan sin timezone, Flowsery los agrupa según la zona horaria del propio sitio web, que se configura en Flowsery y puede no ser la tuya. Indica la zona horaria en el prompt, o "la semana pasada" puede cubrir siete días distintos a los de tu calendario.

Cree un token de workspace y dele la especificación a Muse, o lea antes la referencia de la API.

Fuentes: el artículo de ayuda de Meta sobre los conectores de Muse, el análisis de Parallel sobre las integraciones personalizadas de Muse (14 de septiembre de 2026) y la especificación OpenAPI de Flowsery. Revisado el 20 de septiembre de 2026.