O seu relatório de atribuição de canais do GA4 tem uma falha. Os envios de push do mês passado aparecem sem meio e sem origem, pelo que, no papel, parecem tráfego direto em vez de receita recuperada. Você rastreia isso até um parâmetro UTM que nunca foi preenchido além do espaço reservado que sua equipe definiu na instalação. Este guia de configuração das definições do site pushengage existe porque corrigir esse único campo hoje significa fazer login no painel, encontrar a aba certa e reenviar todos os outros campos padrão de uma vez, já que o formulário não permite editar apenas um.
Esse é o custo real das configurações do site PushEngage: não que qualquer configuração individual seja difícil de entender, mas que os detalhes do site, as predefinições de campanha e a configuração do service worker vivem em locais separados, são tocados com pouca frequência para que ninguém se lembre onde, e exigem um reenvio completo do formulário para corrigir um campo. Este guia abrange os três grupos de configurações que você realmente revisitará — detalhes do site, predefinições de campanha e configurações do service worker — e como alterar qualquer um deles com uma solicitação em linguagem natural a um assistente de IA conectado ao servidor MCP do PushEngage, em vez de uma caça a abas no painel.
Por que a configuração das definições do site PushEngage se transforma num ticket de suporte em vez de uma correção de cinco minutos
As configurações do site não são configuradas uma vez e esquecidas. Elas são revisitadas toda vez que o negócio muda de forma: um novo mercado significa uma mudança de fuso horário, um novo requisito de atribuição significa uma atualização de parâmetro UTM, um rebranding significa que o alternador "Powered By PushEngage" precisa de uma segunda olhada, uma migração de plataforma significa verificar se o arquivo do service worker ainda está onde o PushEngage espera. Como cada um desses reside num canto diferente do painel, o atrito real não é a edição em si. É reencontrar a aba, depois reenviar campos que você não pretendia tocar, numa tarefa que você fará novamente em três meses quando algo mais mudar.
Três modos de falha aparecem com frequência suficiente para importar, e nenhum deles gera um erro quando acontecem:
- Uma lacuna padrão de UTM. As predefinições de campanha vêm com parâmetros UTM de espaço reservado ou em branco, então cada envio de push nessa janela aparece no GA4 sem meio ou origem, invisível num relatório de atribuição de canais.
- Uma notificação de fallback em falta. Assinantes não segmentados, aqueles que não correspondem a nenhuma regra de audiência, não recebem nada, ou uma cópia genérica, em vez de um padrão deliberado que sua equipe escolheu.
- Um caminho de service worker desatualizado após uma migração de site. Isso impede a entrega de notificações, sem produzir uma mensagem de erro óbvia que aponte para a configuração que a causou.
Todos os três apenas custam silenciosamente dados, alcance ou entrega até que alguém perceba, geralmente enquanto olha para um relatório que não bate certo.
Este é o caso para tratar as definições do site como uma verificação recorrente em vez de uma etapa de instalação única, e é o caso para mudar a forma como as verifica.
Primeiros passos: ligue o servidor PushEngage MCP ao seu assistente
@pushengage/mcp é o servidor oficial do Protocolo de Contexto de Modelo (MCP) da PushEngage, e todas as ferramentas neste guia funcionam através dele. Adicione-o à configuração MCP do seu cliente — claude_desktop_config.json do Claude Desktop, ~/.cursor/mcp.json do Cursor, ou a própria configuração MCP do Claude Code — com o comando npx -y @pushengage/mcp. Não é necessária nenhuma instalação global.
Na primeira vez que pedir ao seu assistente para o iniciar sessão, ele abrirá um separador no navegador para autorizar a ligação, pelo que a sua palavra-passe PushEngage nunca toca no próprio assistente, e o token resultante é armazenado localmente na sua máquina. A partir daí, peça para ver os seus sites PushEngage e selecione aquele em que deseja trabalhar; todas as ferramentas de configuração abaixo têm como padrão o site que tem atualmente selecionado. Para o guia completo, incluindo a resolução de problemas de ligação, consulte o guia completo de configuração do PushEngage MCP.
Detalhes do site: nome, URL, fuso horário, geolocalização e o alternador de marca
pushengage_get_site_details lê a sua configuração atual; pushengage_update_site_details altera-a. Entre elas, cobrem os campos que a própria documentação de integração da PushEngage chama de “Adicionar Detalhes do Site”:
- Nome do site
- URL do site
- Fuso horário
- Rastreamento de geolocalização
- O alternador de marca "Powered By PushEngage" no seu widget de painel
Se alguma vez precisou de corrigir algum desses detalhes do site pushengage após a instalação inicial, este é o par de ferramentas que alcança todos os cinco campos, e é o mesmo par de ferramentas para os ler antes de assumir que algo está mal configurado.
O fuso horário importa mais do que parece. É o ponto de referência para cada envio agendado e cada peça de agendamento baseado no fuso horário do assinante que executa. Se o errar, um envio às 9h aterrará às 2h para uma parte da sua lista, o que é lido como uma falha de segmentação quando a causa real é um campo mal configurado.
A geolocalização está desativada por defeito e tem de ser explicitamente ativada antes que o PushEngage possa anexar dados de cidade, estado e país a um registo de assinante, que é a base sobre a qual a segmentação por geolocalização depende. Se os seus segmentos referenciam a localização e os números parecem baixos, vale a pena verificar isto antes de assumir que a sua base de assinantes não tem a dispersão geográfica que esperava.
O alternador de marca é mais simples: controla se "Powered By PushEngage" é exibido no seu widget de painel ou não, o que é mais importante para equipas que executam uma experiência de suporte ou chat com marca branca onde cada marca de fornecedor visível é examinada.
Nenhum destes requer um ticket de suporte ou uma busca em menus de definições aninhados. O próprio exemplo do README é o padrão a seguir: pergunte ao seu assistente, “Mude o fuso horário do meu site para Asia/Kolkata e ative a geolocalização”, e ambos os campos são atualizados num único pedido. Corrigir o URL do seu site após uma alteração de domínio, ou o nome do seu site após um rebranding, segue o padrão idêntico.
Padrões de campanha: as definições que controlam silenciosamente a atribuição e o alcance de cada envio
pushengage_get_campaign_defaults e pushengage_update_campaign_defaults cobrem quatro campos. Estes padrões de campanha do pushengage não são cosméticos. São as definições que estão por baixo de cada envio que executa, quer alguém da equipa se lembre ou não de que existem, e errar em qualquer uma delas não falha ruidosamente o suficiente para que alguém note imediatamente.
- Parâmetros UTM: a sua base para rastrear notificações push com parâmetros UTM no GA4 ou em qualquer pilha de análise a jusante dele. Ignorar esta definição e cada envio herda atribuição em branco: envios sem origem ou meio, receita não atribuível, uma lacuna que ninguém nota até que um relatório mensal não some. Esse é o relatório de atribuição de canal que abriu este artigo.
- Notificação de fallback: o que é acionado para um assinante que não corresponde a nenhuma regra de audiência. Deixe-a desmarcada e esses assinantes não recebem nada.
- Atributos de fallback: tokens de personalização para esse mesmo grupo não segmentado, para que a sua cópia pareça intencional em vez de quebrada ou genérica. Um assinante sem um atributo correspondente não deve ver um espaço em branco onde o seu primeiro nome deveria estar.
- Expiração padrão da notificação: quanto tempo um envio não entregue fica em fila antes que o PushEngage o descarte. Um envio de flash-sale com expiração de 7 dias ainda pode chegar dias após o fim da venda, enganando um assinante em vez de simplesmente falhar silenciosamente, o que é pior para o relacionamento do que o envio nunca chegar.
Definir uma expiração padrão de 7 dias é um único pedido: “Defina a minha expiração padrão de notificação para 7 dias”, diretamente do próprio exemplo do README. O mesmo padrão cobre uma notificação de fallback para assinantes não correspondentes, atributos de fallback para a personalização desse grupo, ou uma passagem completa pelos parâmetros UTM para que cada envio atribua corretamente de volta ao GA4 daqui para frente. Rever os seus padrões de campanha atuais do pushengage antes de uma grande janela de envio, em vez de depois de uma lacuna de relatório aparecer, é a versão deste hábito que vale a pena construir.
Definições do service worker: registo, suporte a sub-pastas e o caminho do ficheiro do worker
pushengage_get_service_worker_settings e pushengage_update_service_worker_settings cobrem o registo, o suporte a subdiretórios e o caminho do ficheiro do worker: a mecânica que permite que as notificações push cheguem a um navegador em primeiro lugar. Errar em qualquer um dos três e o modo de falha é o mesmo. As notificações param silenciosamente de ser entregues, sem um erro óbvio que aponte para a configuração que o causou, e o primeiro sintoma que alguém nota é uma queda nos números de envio sem causa aparente.
O suporte a subdiretórios é o que engana sites com restrições de plataforma que não permitem um ficheiro worker a nível raiz: um CMS, uma instalação em subdiretório, uma configuração multi-site a partilhar um domínio. Se o seu ficheiro worker estiver noutro local que não a raiz, a configuração do caminho tem de corresponder a essa localização exata, tanto o diretório como o nome do ficheiro, ou o registo falha silenciosamente.
Esta é a primeira coisa que vale a pena verificar após uma migração de site ou uma alteração de plataforma: peça ao seu assistente para obter as suas configurações atuais do service worker do pushengage e confirme se o caminho registado ainda corresponde a onde o ficheiro realmente reside, o mesmo tipo de verificação que a configuração do service worker da PushEngage para configurações com restrições de plataforma existe para resolver.
O próprio registo também merece uma análise periódica, particularmente após qualquer alteração na forma como o seu site carrega scripts. Uma atualização da política de segurança de conteúdo, um novo contentor de gestão de tags ou uma camada de cache que remove cabeçalhos podem interferir com o registo de formas que não aparecem em lado nenhum, exceto num declínio silencioso nas notificações entregues. Obter as suas configurações do service worker do pushengage juntamente com uma verificação da taxa de entrega é um hábito de cinco minutos que apanha o problema antes que lhe custe um ciclo de relatório completo.
Edições parciais sem reintroduzir tudo: porque é que o comportamento de mesclagem é importante
Aqui está o detalhe que torna o pedido a um assistente de IA mais rápido do que o painel de controlo, não apenas diferente: pushengage_update_campaign_defaults mescla a sua alteração sobre os valores atuais em vez de substituir todo o registo. Peça para alterar apenas a expiração padrão da notificação, e os seus parâmetros UTM, notificação de fallback e atributos de fallback permanecem exatamente como estavam. Não tem de ress-especificar campos que não tem intenção de tocar.
Compare isso com um formulário de configurações típico, onde alterar um campo num bloco guardado muitas vezes significa que todo o formulário é recarregado com todos os campos editáveis, e um deslize num campo não relacionado substitui silenciosamente algo que estava a funcionar corretamente. “Definir a minha expiração padrão de notificação para 7 dias” altera exatamente uma coisa e deixa o resto das suas configurações de campanha intocadas. Essa é a diferença entre uma edição direcionada e uma re-gravação completa sempre que uma única configuração precisa de um ajuste, e é a diferença que transforma uma revisão mensal de configurações de uma tarefa de quinze minutos de volta na solicitação de uma frase que deveria ter sido desde o início.
O que as configurações precisas realmente protegem: entregabilidade e atribuição, não apenas organização
Nada disto tem realmente a ver com arrumação. Um fuso horário errado quebra o tempo de envio programado para parte da sua lista. Um padrão UTM em falta quebra a atribuição para todos os envios até que alguém o detete. Um service worker mal registado quebra a entrega completamente, e fá-lo silenciosamente. Cada uma destas definições está por baixo de cada campanha que a sua equipa executa. A campanha não falha ruidosamente; a análise por cima dela simplesmente para silenciosamente de corresponder à realidade.
Esse é o caso real para tratar detalhes do site, padrões de campanha e configuração do service worker como definições de notificação push do assistente de IA que verifica rotineiramente, da mesma forma que verificaria um painel de controlo de taxa de entrega, em vez de um passo de configuração único que configura uma vez e nunca mais revisita. Enquadrar estas como definições de notificação push do assistente de IA em vez de um separador de painel de controlo oculto significa que a verificação em si demora o tempo que leva a digitar o pedido. Detetar um padrão UTM quebrado ou um caminho de worker desatualizado num pedido protege os mesmos números de receita recuperada em que os seus relatórios de retenção dependem, sem esperar por um ticket de TI ou uma chamada de re-onboarding para corrigir algo que leva uma frase a dizer em voz alta.
Assim que o seu servidor PushEngage MCP estiver ligado, percorra os três grupos de definições abordados neste guia de configuração de definições do site PushEngage da forma como percorreria qualquer outra auditoria de retenção: rapidamente e no seu próprio horário, em vez de apenas quando um relatório não bate certo. Funciona em todos os planos PushEngage, incluindo o nível gratuito, pelo que não há porta entre ter o servidor MCP ligado e utilizá-lo efetivamente para verificar os seus detalhes do site PushEngage, padrões de campanha e definições do service worker antes que lhe custem atribuição ou alcance.
