Rode o relatório de segunda com um conector do Meta Muse para relatórios de analytics

O relatório semanal é a única tarefa que um conector do Meta Muse para relatórios de analytics consegue fazer sem nunca alterar um número, porque todo endpoint de que ele precisa é um GET. O próprio Muse escreve esse conector a partir da especificação pública da API da Flowsery. A Parallel relatou em 14 de setembro de 2026 que o trabalho acontece na VM em nuvem que a Meta dá a cada conta do Muse; a Meta, em suas próprias palavras, só diz que essa VM tem poder de computação suficiente para fazer trabalho de verdade. Configuração e credenciais estão no guia do conector do Meta Muse para analytics de site; este post começa no relatório que você roda toda segunda.

Resumindo: um relatório semanal é GET /websites uma vez, GET /overview duas vezes, GET /timeseries para ver o formato, depois GET /channels e GET /breakdown para nomear a causa. Seis leituras, zero escritas e um websiteId em cada uma.

De quais chamadas um relatório semanal realmente precisa?

Um relatório semanal da Flowsery são seis chamadas, e a ordem importa mais que a quantidade. GET /websites entrega os IDs que toda chamada seguinte carrega. GET /overview roda duas vezes, uma por período. GET /timeseries transforma a variação em um formato, então uma única terça ruim para de parecer tendência. Depois GET /channels e GET /breakdown nomeiam o que mudou.

GET /countries, /devices, /browsers e /realtime pertencem à pergunta seguinte, não ao relatório agendado. Ainda assim, dê a lista inteira ao conector: um endpoint que ele nunca chama não custa nada, e um de que ele precisa numa terça e não tem custa um conector refeito.

Como você pede uma comparação entre períodos?

Nomeie as duas faixas de datas explicitamente e nomeie o fuso horário. O Muse resolve "semana passada" por conta própria, antes de a chamada ser feita, e a Meta não publica nada sobre qual relógio ele usa. A Flowsery então agrupa startAt e endAt conforme o fuso do site, a menos que a chamada nomeie um. Duas resoluções separadas, ambas silenciosas, ambas capazes de deslocar um relatório em um dia.

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 primeiro, sem recomendações" ganha seu lugar. Um agente a quem se pede análise produz análise, e um com vinte e dois endpoints de leitura e nenhum acesso ao seu roadmap monta essa análise só em cima do tráfego. O modelo de Grok Bot para relatórios de analytics traz a mesma instrução pelo mesmo motivo.

Por que toda chamada precisa de um seletor de site?

Um token de workspace da Flowsery cobre todos os sites do workspace, então a API não tem como adivinhar qual deles você quer. Toda chamada precisa de websiteId ou domain. Deixe o seletor de fora e o token de workspace não tem site para resolver, então a chamada falha em vez de retornar em silêncio os números de um site qualquer.

Onde o token flow_ws_ entra e por que ele nunca pertence ao chat está no pilar. O que o relatório precisa tratar é o alcance dele: um token chega a todos os sites.

Diga ao conector para guardar os IDs dos sites depois da primeira execução e reutilizá-los. Da segunda semana em diante o relatório são cinco chamadas, e rodar GET /websites de novo só vale a pena quando você adiciona um site.

O que um conector de relatórios pode alterar?

Nada. Todo endpoint deste post é um GET, o que faz de um conector de relatórios a coisa mais segura de entregar a um agente: nenhuma aprovação para configurar, nenhuma escrita para supervisionar, nenhum desfazer para planejar.

A Meta afirma com todas as letras que não revisa conectores customizados nem como eles usam suas informações, e essa ausência de revisão pesa menos quando todo o vocabulário do conector é leitura.

O que um relatório montado por agente erra e um painel não?

Um agente que monta um relatório comete três erros que um painel não comete: ele escreve prosa sobre os números em vez de desenhá-los.

Ele arredonda e depois raciocina sobre o número arredondado. "Estável semana a semana" absorve uma queda de 9%. Peça os números brutos junto com a frase.

Ele atribui causas que nunca consultou. GET /breakdown?dimension=channel nomeia o canal que mudou. Nenhum endpoint da Flowsery retorna um motivo, e o conector não tem log de releases nem fila de tickets de onde tirar um. O agente vai fornecer um motivo mesmo assim, a menos que você mande não fazer isso.

Ele compara janelas desiguais. Um feriado, uma janela de sete dias contra uma de seis, uma mudança de fuso. Um painel erra de um jeito que dá para ver; um parágrafo, não.

A correção para os três é GET /timeseries com interval=day. Números diários por baixo do total semanal deixam o leitor conferir a frase do agente contra o formato, e é por isso que o painel fica aberto ao lado.

Quanto custa um relatório semanal quando ele roda toda semana?

O Muse mede tudo contra uma única cota semanal de tokens, e os números dos planos estão no pilar. O que um trabalho agendado muda é o formato do gasto, não a tabela de preços: as mesmas leituras rodam 52 vezes por ano, com ou sem alguém lendo o resultado.

Seis leituras e um parágrafo de prosa é um gasto semanal pequeno. A versão que dá errado não é: um agente repetindo uma chamada que falha vinte vezes, toda segunda, para sempre, porque ninguém disse a ele que o seletor era obrigatório.

A API está nos dois planos da Flowsery, então a execução semanal não depende de qual deles você usa.

O que quebra especificamente em relatórios?

Quatro coisas, e nenhuma delas é autenticação, que funciona na primeira chamada ou não funciona.

A primeira é o fuso horário, a falha que sobrevive por mais tempo porque o relatório continua chegando e continua parecendo correto. startAt e endAt sem um timezone calculam com base no fuso do próprio site, o que está configurado na Flowsery em vez do fuso de quem pediu o relatório, então "semana passada" cobre em silêncio sete dias diferentes dos que estão no calendário dessa pessoa.

A segunda é o websiteId ausente, que o agente vai tentar resolver reescrevendo a consulta em vez de adicionar o parâmetro.

A terceira é a defasagem na skill salva. A Parallel relatou em 14 de setembro de 2026 que o Muse salva uma integração customizada como uma skill reutilizável que persiste entre conversas, o que congela a lista de chamadas no momento em que o conector foi criado. A Meta não documenta isso, então trate o congelamento como comportamento observado e não como garantia. Quando a API mudar, o reparo de uma mensagem do pilar se aplica sem alterações. Ninguém está olhando quando um relatório agendado quebra, então releia a referência por um lembrete no calendário em vez de por uma falha.

A quarta é o relatório que ninguém lê. Um que informa a variação, nomeia o canal e para por aí é lido por anos; um que opina é ignorado já no terceiro mês.

Perguntas frequentes

Um conector de relatórios do Muse pode alterar meus dados da Flowsery?

Não, se você construí-lo apenas com os endpoints de relatório. Os treze de que um conector de relatórios realmente precisa são todos de leitura: GET /overview, /timeseries, /pages, /referrers, /channels, /campaigns, /countries, /devices, /browsers, /breakdown, /goals, /realtime e /websites. As chamadas de escrita da Flowsery cobrem metas, pagamentos e status de problemas; um conector de relatórios não fica sabendo de nenhuma delas.

Por que o segundo período volta vazio?

O segundo GET /overview carrega um startAt e um endAt que o próprio conector escreveu, então confira o que ele mandou de verdade: a Flowsery assume startAt como trinta dias atrás e endAt como agora sempre que um dos dois falta, e uma janela sem tráfego volta como zeros em vez de erro. Dê ao Muse as duas faixas como datas literais no prompt em vez de "a semana anterior", e confira se as duas respostas diferem antes de ler a variação.

Ele consegue comparar mais de dois períodos?

Sim. Cada período é sua própria chamada de GET /overview ou GET /timeseries com seu próprio startAt e endAt, então quatro trimestres custam quatro chamadas. Dê o mesmo fuso horário a todas ou a comparação atravessa limites de dia diferentes.

O relatório semanal roda com o app fechado?

A Meta diz que o Muse continua trabalhando depois que o app é fechado e volta quando algo muda ou quando precisa de aprovação. A Central de Ajuda dela documenta lembretes e tarefas agendadas como um recurso do Muse e não diz nada sobre um conector customizado rodando dentro de uma delas (verificado em 20 de setembro de 2026). Verifique uma execução semanal sem supervisão por um mês antes de depender dela.

Devo usar o Muse ou o modelo de Grok Bot para isso?

Escolha pelo lugar onde o relatório precisa chegar. O modelo de Grok Bot para relatórios de analytics instala a partir de um link de compartilhamento com o texto da skill já escrito e publica no chat que seu time já lê; o Muse escreve o próprio conector a partir da especificação pública e mantém o resultado no app dele. Os dois leem a mesma API da Flowsery, e todo endpoint que qualquer um deles chama é um GET.

O que o conector chama primeiro?

Ele chama GET /websites, uma única vez, na primeira execução. Isso devolve os IDs de site que toda chamada seguinte leva. Diga ao conector para salvá-los e reutilizá-los, e da segunda semana em diante o relatório são cinco chamadas.

Qual token um conector de relatórios do Muse usa?

Um token de workspace flow_ws_, colado no prompt seguro de credenciais do Muse e nunca no chat. Um token de workspace abrange todos os sites da conta, então o conector alcança todos eles. Por isso toda chamada ainda nomeia um websiteId.

O que acontece quando uma chamada não tem websiteId?

A chamada falha. Um token de workspace não tem um único site para resolver, então a API não devolve em silêncio os números de um site só. O agente tenta corrigir reescrevendo a consulta, por isso avise desde o início que o seletor é obrigatório.

Preciso de um plano específico da Flowsery para o relatório semanal?

Não. A API está nos dois planos da Flowsery, então a execução semanal não depende de qual você tem. A cota semanal de tokens do Muse é um limite separado.

Qual fuso horário um relatório semanal da Flowsery usa?

O que você nomear na chamada. Se startAt e endAt chegam sem timezone, a Flowsery os agrupa pelo fuso do próprio site, definido na Flowsery e que pode não ser o seu. Informe o fuso no prompt, ou "semana passada" pode cobrir sete dias diferentes dos do seu calendário.

Crie um token de workspace e entregue a especificação ao Muse, ou leia a referência da API antes.

Fontes: o artigo de ajuda da Meta sobre conectores do Muse, o texto da Parallel sobre integrações customizadas do Muse (14 de setembro de 2026) e a especificação OpenAPI da Flowsery. Verificado em 20 de setembro de 2026.