Com o surgimento de questões ligadas a dados, privacidade e “primeira parte” no marketing digital, o assunto da marcação “do lado do servidor” frequentemente surge em cima da mesa. A questão subjacente, do lado da pilotagem, é: “Devo ir para lá ou não devo ir?” ou “Devo ir agora ou mais tarde?” Neste artigo, tentaremos uma abordagem sintética para ajudar na tomada de decisões.
resumo:
- 3 questões principais
- Confiança nos dados coletados
- Controle de dados enviados a terceiros
- Otimizando o desempenho do site
- “Lado do servidor”, Kézako?
- Equívocos
- Como fazemos
- Conclusão
Definições úteis:
- Biscoito original: um cookie associado ao mesmo nome de domínio do site visitado.
- Cookie de terceiros (ou cookie de terceiros): um cookie que está associado a um domínio diferente do site visitado (muitas vezes um domínio de uma plataforma de publicidade).
- ITP (Prevenção de rastreamento inteligente) : Recurso de privacidade introduzido pela Apple no Safari em 2017.
- TMS (Sistema de gerenciamento de tags): sistema de gerenciamento de tags
3 questões principais
Primeiro, vamos colocar na mesa três questões principais frequentemente levantadas no contexto de uma estratégia “do lado do servidor”. Para cada uma dessas questões, abordaremos seus impactos e o que a tecnologia do lado do servidor pode trazer.
Problema 1: Confiança nos dados (qualidade dos dados)
Decisões importantes são tomadas com base nos resultados observados nos relatórios de Web Analytics. As campanhas publicitárias também são ajustadas e otimizadas com base nos dados coletados. La confiabilidade dos dados então é um questão importante.
Nos últimos anos, vários eventos técnicos ou regulamentares impactaram a recolha de dados:
- RGPD (regulatório) : perdemos parte dos dados.
- Bloqueadores de anúncios (técnico) : perdemos outra parte dos dados.
- Safári/iOS/Firefox(técnico) : ainda perdemos dados (com ITP, um sistema de prevenção de rastreamento que limita consideravelmente o uso de cookies)
- Cookies de terceiros do Chrome (técnico): em espera no momento, mas esperamos desenvolvimentos futuros que certamente levarão a mais perdas de dados
Vejamos esses diferentes pontos um pouco mais de perto:
1 – RGPD
Do lado regulatório, alguns visitantes não dão o seu consentimento. É normal, está feito. E podemos muito bem ser claros desde o início, a ideia do lado do servidor não é substituir consentimentos !
️ </ s> </ s> Em França, estima-se que cerca de 35% dos utilizadores da Internet não dão o seu consentimento.
(fonte: Barômetro Digital Credoc – 2022)
⚠️ Impacto: Parte dos dados não é coletada. Os KPIs volumétricos nos relatórios de Web Analytics perdem o sentido (as proporções e desenvolvimentos permanecem utilizáveis).
2 – Bloqueadores de anúncios
Uma proporção significativa de usuários equipa seus navegadores complementos, chamados bloqueadores de anúncios (bloqueadores de anúncios). O papel destas ferramentas é principalmente dificultar o funcionamento dos processos de marketing/publicidade nos sites visitados. Às vezes, essas ferramentas podem até ir além desse objetivo, chegando ao ponto de impedir o carregamento completo do Tag Manager.
Como dissemos, basicamente, trata-se obviamente de respeitar as escolhas do utilizador em termos do RGPD. Para isso, provavelmente o seu site já está equipado com um gerenciador de consentimentos (Axeptio, Cookiebot, Didomi, etc.).
Mas ao carregar um Gerenciador de tags, executar tags e coletar dados em conformidade com os regulamentos, você está simplesmente fazendo seu trabalho como operador de site e pode visar legitimamente o objetivo de não permitir que suas ferramentas compatíveis atrapalhem.
️ </ s> </ s> Na França, cerca de 30 a 40% dos usuários de Internet (desktop) usam bloqueadores de anúncios
⚠️ Impacto: uma parte adicional dos dados não é coletada. O impacto do ponto anterior (RGPD) é amplificado.
3 – ITP (Safari/Firefox…)
O sistema ITP (Intelligent Tracking Prevention), lançado em 2017, tem como objetivo restringir a utilização de cookies. Está presente nos navegadores Safari e Firefox, entre outros.
Ele bloqueia notavelmente cookies de terceiros e elimina cookies primários após 1 dias.
️ </ s> </ s> Na França, cerca de 32% dos usuários da Internet usam Safari (fonte Statista)
⚠️ Impacto: Aqui, são principalmente as capacidades de segmentação ou modelos de atribuição de sistemas de publicidade de terceiros que são impactados (cookies de terceiros bloqueados). No lado do Web Analytics, eles não conseguem mais reconhecer um usuário recorrente de forma eficaz (cookies primários eliminados dentro de 1 a 1 dias).
4 – Bloqueio de cookies de terceiros no Chrome
A mesma ideia aqui: depois de mencionar pela primeira vez um adiamento da depreciação de cookies de terceiros para 2025, O Google anunciou recentemente que cookies de terceiros no Chrome não seriam descontinuados (22/07/24). Apesar de tudo, este bloqueio de cookies de terceiros continua a ser um problema a resolver. Mesmo que os futuros desenvolvimentos do Chrome não consistam num bloqueio total, podemos esperar que deixem mais controlo aos utilizadores com, como consequência, uma alteração do funcionamento atual.
É em particular o burburinho em torno deste ponto que está a gerar um recente aumento no interesse em tecnologias do lado do servidor.
️ </ s> </ s> Na França, cerca de 57% dos usuários da Internet usam o Chrome (fonte Statista)
⚠️ Impacto: Ampliará o impacto do ponto anterior (ITP) nos cookies de terceiros. Assim, especialmente no que diz respeito ao direcionamento das campanhas publicitárias e aos modelos de atribuição (queda no retorno dos investimentos publicitários ou ROAS).
Resumo, ao reduzir a quantidade de dados recolhidos, a massa estatística fica naturalmente enfraquecida. A confiança nos dados é abalada e as estratégias de marketing perdem um pouco da sua precisão e eficácia.
Contribuições do lado do servidor sobre a confiança nos dados:
Nesta primeira questão, uma implementação no lado do servidor reduzirá o impacto dos limites técnicos:
- Reduza o impacto dos bloqueadores de anúncios (dependendo da solução técnica utilizada).
- Reduza o impacto das limitações no Safari/Firefox (ITP).
- Reduza o impacto do bloqueio de terceiros no Chrome.
⚠️ Observe que existem diferentes maneiras de implementar no lado do servidor, garantindo mais ou menos eficiência. Discutiremos nossas recomendações nesta área no final do artigo.
👍 Com o server-side, a coleta de dados será mais ampla e qualitativa, o que será favorável para otimizar estratégias de campanhas de marketing e melhorar a qualidade da análise de audiência.
Problema 2: Controlar os dados coletados (governança de dados)
Do lado do cliente, os scripts de tags podem coletar determinados dados sem que sejam totalmente transparentes e controlados. Na verdade, é bastante difícil verificar o que realmente é capturado e enviado pela tag.
No lado do servidor, a implementação da marcação envolve um processo no qual cada dado capturado no lado do cliente é definido e enviado para as tags do lado do servidor.
Contribuições do lado do servidor sobre governança de dados:
Nesta segunda questão, o lado do servidor fornece:
- Visibilidade total dos dados veiculados pelas tags
- Controle total destes dados veiculados por tags (anonimização/modificação de dados pessoais)
- Os “fornecedores” (Meta, Google, etc.) acessam apenas os dados configurados nas tags no Tag Manager.
👍 O server-side permite recuperar o controle dos dados envolvidos nos processos de Web Analytics e Marketing Digital.
Questão 3: Preservar o desempenho do site
Em um sistema de marcação do lado do cliente, as tags são carregadas e executadas pelo navegador do usuário.
Algumas tags, tomadas individualmente, já são bastante pesadas (ex: Facebook Pixel). Mas, no conjunto, às vezes temos cobranças cumulativas significativas e impactantes para os visitantes.
© Sorriso
Contribuições do lado do servidor para o desempenho do site:
Na questão de desempenho, o lado do servidor fornece:
- Otimização/limitação da quantidade de elementos processados do lado do Cliente.
- Favorável para experiência do usuário (UX).
- Favorável para SEO.
👍 O lado do servidor promove o desempenho do site e o SEO.
O “lado do servidor”, kézako?
Mas Jamy, o que é uma tag “do lado do servidor”?
Normalmente, uma tag de rastreamento é executada no navegador do cliente. A troca de dados é direta entre o navegador do visitante e a plataforma de marketing ou análise. Falamos então de uma tag “do lado do cliente”.
Lado do cliente:
- Cada tag é carregada/executada pelo navegador.
- Cada tag coleta seus dados (geralmente iguais a outras tags).
No caso de uma tag do lado do servidor, a informação é transmitida do lado do cliente para outro contêiner hospedado em um servidor na nuvem, por meio de uma única tag que atua como “transportador”. As tags são então executadas com esses dados do servidor para as plataformas de marketing ou análise.
Lado do servidor:
- Apenas uma tag de coleção é carregada pelo navegador.
- Uma única tag de coleção pega os dados e os disponibiliza para tags do lado do servidor.
© Sorriso
Ok, mas qual é o objetivo?
Graças ao fato das tags serem executadas a partir de um servidor e não do navegador/cliente, obtemos as seguintes características:
- Uma tag do lado do servidor não coloca cookies de terceiros nos navegadores dos visitantes. No entanto, os cookies colocados pelo servidor tornam-se primários.
- Uma tag do lado do servidor só pode enviar dados recebidos pelo ponto de entrada único do cliente.
- Uma tag do lado do servidor não é executada nos navegadores dos visitantes.
Isso confere então estas vantagens principais:
- Melhor qualidade de dados
Ao limitar o impacto dos bloqueadores de anúncios ou das limitações associadas aos cookies de terceiros, recolhemos mais dados.
- Controle dos dados coletados
Ao gerenciar o canal de dados para tags do lado do servidor, você recupera o controle do que é enviado e, portanto, coletado.
- Otimização de tempos de cobrança
Ao executar as tags no lado do servidor, reduzimos o trabalho do navegador. Isso vai no sentido de melhorar a experiência do usuário e a otimização de SEO.
- Método mais sustentável
A evolução das regulamentações e tecnologias tende a aumentar o interesse do lado servidor. Ao embarcarmos cedo o suficiente, podemos esperar uma boa sustentabilidade, em oposição a tudo o que gira em torno de cookies e do lado do cliente.
Algumas ideias pré-concebidas
-
O lado do servidor permite que você ignore bloqueadores de anúncios
Na minha opinião, isso é um pouco verdadeiro e um pouco falso :cEste não é o objetivo principal do lado do servidor. Contudo, é verdade que
Este não é o objetivo principal do lado do servidor. Porém, de fato, logicamente ao enviar tags do lado do servidor, estas não serão mais prejudicadas.
Mas para que a marcação do lado do servidor funcione, seu site ainda deve continuar a usar um contêiner do Gerenciador de tags do lado do cliente com tags vinculadas ao lado do servidor. Essas tags “ponte” podem permanecer bloqueadas por um bloqueador de anúncios. Nesse caso, não podemos dizer que o lado do servidor está contornando o bloqueador de anúncios. A mesma coisa se o bloqueador de anúncios bloquear completamente o Gerenciador de tags.
Em resumo, o lado do servidor por si só não é suficiente para contornar os bloqueadores de anúncios.
Mencionaremos um pouco mais adiante neste artigo que técnicas avançadas de implementação permitem limitar o impacto dos bloqueadores de anúncios.
-
O lado do servidor permite que você não carregue nada no lado do cliente
Também aqui é necessário ser qualificado e ppelo mesmo motivo: Na verdade, na maioria das vezes, quando falamos sobre marcação no lado do servidor, estamos na verdade falando de “Cliente para Servidor para Servidor”. Observe que existe um tipo de implementação avançada que permite Servidor a Servidor (com o Protocolo de Medição, reservado para especialistas).
Para fazer com que a marcação “clássica” do lado do servidor funcione, seu site ainda deve continuar a usar um contêiner do Gerenciador de tags do lado do cliente com tags que fazem a “ponte” para o lado do servidor. Portanto, em todos os casos, ainda existem processos no lado do navegador/cliente.
Mas, na verdade, certas tags serão transferidas para o lado do servidor.
Em resumo, o lado do servidor (clássico) pode reduzir as cargas do lado do cliente, mas não eliminá-las completamente.
-
O lado do servidor é bom, mas é caro
Então, no que diz respeito ao custo, tudo é relativo (de novo!?): Se olharmos apenas para os custos diretos das soluções e o tempo do especialista necessário para a implementação, pode esfriar (caso contrário não fazemos nada e não gaste nada extra).
Mas obviamente vou propor aqui ampliar um pouco a reflexão: fiz um cálculo rápido num canto de uma toalha de mesa (ok… usei uma planilha) que gostaria de compartilhar com vocês:
Vamos começar com a hipótese de um varejista eletrônico que executa campanhas de SEA usando retargeting. Temos alguns KPIs disponíveis:
- Gasta 5€/mês em SEA.
- O seu CPC médio é de 1,5€/clique.
- O seu cabaz médio é de 140€ com uma margem bruta de 40%.
- Ele observa uma taxa média de conversão do SEA de 3%.
Tudo está a correr bem no melhor dos mundos possíveis e tudo está a funcionar com cerca de 100 conversões por mês e uma margem bruta total gerada de 7€/mês. O impacto direto da SEA é positivo em +000€/mês (margem bruta – gastos CPC). E então, um “bem dia”, reduzimos suas capacidades de segmentação por causa de uma atualização do Chrome que bloqueou cookies de terceiros… A partir daí, com suas campanhas um pouco menos efetivas, ele viu sua taxa de conversão cair para 2%. Ele então perde € 2 em margem por mês, apenas para taxa de conversão de -1%…
Vou deixar você planejar com antecedência e imaginar outros cenários. Mas, em resumo, colocando em perspectiva os custos do lado do servidor, geralmente é bastante reconfortante. O que pode custar caro é não fazer nada.
Como fazemos isso?
Então, a questão é bastante ampla. Como já gastei muito do seu precioso tempo (e especialistas muito mais conhecedores do assunto que eu já oferecem excelentes recursos), tentarei resumir minha maneira de ver as coisas de forma concisa e simplificada:
-
Método 1: “velha escola”
O cliente abre uma instância de servidor para nós na nuvem (geralmente no Google Cloud Platform porque é oferecido diretamente pelo Google Tag Manager), colocamos tudo no lugar para transportar os dados do lado do cliente para o lado do servidor… Fazemos nos testes, vemos as tags do lado do servidor saindo… está tudo bem. Estamos fazendo do lado do servidor!
Mas... sem perceber imediatamente, temos tags 'ponte' do lado do cliente bloqueadas por bloqueadores de anúncios... temos gerenciadores de tags de contêiner do lado do cliente bloqueados por bloqueadores de anúncios... podemos ter um problema na instância do Google Cloud para um problema de cobrança que o cliente não administrou… podemos ter problemas com dados mal coletados… etc.
Deparamo-nos rapidamente com um forte risco associado à falta de monitorização e a um efeito de «caixa negra». Resumindo, estamos chegando lá, mas ei, é cheio de pequenos incômodos, muitas vezes bastante sorrateiros e impactantes para o desempenho da sua operação “do lado do servidor”.
-
Método 2: Conte com uma solução/parceiro especializado
E então, um belo dia, descobrimos num fórum de dados/marketing, ou num artigo de blog, que uma empresa francesa oferece uma plataforma e serviços que respondem a estas questões.
Não estamos mais sozinhos, verdadeiros especialistas estão lá para apoiá-lo. As ferramentas simplificam muito a implementação. A plataforma evolui regularmente.
Resumindo, a coisa toda supera em muito o método da “velha escola”.
Este parceiro tecnológico é a Addingwell. E não, não tenho nenhuma ação com eles (que pena). Realmente existe uma lacuna (que, aliás, não é ilógica). Rapidamente percebemos que conhecem muito bem o assunto e que tudo o que colocam em prática responde diretamente a questões concretas. Ganhamos enormemente em tempo de instalação, possibilidades e confiabilidade.
Conclusão
Devo ir para lá ou não?
- Vá em frente! Dados os problemas de dados e desempenho que já existem e os que estão por vir, você precisa se posicionar nessa tecnologia (exceto se você não fizer nenhuma aquisição/publicidade de tráfego).
Devo ir agora ou mais tarde?
- Você vê, mas não espere muito: quando chegarem as próximas alterações no Chrome relacionadas a cookies de terceiros (2025?), há o risco de um engarrafamento de solicitações de implementação do lado do servidor.
E como faço isso?
- Você liga para UX-Republic (aleatoriamente).
- Estudaremos a necessidade e possivelmente sugeriremos que nosso parceiro Addingwell se junte a nós para elaborar um projeto adequado para você.
Em qualquer caso, não recomendamos ir até lá sem estar acompanhado. A complexidade de configurar a marcação no lado do servidor está um passo acima da implementação no lado do cliente (que já pode ser bastante complicada).
Laurent Neuville, Consultor Sênior de Web Analytics na Smile