O que é a Camada de Dados?

Neste artigo, considero que a camada de dados compreende as seguintes definições:

• A descrição dos requisitos e objetivos do negócio, alinhada em um formato facilmente transferível para especificações técnicas.
• O conceito de uma camada discreta de informação semântica, armazenada em um contexto digital.

Também usarei o nome de variável dataLayer para denotar a estrutura de dados usada pelo Google Tag Manager para armazenar, processar e passar dados entre o contexto digital e a sua ferramenta de gerenciamento de tags. Também prefiro o termo contexto digital a site, já que a Camada de Dados pode ser usada em vários contextos, não apenas na Web.

A camada de dados mais explorada neste artigo é aquela que está firmemente enraizada na DMZ entre desenvolvedores e profissionais de marketing. É um conceito muito técnico, pois sua existência é justificada pelas limitações impostas por certas tecnologias web (JavaScript, por exemplo) sobre como os navegadores interagem com aplicativos (Google Tag Manager, por exemplo). Ao mesmo tempo, o Data Layer é, e deve ser, propriedade, pelo menos em parte, de profissionais de marketing, analistas, executivos, designers e profissionais de comunicação, que elaboram os requisitos e objetivos de negócios que são atendidos pelos métodos de coleta de dados.

Em outras palavras, é muito comum que a governança do Data Layer seja debatida acaloradamente entre diferentes stakeholders da “organização de dados” dentro de uma empresa. Uma vez que, como veremos, é um modelo de dados genérico que pode ser usado por todos os aplicativos que fazem interface com seus dados digitais, é muito difícil esboçar um modelo de governança que satisfaça todas as partes.

No final, compartilharei alguns ótimos recursos para aprender mais sobre o Data Layer.

O que é a Camada de Dados?

Para resumir, uma camada de dados é uma estrutura de dados que idealmente contém todos os dados que você deseja processar e passar de seu site (ou outro contexto digital) para outros aplicativos aos quais você se vinculou.

A razão pela qual usamos uma camada de dados é porque às vezes é necessário desacoplar informações semânticas de outras informações armazenadas no contexto digital. Isso, por sua vez, porque se utilizarmos informações já disponíveis, corremos o risco de que, uma vez feitas modificações na fonte original, a integridade dos dados seja comprometida.

Um exemplo muito comum é o rastreamento de um website. Você pode ter uma camada de dados que alimenta sua ferramenta de análise de dados sobre o visitante. Freqüentemente, esses dados não estão disponíveis na camada de apresentação ou na marcação. Esses dados podem ser, por exemplo, detalhes sobre o visitante (status de login, ID do usuário, geolocalização), metadados sobre a página (resolução ideal, direitos autorais da imagem) ou até mesmo informações que já estão na marcação, mas que você deseja acessar em uma forma mais robusta.

Se, por exemplo, você estivesse disposto a usar dados de um cabeçalho H2 da marcação HTML na página de agradecimento, uma única alteração na marcação ou no formato das informações neste elemento HTML comprometeria a coleta de dados do site para sua ferramenta de rastreamento. Se, no entanto, os dados foram armazenados em uma camada de dados sem vínculo com a camada de apresentação, há um risco muito menor de ocorrência de alterações inesperadas (embora isso definitivamente não seja impossível).

Resumindo, a camada de dados (Data Layer) é uma estrutura de dados para armazenar, processar e transmitir informações sobre o contexto em que existe.

A camada de dados para leigos

Para o profissional de marketing, o analista, o executivo, o diretor de comunicações ou outro não-desenvolvedor, a camada de dados é, na verdade, uma lista de requisitos e metas de negócios para cada subconjunto do contexto digital do negócio.

Para uma loja virtual, por exemplo, os requisitos e objetivos de negócios podem incluir informações transacionais (o que foi comprado), dados do usuário (quem fez a compra), detalhes espaciais e temporais (onde foi feita a compra e em que momento) e informações sobre possíveis micro-conversões (o usuário assinou a newsletter).

Para outra parte do mesmo site, os requisitos e objetivos de negócios podem incluir simplesmente detalhes sobre qual canal de mídia social trouxe o usuário ao site ou quais páginas o usuário visualizou mais de uma vez.

Estas não são especificações técnicas, mas sim listas claramente definidas de itens que precisam ser coletados para satisfazer os objetivos de negócio definidos para cada área de negócio do site.

Idealmente, a camada de dados carrega informações que podem ser usadas por tantas ferramentas/usuários/partes interessadas diferentes quanto possível, mas é muito comum que surjam idiossincrasias. É por isso que é extremamente importante tratar a camada de dados como um modelo vivo e ágil, e não como uma entidade estagnada, monolítica e singular.

Da mesma forma que qualquer aspecto da análise digital, uma camada de dados também deve ser tratada como algo que está em constante mudança. Os dados que ele contém devem ser otimizados, elaborados, divididos, reunidos, limpos, refatorados e questionados sempre que surgirem novos requisitos de negócios ou quando as metas anteriores não forem benéficas para os negócios.

A Camada de Dados no Google Tag Manager

Como não existe um padrão para o modelo de dados explorado neste artigo (mas você pode seguir essa documentação), a camada de dados pode ter muitas formas técnicas. A perspectiva técnica que escolhi é aquela que evoluiu através do Google Tag Manager. Isso ocorre porque penso, e sou apenas um pouco tendencioso aqui, que dataLayer é uma das implementações mais elegantes de um modelo de dados estruturados na web.

dataLayer é um array JavaScript, que contém dados em pares de valores-chave. A chave é um nome de variável no formato String e os valores podem ser qualquer tipo de JavaScript permitido. Este é um exemplo de dataLayer com diferentes tipos de dados:

dataLayer = [{ 
    'products': [{ 
            'name': 'Kala Ukulele',
            'tuning': 'High-G',
            'price': 449.75
        },{
            'name': 'Fender Stratocaster',
            'tuning': 'Drop-C',
            'price': 1699
    }],
    'stores': ['Los Angeles', 'New York'],
    'date': Sat Sep 13 2014 17:05:32 GMT+0200 (CEST),
    'employee': {'name': 'Reggie'}
}];

Aqui temos valores como um Array de objetos (products), valores numéricos (price), um Array de Strings (stores), um objeto de data (date) e um objeto aninhado (employee.name , o nome do funcionário).

A questão aqui é que o dataLayer é genérico e independente de ferramentas. Contanto que se comporte como um array JavaScript padrão, não ficará restrito a apenas uma ferramenta. As informações no objeto dataLayer acima podem ser usadas por qualquer aplicativo que tenha acesso ao namespace global desta página.

A forma como os dados dentro deste Array são processados é, portanto, deixada para a ferramenta. No Google Tag Manager, por exemplo, um objeto é usado para processar dados no dataLayer, que é então armazenado em um modelo de dados abstrato e interno dentro da própria ferramenta. Isso garante que o dataLayer possa permanecer genérico e independente de ferramentas, mas os dados contidos nele serão processados para cumprir os recursos do Google Tag Manager.

O objeto usado pelo Google Tag Manager e possui vários recursos interessantes, como:

• Um listener que escuta pushes para dataLayer. Se ocorrer um push, as variáveis no push serão avaliadas.
• Obtenha e defina métodos que processam/manipulem o dataLayer como uma fila (primeiro a entrar, primeiro a sair) e garanta que os valores especiais (objetos, arrays) dentro do modelo de dados possam ser atualizados e anexados corretamente.
• A capacidade de acessar comandos e métodos de objetos armazenados em dataLayer e a possibilidade de executar funções personalizadas no contexto do modelo de dados.

Tudo isso é transparente para os usuários do Google Tag Manager, é claro, mas explica por que, por exemplo, a macro de variável da camada de dados pode acessar nomes de variáveis pontilhadas (gtm.element) e propriedades (gtm.element.id) igualmente, e também por que você pode enviar vários valores com a mesma chave para o dataLayer, mas apenas o valor enviado mais recentemente estará disponível para tags que são acionadas após o envio.

Como o modelo de dados abstrato no Google Tag Manager respeita apenas o valor mais recente de qualquer nome de variável, a empresa deve decidir onde e quando uma camada de dados se torna um dataLayer na estrutura Array.

Dos negócios à implementação técnica

A abordagem mais comum, acredito, é que os requisitos e objetivos de negócio sejam traduzidos em um conjunto de pares chave-valor, que devem ser renderizados pelo código do lado do servidor, para que o dataLayer seja preenchido com todos os dados necessários antes do carregamento do GTM.

Naturalmente, você poderia fazer isso com código do lado do cliente, e ele não precisa ser pré-preenchido, mas os dados críticos para os negócios são mais bem protegidos se forem renderizados no dataLayer o mais cedo possível no carregamento da página, para que a perda de dados seja minimizada se o usuário decidir sair da página antes que o dataLayer seja renderizado.

Aqui está um exemplo. Temos uma página com os seguintes requisitos que queremos acompanhar como metas de negócio:

1. ID do usuário – porque queremos rastrear toda a jornada do usuário, não apenas sessão por sessão ou dispositivo por dispositivo.
2. Usuário interno - porque queremos filtrar o tráfego de nossos próprios funcionários dos dados.
3. Clima no momento da visita - porque queremos ver como o clima afeta o comportamento da visita.

Esta é uma lista simples, embora sem sentido, de requisitos de negócios que têm um impacto direto em como rastreamos as metas em um website. Esta lista precisa ser anexada com mais informações, como quais são os valores de exemplo para essas variáveis, qual é o seu escopo (hit, sessão, usuário, produto, por exemplo), caso elas persistam (permaneçam de página para página). Não farei isso agora, pois depende muito de como sua organização lida com projetos que abrangem diferentes departamentos.

De qualquer forma, um exemplo de dataLayer, renderizado antes do snippet do contêiner, pode ser assim:

<script>
    window.dataLayer = window.dataLayer || [];
    dataLayer.push({
        'userId' : 'abf5-3245-ffd1-23ed',
        'internalUser' : true,
        'clima' : 'Nublado'
    });
</script>
<!-- Código do GTM Aqui -->

Como você pode ver, os dados são renderizados antes do código do GTM, para que todas as tags disparadas assim que o GTM for carregado possam usar esses dados.

Saiba mais sobre como implementar o método dataLayer.push em seu website.

Observe que você também pode e usará o dataLayer dentro dos limites do GTM, já que suas tags ou outras bibliotecas na página podem enviar dados para a estrutura após essa sequência de pré-carregamento. Não creio que esses pushes dinâmicos ou trocas de dados precisem ser documentados com tanto cuidado, uma vez que ocorrem apenas no domínio da ferramenta que faz os pushes. Assim, a documentação e o controle de versão ficam por conta da sofisticação da própria ferramenta.

A razão pela qual você precisa pensar muito por trás do dataLayer pré-renderizado é porque cada nova parte interessada torna a questão da governança um pouco mais complexa.

Implementações Avançadas do DataLayer

Proteção Contra Poluição de Dados

Evitar a poluição do DataLayer é essencial para garantir a precisão dos dados enviados para ferramentas de análise, como o Google Analytics. Para isso, você pode implementar um token de proteção que valida os pushes antes que sejam processados. Aqui está um exemplo de código:

<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
    if (arguments[0] !== 'protectToken') return;

    function passArgumentsBack() {
        dataLayer.push(arguments);
    }
    passArgumentsBack.apply(this, Array.prototype.slice.call(arguments, 1));
}
gtag('protectToken', 'js', new Date());
gtag('protectToken', 'config', 'G-XXXXXX');
</script>

Este código assegura que apenas eventos autenticados por meio do protectToken serão processados, bloqueando pushes não autorizados de terceiros ou bots.

Uso de Proxy no DataLayer

Outro método avançado é utilizar proxies para interceptar e validar chamadas ao DataLayer. Este exemplo utiliza ES6 Proxies para proteger dados:

(function() {
    const originalPush = window.dataLayer.push;
    window.dataLayer.push = function() {
        const eventData = arguments[0];
        if (eventData && eventData.protectKey === 'expectedValue') {
            delete eventData.protectKey;
            return originalPush.apply(this, arguments);
        }
        console.warn('Push bloqueado: evento inválido');
        return false;
    };
})();

Com esta abordagem, você filtra eventos e protege seu DataLayer contra acessos não autorizados, garantindo integridade.

Otimização do DataLayer para SEO e Web Analytics

Configurações Personalizadas de Rastreamento

Configure eventos personalizados que atendam a objetivos específicos, como rastrear interações do usuário em carrosséis de produtos ou vídeos. Por exemplo:

dataLayer.push({
    'event': 'video_play',
    'video_name': 'demo_product',
    'video_duration': 120
});

Essa configuração permite analisar interações e otimizar conteúdo baseado no comportamento do usuário.

Estruturação Ideal de Eventos

Organize os eventos com nomenclaturas consistentes, como:

Eventos: event: 'add_to_cart'

Propriedades: product_id, category, price

Essa abordagem facilita integração com ferramentas de BI e SEO, além de melhorar a interpretação dos dados por equipes multidisciplinares.

Exemplos Práticos

Rastreamento de Comércio Eletrônico Avançado

Configure o DataLayer para capturar detalhes de transações e interações com produtos:

dataLayer.push({
    'event': 'purchase',
    'ecommerce': {
        'transaction_id': 'T12345',
        'affiliation': 'Online Store',
        'value': 59.99,
        'currency': 'USD',
        'items': [
            {
                'item_name': 'Camisa',
                'item_id': 'C123',
                'price': 29.99,
                'quantity': 1
            }
        ]
    }
});

Com isso, você consegue rastrear vendas e otimizar campanhas baseadas em conversões reais.

Implementação de Arrays no Google Tag Manager

Arrays no DataLayer são úteis para rastrear itens como produtos em um carrinho. Para acessá-los, utilize a notação de ponto no GTM:

// Exemplo no GTM para acessar o nome do primeiro produto
"ecommerce.purchase.products.0.item_name"

Governança da camada de dados

É difícil criar um bom modelo de governança. Criar uma estrutura de dados que esteja à mercê de diversas partes diferentes, todas com diferentes níveis de especialização (e interesse geral), é ainda mais difícil.

No entanto, um modelo de governança bem definido, estruturado e formalizado é provavelmente a única coisa que impedirá que sua empresa perca performance devido a erros na operação com uma camada de dados.

1. Introdução

• Objetivo do documento
• A quem se destina este documento
• Índice

2. Histórico de versões

• O que foi revisado
• Quando foi revisado
• Por quem foi revisado

3. Propriedade

• O que significa propriedade
• Quem é o responsável pelo processo
• Quais são os direitos e privilégios do proprietário

3.1 Partes Interessadas

• Quem tem responsabilidade pela Camada de Dados (ferramentas, plataformas, departamentos, agências, terceiros)
• Qual é o seu papel
• Quais são seus direitos e privilégios

3.2 Especificações Técnicas

• Quem possui acesso técnico a Camada de Dados (TI, na maioria das vezes, ou um profissional de marketing com conhecimentos em TI);
• Qual é o seu papel;
• Quais são seus direitos e privilégios;

3.3 Gestão

• Quem é o responsável pelos requisitos de negócios (chefe de marketing ou alguma função semelhante na organização do cliente);
• Qual é o seu papel;
• Quais são seus direitos e privilégios;

4. Distribuição de Processos

• Quais partes usam a camada de dados
• Quais são seus requisitos especiais
• Como evitar conflitos entre diferentes partes interessadas

5. Gestão de Riscos

• Quais são os riscos
• Qual é a gravidade deles
• Qual é a probabilidade deles
• Quem é o proprietário dos riscos (e quaisquer ações tomadas para mitigá-los).

6. Modelo de gerenciamento de camada de dados

• Como planejar atualizações;
• Como implementar atualizações;
• Quem implanta as atualizações;
• Quem testa as atualizações;
• Quem precisa ser notificado;
• Quem atualiza o documento;
• Como evitar conflitos.

7. Descrição Técnica da Camada de Dados

• Qual é a estrutura de dados subjacente;
• Como essa estrutura é traduzida no modelo de dados próprio de cada ferramenta;
• Existem nomes de variáveis reservados ou outras fontes potenciais de conflito.

8. Variáveis da Camada de Dados

• Requisitos de negócios traduzidos em variáveis da camada de dados
• Classificado por domínio comercial
• Valores de exemplo, escopo, parâmetros, tipos esperados
• De onde vêm os dados
• Como os dados são usados

Eu sei, parece horrível. E provavelmente inutilizável para muitos. Porém, ter um documento como este que também é constantemente atualizado não só proporciona alguma segurança contratual, mas também mantém todos atualizados sobre a estrutura e formato mais recente da Camada de Dados.

Este documento precisa ser consultado/atualizado quando você cria um novo trecho de código JavaScript que calcula a quantidade de imagens na página?

Provavelmente não.

Este documento precisa ser consultado/atualizado quando você está implementando um pixel de conversão que também utiliza o valor de transação?

Provavelmente.

Este documento precisa ser consultado/atualizado ao implantar um comércio eletrônico?

Com certeza.

Não precisa ser uma grande complicação. Basta ter sempre disponível uma descrição concreta da camada de dados e, no mínimo, concordar por escrito sobre como a camada de dados é atualizada e por quem. Dessa forma, você evitará muitos problemas no longo prazo, quando mudanças injustificadas estiverem prestes a acontecer.

Duvidas e Respostas

O que é um DataLayer?

O DataLayer é uma estrutura usada para armazenar e transmitir dados em aplicações web, especialmente para ferramentas de análise.

Por que o DataLayer é importante para SEO?

O DataLayer permite rastrear eventos e interações do usuário, fornecendo dados valiosos para otimizações de SEO e melhorando a precisão de relatórios.

Como proteger meu DataLayer contra dados inválidos?

Você pode implementar tokens de proteção ou usar proxies para validar eventos antes que sejam processados pelo DataLayer.

Quais são os benefícios de usar o DataLayer no Google Tag Manager?

O DataLayer facilita a organização e o envio de dados estruturados para o Google Tag Manager, permitindo uma configuração mais simples e eficiente de tags.

Conclusão

Acho que a Camada de Dados é um conceito muito difícil de entender. Isso não ocorre apenas porque para a maioria é uma questão técnica, mas porque a maioria não percebe que também se trata de uma lista de regras de negócios.

Traduzir as metas de negócios para uma camada de dados bem formatada, enxuta e 100% utilizada é realmente difícil. Sinceramente, acho que um dos maiores erros é seguir o modelo cascata, onde uma lista enorme de requisitos é anotada no início do projeto, depois traduzida em uma camada de dados que aparece em todas as páginas do site, e depois disso ponto a estrutura nunca mais é tocada.

Isso não funciona.

O modelo em cascata é falho devido a erros humanos. Simplesmente não podemos conceber ou prever a forma final de algo tão vasto como uma camada inteira de dados semânticos, que pode cobrir quase todos os aspectos do negócio. Tem que ser ágil. Tem que haver um entendimento mútuo de que a forma da camada se torna mais clara com o tempo.

Comece pequeno e aumente, se tiver tempo. Se você estiver com pressa, concentre-se apenas nos requisitos críticos para o negócio.

Faça o que fizer, certifique-se de que haja um processo em vigor que permita sugerir modificações na camada de dados rapidamente. Isso requer muita maleabilidade e transferência de conhecimento. É por isso que acho que a coisa mais importante em qualquer projeto é começar educando todas as partes sobre o que as outras partes estão fazendo no projeto. Torne os profissionais de marketing mais preocupados com o desenvolvimento e os desenvolvedores mais respeitosos com seus esforços de marketing.

Dessa forma, todos ganham e você terá uma bela Camada de Dados.