Defina regras de conversão

Conversion Rules é um recurso avançado do pilar de Proteção . Ele permite validar as instalações e os engajamentos do usuário aplicando regras personalizadas definidas por você.

Níveis das regras de conversão

As regras de conversão estão disponíveis em diferentes níveis, cada uma oferecendo um nível diferente de validação e profundidade de relatórios para atender suas necessidades.

Antes de começar

O que você precisa saber antes de começar.

Requisitos

• Usuários com permissões de Administrador, Editor ou Editor personalizado na Adjust.
• Um aplicativo multiplataforma ou de plataforma única na Adjust.

Defina uma regra de conversão

Para definir uma regra de conversão, siga os passos abaixo:

1. Em Proteção, selecione Conversion Rules.

2. Selecione Nova regra de conversão.

3. Insira um nome para sua regra.

4. Escolha entre um dos seguintes status:

   • Ativo - A regra é aplicada às atribuições imediatamente quando as condições forem cumpridas.
   • Teste - Use esse status para testar sua regra de conversão. Para regras de conversão com status de Teste, nós não alteramos a fonte de atribuição.
   • Pausado - Sua regra não é aplicada a nenhuma atribuição.

5. Selecione o tipo de regra para definir que condições e definições estarão disponíveis:

   • Loja
   • Região
   • Versão
   • Parâmetro
   • Correspondência entre região e campanhas
   • Correspondência entre versão e campanhas

6. Para regras de Loja, Região, Versão e Parâmetro, escolha o comportamento do fallback de atribuição — dispositivos não verificados ou não confiáveis — e, se disponível para o seu tipo de regra, se a validação da regra deve ser entendida para atividades pós-instalação. As regras de correspondência entre região e campanhas ou de correspondência entre versões e campanhas usam, por sua vez, Pular atribuição, então esse passo não se aplica a elas.

7. Em Aplicar regra a , selecione o seu aplicativo e, dependendo do tipo da regra, os canais, filtros-alvo ou o segmento da campanha (canal, campanha, grupo de anúncios) do escopo da regra.

8. Em Definição da regra , configure suas condições ( Se isso acontecer ) e escolha Aceitar ou recusar ( Realizar ) para determinar qual lado da condição ganha o fallback.

9. Selecione Criar regra.

Uma vez que a regra estiver ativa , a Adjust compara os dados de atribuição com a regra de configuração. Isso pode mudar os resultados da sua atribuição. Você vai ver essas mudanças na exportação de dados brutos e no Datascape. Para quaisquer regras com status de teste , nós não alteramos a fonte de atribuição. Resultados rejeitados e não verificados são sinalizados e visíveis nos relatórios do Datascape e nos dados brutos (callbacks e exportações em CSV). Diferentemente do modo ao vivo, os resultados rejeitados não são compartilhados com os parceiros, mesmo que o compartilhamento com parceiros esteja configurado para rejeições. Para distinguir resultados de teste de resultados reais, adicione o placeholder {conversion_rule_status} (test / live) à sua configuração.

Comportamentos de atribuição

Aceitar e recusar

Cada condição de regra é avaliada como Se isso acontecer (a condição) -> Realizar (ação). A ação determina que lado da condição está sujeita ao comportamento da atribuição da regra:

• Aceitar — O que atender a essas condições continuarão no fluxo de atribuição. O que não atender está sujeito ao comportamento de atribuição selecionado.
• Recusar — O que atender a essas condições está sujeito ao comportamento de atribuição selecionado. O que não atender continua o fluxo de atribuição normal.

O que seria "sujeito ao comportamento de atribuição" dependendo do tipo da regra:

• Para regras de Loja, Região, Versão e Parâmetro, a instalação é atribuída a um Dispositivo não verificado ou Dispositivo não confiável, você define qual.
• Para regras de Correspondência entre região e campanhas ou de Correspondência entre versões e campanhas, a fonte é pulada para esta instalação. Não se trata de uma escolha separada, apenas do comportamento da regra.

Dispositivos não verificados

• Instalações de dispositivos não verificados serão não verificadas .

• A Adjust retém os postbacks e dados agregados.

  • Os dados brutos são compartilhados como uma atividade unverified_install para dispositivos não verificados.
  • As fontes recebem callbacks padrão install sem nenhuma mudança na atribuição de instalação .
  • O relatório da coorte está disponível até o nível da campanha .

• Os dispositivos não verificados não podem ser reatribuídos.

Dispositivos não confiáveis

• Isso representa o nível mais alto de severidade.

• As instalações de dispositivos não confiáveis serão rejeitadas .

  • Os postbacks de instalação serão enviados, mas a instalação será marcada como não atribuída .
  • As fontes podem receber callbacks rejected_install , que podem incluir campos como click_id e o motivo para a rejeição. Esses dados são fornecidos para fins de diagnóstico e de análise de fraude.
  • O relatório de coorte está limitado aos totais de alto nível . Não há detalhamento por canal, campanha ou outras dimensões granulares.

• Os dispositivos não confiáveis não podem ser reatribuídos.

Pular atribuição

O comportamento de atribuição para regras de Correspondência entre região e campanhas e de Correspondência entre versões e campanhas. Diferentemente de Dispositivo não verificado e Dispositivo não confiável, não se trata de uma escolha, e sim de um comportamento regular desse tipo de regra.

• A fonte vinculada ao lado pulado da condição (conferir Aceitar e recusar) não é considerada para essa instalação.
• A Adjust então busca o melhor engajamento elegível anterior. Caso encontre um, a atribuição vai para a fonte dele.
• Se nenhum engajamento elegível for encontrado, a instalação será atribuída como orgânica .

Estender regra para validação de atividades pós-instalação

Disponível para regras de Região, Versão e Parâmetro.

As atividades pós-instalação não são reatribuídas. Elas são sinalizadas como rejeitadas pela mesma fonte a que a instalação é atribuída.

Habilita a imposição da regra para todas as atividades pós-instalação (sessões, eventos e receita de anúncios) do app. Isso inclui atividades de usuários existentes e de instalações previamente atribuídas.

Quando essa opção estiver habilitada, a descrição Aceitar ou Recusar se estende para atividades pós-instalação.

• Aceitar + opção habilitada : as instalações que atenderem a essas condições continuarão no fluxo de atribuição. Aquelas que não o fizerem serão atribuídas ao comportamento de atribuir selecionado. As atividades pós-instalação que cumprirem essas condições serão rejeitadas.
• Recusar + opção habilitada : as instalações que cumprirem essas condições serão atribuídas ao comportamento de atribuição selecionado. Aquelas que não o fizerem continuarão no fluxo de atribuição. As atividades pós-instalação que cumprirem essas condições serão rejeitadas.

• Se a instalação foi atribuída a uma fonte válida (isso é, não classificada como um dispositivo não confiável ):
  • Os dados brutos serão compartilhados como atividades rejected_session, rejected_event ou rejected_ad_revenue.
  • As atividades rejeitadas são expostas em relatórios nos buckets Sessões rejeitadas , Eventos rejeitados ou Receitas de anúncios rejeitadas .

Aplicar regra a

Cada tipo de regra inclui uma seção Aplicar regra a , em que você define qual tráfego será afetado pela regra:

• Aplicativo — o aplicativo ao qual a regra se aplica. Isso não pode ser alterado após a criação da regra.
• Canais — limite a regra a canais específicos ou escolha Todos para aplicar a regra a todos os canais.
• Filtros-alvo (Apenas tipo de regra de Versão, opcional) — uma ou mais condições combinadas com E que limitam a qual tráfego as condições se aplicam.

Para as regras de Correspondência entre região e campanhas e de Correspondência entre versões e campanhas , aplique a regra para exibir, em vez disso, o aplicativo , o canal , a campanha e o grupo de anúncios , já que esses tipos de regra limitam a campanha a um segmento em vez de canais.

Tipos de regra

Loja

O regra de tipo de loja permite instalações de aplicativos da Google Play Store e da App Store da Apple.

Se quiser configurar a regra da loja, siga estes passos:

1. Escolha o comportamento do fallback da atribuição — dispositivo não verificado ou dispositivo não confiável.
2. Em Aplicar regra a , selecione seu aplicativo e, caso queira, limite a regra a canais específicos.
3. Em Definição da regra , escolha a(s) loja(s) permitida(s) em Se isso acontecer . Para aplicativos de plataforma única, apenas as lojas de plataformas correspondentes serão exibidas.
4. Selecione Criar regra.

Com essa regra, as instalações que não sejam das lojas permitidas serão atribuídas a Dispositivos não verificados ou a Dispositivos não confiáveis .

Região

O tipo de regra Região permite dispositivos e instalações de regiões específicas.

Se quiser configurar a regra da região, siga estes passos:

1. Escolha o comportamento do fallback da atribuição — dispositivo não verificado ou dispositivo não confiável. Essa regra também é compatível com Estender regra para validação de atividades pós-instalação.

2. Em Aplicar regra a , selecione seu aplicativo e, caso queira, limite a regra a canais específicos.

3. Em Definição da regra , escolha várias regiões definindo condições por País .

   1. Tipo de condição - Defina como Igual a ou Diferente de .
   2. Valor - Escolha um valor da lista.

4. Escolha Aceitar ou Recusar e Realizar .

5. Selecione Criar regra.

Exemplo: uma regra de Região com

• Tipo de condição: igual a
• Valor de país: Japão
• Realizar: Aceitar
• Estender regra para validação de atividades pós-instalação: habilitado

Interpretação: como um profissional de marketing, eu quero aceitar apenas as atividades vindas da região Japão.

Comportamento:
As instalações vindas de fora do Japão serão tratadas como Não verificado , e quaisquer atividades pós-instalação que não cumpram as condições serão rejeitadas.

Versão

A regra de Versão permite que você defina condições com base em campos específicos d versão, como:

• Versão do aplicativo
• Versão do SDK
• Versão da assinatura
• versão do SO

Você pode usar essa regra para restringir a atribuição a dispositivos com versões específicas. Dependendo se a regra estiver definida como Aceitar ou Recusar , as instalações que não cumprirem as condições (ou que cumprirem, para a opção Recusar) serão atribuídas ao fallback Não verificado ou Não confiável selecionado.

Se quiser configurar a regra de Versão, siga estes passos:

1. Escolha o comportamento do fallback da atribuição — dispositivo não verificado ou dispositivo não confiável. Essa regra também é compatível com Estender regra para validação de atividades pós-instalação.

2. Em Aplicar regra a , selecione o aplicativo. Você também pode limitar a regra a canais específicos ou ainda adicionar um ou mais filtros-alvo para limitar a qual tráfego as condições da regra se aplicam.

   Por exemplo, para aplicar essa regra apenas a dispositivos Android em um aplicativo multiplataforma, adicione o seguinte filtro-alvo:

   • Condição: Nome do sistema operacional
   • Tipo de condição: igual a
   • Valor: Android

3. Em Definição da regra , adicione uma ou mais condições baseadas em versões em Se isso acontecer . As condições dentro de um grupo são combinadas usando a lógica E . Use grupos separados para aplicar a lógica OU .

4. Escolha Aceitar ou Recusar e Realizar .

5. Selecione Criar regra.

Exemplo:
Como profissional de marketing, preciso definir uma regra que atenda aos requisitos da equipe de segurança para o meu aplicativo multiplataforma. O requisito é apenas permitir instalações (a regra não se aplica a atividades pós-instalação) no Android se:

• Versão do app é 2.2.1 ou mais recente e a versão do SO é 6.0.0 ou mais recente , ou
• Versão do app é 2.9.1 ou mais recente e a versão do SO é 7.1.2 ou mais recente

Comportamento de fallback da atribuição: Dispositivo não confiável
Realizar: Aceitar
Estender regra para validação de atividades pós-instalação: Desabilitada

Filtros-alvo: [Nome do SO] [igual a] [Android]

Definição da regra:

Grupo 1 [Versão do aplicativo] [Maior que ou igual a] [2.2.1] [Versão do SO] [Maior que ou igual a] [6.0.0]

Grupo 2 [Versão do aplicativo] [Maior que ou igual a] [2.9.1] [Versão do SO] [Maior que ou igual a] [7.1.2]

• Caso 1: o nome do SO instalado é iOS

  • Resultado: regra é pulada — não há correspondência com o filtro-alvo, então a regra não se aplica.

• Caso 2: o nome do SO instalado é Android; a versão do aplicativo é 2.3 e a versão do SO é 6.1.

  • Resultado: condição correspondida (Grupo 1). Aceita — sem rejeições.

• Caso 3: o nome do SO instalado é Android; a versão do aplicativo é 2.1 e versão do SO é 6.1

  • Resultado: a condição não teve correspondência com um grupo. Atribuição rejeitada conforme o comportamento do fallback.

Parâmetro

O tipo de regra Parâmetro confere se os parâmetros especificados do SDK (por exemplo, product_id) estão inclusos no payload e se, caso não estejam, eles cumprem a ação selecionada.

Se quiser configurar a regra de parâmetro, siga estes passos:

1. Escolha o comportamento do fallback da atribuição — dispositivo não verificado ou dispositivo não confiável. Essa regra também é compatível com Estender regra para validação de atividades pós-instalação.
2. Em Aplicar regra a , selecione seu aplicativo e, caso queira, limite a regra a canais específicos.
3. Em Definição da regra , forneça os nomes de parâmetros do SDK que devem ser conferidos em Realizar . Você pode incluir vários parâmetros — quando vários parâmetros são definidos, todos precisam estar presentes para que a atividade seja aprovada no monitoramento.
4. Escolha Aceitar ou Recusar e Realizar .
5. Selecione Criar regra.

Exemplo: Uma regra de Parâmetro com

• Nome do parâmetro: product_id
• Realizar: Aceitar

Interpretação: como profissional de marketing, quero aceitar apenas atividades que incluam o parâmetro product_id no payload.

Comportamento:
As instalações que não incluãm o parâmetro product_id obrigatório serão tratadas como Não confiáveis , e quaisquer atividades pós-instalação (sessões, eventos e receitas de anúncios) que não incluam o parâmetro product_id obrigatório serão rejeitadas.

Correspondência entre região e campanhas

O tipo de regra Região e campanhas são correspondentes permite dispositivos e instalações de regiões e campanhas específicas.

Se quiser configurar a regra Região e campanhas são correspondentes, siga estes passos:

1. Em Aplicar regra a , selecione o aplicativo , o canal , a campanha e o grupo de anúncios para escolher o segmento da campanha.

2. Em Definição da regra , escolha várias regiões definindo condições por País .

   1. Tipo de condição - Defina como Igual a ou Diferente de .
   2. Valor - Escolha um valor da lista.

3. Escolha Aceitar ou Recusar e Realizar .

4. Selecione Criar regra.

Exemplo: para uma regra de Região e campanhas são correspondentes com

• Valor do canal da campanha: Moloco
• Valor de país: EUA
• Realizar: Aceitar

Interpretação : para a campanha da Moloco, eu quero atribuir apenas as instalações vindas dos EUA.

Comportamento : se houver uma instalação de fora dos EUA, ela não será atribuída a nenhuma campanha da Moloco, mesmo que o último engajamento (que ganhou a atribuição) tenha vindo da Moloco. Confira Pular atribuição para ver como a Adjust lida com a busca de fallback.

Correspondência entre versão e campanhas

A regra Correspondência entre versão e campanhas permite a atribuição apenas para instalações que correspondam tanto a uma versão específica do aplicativo quanto a uma campanha específica.

Você pode usar essa regra para garantir que apenas instalações de versões específicas do aplicativo sejam atribuídas a redes designadas. Por exemplo:

• A Rede A só deve receber atribuições se a versão do aplicativo for 3.0.5.
• A rede B só deve receber atribuições se a versão do aplicativo for 3.0.6 ou 3.0.7.
• A rede WW só deve receber atribuições se a versão do aplicativo contiver o sufixo "_ww" (p. ex., 3.0.8_ww).

Para configurar uma regra de correspondência de versão e campanhas:

1. Em Aplicar regra a , selecione o aplicativo , o canal , a campanha e o grupo de anúncios para a correspondência de campanha. Se estiver usando um aplicativo multiplataforma, selecione também as plataformas às quais a regra deve se aplicar .

2. Em Definição da regra , escolha um Tipo de condição e um Valor :

   • O tipo de condição deve ser um dos tipos de condição de string ou de versionamento semântico.
   • Para o valor, insira um ou mais valores, dependendo do tipo selecionado.
   • A Adjust compara o valor com:
     • app_version_short no iOS
     • app_version em todas as outras plataformas

3. Escolha Aceitar ou Recusar e Realizar .

4. Selecione Criar regra.

Exemplo

Para uma regra de Correspondência entre versão e campanhas :

• Valor do Canal da campanha: WW
• Condição da versão do aplicativo: [Contém] _ww

Interpretação : para o canal WW, quero atribuir apenas as instalações que tenham versões de aplicativo terminando com _ww.

Comportamento : se uma instalação tiver uma versão do aplicativo que não contenha _ww, ela não será atribuída a nenhuma campanha do WW, mesmo que o último engajamento tenha vindo do WW. Confira Pular atribuição para saber como a Adjust lida com a busca de fallback.

Gerencie sua regra de conversão

Na página Conversion Rules , você pode:

• Ver uma lista com suas regras de conversão.

• Ver o status da regra e alterá-lo.

• Selecionar (ícone de edição) para editar a regra. É possível alterar o nome, status, tipo e configurações da regra.

  • Não é possível mudar o app para o qual você adicionou a regra.

• Selecionar (ícone de exclusão) para excluir a regra.

Relatórios

Aqui você encontra detalhes de como a Adjust registra dados de regras de conversão no Datascape. É usada a seguinte estrutura nos relatórios:

Atribuição alterada para Dispositivos não verificados

Atribuição alterada para Dispositivos não confiáveis

Dimensões

• Dispositivos não verificados
• Dispositivos não confiáveis

Métricas

Comportamentos de atribuição Dispositivos não verificados e não confiáveis

• Instalações

  1. Instalações não verificadas (regra da loja)
  2. Instalações não verificadas (regra da região)
  3. Regra de versão de instalações não verificadas
  4. Regra de parâmetro de instalações não verificadas
  5. Instalações rejeitadas (regra da loja)
  6. Instalações rejeitadas (regra da região)
  7. Regra de versão de instalações rejeitadas
  8. Regra de parâmetro de instalações rejeitadas

• Reatribuições

  1. Reatribuições não verificadas (regra da loja)
  2. Reatribuições não verificadas (regra da região)
  3. Regra de versão de reatribuições não verificadas
  4. Regra de parâmetro de reatribuições não verificadas
  5. Regra de loja reatribuições rejeitadas
  6. Regra de região reatribuições rejeitadas
  7. Regra de versão de reatribuições rejeitadas
  8. Regra de parâmetro de reatribuições rejeitadas

Atividades pós-instalação rejeitadas

1. Regra de região de sessões rejeitadas
2. Regra de região de eventos rejeitados
3. Regra de região de receitas de anúncios rejeitadas
4. Regra de versão de sessões rejeitadas
5. Regra de versão de eventos rejeitados
6. Regra de versão de receitas de anúncios rejeitadas
7. Regra de parâmetro de sessões rejeitadas
8. Regra de parâmetro de eventos rejeitados
9. Regra de parâmetro de receita de anúncios rejeitadas

Pular atribuição — métricas

1. Engajamentos não verificados (regra de campanha da região)
2. Cliques não verificados (regra de campanha da região)
3. Impressões não verificadas (regra de campanha da região)
4. Regra de campanha da versão - Engajamentos não verificados
5. Regra de campanha da versão - Cliques não verificados (regra de campanha da versão)
6. Regra de campanha da versão - Impressões não verificadas