Sugestão de inclusão no GW Server

Olá @Gabriel, gostaria de fazer uma sugestão de inclusão, de um aplicativo, no GW Server:

Trate-se do sGTM (Server-side Google Tag Manager ou Gerenciador de Tags do Google no Lado do Servidor).

Ferramenta que eu vejo que existe um custo benefício muito bom, quando instalada em um VPS. E que muitas pessoas irão precisar, mas que ainda nem sabem que irão precisar. E as que sabem que precisam, esbarram nas barreiras técnicas ou barreiras de custo.

Estou pensando em instalá-lo aqui em um VPS da Oracle (Always Free - Canonical-Ubuntu-24.04-Minimal-aarch64-2026.09.18-0, OCPU count 2, Network bandwidth (Gbps) 2, Memory (GB) 12, Local disk 200 gb) manualmente, mas sinceramente, ficar sem a cobertura do GW Server para gerenciar uma aplicação (F2Ban, instalação automática, registro de logs, isolamento entre apps, monitoramento de cada ferramenta e etc.) dificulta o processo.

Abaixo, estão alguns detalhes que reuni, caso você deseje considerar a inclusão dessa aplicação no GW Server:

Como funciona:
Diferentemente do já conhecido e popular GTM “Tradicional”, que carrega dezenas de scripts de terceiros diretamente no navegador do visitante para enviar dados individualmente a cada plataforma (Google Analytics, Meta, TikTok, etc.). Já o sGTM funciona movendo o processamento e o disparo das tags de marketing e análise do navegador do usuário (Client-Side) para um único fluxo de dados unificado para o seu servidor e assim você, trata, limpa e distribui essas informações para os destinos finais.

Porque usá-lo?
Antes era considerado um recurso avançado e opcional para grandes empresas, mas hoje em dia está se tornando o padrão de mercado para negócios de todos os tamanhos que buscam manter a precisão de suas métricas. Principalmente por conta de 3 características:

  1. O Fim dos Cookies de Terceiros e Bloqueadores de Anúncios:
    Com as restrições severas de privacidade dos navegadores (como o ITP da Apple) e o uso em massa de adblockers, o rastreamento tradicional via navegador (Client-Side) perde até 30% ou mais dos dados de conversão. Como o sGTM permite coletar dados em um subdomínio próprio (first-party), ele contorna esses bloqueios, garantindo que as informações cheguem corretamente a plataformas como Meta (Facebook API), Google Ads e TikTok.
    2. Ganho Massivo em Performance de Sites (Core Web Vitals):
    No GTM tradicional, dezenas de scripts pesados de terceiros são carregados diretamente no navegador do usuário, deixando o site lento. Com o sGTM, o site envia apenas um fluxo simplificado de dados para o servidor. O servidor processa e distribui essas informações, reduzindo drasticamente o código executado no navegador, o que melhora a velocidade do site e, consequentemente, a taxa de conversão.
    3. Segurança e Controle Total dos Dados:
    Privacidade e conformidade com leis como a LGPD são prioridades. No modelo antigo, uma tag de terceiros tinha acesso livre a dados do usuário no navegador. Com o sGTM, a empresa decide exatamente quais dados enriquecer, mascarar ou remover antes de enviá-los para parceiros externos.

Custos
Os custos médios para manter o sGTM variam drasticamente dependendo da plataforma escolhida e do volume de requisições (tráfego do site).
Detalhe: 1 acesso (sessão) no seu site não equivale a apenas 1 requisição no sGTM. Em média, 1 sessão gera cerca de 5 a 10 requisições para o servidor (considerando visualizações de página, cliques, eventos de e-commerce e disparos para múltiplas tags como Google Analytics e Meta CAPI).
Opções no mercado:

  1. Stape.io
    É uma hospedagem especializada em sGTM que compra servidores da Google Cloud em lote e otimiza a arquitetura, repassando um preço fixo muito menor. É a opção preferida para pequenas e médias empresas pela simplicidade (configuração em 5 minutos).
    • Até 10.000 requisições/mês: Gratuito (Excelente para testes).
    • Até 500.000 requisições/mês: US$ 17 a US$ 20 / mês (Plano Pro - cobre a maioria dos sites institucionais e e-commerces iniciantes).
    • Até 5.000.000 requisições/mês: US$ 83 a US$ 100 / mês (Plano Business).
    • Vantagens adicionais: Os logs de rastreamento e recursos extras (como o Cookie Keeper para burlar o ITP do Safari) já estão inclusos no preço.
  2. Google Cloud Platform - GCP (A opção Nativa/Oficial)
    A infraestrutura recomendada oficialmente pelo Google roda através do Cloud Run (ou App Engine). Embora o Cloud Run tenha uma camada gratuita generosa, o ambiente de produção do sGTM exige uma arquitetura robusta com balanceadores de carga e instâncias mínimas ativas para evitar lentidão (cold starts).

Requisitos:
Variam de acordo com o volume de requisições, mas a aplicação em si é bastante leve (roda sobre Node.js dentro de um container Docker). A imagem Docker oficial do GTM
gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
é compatível com arquitetura ARM64.

1.Requisitos de Hardware (CPU, RAM e Disco)
Produção / Médio Tráfego (50.000 a 500.000 requisições/dia):

  • CPU: 2 vCPUs
  • RAM: 2 GB a 4 GB
  • Disco: 25 a 30 GB SSD

2.Requisitos de Software

  • Sistema Operacional: Linux (Ubuntu 22.04/24.04 LTS ou Debian 12 recomendados).
  • Engine de Containers: Docker e Docker Compose.
  • Proxy Reverso: Nginx, Caddy ou Traefik. O proxy reverso é necessário para:
    1.Gerenciar o certificado SSL/TLS (HTTPS).
    2.Direcionar as requisições das portas 80/443 para as portas internas do Docker (geralmente porta 8080).

3.Requisitos de Rede e Segurança

HTTPS/SSL Obrigatório: O sGTM exige HTTPS funcional para leitura/gravação de cookies first-party e comunicação segura com plataformas como Google Analytics 4, Meta CAPI e TikTok.

  • Portas de Entrada (Inbound):
  • 80 (HTTP — necessário para a emissão/renovação de certificados Let’s Encrypt).
  • 443 (HTTPS — tráfego principal de tags).
  • Portas de Saída (Outbound):
  • Acesso total de saída na porta 443 para que a VPS consiga enviar eventos para as APIs externas (Google, Meta, TikTok, etc.).
  • Configuração na Oracle Cloud:
  • Lembre-se de abrir as portas 80 e 443 nas Security Lists (no painel da Oracle VCN) e também no firewall interno do SO (via iptables ou ufw dentro da VPS).

4.Arquitetura Recomendada no Docker
Para um ambiente de produção limpo, o recomendado é rodar dois containers sGTM via Docker Compose:

  1. Live/Tagging Server: Processa os dados de produção recebidos dos usuários (RUN_AS_PREVIEW_SERVER=false).
  2. Preview Server: Utilizado para o modo de depuração (Tag Assistant) do GTM (RUN_AS_PREVIEW_SERVER=true).

Exemplo prático de docker-compose.yml

version: '3.8'

services:
  gtm-live:
    image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
    restart: always
    ports:
      - "8080:8080"
    environment:
      - CONTAINER_CONFIG=SEU_CONTAINER_CONFIG_BASE64_AQUI
      - PREVIEW_SERVER_URL=https://preview.seu-dominio.com

  gtm-preview:
    image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
    restart: always
    ports:
      - "8081:8080"
    environment:
      - CONTAINER_CONFIG=SEU_CONTAINER_CONFIG_BASE64_AQUI
      - RUN_AS_PREVIEW_SERVER=true

(O CONTAINER_CONFIG é obtido nas Configurações do Container no painel do GTM Server-Side).

Obrigado.