Configurar regras de evento
As Regras de eventos estendem o Conversion Rules para validar eventos pós-instalação com base nas condições personalizadas que você definiu.
Quando um evento não cumpre essas condições, a Adjust o rejeita e avisa sobre a rejeição nos callbacks, nas exportações de CSV e nos relatórios.
Para ativar o Conversion Rules (e as Regras de eventos) na sua conta, entre em contato com sales@adjust.com.
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.
Configurar uma regra de evento
Para definir uma regra de evento, siga os passos abaixo:
No AppView, abra Eventos e assinaturas e selecione o evento que queira validar.
Selecione Editar evento .
Vá até o monitoramento que deseja configurar.
Escolha uma das seguintes opções de status:
- Ativo - Quando a regra é salva, o monitoramento fica ativo no sistema da Adjust. Os eventos que não cumprirem os requisitos de monitoramento serão rejeitados .
- Teste - Quando a regra é salva, o monitoramento fica ativo no sistema da Adjust. Os eventos que não cumprirem os requisitos de monitoramento não serão rejeitados , e sim sinalizados e relatados.
- Pausado - A regra não é aplicada a nenhum evento. Use esse status para salvar suas alterações sem ativá-las.
Configure um ou mais monitoramentos (veja Monitoramentos).
Selecione Save changes (Salvar alterações).
Você também pode configurar monitoramentos de regras de evento durante o processo inicial de criação do evento.
Remover um monitoramento de regras de evento
Para remover um monitoramento, basta definir seu status como Desativado .
Monitoramentos
É possível aplicar vários monitoramentos na sua regra de evento.
Se qualquer monitoramento com o status Ativo apresentar erros, o evento será rejeitado .
Filtros-alvo
Use filtros de destino para restringir o tráfego ao qual cada verificação se aplica. Os filtros são configurados por verificação e não afetam outras verificações na mesma regra.
Nível de campanha
Por padrão, a verificação se aplica a todos os canais. Escolha qual nível da sua estrutura de campanha definir como escopo da verificação:
- Canais — Limite a verificação a um ou mais canais.
- Campanhas — Limite a verificação a um canal e, em seguida, a uma ou mais campanhas nele.
- Adgroups — Defina o escopo da verificação para um channel e campaign e, em seguida, para um ou mais adgroups (source IDs) dentro dele.
Apenas o campo correspondente ao nível de Campaign selecionado permite várias seleções — por exemplo, no modo Adgroups você escolhe um único channel, uma única campaign e um ou mais adgroups. Os campos acima desse nível (Channel e Channel + Campaign) são de seleção única e existem apenas para restringir o escopo ao nível que você escolheu.
Uma seleção só tem efeito no nível em que você escolhe um valor específico. Se você deixar o campo do nível escolhido em All ou não selecionado — por exemplo, escolhendo Adgroups , mas sem selecionar uma campaign — a configuração reverte, ao salvar, para o nível mais próximo em que um valor específico foi realmente selecionado (por exemplo, Adgroups → Campaigns, ou Adgroups/Campaigns → Channels, se nada tiver sido selecionado).
Instalar versão do aplicativo
Restringa a verificação a usuários que instalaram uma versão específica do app. Use isso para garantir que a lógica da regra seja aplicada apenas a usuários para os quais ela é válida e significativa — por exemplo, usuários que instalaram uma versão onde todos os eventos e fluxos referenciados pela regra já faziam parte do app.
A versão instalada do aplicativo refere-se à versão no momento da instalação, não à versão atual do aplicativo. Um usuário que atualiza após a instalação mantém sua versão original para fins de avaliação de regras.
Controle de fonte
Use isso para controlar qual fonte de evento é aceita e para lidar com eventos que não estão mais ativos no seu app.
Fonte de evento aceita
Restringe quais fontes de eventos serão aceitas.
- SDK - Aceita apenas eventos vindos do SDK.
- S2S - Aceita apenas eventos de servidor para servidor (S2S).
- Se o seu app tiver a Lista de permissão de S2S habilitada, ela se aplicará a todos os eventos por padrão. Você pode desativá-la para eventos específicos a fim de excluí-los da verificação de IP — por exemplo, se eventos de servers de parceiros confiáveis precisarem apenas de autenticação por token, enquanto eventos de fluxos internos ou sensíveis devem manter a restrição adicional de IP.
Se um evento vier de uma fonte não permitida, ele será rejeitado.
Para eventos vindos do SDK, revise a integração e configuração da sua assinatura de SDK para garantir uma melhor proteção. Para eventos vindos de servidor para servidor, revise sua configuração de segurança S2S.
Evento descontinuado
Rejeite o evento se ele tiver sido removido do app e não estiver mais sendo acionado. Use isso para invalidar quaisquer acionadores restantes para eventos que não fazem mais parte do fluxo de eventos do seu app.
Controle de fluxo
Use-o para controlar a sequência esperada, o timing e os parâmetros necessários de eventos.
Você pode selecionar várias condições. Neste caso, todas as condições selecionadas precisam sem preenchidas para que o evento seja aprovado. Do contrário, o evento será rejeitado.
Tempo após a instalação
Exija que o evento ocorra dentro de ou após um período específico após a instalação.
Por exemplo: "Maior que ou igual a 5 minutos após a instalação".
Evento anterior obrigatório
Exija que um evento específico (como Nível 1 ) ocorra antes desse evento. Como uma restrição adicional, você pode também especificar um tempo mínimo ou máximo entre o evento anterior necessário e o atual.
A condição Evento anterior necessário funciona apenas para eventos enviados pelo SDK .
Não configure esse monitoramento para eventos de servidor para servidor (S2S) , já que eles não serão avaliados corretamente.
Evento não pode acontecer se... - exclusão mútua de eventos específicos
Rejeite o evento se um outro evento especificado já foi acionado para esse usuário. Use isso para impor exclusão mútua entre dois eventos — se um ocorreu, o outro é bloqueado.
Exemplo: " a compra não pode ser efetuada se o reembolso já tiver sido realizado".
Os eventos que já estão vinculados a uma regra de exclusão mútua existente são marcados como Já conectados a no menu suspenso.
A definição dessa condição cria automaticamente uma regra simétrica no evento especificado, com o mesmo status de regra, visível na interface do usuário.
Se você usar filtros-alvo , certifique-se de que eles estejam alinhados em ambos os eventos para evitar comportamentos de rejeição inconsistentes.
O último disparo do evento aconteceu no mínimo antes — supressão de eventos baseada no tempo
Rejeite o evento se ele tiver sido acionado há menos de um determinado período de tempo. Use isso para limitar a frequência com que o mesmo evento pode ser aceito para um determinado usuário.
Exemplo: "o último gatilho da compra aconteceu há no mínimo 5 minutos ."
Parâmetros obrigatórios
Verifique os parâmetros do SDK do evento em relação a uma ou mais condições — por exemplo, exigindo que uma chave exista ou que seu valor corresponda a valores específicos, os contenha ou os exclua.
Para cada condição, escolha um Tipo de condição :
- Existe — Exija que uma ou mais chaves de parâmetro estejam presentes no payload do evento, independentemente do valor. Você pode incluir várias chaves de parâmetro; todas precisam estar presentes para que o evento seja aprovado no monitoramento.
- é igual a — Exige que o valor do parâmetro corresponda exatamente a um dos valores que você fornecer.
- não é igual a — Exige que o valor do parâmetro não corresponda a nenhum dos valores fornecidos por você.
- contém — Exige que o valor do parâmetro contenha um dos valores que você fornecer, como uma substring.
- não contém — Exige que o valor do parâmetro não contenha nenhum dos valores informados por você.
Selecione + Adicionar para adicionar mais condições. Cada condição é avaliada de forma independente, e todas precisam ser aprovadas para que o evento seja aprovado na verificação.
Exemplo: para aceitar o evento apenas se for uma assinatura premium ou gold que inclua um ID de transação, defina:
- Chave do parâmetro:
subscription_tier— Tipo de condição: é igual a — Valor do parâmetro:premium,gold - Chave do parâmetro:
transaction_id— Tipo de condição: Existe
Não há uma condição dedicada para verificar se o valor de um parâmetro está vazio — a Adjust não consegue distinguir de forma confiável "o valor está vazio" de "o valor está ausente". Use Exists para verificar se um parâmetro está presente no payload, como na condição transaction_id acima.
Os nomes das chaves do parâmetro não podem conter um sublinhado duplo (__).
A correspondência de chaves de parâmetro distingue minúsculas de maiúsculas — Subscription_Tier e subscription_tier são tratadas como chaves diferentes. A correspondência de valores de parâmetro não distingue minúsculas de maiúsculas — um valor subscription_tier de Premium ainda corresponde à condição premium acima.
Se quiser conferir os parâmetros para atividades de instalação e pós-instalação (não instâncias de eventos individuais), use então a regra de tipo Parâmetro.
Controle de receita
Use esse monitoramento para validar eventos monetizados para completude e verificação de compra.
Ele será aprovado ou não com base no resultado da Verificação de compra .
Ative a opção de também rejeitar eventos com dados de transação ausentes.
Configuração de controle de receita
A configuração da verificação de compra é gerenciada em AppView -> Protection -> Verificação de compra .
Para usar os resultados da verificação de compra no fluxo de controle de receita, é preciso trocar do Modo antigo para o Modo de evento primeiro.
- Verificação de compra não configurada para regras de eventos
- Exemplo de configuração de verificação de compra
Compartilhamento de dados
Os eventos rejeitados serão relatados como:
Callbacks e exportações de CSV quando um alerta de Evento rejeitado é configurado. O placeholder {rejection_reason} é informado com valores granulares por verificação:
post_install_activity_event_rule_source_checkpost_install_activity_event_rule_flow_checkpost_install_activity_event_rule_pv_status_check
Métricas de eventos rejeitados e taxa de eventos rejeitados em relatórios, com detalhamento do motivo da rejeição :
rejected_events_post_install_activity_event_rule_source_check(Verificação da fonte da regra de evento)rejected_events_post_install_activity_event_rule_flow_check(Verificação do fluxo de regras de evento)rejected_events_post_install_activity_event_rule_pv_status_check(Verificação de status PV da regra de evento)rejected_events_post_install_activity_rule(Filtros de atividade pós-instalação) — preservados para compatibilidade retroativa
Resultados do modo de teste
As regras com o status de Teste não rejeitam eventos mesmo se a regra apresentar erros. Resultados rejeitados são compartilhados apenas com os clientes — eles não são encaminhados para parceiros.
Para distinguir resultados de teste dos resultados ao vivo, adicione o placeholder {conversion_rule_status} às suas callbacks ou à configuração de exportação CSV. O placeholder retorna test quando a regra está em status de teste e live quando a regra está em status ao vivo.