A API de conversões da Meta
A API de Conversões da Meta é uma "interface de programação" destinada a receber dados de eventos de conversão. Esses dados são recebidos através de aplicações com integrações nativas ou servidores configurados para esse propósito. A API foi criada como forma de estabelecer uma comunicação direta entre aplicações(como CRM, ecommerce, sites) e a plataforma Meta Ads.
A API ganhou relevância após a implementação do update do iOS14, que trouxe restrições para o envio de dados de eventos através do próprio Browser, em dispositivos iPhone. Utilizando a API para enviar os mesmos eventos simultaneamente, é possível criar uma redundância e mitigar a perda de dados nesse cenário.
Esse não é único use-case onde a API pode trazer benefícios para a coleta de dados e mensuração da jornada de compra. Também é possível usar a API para relatar eventos ocorridos em conversas por mensagem(WhatsApp, Messenger), em contextos offline, em aplicativos, entre outros. Contudo, esse artigo foca na dinâmica do rastreio de conversões para eventos ocorridos no site.
Como funciona a API de Conversões
A API funciona como o ponto central para recebimento de qualquer evento, de qualquer lugar onde ele possa ter ocorrido. Isso significa que o evento pode ter ocorrido em um site próprio, um gateway de pagamentos, um aplicativo de terceiros e etc...
A principal diferença, em relação ao Pixel da Meta, é que o uso da API promove centralização no disparo de eventos. Enquanto o Pixel efetua disparos através do Navegador de cada cliente, um implementação para API vai centralizar essa comunicação em alguns serviços, ou em um único servidor.
Não é incomum uma única estrutura digital trabalhar com diversos provedores de serviços distintos como Hotmart, Typeform, Wordpress, entre outros. Cada um desses serviços foi construído de forma diferente, com tecnologias e linguagens distintas, mas se comunicam com a Meta de uma forma padronizada, através da API. O mecanismo que cada plataforma desenvolve para se comunicar com a API, iremos chamar de "Integração".
Integrações
A forma como cada um desses serviços constrói essa Integração, no entanto, pode diferir. Por exemplo, a Hotmart optou por fornecer apenas um subconjunto de dados de usuário, associados aos eventos ocorridos no Checkout. Sendo um gateway de pagamento, essa pode ser uma regra de negócio que faz sentido. Em outros serviços, como o Wordpress, é possível ter maior controle sobre como e quais dados serão enviados.
Quaisquer que sejam os serviços e plataformas que componham a Jornada de compra, é sempre mais interessante procurar obter maior nível de controle e autonomia sobre os eventos disparados. Isso vem com dois claros trade-offs: Complexidade e Custo. Ainda que limitadas, as integrações "prontas" de terceiros são simples de configurar e muitas vezes não geram custos adicionais.
Contudo, estabelecer um maior controle sobre os dados dos eventos disparados à API, permite:
1. Maior cobertura no rastreio de conversões;
2. Maior atribuição de eventos a cliques;
O quanto esses trade-offs podem ser compensados por estes benefícios, vai depender do volume de dados que a operação gera, e da capacidade técnica do time.
Tag Manager Server-Side
Como forma de mitigar a complexidade, manutenção, gestão e treinamento da equipe acerca das Integrações, recomendo o uso do Google Tag Manager Server-Side. O uso de um container do servidor para centralizar a lógica do disparo de eventos, tanto via Browser quanto via servidor, traz alguns benefícios:
1. Permite que múltiplas equipes trabalhem em um mesmo projeto, com um ambiente e interface em comum;
2. Simplifica a documentação da lógica, facilitando o treinamento da equipe e manutenção da estrutura de Analytics;
3. Preserva a flexibilidade necessária para operações em qualquer nível de complexidade;
Com essa flexibilidade, ainda é possível fazer escolhas acerca da infraestrutura que proverá o Tag Manager. Ou seja, rodar através de serviços de computação em nuvem do Google, através de implementações de terceiros(como Stape.io) ou optar por gerenciar uma instância em servidor próprio(self-hosted). A escolha dessas opções gera mais desdobramentos referentes à custos e complexidade(que fogem ao escopo desse artigo).
Como usar a API de Conversões
Estabelecemos, anteriormente, que a comunicação com a API pode originar de múltiplas fontes, e que a melhor forma de gerenciar esse ecosistema é através do Tag Manager. Independente dos detalhes de implementação da infraestrutura, existem boa práticas e indicadores que devem ser observados. Indicadores de atualidade, qualidade e eficácia dos dados de eventos na correspondência e atribuição.
A seguir, vamos entender como diversos desses conceitos funcionam na API de Conversões.
Desduplicação
A recomendação da Meta é o uso simultâneo da API com os eventos disparados via Navegador(Pixel). Isso gera um duplicidade para os eventos recebidos de ambas as fontes. Em função disso, uma das boas práticas mais essenciais, no uso da API, é a inclusão de um Identificador de Evento.
Esse identificador pode ser um número ou código, e precisa ser enviado junto ao evento disparado tanto por API quanto Pixel(Navegador). Esse identificador deve ser idêntico em ambos os disparos, permitindo que a Meta entenda que se trata de um único evento, disparado duas vezes.
Utilizando o Tag Manager, é necessário configurar uma variável para este propósito, a partir de um "modelo da comunidade". Configurando essa variável no container WEB, basta transmitir esse identificador ao container SERVER. Incluindo esse identificador nos eventos disparados por ambos os containers, a desduplicação será feita pela Meta automaticamente.
Qualidade de eventos
Nem sempre um evento enviado para a API de conversões poderá ser correspondido a um usuário e atribuído a um clique na Meta. Isso pode acontecer por diversos fatores, dentre eles, a baixa qualidade e quantidade dos dados associados ao evento. Em termos de correspondência avançada, os dados de usuário precisam "corresponder" ao dados registrados na Meta. Se os dados enviados estiverem incorretamente formatados, ou forem diferentes dos dados que usuário forneceu à Meta, a correspondência não ocorrerá.
Prioridade
Nem todos os tipos de dados que podem ser enviados junto a um evento, possuem a mesma relevância e eficácia na correspondência. Enviar apenas dados de endereço, por exemplo, não trará benefício para a correspondência, visto que podem haver outras centenas ou milhares de pessoas com os dados informados. Portanto, quanto mais únicos forem os tipos de dados, melhores as chances de uma correspondência de sucesso.
A Meta estabelece níveis de prioridade para os dados de usuários associados aos eventos. Onde são de mais alta prioridade, aqueles que tem maior capacidade de identificar usuários. Email, número de telefone e endereço IP, são os dados de maior prioridade. A seguir é possível conferir a tabela completa.
Qualidade
A partir dos dados informados junto ao evento, a Meta define indicadores de qualidade para cada um dos tipos de eventos recebidos. Esses indicadores são apresentados na forma de uma Pontuação de 0 a 10 e uma Classificação, que varia entre: Ruim, OK, Boa ou Ótima.
Pontuação
O indicador numérico é calculado a partir da qualidade dos dados enviados e da porcentagem de eventos que de fato corresponderam a uma conta Meta. Ou seja, para obter uma pontuação elevada, não basta apenas que os dados sejam enviados. Também o necessário que esses dados sejam efetivos em corresponder aos dados de usuário registrados pela Meta.
Classificação
A partir dessa pontuação, a Meta com define uma classificação de qualidade para o tipo de evento. Essa classificação é determinada em relação a pontuação de outros anunciantes na mesma região. Ou seja, se grande parte dos anunciantes na região não fazem um trabalho de correspondência, a classificação será mais alta, automaticamente.
Detalhes da cobertura
No painel de qualidade de eventos, também é possível acompanhar o detalhamento da cobertura para cada um dos tipos de dados recebidos. Esse detalhamento é o percentual de eventos que estão sendo recebidos com cada dado.
É importante ter em mente que, cada tipo de evento pode representar uma etapa ou ponto de contato durante a jornada de compra. Etapas mais inicias nessa jornada, podem preceder qualquer tipo de interação com formulários, inviabilizando a coleta de dados. Portanto, é natural que alguns tipos de eventos tenham cobertura e pontuações inferiores a eventos como compra.
Podemos tomar como exemplo uma primeira Visualização de Página, em uma loja virtual. Neste primeiro contato o visitante não interagiu com nenhum formulário, logo, dados como nome e mail não estão disponíveis para envio. Em uma interação seguinte, o usuário se cadastra na Newsletter, informado nome e email. A partir de agora, é possível enviar estes dois dados para correspondência, junto aos eventos. Em uma terceira interação, o usuário realiza uma compra, informando também seus dados de endereço para a entrega. Ou seja, somente após a compra temos todos os dados possíveis para a jornada desta loja. Como consequência, os eventos de Visualização de Página, Cadastro e Compra terão pontuações, classificações e cobertura diferentes.
Atualidade dos dados
O envio/recebimento de eventos através do Pixel(navegador) ocorre de forma imediata, visto que depende unicamente do funcionamento do navegador do usuário. Em contrapartida, o recebimento de eventos através da API de conversões pode variar, conforme a implementação da integração. O ideal, recomendado pela Meta, é que o que o evento seja enviado em tempo real.
É importante lembrar, contudo, que diferentes serviços e plataforma podem implementar suas integrações de formas diversas. A capacidade da integração de enviar eventos o mais rápido possível, afeta diretamente o nível de atualidade dos dados.
Esse nível de atualidade pode ser acompanhado através do gerenciador de eventos, e deve ser o mais próximo possível de "Tempo real". A implicação de um nível de atualidade mais longo, é a menor atribuição dos eventos aos cliques.
Conversões adicionais relatadas/reportadas
Como vimos no artigo [[Atribuição e correspondência no Meta Ads]], o disparo de eventos a partir do Pixel(navegador), pode não ocorrer. Configurando a API de conversões de modo a gerar uma redundância com os eventos via Pixel, é possível mitigar esses cenários. As conversões registradas a partir de eventos recebido pela API, e que não têm um evento idêntico recebido através do Pixel, são chamada de Conversões Adicionais.
Essa métrica serve para acompanhar o impacto que o uso da API de conversões está tendo na atribuição dos eventos ao cliques. Ou seja, contas que trabalham com públicos que utilizam mais dispositivos iPhone, podem esperar uma porcentagem maior.
Conclusão
Como vimos nos parágrafos anteriores, o uso da API de conversões pode envolver diferentes níveis de complexidade e custo. A escolha dos serviços e integrações escolhidas, também afeta a eficácia dos eventos enviados em gerar Conversões Adicionais. Outros fatores, como o comportamento público ou a etapa dos eventos configurados, adicionam ainda mais complexidade.
Portanto, é difícil estimar o impacto que a implementação dessa comunicação com a API pode gerar em termos de performance. Contudo, a tendência de mercado, refletida nas recomendações da própria Meta, é de reforçar cada vez mais o uso da API. Na forma de ampliar a cobertura na coleta de dados de comportamento do usuário, criando redundância no envio de eventos. Também na forma de buscar uma qualidade cada vez melhor para este eventos, associando dados em maior qualidade e quantidade.
Comments