Eventos in-app

Saiba mais sobre conceitos básicos e terminologia relacionados a eventos in-app.

Os eventos in-app fornecem insights sobre como os usuários interagem com seu aplicativo. Os SDKs da AppsFlyer permitem que você registre facilmente essas interações.

Guias do SDK de eventos in-app

Anatomia de um evento

Os eventos in-app consistem em 2 partes:

  • Nome do evento: o identificador exclusivo do evento. Geralmente é como os profissionais de marketing veem o evento no painel.
  • Valores de evento: um objeto que consiste em pares de valores da chave chamados parâmetros de evento. Os parâmetros do evento fornecem contexto e informações adicionais sobre o evento que está ocorrendo.

Nomes de eventos e parâmetros de eventos podem ser predefinidos ou personalizados.

👍

Dica

Defina e gere rapidamente o código de eventos em plataforma para todas as principais plataformas usando nossa ferramenta geradora de eventos in-app.

Constantes de eventos

Nos SDKs, eventos e parâmetros predefinidos são expostos como constantes.

Ao enviar eventos, é recomendável usar as constantes em vez de strings brutas:

  • Isso reduz a chance de introduzir discrepâncias de nomenclatura.
  • As alterações nos nomes de eventos/parâmetros subjacentes são transparentes para você e exigem menos manutenção.

Tecnicamente, nomes/parâmetros predefinidos de eventos são strings prefixadas com af_.

Parâmetros de eventos e eventos personalizados

Nomes e parâmetros de eventos personalizados são definidos pelo usuário e geralmente descrevem cenários específicos para a lógica de negócios do aplicativo e a interação de seus usuários com o aplicativo.

🚧

Atenção

Para evitar confusão com eventos predefinidos, não prefixe nomes de eventos personalizados com af_.

Valid custom event names

Nomes de eventos personalizados devem seguir estas regras:

  • Ter até 100 caracteres.
  • Caracteres que não são do português são compatíveis.

Valid custom event parameters

Parâmetros de evento personalizados:

  • Não deve exceder 1000 caracteres; se for maior, pode ser truncado
  • Preço e receita: use apenas dígitos e decimais, por exemplo, 5 ou 5.2
  • Os valores de preço e receita podem ter até 5 dígitos após o ponto, por exemplo, 5.12345

Compreendendo as definições da estrutura

O ideal é que o profissional de marketing forneça definições claras da estrutura de eventos, com base nas instruções em Definindo eventos in-app. Por exemplo, uma definição de um af_content_view evento para um aplicativo de eCommerce seria algo parecido com isto:

Nome do eventoParâmetros do eventoValores de parâmetrosOnde/Quando (opcional)
af_content_viewaf_price
af_content_type
af_content_id
af_price: Preço do item
af_content_type: Categoria do item
af_content_id: SKU do item
Quando um usuário navega até uma visualização do item.
  • A primeira coluna (nome do evento) é o valor que você passa como logEvento segundo argumento.

    af_content_view é como os profissionais de marketing veem o evento no painel. Recomenda-se usar as constantes de evento predefinidas em vez dos valores de cadeia bruta que os profissionais de marketing fornecem.

  • A segunda coluna (Parâmetros de evento) lista os parâmetros de evento associados ao evento. Neste caso, você deve passar os seguintes parâmetros de eventos para logEvent:

    • af_price
    • af_content_type
    • af_content_id
  • A terceira coluna (valores de parâmetro) contém informações adicionais sobre valores específicos atribuídos aos parâmetros de evento. No exemplo acima, o profissional de marketing comunica claramente que o af_content_id o valor do parâmetro de evento deve ser o SKU do item visualizado.

  • A quarta coluna é onde o profissional de marketing descreve onde e quando no aplicativo deve ocorrer o evento

Veja como a definição de exemplo acima é implementada no Android e no iOS.

Eventos in-app offline

O SDK pode armazenar eventos in-app em cache que ocorrem quando nenhuma conexão com a internet está disponível:

  • O SDK envia os eventos para servidores da AppsFlyer e aguarda uma resposta
  • Se o SDK não receber uma resposta 200, os eventos serão armazenados em cache
  • Depois que a próxima resposta 200 for recebida, os eventos armazenados são reenviados para o servidor
  • Se houver vários eventos no cache, eles serão enviados para o servidor um após o outro (sem lote, uma solicitação de rede por evento).

O SDK pode armazenar até 40 eventos em cache. Somente os primeiros 40 eventos offline são armazenados. Tudo o que vem depois (até a próxima resposta bem-sucedida), é descartado.