O FunnelFlux Pro possui uma série de recursos que são precursores necessários para a construção de um funil e execução de uma campanha completa.
Eles são:
- Fontes de tráfego
- Fontes de ofertas
- Ofertas
- Páginas de destino
- Um domínio personalizado (não é exatamente um recurso, mas necessário)
Abaixo está uma descrição da configuração desses itens e como eles impactam os processos de rastreamento.
Fontes de Tráfego
Uma fonte de tráfego define a origem dos visitantes e deve ser selecionada ao gerar URLs de campanha.
A configuração da fonte de tráfego tem dois componentes principais:
- Os campos de rastreamento de URL
- Rastreamento de conversão
Configuração do campo de rastreamento de URL
Veja a imagem abaixo:
O FunnelFlux permite 20 campos de rastreamento personalizados, cada um deve ter um nome (um alias) e um valor de espaço reservado opcional. Os números no lado esquerdo representam números de colunas no banco de dados. Assim, essa configuração está criando aliases para mapear nome -> ID da coluna.
A configuração do campo de rastreamento é usada ao gerar links de redirecionamento/diretos -- esses campos determinam os dados específicos da fonte de tráfego da string de consulta anexados à URL.
Temos dois campos reservados que não podem ser removidos, mas podem receber aliases -- campanha e externo.
Estes são reservados para valores de ID de campanha (ou nome de campanha) e IDs de rastreamento de cliques, respectivamente.
Os espaços reservados devem ser todos os tokens/macros que a fonte de tráfego irá analisar (já que estes estão em URLs que se espera que sejam usadas na fonte de tráfego), e o token FunnelFlux é o formato de token utilizável em URLs de páginas de destino/ofertas para passar dados da fonte de tráfego adiante.
Notas úteis
- As fontes de tráfego não precisam ser plataformas de anúncios -- você pode criar uma fonte de tráfego para e-mails, usando tags de mesclagem de e-mail como tokens. Você também pode criar fontes de tráfego para afiliados específicos, com campos criados manualmente e permitir que o usuário passe dados estáticos. Ao fazer isso, é uma boa prática colocar o espaço reservado como REPLACE, para reduzir o erro humano ao usar links.
- Se um campo de rastreamento tiver seu espaço reservado deixado em branco, omitiremos isso da URL gerada, mas o campo ainda será capturado se os dados da URL existirem.
- Em alguns casos, pode fazer sentido desbloquear nossos campos reservados e renomeá-los, onde um ID de campanha ou clique é automaticamente anexado às URLs -- como com o Facebook anexando "FBCLID" automaticamente. Em nosso modelo, o campo externo é renomeado para FBCLID e recebe um espaço reservado em branco. Nosso sistema, portanto, NÃO adicionará FBCLID= às URLs geradas, mas capturará valores de parâmetros de string de consulta FBCLID recebidos e os armazenará como IDs de clique externos.
- Os usuários podem renomear campos a qualquer momento e isso pode levar ao registro de dados para uma coluna numerada mudando abruptamente em algum momento, então deve-se tomar cuidado para não alterar significativamente os dados que entram em cada número de coluna após a configuração. Em vez disso, seria melhor arquivar aquela linha numerada e criar um novo campo, ou usar uma nova fonte de tráfego.
- Campos de rastreamento arquivados ficam ocultos da visualização e dos menus suspensos de relatórios, mas ainda aparecem nos dados. Criar uma nova linha com o mesmo nome de um campo arquivado irá desarquivar esse campo em vez de criar um campo duplicado, pois o arquivado ainda capturará e armazenará dados se as URLs o utilizarem.
- Ao renomear campos, um valor previousName é armazenado para mapear dados de URL de link antigos para valores renomeados.
Configuração de Rastreamento de Conversão
Aqui, os usuários podem definir o método para passar dados de conversão de volta à fonte de tráfego.
URLs de postback são simples solicitações GET para a fonte, passando quaisquer dados necessários e nosso token {external} para o ID de clique disponível.
HTML permite pixels JS ou de imagem. Para que isso funcione, os usuários devem rastrear uma conversão com nosso rastreamento JavaScript, que aproveitará o código HTML na página se definido.
Cenários personalizados são integrações personalizadas que criamos para várias fontes de tráfego, que normalmente envolvem uma API.
Os usuários precisarão consultar nossa documentação de ajuda para detalhes de configuração. Estes devem ser aproveitados se disponíveis, pois darão um rastreamento muito mais confiável. Todos são baseados em servidor para servidor, então funcionam quando as conversões são passadas para o FunnelFlux com URLs de postback, mas também se as conversões forem acionadas com JS.
Fontes de Ofertas
Estas definem a fonte das ofertas, que geralmente são redes de afiliados. Embora um usuário possa muito bem criar fontes como "Meus Produtos" ou um nome de site.
Estas servem a três propósitos:
- Modelagem de passagem de dados, pois quando uma oferta usa esta fonte, ela herda a configuração de passagem de dados
- Modelagem de URLs de postback, para facilitar aos usuários copiar/colar URLs para redes
- Como uma categoria geral para relatórios
Nota: pretendemos atualizar nosso paradigma de passagem de dados em um futuro próximo. No momento, a configuração da fonte da oferta é herdada de maneira unidirecional no momento em que é selecionada na configuração da oferta. Se o usuário atualizar a fonte da oferta, nenhuma alteração é feita nas ofertas. No futuro, criaremos uma herança estrita onde as ofertas primeiro herdam a configuração de passagem de dados da fonte (e algumas outras configurações), então no nível da oferta, campos adicionais podem ser definidos, bem como substituições.
Passagem de dados
Aqui os usuários podem usar uma abordagem baseada em formulário para construir a string de consulta anexada à URL da página base nas configurações gerais.
Esta abordagem reduz o erro humano e nos permite modelar melhor a passagem de dados.
Como uma boa prática, a URL da página base deve conter todos os dados de URL estáticos que nunca mudarão. Para URLs de afiliados, isso geralmente significa incluir algum ID de afiliado/oferta.
Todos os dados dinâmicos devem ser configurados através da seção de passagem de dados, idealmente.
Notas Úteis
- Alguns nomes de campos são restritos como vid, n, c, ts, etc. que são usados para parâmetros reservados passados pelo FunnelFlux ou nosso Javascript
- Para passar dados de URL, você pode escolher essa opção e então inserir apenas o nome da chave da string de consulta. Ao salvar, o item será recolhido para
{data-url_key_name}-- pretendemos melhorar isso mais tarde. - Observe que os dados passados em links de rastreamento são acessados via este token, assim como os dados da string de consulta passados para nosso buffer de URL. Ou seja, qualquer dado de string de consulta de URL passado para um link de redirecionamento ou ação que NÃO seja um campo de rastreamento definido ainda será armazenado nos dados da sessão e pode ser acessado com
{data-url_key_name}. No entanto, não estará disponível nos relatórios. - Para passar dados compostos ou outros, selecione string personalizada. Aqui você pode usar tokens como de costume, então pode fazer, por exemplo,
{funnel-id}-{campaign}-{trafficsource-id}. Se estiver passando dados complexos como uma string de URL, não precisa ser codificado, pois nosso sistema codificará automaticamente a URL ao salvar.
Rastreamento de Conversão
Esta seção é bastante autoexplicativa.
Para modelar a URL de postback, insira os tokens de receita/ID de transação opcional que a plataforma da fonte da oferta irá analisar e substituir.
Para o ID de hit, verifique o campo para o qual você está passando nosso valor {hit} na passagem de dados. Se for "aff_sub5" por exemplo, então na página de rastreamento de conversão, você deve inserir o token correspondente da fonte da oferta que representaria o valor armazenado de aff_sub5, por exemplo {aff_sub5}
Notas Úteis
- Conversões passadas para o FunnelFlux com valores idênticos de ID de hit e TxID atualmente substituirão a conversão existente, mas não causarão duplicação. No momento, isso atualiza o timestamp da conversão. Pretendemos substituir essa funcionalidade para NÃO atualizar o timestamp original, de modo que o novo evento, se for uma duplicata, seja efetivamente ignorado.
- Atualmente, o rastreamento de conversão não é desduplicado em relação ao disparo de eventos para a fonte de tráfego. Então, mesmo que o FunnelFlux deduplique a conversão internamente, um evento ainda é enviado para a fonte de tráfego. Também pretendemos atualizar esse comportamento para não enviar eventos duplicados.
- Assim, se os usuários quiserem disparar múltiplas conversões legítimas, eles devem sempre especificar valores únicos de ID de transação através do parâmetro "tx" em nossa URL de postback/JS.
Ofertas
As ofertas devem escolher uma fonte de oferta para primeiro herdar configurações importantes, economizando tempo e reduzindo o erro humano.
A oferta então tem uma URL base, que deve incluir todos os dados estáticos com todos os dados dinâmicos passados através da seção de passagem de dados.
Quando o FunnelFlux redireciona para uma oferta, ele redirecionará para a URL base + configuração de passagem de dados = URL final da oferta.
As categorias de oferta são puramente para agrupamento em relatórios e não têm impacto funcional.
Links de Ação de Página
Estes são os URLs de ação (CTA) a serem usados nas páginas. Eles são genéricos e têm o formato:
https://DOMAIN/action/number
No FunnelFlux, os URLs de clique (links de ação) nas páginas não especificam um destino. Eles fazem referência a uma "ação" a ser executada. No momento do clique, o FunnelFlux processará a configuração do funil para o usuário atual e, com base em sua posição de nó atual conhecida, executará a ação X desse nó.
Dessa forma, o FunnelFlux não prevê qual será o próximo destino para um usuário, e assim não é possível criar um link em uma página que crie um clique/ação, mas também force o redirecionamento para um determinado nó.
Pode-se, é claro, usar um nó de condição e rotear com base em alguns dados de URL passados para a URL de ação, mas esta é uma funcionalidade separada -- a ação da página de destino ainda estaria naturalmente indo para o próximo nó esperado (uma condição neste caso).
Observe que os links de ação são genéricos e não precisam ser específicos para a página, funil ou fonte. Dentro do construtor de funil, essas ações também podem ser recuperadas com parâmetros padrão adicionados. Isso será discutido no documento técnico do funil.
IDs de produto de integração
Esta é uma seção em beta - é especificamente para integrações de webhook que planejamos construir, onde eles passarão IDs de produto e um ID de visitante. Se uma oferta tiver IDs de produto definidos, poderemos fazer referência cruzada para determinar que o ID de produto X deve ser a oferta Y --> essa é a oferta que converteu. Atualmente de uso limitado.
Páginas de Destino
Assim como as ofertas, uma página de destino é apenas uma página.
As principais diferenças, além do ícone/nome, é que uma página de destino não tem "fonte" da qual herda configuração
As páginas de destino devem ser usadas para qualquer página que não vá gerar receita diretamente de uma ação do usuário nessa página, ou derivada dela.
Por exemplo, uma página de checkout provavelmente seria uma página de oferta -- mas a página de venda de produto anterior seria uma página de destino, já que a página de checkout é o local onde o usuário finalmente converte.
Qualquer página que seja um término, onde um visitante é redirecionado para algum terceiro, por exemplo, uma rede de afiliados, certamente será uma oferta, não uma página de destino.
Observe que, embora as páginas de destino não convertam, nos relatórios elas ainda herdam receita e conversões criadas pelos usuários mais tarde em sua jornada.