Resumo: adicione uma camada personalizada de proteção contra campanhas e fraudes direcionadas incorretamente. As regras permitem que os proprietários de aplicativos controlem quais instalações e eventos in-app são bloqueados ou atribuídos à fonte válida mais recente.
Visão geral
- As regras de validação são definidas no criador de regras usando condições personalizadas e lógicas que filtram e selecionam quais instalações do aplicativo ou eventos in-app devem ser mantidos ou bloqueados.
- As regras se baseiam em uma variedade de parâmetros para vários casos de uso, incluindo:
- Instalações não direcionadas para sua campanha (geolocalização ou versão do sistema operacional errada, etc.)
- Instalações que não atendem à ordem de inserção acordada com a ad network
- Hijacking de instalações por redes fraudulentas
- Instalações falsas ou eventos in-app enviados de bots, emuladores ou device farms
- As regras definidas para eventos in-app só entram em vigor em eventos in-app associados a instalações que não foram bloqueadas anteriormente.
- As regras que incluem uma ad network são visíveis para a equipe dessa ad network (mas essa equipe não pode ver outras ad networks incluídas na regra). Isso faz parte do interesse da transparência, que ajuda as ad networks a entenderem melhor a performance do tráfego que elas oferecem.
- As regras são executadas em tempo real e tomam medidas imediatas. Saiba mais na seção de resultados.
- Outras opções de regra de validação estão disponíveis para os clientes do Protect360, além do bloqueio e detecção automáticos de fraudes do Protect360. Essas condições são conhecidas por ajudar na detecção de vários tipos de hijacking de instalação, instalação falsa e fraude de eventos in-app falsos.
Atenção: as regras de validação validam apenas instalações/eventos in-app que não foram identificados como fraude pelo Protect360.
Resultados
- Para instalações: as regras de validação, dependendo da ação selecionada, bloqueiam a atribuição e a corrigem para a última fonte de mídia válida ou bloqueiam completamente a atribuição.
- Para eventos in-app: As regras de validação bloqueiam a atribuição do evento in-app.
-
Consulte a tabela a seguir mostrando os resultados do tipo de bloco de regra de validação.
Tipo de bloqueio Descrição Onde os dados de instalação podem ser visualizados Eventos in-app que se seguem Instalações Bloquear atribuição e corrigi-la para a última fonte de mídia válida. - Selecionado quando você considera a instalação real, mas suas condições determinam quais fontes devem ou não ser atribuídas a ela.
- A atribuição é corrigida e a instalação é atribuída à última fonte de mídia válida.
- Se nenhuma fonte de mídia válida for identificada, a instalação será marcada como orgânica.
- Dashboards da AppsFlyer e relatórios de dados brutos como uma instalação regular (atribuída à última fonte de mídia válida)
- Com o plano Protect360 Premium:
- Dashboard de instalações do Protect360
- Relatório de dados brutos de instalações do Protect360 (com a fonte de mídia bloqueada)
- Sem o plano Protect360 Premium:
- Relatório de dados brutos de instalações do Protect360 (com a fonte de mídia bloqueada)
- Tem a mesma atribuição corrigida que a instalação
- Dados disponíveis com o plano Protect360 Premium:
- Com atribuição corrigida nos dashboards e relatórios da AppsFlyer como um evento in-app regular
- Com fonte de mídia bloqueada no dashboard de eventos in-app do Protect360 e relatório de dados brutos de eventos in-app bloqueados do Protect360
Marque instalações como inválidas e não faça sua atribuição - Selecionado quando as instalações inválidas com base nas condições da regra são consideradas falsas.
- A instalação não é atribuída (nem como não-orgânica ou orgânica)
- Com o plano Protect360 Premium:
- Dashboard de instalações do Protect360
- Relatório de dados brutos de instalações do Protect360 (com a fonte de mídia bloqueada)
- Sem o plano Protect360 Premium:
- Relatório de dados brutos de instalações do Protect360 (com a fonte de mídia bloqueada)
- Bloqueado
- Dados disponíveis com o plano Protect360 Premium no dashboard de eventos in-app do Protect360 e relatório de dados brutos de eventos bloqueados
Eventos in-app Bloquear atribuição - Selecionado quando eventos in-app que são inválidos com base nas condições da regra são considerados falsos.
-
Com o plano Protect360 Premium:
- Dashboard de eventos in-app do Protect360
- Relatório de dados brutos de eventos in-app do Protect360
- Sem o plano Protect360 Premium: N/D
- Dados disponíveis com o plano Protect360 Premium no dashboard de eventos in-app do Protect360 e relatório de dados brutos de eventos in-app bloqueados
Remover da AppsFlyer - Recomendado quando há eventos in-app para os quais você não precisa de nenhum dado.
- A AppsFlyer não registra esses eventos.
- As ad networks e agências só poderão visualizar os dados se o anunciante lhes der as permissões necessárias.
- Quando uma atribuição de instalação é bloqueada ou atribuída a uma fonte de mídia válida em tempo real, um postback rejeitado é enviado instantaneamente para a ad network bloqueada, para agilizar seu fluxo de reconciliação. Quando a atribuição é bloqueada e corrigida para a última fonte de mídia válida, um postback também é enviado para a última ad network válida.
-
Quando um evento in-app é bloqueado, um postback de rejeição é enviado instantaneamente para a ad network bloqueada.
Atenção:- um postback só é enviado se o conjunto de ad networks configurado para recebê-lo estiver integrado à AppsFlyer.
- Os relatórios de postbacks e de postbacks rejeitados estão disponíveis na página de exportação.
- Saiba mais sobre postbacks e postbacks rejeitados.
-
O bloqueio de instalações e a atribuição de eventos in-app afeta apenas a forma como e onde os dados são relatados na AppsFlyer. Eles não impedem o uso do aplicativo pelos seus usuários finais.
- Se necessário, você pode usar os relatórios de dados brutos de instalações e eventos in-app bloqueados (disponíveis via exportação, pull API e data locker), para que a lista de usuários do aplicativo seja desativada.
-
Os relatórios de instalações/eventos in-app bloqueados e postbacks rejeitados contêm o nome das regras que bloquearam as instalações/eventos in-app sob o motivo do bloqueio. Consulte a seção regras múltiplas se houver mais de uma regra.
- Quando as instalações/eventos in-app são bloqueados pelo mecanismo antifraude do Protect360, mesmo que também haja uma regra de validação, os motivos do Protect360 são exibidos.
- As regras podem resultar em discrepâncias entre os relatórios da AppsFlyer e SRNs, como o Meta ads e oGoogle Adwords, pois eles implementam sua própria lógica para validar as instalações.
Várias regras
- Várias regras de validação podem ser executadas na mesma instalação/evento in-app. Isso acontece quando a instalação atende às condições de várias regras.
- A instalação/evento in-app é classificada como inválida quando não cumpre as condições de nenhuma das regras separadamente.
- Em relatórios de dados brutos e postbacks rejeitados, o campo do valor do motivo do bloqueio contém os nomes de todas as regras que classificam a instalação ou evento in-app como inválidos.
- Várias regras para a mesma instalação são sequenciadas para serem executadas na seguinte ordem, com base nos tipos de bloqueio das regras:
Tipos de regra/bloqueio | Pedido |
---|---|
Bloquear instalações | Aleatório |
Bloquear atribuição | Aleatório |
Bloquear evento in-app | Aleatório |
Remova da AppsFlyer e de qualquer outra parte | Removido da AppsFlyer. Outras regras são ignoradas. |
Bloquear instalações e bloquear atribuição |
|
Bloquear instalações e bloquear atribuição através do mecanismo do Protect360 e das regras de validação |
|
Bloquear eventos in-app com o mecanismo do Protect360 e regras de validação |
|
Criador de regras
A interface de usuário do criador de regras foi projetada para criação de regras interativa. Dica! Familiarize-se e teste o criador de regras antes de ler este artigo em detalhes.
O criador de regras contém as seguintes seções:
Seção | Observações |
---|---|
Detalhes gerais |
AtençãoA versão do aplicativo deve conter apenas números. Por exemplo, 2.2.1. Atenção: as versões numéricas do aplicativo (por exemplo, 2.2.1) oferecem suporte a todos os operadores (iguais, maiores que, menores que, etc.). Se a versão do aplicativo for de texto personalizado (por exemplo, version123 ou our_latest_version), somente os operadores "igual a" ou "não é igual a" funcionarão; "maior do que" ou "inferior do que" não será aplicado. |
Fontes de tráfego | Origem do tráfego para a qual a regra é aplicada. Veja também fontes do Protect360 |
Condições |
Escolha se deseja bloquear instalações/eventos in-app que "correspondem" ou "não correspondem" às condições definidas.
Veja também as condições do Protect360 para instalações e eventos in-app. |
Ações |
Para instalações: selecione o que fazer com as instalações que atendem às condições especificadas:
Para eventos in-app: selecione o que fazer com as instalações que atendem às condições específicas:
Consulte resultados para mais informações. |
Fontes de instalação
A seção Fontes é onde você define as origens de tráfego das instalações às quais a regra se aplica.
Existem duas opções:
-
Todo o tráfego Todo o tráfego: a regra se aplica a qualquer instalação, independentemente da sua fonte (agência, fonte de mídia, campanha, orgânica etc.).
Atenção: Como essa opção inclui instalações orgânicas, nenhuma informação adicional da fonte pode ser selecionada e apenas a opção de bloquear instalação está disponível. Não é possível bloquear/corrigir a atribuição para instalações orgânicas. - Só não orgânicas Somente não orgânico: a regra se aplica às origens selecionadas, com os campos, operadores e valores conforme descrito na tabela a seguir.
Opções de fonte adicionais estão disponíveis para clientes do Protect360, para instalações e eventos in-app.
Campo | Operador | Valor | Observações |
---|---|---|---|
Agência |
|
|
|
Fonte de mídia |
|
|
|
Campanha |
|
|
|
Campaign ID |
|
||
Ad ID | |||
Ad set ID | |||
Nome do adset |
Condições de instalação
A seção Condições é onde você define as condições que determinam quando as instalações são bloqueadas ou atribuídas à última fonte válida.
Você pode adicionar várias condições e grupos de condições a cada regra.
As condições são definidas de acordo com as condições, operadores e valores descritos na tabela a seguir.
Upload em massa
Ao selecionar os operadores na lista ou fora da lista dentro das condições disponíveis, você tem a opção de fazer upload em massa de um arquivo CSV ao adicionar novos itens.
Para fazer isso:
- Selecione uma condição com um operador na lista ou fora da lista .
- Selecione na lista ou fora da lista na lista suspensa do operador.
- Selecione fazer upload de arquivo CSV na caixa adicionar novos itens.
Atenção: o arquivo CSV pode conter até 17 mil valores.
Opções de condição adicionais estão disponíveis para os clientes do Protect360, para instalações e eventos in-app.
Condição | Operador | Valor | Observações |
---|---|---|---|
Campanha |
|
|
|
Campaign ID |
|
||
Ad ID | |||
Ad set ID | |||
Nome do adset | |||
Tipo de dispositivo | |||
Geo |
|
|
|
Plataforma | Selecione o valor no menu. | ||
Moeda |
Apenas moeda. Valores possíveis: USD, NZD, SGD, IMP, ANG, MNT, BIF, BBD, HUF, ERN, AZN, AOA, PYG, MYR, GYD, VUV, SLL', FKP, DJF, GNF, LVL, MMK, MRO, RSD, CLF, XDR, ZAR, TND, PHP, KGS, XPD, RON, RUB, KMF, SCR, GIP, TRY, JEP, UYU, XCD, FJD, GHS, MVR, AWG, UGX, TOP, CVE, MKD, COP, CUC, GTQ, KZT, MXN, MGA, AUD, BDT, ISK, KRW, DZD, GGP, OMR, ZMW, MOP, CUP, JPY, SHP, LSL, ETB, BWP, MAD, AED, NGN, BRL, GEL, IDR, EUR, GBP, WST, XAF, SZL, XOF, SEK, UZS, KES, KYD, ILS, KWD, NPR, BZD, QAR, UAH, BTN, HTG, DKK, VND, SBD, JMD, IQD, LBP, XPT, HRK, HKD, JOD, PAB, CDF, VEF, XAU, BAM, CNY, SOS, XPF, GMD, DOP, XAG, KPW, BOB, BHD, BYN, BYR, LRD, BGN, AMD, CZK, CAD, LAK, EEK, MTL, PLN, LKR, BTC, MWK, LTL, ZMK, PGK, YER, PEN, KHR, RWF, BSD, AFN, ZWL, LYD, TMT, HNL, TWD, IRR, MUR, THB, ALL, TJS, SDG, BMD, CRC, NOK, SRD, MZN, CLP, STD, SYP, TZS, EGP, ARS, MDL, INR, SAR, PKR, TTD, NIO, BND, NAD, SVC, CHF |
||
Receita |
|
|
|
Versão do sistema operacional |
|
|
|
Dias de lookback |
|
|
|
Está pré-instalado |
|
|
|
É deep link | Um campo de deep link vazio em dados brutos é considerado "Is deeplink = No" |
Fontes de eventos in-app
Quando eventos in-app são selecionados na seção Eventos, além das opções de fonte regulares, os clientes têm outra opção de fonte para definir a quais eventos in-app sua regra se aplica.
A origem é definida de acordo com o campo, operadores e valores descritos na tabela a seguir.
Nota: Observação: todas as outras fontes de eventos in-app têm como base a origem da instalação à qual o IAE está associado (por exemplo, agência, fonte de mídia, campanha, ID da campanha, ID do site etc).
Campo | Operador | Valor | Observações |
---|---|---|---|
Nome do evento |
|
|
|
Condições do evento in-app
Quando os eventos in-app são selecionados na seção Eventos, os clientes têm opções de condição adicionais para definir a quais eventos in-app sua regra se aplica. Essas condições podem ser misturadas e combinadas com qualquer uma das condições fora do Protect360 listadas anteriormente.
As condições do Protect360 são definidas de acordo com as condições, operadores e valores descritos na tabela a seguir.
Condição | Operador | Valor | Observações |
---|---|---|---|
Nome do evento |
|
|
|
Atenção
As condições de nome do evento não diferenciam maiúsculas de minúsculas. Todos os nomes de eventos são convertidos automaticamente para letras minúsculas antes da avaliação. Por exemplo, se você inserir o Formulário de envio, o sistema o tratará como um formulário de envio.
Fontes de instalação e de eventos in-app do Protect360
Além das opções de fontes regulares, os clientes do Protect360 têm outra opção de fonte para definir a quais instalações sua regra se aplica. A fonte é definida de acordo com o campo, operadores e valores descritos na tabela a seguir.
Campo | Operador | Valor | Observações |
---|---|---|---|
Site ID |
|
|
|
Condições de instalação do Protect360
Os clientes do Protect360 têm um conjunto adicional de condições para validar suas instalações. Essas condições podem ser misturadas e combinadas com qualquer uma das condições fora do Protect360 listadas anteriormente.
As condições do Protect360 são definidas de acordo com as condições, operadores e valores descritos na tabela a seguir.
Condição | Operador | Valor | Observações |
---|---|---|---|
CTIT (Click Time to Install Time, tempo do clique à instalação) |
|
|
|
Customer user ID (CUID) |
|
|
|
Versão do aplicativo |
|
|
|
Versão do SDK |
|
|
|
Instalador/Loja |
|
Selecione o valor no menu:
|
|
Instalador/Loja personalizada | Free text (para valores que não existem nos resultados da pesquisa). |
|
|
Tipo de toque de atribuição |
|
|
|
Operadora |
|
|
|
User agent |
|
|
|
IP address |
|
|
Condições de eventos in-app do Protect360
Quando os eventos in-app são selecionados na seção eventos, os clientes do Protect360 têm opções adicionais de condições para definir a quais eventos in-app sua regra se aplica. Essas condições podem ser misturadas e combinadas com qualquer uma das condições fora do Protect360 listadas anteriormente.
As condições do Protect360 são definidas de acordo com as condições, operadores e valores descritos na tabela a seguir.
Condição | Operador | Valor | Observações |
---|---|---|---|
Fonte do evento |
|
|
Selecione SDK ou Server-to-server. |
Valor do evento |
|
|
|
Instalação x tempo do evento (em segundos) |
|
Free text. Um único valor numérico. |
|
Lógica entre condições e grupos de condições
Se você adicionar várias condições ou grupos de condições a uma regra, selecione a relação lógica entre eles usando:
- e E: o que significa que a instalação está em conformidade com todas as condições definidas.
- OU Ou: o que significa que a instalação está em conformidade com pelo menos uma das condições definidas.
Por exemplo, se você quiser validar instalações com base tanto na plataforma quanto no sistema operacional, você deve selecionar and. Dessa forma, a plataforma definida deve sempre acompanhar o sistema operacional definido. Se quiser validar instalações com base em plataforma ou sistema operacional, você deve selecionar or.
Procedimentos
Ver lista de regras
Para visualizar todas as regras criadas na sua conta:
-
Na AppsFlyer, acesse Configurações > Regras de validação.
A janela Regras de validação é aberta, com a lista de regras de validação. - Selecione sua exibição de tabela preferida usando o botão de Ver lista/Detalhes.
-
Filtre as regras na lista usando as opções de pesquisa e filtro.
- Você pode pesquisar pelo nome da regra, fonte, nome da condição e valor. e valor.
- Por exemplo, digite 7 para encontrar todos regras definidas para uma versão do SO que contém 7. % (por exemplo, etc. Ou digite Canadá para encontrar regras definidas para o Canadá na condição Geolocalização.
Adicionar regra
Para configurar uma nova regra:
-
Na AppsFlyer, acesse Configurações > Regras de validação.
A janela de regras de validação abre. -
Clique em Adicionar regra.
A janela para adicionar nova regra é aberta. -
Insira um nome de regra. Use um nome exclusivo
que
- descreva precisamente a regra.
- não é ofensivo para as ad networks, pois é exibido no relatório de instalações bloqueadas, assim como nas rejeitadas postbacks para ad networks.
- Complete o Seções do criador de regras
- [Opcional] Adicione condições e/ou grupos de condições, conforme necessário. Certifique-se de selecionar a lógica relevante entre condições/grupos de condição.
- [Opcional] Clique em Estimar impacto no tráfego to ver como sua regra afetará o tráfego.
- Clique em Salvar.
Atenção
A versão do aplicativo deve conter apenas números. Por exemplo, 2.2.1.
Atenção:
As versões numéricas do aplicativo (por exemplo, 2.2.1) são compatíveis com todos os operadores (iguais, maior que, menor que, etc.).
Se a versão do aplicativo for de texto personalizado (por exemplo, version123 ou our_latest_version), apenas "igual" ou "não igual" operadoras funcionam; o "maior que" ou "menor que" não se aplica.
Ver o impacto da regra de validação
Veja o impacto estimado que suas regras de validação têm no tráfego, o que significa quantas instalações bloqueadas e atribuições bloqueadas provavelmente resultarão.
Atenção:
- O estimador da regra de validação pode ser acessado apenas por anunciantes. Apenas Os parceiros não têm acesso.
- As estimativas estão disponíveis para regras relacionadas a instalações, não para regras relacionadas a eventos in-app.
- A estimativa também exibe o que se aplica à regra, mas já está bloqueada pela proteção contra fraudes do Protect360, outra regra de validação, ou, se a regra estimada não for nova, o tráfego é bloqueado por sua configuração anterior.
Para ver o impacto estimado da sua regra de validação:
- Na AppsFlyer, vá para Regras de validação.
- Selecione uma regra existente ou clique em + Adicionar regra e crie uma nova regra com fontes e condições de regra.
-
Vá até a parte inferior da regra e clique em Estimar impacto no tráfego.
A janela de impacto estimado da regra se abre. -
Selecione se deseja basear o impacto estimado em dados do último dia ou dos últimos 7 dias.
- Os novos blocos estimados, bem como os porcentagem de tráfego bloqueado devido à validação regra, exibe.
-
Quando a regra é definida apenas em não orgânico
fontes, a estimativa exibe o impacto de
a regra versus todo o seu tráfego. Para ver o
impacto vs. somente as fontes (por exemplo, um
fonte de mídia ou campanha específica), no gráfico
legenda, desmarque Outras fontes.
Editar ou excluir uma regra
Para editar, excluir, ativar ou desativar uma regra:
-
Na lista de regras,
selecione a ação que você deseja executar para uma regra específica
Regra
- Em Ativo: habilitar ou desative a regra.
- Em Ação: edite ou exclua a regra. a regra.
Perguntas frequentes
O que é uma "expressão regular"?
Um padrão de expressão regular é composto por caracteres para que você deseja encontrar. Padrões simples são construídos com caracteres para os quais você deseja encontrar uma correspondência direta. Quando a busca por uma correspondência exige algo mais do que uma correspondência direta, você pode incluir caracteres especiais no padrão.
Exemplos:
Expressão regular | Descrição |
---|---|
^abc | Começa com abc |
xyz$ | Termina com xyz |
^abc.*xyz$ | Começa com abc e termina com xyz |
^abc.*(?<!xyz)$ | Começa com abc e não termina com xyz |
^([0-9]{2}) | Começa com 2 dígitos |
\"example_param\":\"[5|6] | O valor do parâmetro especificado começa com 5 ou 6. |
^.{0}$|^\{\}$ | Está vazio, ou é apenas {} |
Por que a fonte ou condição não é exibida como um valor sugerido? quando eu pesquiso?
Existem duas razões possíveis:
- Verifique se os aplicativos relevantes estão selecionados. Se o aplicativo não estiver selecionado, os valores não serão exibidos nos resultados da pesquisa.
- Os resultados são exibidos somente se o valor que você está procurando aparecer em seu tráfego durante os últimos 30 dias. Além disso, há um intervalo de até um dia entre quando a conversão ocorre e quando a fonte ou condição é exibida como uma opção de menu.
Se o valor não aparecer como resultado de pesquisa, você pode digitar o valor como texto livre e pressionar a tecla Enter no teclado.
Por que minhas opções de fonte de mídia incluem apenas Meta ads e X Ads?
As opções do campo fontes de mídia são afetadas pela seleção da Agência. Se "agência não transparente" for selecionada como uma das fontes de tráfego, nenhuma fonte de mídia será exibida, exceto para Meta ads e X Ads - em que mesmo as agências não transparentes precisam ser transparentes.
Nota: Observação: se sua regra se aplicar a vários aplicativos, qualquer agência que seja transparente em alguns dos aplicativos selecionados, mas não transparente em outros, será considerada não transparente. Isso significa que você não pode selecionar fontes de mídia específicas que não sejam o Meta ads ou X Ads.
É necessário ter "e/ou" ambos em condições específicas e entre grupos de condição?
Depende do seu caso. Às vezes, qualquer opção alcança os mesmos resultados. Outras vezes, ambas as opções são necessárias.
Por exemplo, se nos EUA você oferecer suporte apenas para instalações no SO V10 ou posterior, mas no Brasil, você tem o suporte da V7 e, posteriormente, precisam de uma regra como:
{[Geo = US] and [OS version = 10]} OR {[Geo = Brazil] and [OS version = 7]}
As regras de validação bloqueiam cliques?
Não. As regras de validação podem bloquear instalações, bloquear atribuição para as fontes de uma instalação (que impede que a fonte de mídia de um clique/impressão de receber atribuição) ou bloqueio Eventos in-app No entanto, nenhuma dessas opções bloqueia o clique real e KPIs de clique não são afetados pela execução Regras de validação
Olhando para os dados brutos, vejo que as instalações que eu esperava ser bloqueadas por regras de validação com um motivo de bloqueio diferente de nome da minha regra. Por que?
Isso significa que o bloqueio foi devido à Mecanismo do Protect360 e não uma regra de validação. Veja também Várias regras
As regras existentes se aplicam automaticamente ao tráfego de agências recém-integrado? tráfego
Isso depende das configurações de Fonte, como descrita na tabela abaixo.
Se a regra não for aplicada automaticamente, você deverá editar a regra: Regra
- Altere o campo Agência para Tráfego de agência e não agência, ou selecione a agência específica.
Configuração de fonte | Seleção de campo de agência | É regra aplicada se a regra foi criada antes alguma integração de agência com um de seus aplicativos? | É regra aplicada se a regra foi criada após pelo menos uma integração de agência com um dos seus aplicativos? |
---|---|---|---|
Todo o tráfego | N/R | Yes | Yes |
Só não orgânicas |
N/R | No | N/R |
Tráfego de agência e de outras fontes | N/R | Yes | |
Tráfego de não agência e/ou agências específicas |
N/R | No |
Como funcionam as condições "not in last"?
Não em último é uma condição usada quando você tem uma série das versões do aplicativo que você deseja incluir na validação Regra Não em último (major) é uma condição usada quando você tem mais de uma série de versões de aplicativos que você deseja para incluir na regra de validação.
Exemplo:
- Você tem uma série de versões de aplicativos 1.0 e 2.0
-
Todas as suas versões de aplicativos existentes:
- 1.0.01
- 1.0.02
- 1.0.03
- 2.0.01
- 2.0.02
- 2.0.03
-
Uma regra definida com blocos "Not in last 2 versions":
- 2.0.02
- 2.0.03
-
Uma regra definida com blocos "Not in last (major) 2 versions":
bloqueios:
- 1.0.02
- 1.0.03
- 2.0.02
- 2.0.03
Características e limitações
Características | Descrição |
---|---|
Acesso do usuário à conta | Somente os usuários da conta com as permissões apropriadas podem visualizar, adicionar e editar regras de validação. |
Aquisição de usuários | As regras de validação se aplicam a instalações, reinstalações e reatribuições (quando o aplicativo foi removido do dispositivo). Elas não se aplicam a casos de reengajamento, ou seja, quando o aplicativo ainda está no dispositivo. |
Desativação automática das regras |
Se você criar regras:
|
Ad networks |
Solicite a permissão do anunciante para: Ver regras de validação para visualizar os detalhes da regra. Atenção: Os nomes das regras estão sempre visíveis (incluindo Nos dados brutos |
Agências |
Solicite a permissão do anunciante para:
|
Usuários únicos | Se você tiver mais de 100 eventos in-app configurados, mesmo se você usar as regras de validação para invalidar determinados eventos in-app, o limitação de contagem de usuários únicos ainda se aplica. Significa que eventos com mais de 100 não ter usuários únicos contados, mesmo que sejam invalidado pelas regras de validação. |
SKAN | Indisponível |