Este guia é para o provedor de arbitragem de busca System1. Veja a documentação deles aqui.
O rastreamento de arbitragem de busca em geral pode ser bastante complicado, dada a presença de palavras-chave e vários parâmetros de dados necessários.
O System1 tem uma das configurações de passagem de dados mais complexas. Em vez de passar IDs para eles, que eles disparam em postbacks, eles esperam que você passe strings de URL pré-computadas para chamar.
Então, em vez de passar algo como click_id=xxx, eles esperam que você passe algo como postback_to_fire=https%3A%2F%2Fmydomain.com%2Fpb%3Fhit%3Dxxx
Já está confuso? Certifique-se de seguir o guia abaixo e preste muita atenção na configuração de passagem de dados.
Criando a fonte de oferta System1
Primeiramente, crie uma nova fonte de oferta e use nosso modelo System1.
Observe a seção de passagem de dados:
Aqui há algumas coisas muito importantes a considerar:
- Estamos passando compkey e rskey usando um token
{data-xxx}. Isso significa que os valores virão da sua fonte de tráfego através do link que você usa lá - então é importante que sua fonte de tráfego tenha campos de rastreamento de URL correspondentes dead_titleekeyword, e que estes sempre passem valores apropriados para o System1 - Estamos passando uma URL de postback sob
click_track_url- isso será disparado pelo System1 mais tarde - Estamos passando outra URL, neste caso um link de ação, sob
search_track_url- esta é totalmente opcional e requer adicionar um lander fictício ao nosso funil. Isso permitirá que você simule CTR na página de arbitragem de busca, mas não é particularmente necessário, afinal, com arbitragem de busca você terá altas taxas de visualizações > conversões de qualquer maneira, então cliques intermediários não são tão importantes. É sua escolha adicionar isso ou não. Se você adicionar, veja a seção posterior sobre rastreamento de CTR inicial. - A string específica para o acima é
https://{tracking-domain}/action/1?vid={visitor}&rn={current-node-id}
Note que, como passamos URLs pré-computadas para o System1, não há nada a fazer na aba de rastreamento de conversão, e nenhum postback para configurar no lado do System1.
Configurando fontes de tráfego utilizadas
Como mencionado anteriormente, precisamos passar dados personalizados (título do anúncio e palavra-chave) da fonte de tráfego, e são esses valores que são passados para o System1.
Verifique a imagem anterior - usamos o token {data-ad_title} e {data-keyword}.
Então, eu recomendaria criar uma nova fonte de tráfego dedicada à arbitragem de busca via System1, por exemplo, TikTok (System1). Você pode usar o modelo apropriado e, em seguida, adicionar ou ajustar os parâmetros. Tomando nosso modelo TikTok como exemplo:
Aqui eu adicionei ad_title e defini como REPLACE, e adicionei o campo de rastreamento keyword com REPLACE como valor também.
Como o TikTok não tem títulos/palavras-chave de anúncios, você precisaria substituir manualmente isso em sua URL, por anúncio, para passar um parâmetro de título apropriado.
Tomando outro exemplo do Taboola:
Aqui, o Taboola tem passagem de dados para títulos, então podemos usar isso como está. No entanto, não há palavras-chave novamente, então devemos adicionar um novo campo keyword e definir seu valor como REPLACE.
O objetivo aqui é gerar URLs de anúncios e alterar os dados de REPLACE --> para outra coisa nessas URLs. No entanto, você também pode substituí-lo no nível da oferta posteriormente, como abaixo.
Passando dados de palavras-chave para ofertas
Para ofertas do System1, você criaria uma oferta e usaria seu domínio de arbitragem como a URL base da página. O resto da estrutura da URL seria tratado pela seção de passagem de dados.
Para cada anúncio que você executar, você estará passando valores de título de anúncio e palavra-chave. Existem duas maneiras de variar esses valores de título de anúncio/palavra-chave.
Opção 1: Passar na URL da fonte de tráfego
Esta é a configuração que você está usando acima.
Com isso, sua oferta seria apenas uma única oferta (a URL do domínio de arbitragem de busca) e você criaria diferentes anúncios --> que podem passar diferentes valores --> gerar diferentes resultados de página de arbitragem de busca.
Nos relatórios, você detalharia por este campo de rastreamento de título de anúncio para analisar o desempenho.
Opção 2: Passando no nível da oferta
Agora, como tudo isso é passagem de dados configurada pela fonte da oferta/oferta, você poderia optar por codificá-la no nível da oferta.
Então você poderia criar sua oferta, escolher System1 como a fonte da oferta, depois ir para a passagem de dados e adicionar uma substituição no nível da oferta para os campos compkey ou rskey, usando a opção de string personalizada.
Desta forma, você poderia criar várias ofertas para diferentes palavras-chave e rotacioná-las em seus funis como qualquer oferta.
Agora, os valores não dependeriam de seus anúncios na fonte de tráfego e são controlados dentro do FunnelFlux:
Agora nos relatórios você poderia ter suas palavras-chave separadas em diferentes ofertas.
A vantagem aqui é mais controle dentro do FunnelFlux e poder mudar isso a qualquer momento ou adicionar/remover páginas da rotação sem tocar em seus anúncios.
A desvantagem é mais trabalho manual com a criação de ofertas e configuração do seu funil, e potencial falta de congruência entre seus anúncios e suas páginas de arbitragem de busca.
Você também precisará considerar a conformidade, e se para fontes com títulos de anúncios, o parceiro de arbitragem de busca está OK com você passando várias palavras-chave que podem não corresponder ao anúncio exibido aos usuários.
Rastreando o CTR inicial
Esta parte é opcional.
Se você quiser, pode tentar rastrear o CTR da página inicial de arbitragem de busca. Se você não quiser fazer isso, pode excluir o parâmetro search_track_url da sua fonte de oferta System1.
Então, em seu funil você pode ter o nó de tráfego --> nó de oferta (a oferta System1) --> lander fictício, assim:
O objetivo disso é apenas criar a ação, para que um clique possa realmente acontecer na página da oferta - caso contrário, não há como acionar um clique.
O lander fictício pode ser qualquer coisa, mas eu sugeriria criar uma nova página como "Página CTR Fictícia" e definir sua URL para algo como https://mylanderdomain.com/non-existent-page
A própria página não será carregada no navegador, mas não queremos potencialmente sobrecarregar algum site real como google.com ou test.com com muitas solicitações de URL aleatórias do lado do servidor, caso os servidores do System1 seguissem a cadeia de redirecionamento.
Agora, quando um usuário vai do seu anúncio > URL do FunnelFlux > página de oferta do System1, eles geralmente serão apresentados com vários botões para clicar. Ao clicar, ele disparará um evento de ação para o FunnelFlux, rastreando um clique. Se eles clicarem em algo na próxima página, então ele enviará uma conversão.
Isso lhe dará alguma ideia sobre o CTR da página inicial, o que poderia ser importante para entender ângulos/congruência.
Eu só recomendaria fazer isso se você realmente quiser os dados, pois são etapas/complicações extras que você pode evitar de outra forma.