É segunda-feira, 8h, e você gerencia notificações push para cinco clientes Shopify Plus e WooCommerce. Antes de qualquer check-in de cliente esta semana, você precisa de duas coisas por conta: todas as automações estão em execução e como os números do mês passado se moveram. A maneira antiga significa cinco logins e cinco viagens pelas mesmas telas (campanhas de gotejamento, campanhas acionadas, fluxos de trabalho, análises), repetidas uma vez por cliente. Chame o que é: um problema de relatório de clientes de agências de marketing com assistente de IA, não um problema de painel. As mesmas verificações são executadas cinco vezes separadamente porque as contas não se comunicam entre si, nem as abas que as mantêm abertas.
Com o PushEngage MCP conectado ao seu sistema de agência, você pede a um assistente para verificar o status da automação e obter análises para cada cliente na mesma conversa, alternando contas por nome em vez de por login. Este post detalha esse fluxo de trabalho real de segunda-feira de manhã: auditar as automações de cada cliente em busca de qualquer coisa pausada que não deveria estar, em seguida, obter análises de CTR e receita para entrar em cada check-in com números reais — não cinco painéis, um prompt de cada vez.
Por que "relatórios de clientes" começa com uma automação quebrada, não com um número
Imagine uma marca DTC de mercado intermediário que você gerencia: uma campanha acionada de abandono de carrinho que deveria disparar em 30 minutos, 4 horas e 24 horas após o checkout é deixada para trás. Três semanas atrás, alguém editou a regra de público da campanha e ela foi silenciosamente pausada. Ninguém notou. A receita de recuperação de carrinho do cliente diminuiu silenciosamente por três semanas antes que alguém pensasse em verificar a própria automação, porque os números de CTR que surgiram (aberturas de e-mail, cliques em anúncios) pareciam normais. O canal push simplesmente ficou mudo.
Este é o modo de falha que "relatórios de clientes" quase nunca considera. Todos os produtos de relatórios de agências no mercado, de painéis white-label a conectores de BI e geradores de relatórios de IA, assumem que o trabalho é transformar métricas existentes em uma leitura mais rápida. Nenhum deles pergunta se a automação que gera essas métricas ainda está ativa. Para um canal de retenção como o push, isso é o oposto. Uma campanha de gotejamento pausada ou um fluxo de trabalho travado não aparece como um número ruim; aparece como uma ausência, e uma ausência é exatamente o que um rápido olhar no painel de cinco minutos perde.
Portanto, antes que este post chegue à CTR, contagens de assinantes ou valor de meta (os números que um cliente realmente quer ouvir em uma ligação), ele começa com a verificação que tem que vir primeiro: algo está pausado que não deveria estar. Esse é o primeiro movimento real de relatórios de clientes para uma agência que executa programas de retenção push em várias contas PushEngage, e é o movimento que todas as outras ferramentas de relatórios pulam.
A razão pela qual é ignorado em todos os outros locais é estrutural, não acidental. Um painel white-label ou um conector de BI extrai quaisquer números que a API da plataforma subjacente já expõe como métricas: envios, aberturas, cliques. Ele os renderiza mais rápido ou de forma mais bonita, nada mais. Nenhuma dessas ferramentas pergunta à plataforma “quais das minhas automações mudaram de estado sem que ninguém lhe dissesse”, porque isso não é uma métrica, é uma verificação de estado, e as verificações de estado vivem numa parte diferente da API do que a análise.
Uma agência que faz relatórios de notificações push de forma eficaz tem de executar ambos os tipos de verificação, na ordem correta, para cada conta que gere. Até agora, isso significava lembrar-se de o fazer manualmente, um separador de painel de controlo de cada vez.
Primeiros passos: PushEngage MCP no seu sistema agentic
O PushEngage MCP instala-se com um comando, npx -y @pushengage/mcp, adicionado à configuração do servidor MCP do Claude Desktop, Claude Code ou Cursor. Assim que o servidor estiver registado, peça ao seu assistente para o iniciar sessão no PushEngage; isto abre um separador no navegador para autorização com um clique, pelo que nenhuma chave de API é alguma vez digitada ou colada no chat. A partir daí, peça os seus sites e escolha aquele com que deseja trabalhar, e todas as chamadas de ferramenta subsequentes atuarão nessa conta até que mude. Esta secção permanece intencionalmente curta — para exemplos completos de ficheiros de configuração, os pré-requisitos do npx e correções para o erro mais comum de “conexão fechada”, consulte o guia completo de configuração do PushEngage MCP.
Gerir uma conta PushEngage por cliente, em segurança
Tudo neste post assume que já está configurado para ter mais do que uma conta PushEngage no mesmo assistente sem que os tokens se cruzem. Essa mecânica (registo do servidor uma vez por cliente com o seu próprio PE_MCP_CONFIG_PATH, depois uso de list_sites e select_site para alternar entre contas a meio da conversa) é real, e é o que torna uma segunda-feira com cinco clientes possível a partir de uma única janela de chat.
É também um tópico próprio com os seus próprios passos de configuração, exemplos de configuração e armadilhas, e repeti-lo aqui apenas abrandaria o fluxo de trabalho sobre o qual este post realmente trata. Se ainda não configurou o acesso multi-cliente, veja como o PushEngage MCP mantém as contas de cliente separadas primeiro, depois volte aqui para saber o que fazer com ele uma vez que esteja a funcionar.
Essa é também a peça que torna a gestão multi-cliente de notificações push genuinamente diferente da alternância de contas que a maioria das ferramentas de agência oferece. Um login partilhado com filtros a nível de cliente ainda significa um token que pode ver todos os clientes de uma vez; uma configuração de caminho de configuração por cliente significa que as credenciais de cada cliente vivem num ficheiro separado que o seu assistente lê apenas quando selecionou explicitamente esse site. O fluxo de trabalho abaixo assume que essa separação já está em vigor.
Primeiro passo, segunda-feira de manhã: auditar as automações de cada cliente para qualquer coisa pausada
Com as contas dos clientes configuradas, a auditoria em si consiste em três chamadas de ferramenta, repetidas por cliente. Peça ao seu assistente para listar as campanhas de gotejamento, campanhas acionadas e fluxos de trabalho para o primeiro cliente, e para incluir análises na chamada do fluxo de trabalho. pushengage_list_drip_campaigns e pushengage_list_triggered_campaigns retornam o estado de cada automação, ativa ou pausada, de modo que uma campanha que foi editada para um estado pausado há semanas e nunca foi notada aparece na primeira resposta, não na quinta tela de um painel para o qual, de outra forma, seria necessário clicar. pushengage_list_workflows com include_analytics definido vai mais longe: juntamente com o estado, retorna contagens de assinantes que entraram, estão ativos, foram concluídos e falharam, mais estatísticas de metas para cada fluxo de trabalho.
É aí que reside o verdadeiro sinal de auditoria. Um fluxo de trabalho com uma contagem saudável de "entrados" e quase nada a passar para "concluídos" não está avariado de uma forma que apareça como um estado pausado: está a funcionar e, de qualquer forma, está a falhar, com assinantes a acumular-se em "ativos" porque uma condição de saída ou um passo de atraso não se está a comportar como quando alguém o construiu. Esse é o tipo de falha que uma coluna de estado esconde e um número de taxa de conclusão revela imediatamente.
Um resultado realista de segunda-feira para um cliente, numa única troca de prompt e resposta, pode parecer assim:
- Campanha acionada de abandono de carrinho: ativa, a funcionar normalmente.
- Campanha acionada de redução de preço: pausada, sem alteração de audiência desde a configuração; sinalizar para a chamada do cliente.
- Fluxo de trabalho da série de boas-vindas: 1.240 entraram este mês, 1.190 concluídos, saudável.
- Fluxo de trabalho de reconquista: 890 entraram, 210 concluídos, 40 falharam. A taxa de conclusão caiu da sua gama habitual e vale a pena uma análise mais atenta antes de assumir que está tudo bem.
Cada uma dessas quatro linhas responde a uma versão diferente da mesma pergunta (está a fazer o que deveria estar a fazer) e cada uma, de outra forma, teria necessitado de um clique separado numa página de detalhes de campanha ou fluxo de trabalho separada para confirmar. A linha de redução de preço, por si só, vale todo o exercício: uma campanha acionada pausada sem um gatilho óbvio para o motivo pelo qual pausou é exatamente o tipo de falha silenciosa que custa a um cliente três semanas de receita recuperada antes que alguém pergunte sobre isso, e surge aqui na mesma resposta que todo o resto, não enterrada a três cliques de profundidade num painel que ninguém abriu.
Repita a mesma sequência de três chamadas para o próximo cliente, trocando de sites, e quando tiver passado por todas as cinco contas, terá uma lista exata do que está pausado, o que está bloqueado e o que está a funcionar bem — compilada a partir de uma conversa, não de cinco sessões de auditoria separadas. Isto é a auditoria de automações de clientes como a sua própria categoria de relatórios, não um efeito secundário da extração de análises, e é o passo que todos os produtos de relatórios concorrentes saltam porque nenhum deles lê o estado da automação. Executar a mesma sequência de auditoria de automações de clientes em todas as contas antes da primeira chamada de cliente da semana é, na prática, a diferença entre relatar um problema e detetá-lo antes do cliente.
Passo dois: extrair análises de CTR e de receita de todos os clientes, numa só passagem
Assim que souber o que está realmente a funcionar, a segunda metade do relatório do cliente são os números que um cliente espera na chamada: crescimento de subscritores, taxa de cliques e valor do objetivo, o número que mais importa. pushengage_get_analytics_summary retorna totais vitalícios por site: subscritores, notificações enviadas, visualizações, cliques e contagem e valor do objetivo. pushengage_get_analytics_timeseries divide as mesmas métricas em grupos diários, semanais ou mensais num intervalo de datas, mais a tendência de CTR e de cancelamento de subscrição, para que possa mostrar a um cliente não apenas onde ele se encontra, mas em que direção os últimos 30 dias se moveram.
A distinção que importa especificamente para relatórios de notificações push de agências: o valor do objetivo é um número de receita, não um número de envolvimento. Um cliente cujo CTR se manteve estável mês após mês, mas cujo valor do objetivo proveniente de push aumentou porque a sequência de abandono de carrinho que acabou de confirmar estava ativa e recuperou mais carrinhos, é uma história materialmente diferente de um CTR que aumentou sem receita por trás dele. Ancore a conversa primeiro no valor do objetivo e depois no CTR, e o relatório será lido como receita recuperada em vez de uma métrica de vaidade.
Na prática, isto parece pedir o resumo e a série temporal dos últimos 30 dias para cada cliente, um de cada vez, logo após a verificação do estado da automação para esse mesmo cliente — para que, quando passar para a conta seguinte, já tenha ambas as metades da história desse cliente: o que está a funcionar e o que produziu. Extrair o CTR e o valor do objetivo de três clientes lado a lado na mesma conversa, em vez de três logins de painel separados, é o que realmente substitui a versão "cinco separadores do navegador" desta segunda-feira.
Considere os mesmos cinco clientes da auditoria acima. Digamos que três deles mostram um CTR estável ou ligeiramente crescente mês após mês, um mostra uma queda que vale a pena notar, e o quinto (aquele cuja campanha de redução de preço apareceu como pausada na auditoria) mostra uma queda no valor do objetivo suficientemente grande para que seja claramente a mesma história, não uma coincidência.
Entrar naquela chamada com o cliente com ambos os factos já ligados ("a sua automação de redução de preços foi pausada há três semanas e aqui está a queda de receita recuperada que se alinha com isso") é uma conversa materialmente diferente de entrar com um gráfico de CTR e sem explicação para o motivo pelo qual se moveu. Esse é o benefício de fazer a auditoria primeiro: as análises deixam de ser um número que você relata e passam a ser um número que você pode explicar.
O que isto substitui realmente, e o que não substitui
Vale a pena ser direto quanto ao âmbito. O PushEngage MCP para agências não é um gerador de relatórios para clientes: não produz um PDF com marca ou um link de painel de marca branca para entregar a um cliente, como um produto de relatórios de BI faz. Também não corrige nada do que encontra. Quando a auditoria revela uma campanha de redução de preços pausada ou um fluxo de trabalho com uma taxa de conclusão em queda, você ainda abre o painel PushEngage para editar a regra de audiência ou o passo de atraso, porque cada ferramenta aqui é de leitura, não de criação ou edição. E a gestão de notificações push multi-cliente através do MCP é apenas para stdio, executando localmente via npx dentro do seu assistente; não há versão de conector remoto nem capacidade de envio de WhatsApp a acompanhar.
O que substitui é mais restrito e, para uma segunda-feira de manhã, mais útil: o ritual manual de iniciar sessão em cinco painéis separados para clicar nas mesmas telas de estado de automação e na mesma aba de análises, um cliente de cada vez, antes de ter dito uma palavra a alguém. Em mais de 25.000 empresas em mais de 150 países a executar push com um total combinado de 15,2 mil milhões de notificações nos últimos 30 dias, esse ritual repete-se todas as semanas em todas as agências que gerem mais de uma conta — e é a peça específica que as 27 ferramentas do PushEngage MCP em 10 domínios foram construídas para comprimir numa única conversa.
Esse é o âmbito honesto de um assistente de IA para o fluxo de trabalho de relatórios de clientes de agências de marketing construído sobre o MCP: encurta o caminho para uma imagem completa e precisa em todos os clientes. Não lhe entrega um relatório finalizado, nem altera uma configuração em seu nome.
Fechando a série: o que catorze posts do PushEngage MCP somam
Este é o décimo quarto e último post desta série, e o arco vale a pena ser declarado claramente: instale o PushEngage MCP uma vez, no Claude Desktop, Claude Code, ou Cursor, e um assistente cobre o envio e agendamento de push, a segmentação dos assinantes certos, a extração de análises semana a semana, e, como este post cobriu, a auditoria de campanhas de gotejamento e fluxos de trabalho em tantas contas de clientes quanto você gerencia. Nenhum deles requer uma segunda assinatura de relatórios ou um painel construído especificamente para IA. Requer a instalação de um comando com que esta série começou, e uma segunda-feira de manhã passada a perguntar em vez de clicar.
Para uma agência especificamente, esse arco agrava-se de uma forma que não acontece para uma marca de um único local: cada ferramenta que esta série abordou (envio, segmentação, análise e a sequência de automações do cliente de auditoria que esta publicação apresentou) é executada uma vez por cliente em vez de uma vez, no total. A segunda-feira de cinco clientes com que esta publicação começou não é um caso especial; é como cada publicação desta série se parece uma vez que a multiplica pelo número de contas pelas quais uma pessoa é responsável.
Se estiver a executar o PushEngage para mais de um cliente e esta for a primeira publicação da série em que aterrou, comece com o guia de configuração, depois volte aqui — a ordem das operações de auditoria primeiro, números depois, nesta publicação é a que escala para além de uma única conta. Essa ordem de operações é para o que serve o cliente de agência de marketing de um assistente de IA para relatórios: detetar o que está quebrado e, em seguida, explicar o que mudou. Consulte os planos do PushEngage para ver o que está disponível em cada nível de cliente, incluindo o plano gratuito em que cada nova conta começa.
