Google Consent Mode no Squarespace: o que a plataforma entrega e o que ela não entrega

Todos os artigos

O banner nativo do Squarespace, configurado como opt-in e opt-out, bloqueia os cookies de análise próprios e os do Google até o visitante aceitar, mas não emite sinais do Consent Mode por conta própria. O Google documenta um bloco de injeção de código que nega ad_storage, ad_user_data e ad_personalization por padrão e depois lê a escolha do banner por meio de um auxiliar do Squarespace. Esse caminho exige um plano que inclua injeção de código.

O que o banner de cookies do Squarespace faz de fato?

Vale começar dando o devido crédito, porque o banner nativo não é um recurso de fachada. O Squarespace traz um em Website tools, e no estilo opt-in e opt-out ele segura os cookies de verdade. A própria página de configuração do Google diz que a opção de desativar os cookies de análise continua ligada, o que impede que os cookies não essenciais do Squarespace Analytics e do Google Analytics sejam gravados até o visitante aceitar. Isso é mais do que várias plataformas hospedadas oferecem sem um plugin.

O limite não é o bloqueio, é o que o banner diz ao Google. Segurar um cookie e declarar um estado de consentimento são trabalhos diferentes, e o banner nativo só faz o primeiro.

Quais sinais do Consent Mode o Squarespace deixa de fora?

O Consent Mode v2 acrescentou ad_user_data e ad_personalization aos já existentes ad_storage e analytics_storage. São esses dois que o Google Ads lê ao decidir se uma visita negada ainda pode contribuir para as conversões modeladas. A diferença está no que cada um dos dois controla, e o panorama mais amplo, no guia direto sobre o Consent Mode v2.

As instruções do Google para o Squarespace resolvem a lacuna com um passo de injeção de código, e o detalhe que vale acertar é que o bloco de padrões delas nega três sinais, não os quatro: ad_storage, ad_user_data e ad_personalization. O analytics_storage fica de fora, porque o banner nativo já está segurando os cookies de análise. É um passo fácil de pular, porque a página dá a entender que a configuração do banner é o principal e que a injeção é uma nota de rodapé para anunciantes. É o contrário. Sem ela, o site não está enviando um sinal negado, está enviando sinal nenhum, e um sinal ausente e um sinal negado são lidos de formas diferentes do outro lado.

O que a maioria dos resumos deixa passar é que o código injetado não substitui o banner. O Squarespace expõe um helper, window.getSquarespaceCookies, e o trecho do Google o chama para ler o que o visitante escolheu e, a partir disso, emite a atualização de consentimento. O banner continua sendo o lugar onde a escolha é feita; a injeção é a camada de tradução. É por isso que rodar um segundo banner por cima cria um conflito, não um backup.

Como configurar o Consent Mode no Squarespace?

1. Confira o plano antes de qualquer coisa

   A própria documentação do Squarespace coloca a injeção de código nos planos Core, Plus e Advanced e em alguns planos de cobrança legados. Todas as instruções disponíveis na web, incluindo as do Google, presumem que você consegue chegar ao Code Injection, que o Squarespace agora coloca em Website, depois Website tools, e que guias mais antigos colocam em Settings, depois Advanced. Abaixo desse nível o caminho não existe, o que torna isso uma questão de cobrança, não de configuração. Confira o nome do plano na área de cobrança em vez de se guiar por um guia antigo, porque os planos já mudaram de nome.

2. Coloque os padrões negados bem no topo da caixa do header

   O Consent Mode funciona declarando um estado negado antes de qualquer tag de medição carregar e atualizando esse estado quando o visitante escolhe, então o bloco de padrões vai no topo da caixa de injeção do header. O trecho do Google para o Squarespace nega ad_storage, ad_user_data e ad_personalization, deixando analytics_storage para o banner nativo. Erre a ordem e as tags carregam como concedidas justamente nos momentos que importam.

3. Instale a ferramenta de consentimento acima do tag manager, na mesma caixa

   A caixa de injeção do header é uma única área de texto simples, então a ordem em que você cola as coisas é a ordem de carregamento que o navegador vê. A plataforma de consentimento vai acima do trecho de código do tag manager. Se essa plataforma for o Velo, a nossa página de configuração para Squarespace mostra o trecho de código e onde ele fica.

4. Desligue o banner nativo se você usa uma plataforma de consentimento

   Dois banners significam dois registros do que o visitante escolheu, e eles vão discordar. Escolha um: se o site precisa do Consent Mode v2 para publicidade, a plataforma fica e o banner nativo é desligado em Website tools.

5. Verifique na página publicada, porque o código injetado só roda ali

   O Squarespace não tem visualização de staging para código injetado. Salvar é publicar, o que torna a verificação abaixo parte da instalação, e não um detalhe para depois. O Webflow divide o mesmo trabalho de outro jeito, com uma etapa real de publicação e uma segunda aba que carrega rastreamento fora do seu contêiner: adicionar um banner de cookies a um site Webflow explica o que muda.

O que o Squarespace não oferece?

Três lacunas custam tempo nas auditorias, e nenhuma delas aparece nas instruções oficiais.

Não há staging para código injetado. O Squarespace aplica essas mudanças ao salvar, sem estado de rascunho para a caixa, então a primeira vez que os seus padrões de consentimento rodam é a primeira vez que um visitante real carrega a página.

As áreas de membros não recebem, por padrão, o código personalizado do site inteiro. Essas páginas são servidas por outro caminho, então o código injetado não chega a elas, a menos que o escopo as inclua. O site então parece corretamente travado em todo lugar que você confere, sem nenhuma camada de consentimento justamente onde os visitantes estão logados.

A versão do site muda a resposta. Sites mais antigos na versão 7.0 lidam com a injeção de código de um jeito diferente o bastante para que instruções escritas para uma versão possam falhar em silêncio na outra, então descubra primeiro em qual você está. A versão também decide a questão da navegação: em sites 7.0 com o carregamento Ajax ativado, e em certos templates, mudar de página não recarrega o documento, o que suprime os novos disparos de visualização de página que um tag manager espera. Isso não vale para todos, então confira em vez de presumir. Onde se aplica, um gatilho de History Change captura as transições.

Qual é o erro de consentimento mais comum no Squarespace?

O Squarespace oferece injeção de código por página e também para o site inteiro, e a caixa por página é a que as pessoas encontram primeiro enquanto trabalham na página que precisa de correção. Uma plataforma de consentimento instalada ali carrega naquela página e em nenhuma outra, e se apresenta como funcionando, porque funciona, na única página em que existe. Os dois vão na caixa do site inteiro, em Website tools. É um dos erros mais comuns que encontramos em auditorias de Squarespace, e é invisível a menos que você confira uma segunda página.

Como conferir se isso se sustenta?

Como não há preview, a verificação acontece na página no ar, e acontece duas vezes. Carregue o site em um perfil limpo, recuse tudo e confira se as tags travadas estão ausentes da página e das entradas de resource timing do navegador. Repita com o consentimento concedido e confirme que elas aparecem. Uma configuração que bloqueia nas duas direções é uma tag quebrada, não uma tag em conformidade. O lado do tag manager está em como instalar um banner de cookies pelo Google Tag Manager.

O Shopify divide o mesmo trabalho de outro jeito: ele roda um segundo sistema de consentimento próprio junto com o Consent Mode, o que está explicado em como configurar o Google Consent Mode v2 no Shopify.

O Squarespace oferece um banner honesto e um lugar para colocar código. O que ele não oferece é a camada de sinalização por cima, que é a parte que o Velo foi feito para carregar.