Notificação push para atendimento noturno de desentupimento na capital: Guia WordPress

Seu cliente tem um vazamento na madrugada, abre o site da desentupidora no celular, mas não sabe que há equipe de plantão naquela hora. A notificação push não chegou — ou pior, nunca foi pedida. Como resolver esse silêncio digital que custa chamados perdidos?

A resposta está na implementação correta da Web Push API com Service Workers no WordPress, garantindo que alertas de disponibilidade noturna cheguem mesmo com o navegador fechado. Diferente de e-mails que ficam enterrados na caixa de entrada ou SMS com custo por disparo, o push nativo aparece na tela de bloqueio do dispositivo em segundos, com custo marginal zero após a infraestrutura pronta.

Este guia técnico cobre da geração de chaves VAPID à métrica de conversão, passando por fallbacks, segmentação geográfica e testes em localhost. O foco é arquitetura confiável para operações 24h na capital paulista, onde a janela de atendimento entre 22h e 6h decide entre fidelizar o cliente ou perdê-lo para o concorrente que notificou primeiro.

Arquitetura de chaves VAPID e armazenamento seguro

O protocolo Voluntary Application Server Identification (VAPID) autentica seu servidor junto ao push service (Google FCM, Mozilla Push, Apple Push) sem cadastro prévio. Gere o par de chaves ECDSA P-256 uma única vez:

openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem
openssl ec -in vapid_private.pem -pubout -out vapid_public.pem

Converta a pública para base64url (sem padding) para uso no JavaScript. No WordPress, armazene a privada em wp-config.php ou variável de ambiente via .env (nunca no banco). A biblioteca web-push-php espera a chave privada em formato PEM ou base64url. Defina também o subject (mailto: ou https://) para contato do push service em caso de abuso.

Service Worker: registro, escopo e ciclo de vida

O Service Worker (SW) é o agente que recebe o push quando o site não está aberto. Registre-o no template do tema ou plugin principal:

if ('serviceWorker' in navigator && 'PushManager' in window) {
  navigator.serviceWorker.register('/sw.js', { scope: '/' })
    .then(reg => console.log('SW registrado:', reg.scope))
    .catch(err => console.error('Falha no registro:', err));
}

O arquivo sw.js deve ficar na raiz do domínio (ou ajuste scope). Nele, trate três eventos essenciais:

1. push: recebe payload do servidor, chama self.registration.showNotification() com título, corpo, ícone, badge, data.url para redirecionamento e actions (ex: “Solicitar agora”, “Agendar”).
2. notificationclick: foca/já abre a janela no data.url e fecha a notificação.
3. pushsubscriptionchange: re-inscreve automaticamente quando o push service rota a subscription (ex: chave de criptografia expirada).

Use event.waitUntil() em todos para estender a vida do SW até a promessa resolver. Teste no DevTools > Application > Service Workers simulando “Push” com payload JSON.

Endpoint REST no WordPress para salvar subscriptions

Crie um endpoint POST /wp-json/seu-plugin/v1/push/subscribe autenticado (cookie nonce ou Application Password) que receba { endpoint, keys: { p256dh, auth }, user_id, region }. Valide: endpoint HTTPS, chaves base64url válidas, região dentro da área de cobertura. Salve em tabela customizada wp_push_subscriptions com índices em user_id, region, endpoint (único).

No frontend, após reg.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: vapidPublicKey }), envie a subscription via fetch para esse endpoint. Trate duplicidade (mesmo endpoint) como update de region/user_id.

Envio confiável: retry, limpeza e batch

O envio server-side usa WebPush::sendNotification($subscription, $payload, true, $options). Implemente fila (Redis + WP-CLI job ou Action Scheduler) para não travar o PHP-FPM. Estratégia de retry exponencial: 1min, 5min, 15min, 1h, 6h, max 24h. Em respostas 410 (Gone) ou 404 (Not Found), marque subscription como invalid e pare retries — o push service removeu aquele endpoint.

Processe em lotes de 100-500 com sleep(1) entre lotes para respeitar rate limits do FCM/APNs. Logue message_id retornado para auditoria. Para plantão noturno, agende disparo imediato quando técnico assume o turno (webhook do sistema de escalas) ou via cron a cada 30min verificando equipe ativa.

Fallback multicanal: e-mail e SMS quando push falha

Nem todo usuário aceita push. Use navigator.permissions.query({ name: 'notifications' }) para ler estado: granted, denied, prompt. Se denied, esconda o botão “Ativar alertas” e mostre “Receber por e-mail/SMS”. Salve preferência notification_channel: 'email' | 'sms' | 'push' no perfil.

No disparo noturno, itere subscriptions válidas por região. Para cada usuário sem subscription push ativa, acione wp_mail() com template de plantão ou integre provedor SMS (Twilio, Zenvia) via hook seu_plugin_notify_fallback. Garanta idempotência: logue notification_log(user_id, channel, status, timestamp) para não duplicar.

Segmentação por bairro e zona de cobertura na capital

São Paulo tem 96 distritos. A equipe de plantão cobre zonas específicas por noite. No cadastro, capture localização via:

• navigator.geolocation.getCurrentPosition() (preciso, exige HTTPS e permissão)
• IP-based (MaxMind GeoIP2, menos preciso, sem permissão)
• Seleção manual de bairro/CEP no formulário

Salve lat, lng, district, zone na subscription. No envio, filtre WHERE zone IN (zones_da_noite) AND valid = 1. Para otimizar, mantenha materialized view ou cache Redis zone:subscriptions atualizado via trigger no insert/update.

Teste local com HTTPS real via túnel

Service Worker e Push API exigem contexto seguro (HTTPS ou localhost). Em desenvolvimento, use ngrok:

ngrok http 8080

Configure WP_HOME/WP_SITEURL ou define('WP_SITEURL', 'https://xxxx.ngrok-free.app') no wp-config.php. Atualize applicationServerKey no JS se regenerar chaves. No DevTools, inspecione navigator.serviceWorker.controller e registration.pushManager.getSubscription(). Use web-push-cli para disparar teste:

web-push send-subscription --endpoint "https://fcm.googleapis.com/..." --payload '{"title":"Teste plantão","body":"Equipe na Zona Sul"}' --vapid-subject "mailto:dev@exemplo.com" --vapid-pubkey "BEl62iU..." --vapid-pvtkey "UUxJy...

Verifique notificação no celular/desktop e clique para confirmar redirecionamento para /area-do-cliente/ ou /plantao-noturno/.

Métricas e dashboard para decisões de plantão

Crie tabela wp_push_metrics(event_date, zone, sent, delivered, clicked, converted, opted_out). No notificationclick, dispare fetch('/wp-json/seu-plugin/v1/push/click', { method: 'POST', body: JSON.stringify({ subscription_id, timestamp }) }) (use navigator.sendBeacon para confiabilidade). No servidor, incremente clicked e, se virar chamado (via hook do formulário), incremente converted.

Dashboard admin: gráfico de linha delivered/sent (delivery rate) por hora, heatmap zone x hour de converted/clicked, alerta se opted_out > 5% no dia. Correle com dados do analytics-de-conversao-para-leads-de-desentupimento-no-mandaqui para validar se push noturno aumenta leads qualificados.

Segurança: headers, CSP e rotação de chaves

Adicione ao .htaccess ou nginx:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; connect-src 'self' https://fcm.googleapis.com https://push.services.mozilla.com; worker-src 'self' blob:;";
add_header Permissions-Policy "notifications=(), push=()";

Ajuste connect-src para seus push services. worker-src blob: permite SW inline se necessário. Para rotação de chaves VAPID (recomendada a cada 12-24 meses): gere novo par, adicione vapid_public_key_v2 no JS, mantenha a v1 ativa no backend. No pushsubscriptionchange, re-inscreva com a nova chave pública. Migre subscriptions em lote noturno (baixo tráfego) via WP-CLI command.

Integração com área do cliente e formulários de emergência

A notificação deve levar a uma ação concreta. No data.url do push, use deep link: /area-do-cliente/?push=plantao&zone=sul&tech=joao. O template da área do cliente lê query params e pré-preenche formulário de chamado com região e técnico de plantão. Veja implementação completa em area-do-cliente-para-manutencao-de-coluna-de-esgoto-em-sp e sistema-de-chamados-para-emergencias-de-esgoto-vasos-e-pias.

Para usuários não logados, redirecione para landing page de plantão com CTA único: “Chamar equipe agora”. Essa página deve carregar em < 1.5s (Core Web Vitals) e funcionar offline via SW cache-first. Consulte pagina-de-plantao-noturno-otimizada-para-desentupimento-na-capital para checklist de performance.

Checklist de deploy para produção

1. Chaves VAPID no .env (não no repo), VAPID_SUBJECT configurado.
2. sw.js na raiz, versionado (sw.js?v=2024.01.15), com self.skipWaiting() e clients.claim() no activate.
3. Endpoint REST com rate limit (ex: 10 req/min/IP) e validação de nonce.
4. Fila de envio processando a cada minuto, logs em wp-content/debug.log rotacionados.
5. Fallback e-mail/SMS testado com contas reais (Gmail, WhatsApp Business API).
6. Geolocation testada em 5 bairros distintos (centro, zona sul, norte, leste, oeste).
7. Dashboard admin acessível só para manage_options, com export CSV.
8. Documentação de rotação de chaves e procedimento de incidente (push service down).

Uma notificação push bem arquitetada transforma o site em canal de alerta ativo, não passivo. O investimento em Service Worker, VAPID e fila assíncrona paga-se no primeiro plantão em que o cliente clica “Chamar agora” às 3h da manhã porque recebeu o aviso na tela do celular. Para o time de desenvolvimento, o ganho é reutilizar essa base para qualquer alerta crítico: vazamento detectado por sensor, agendamento confirmado, técnico a caminho. O www.DezJatoDesentupidora.COM.BR utiliza essa arquitetura para coordenar equipes noturnas na capital com entrega medida em segundos, não minutos.

Checklist prático

Perguntas frequentes