Visão geral: envie eventos de seus servidores para a AppsFlyer para mensurar eventos mobile que ocorrem fora do aplicativo.
API de eventos de servidor para servidor para mobile
Para aplicativos do iOS, a partir do iOS 14, você deve enviar o parâmetro do os (sistema operacional).
A plataforma da AppsFlyer atribui e grava eventos de aplicativos móveis pelo SDK da AppsFlyer e pelas APIs. Use a API S2S para reportar eventos que ocorrem fora do aplicativo. Por exemplo, um usuário renova a assinatura usando sua interface da web. Eventos S2S, uma vez gravados, estão disponíveis em toda a plataforma, incluindo painéis, dados brutos e analytics. Para eventos da web PBA, veja S2S Web para PBA.
A AppsFlyer preenche eventos S2S com:
- Valores enviados na mensagem S2S
- Alguns valores de atribuição da instalação da AppsFlyer, como hora de instalação e fonte de mídia
Para enviar eventos via API, diga ao seu desenvolvedor para seguir as instruções da API de eventos de servidor para servidor.
Como preencher parâmetros
Diferença entre orgânico e não orgânico
Quando a AppsFlyer processa eventos in-app S2S, os campos de atribuição são preenchidos usando a ID da AppsFlyer para identificar o evento de instalação associado que precedeu os eventos in-app.
O que isso significa é que alguns dados que a AppsFlyer associa a eventos in-app S2S não orgânicos não estão associados a eventos in-app S2S orgânicos.
Exemplo
Por exemplo, se você comparar relatórios de dados brutos de eventos in-app S2S não orgânicos e orgânicos, os eventos não orgânicos contêm dados que os eventos in-app não orgânicos não contêm.
Eventos in-app não orgânicos incluem dados sobre a fonte de mídia, campanha, tipo de toque atribuído e hora do toque atribuído.
Eventos in-app orgânicos, por outro lado, seguem uma instalação orgânica. Instalações orgânicas não possuem dados relacionados a campanhas, fonte de mídia, tipo do toque atribuído e hora de instalação.
Mapeamento da ID da AppsFlyer com a ID de usuário cliente (CUID)
A lógica do back-end é necessária para obter valores para preencher o parâmetro. Veja a seguir como você pode obter a ID da AppsFlyer:
- A ID da AppsFlyer é obrigatória e é usada para atribuir eventos.
- É gerada quando um usuário instala o aplicativo móvel pela primeira vez.
- Para que você possa mapear seu CUID para o ID da AppsFlyer, é necessário definir o CUID no aplicativo.
Para que seja mais fácil saber qual usuário executou qual evento, implemente o fluxo abaixo:
- Defina a ID de usuário cliente quando o usuário instalar o aplicativo.
- Os relatórios de dados brutos da AppsFlyer contêm a CUID e a ID da AppsFlyer. Use uma das ferramentas de entrega de dados para obter essa API ou a Push API da AppsFlyer.
- Use os relatórios de dados brutos para combinar a CUID com a ID da AppsFlyer.
- O ID da AppsFlyer está disponível no SDK integrado ao seu aplicativo (Android/iOS).
- Mapeie a ID da AppsFlyer para a ID de usuário cliente em seus sistemas internos (importante para uso futuro).
Depois de mapear a ID da AppsFlyer com sua CUID, você pode associar o usuário aos eventos realizados. Você pode obter os outros valores (valor do evento, moeda do evento, horário do evento etc.) e enviar o evento in-app de servidor para servidor.
Como buscar a ID da AppsFlyer
appsflyer_id
é um parâmetro obrigatório em mensagens de evento de servidor para servidor. A AppsFlyer usa esse parâmetro para atribuir o evento ao dispositivo original e à fonte de mídia atribuída. Você pode obter a ID usando um dos seguintes métodos:
- No dispositivo móvel, chamando a API do SDK da AppsFlyer:
- Na plataforma da AppsFlyer, use um dos seguintes: Pull API Push API,Exportar instalação de dados brutos.
Dica
Ao testar mensagens S2S, se você estiver usando dados brutos, procure o registro com a fonte de mídia "s2s_test". Esse é o seu dispositivo de teste e essa ID de dispositivo AppsFlyer é a ID que você precisa.
Eventos S2S com registro de data e hora
Quando os eventos S2S chegam em massa para a AppsFlyer, eles são carimbados de acordo com seus valores de propriedade eventTime
e hora de chegada. A propriedade eventTime
denota o tempo de ocorrência do evento in-app.
Na chegada, os eventos são marcados com o tempo da seguinte forma:
- Se o parâmetro
eventTime
não estiver incluído no registro do evento, o horário do evento será definido como o horário de chegada da mensagem HTTP. - Os eventos que chegam antes das 02:00 UTC são carimbados com o valor
eventTime
. Ou seja, para que os eventos sejam carimbados comeventTime
, eles devem ser informados no dia do evento ou no dia seguinte até as 02:00 UTC. - Eventos ocorridos no dia anterior ou antes, chegando após 02:00 UTC, são carimbados com a hora de chegada (a hora da chamada da API).
- Eventos chegando com um valor
eventTime
futuro (eventTime > hora de chegada):- Se o
eventTime
relatado e o horário de chegada estiverem no mesmo dia do calendário, o evento será carimbado com o valoreventTime
. - Se o
eventTime
relatado for no próximo dia do calendário, o evento será sinalizado com a hora de chegada.
- Se o
Exemplo
- Um evento é enviado com
eventTime
= Monday 21:00.
Chegou à AppsFlyer | Carimbo de data/hora da AppsFlyer | Observação |
---|---|---|
Terça-feira 01:00 | Segunda-feira 21:00 | Chegou antes do fechamento do negócio. A hora é definida como o valor eventTime . |
Quarta-feira 09:00 | Quarta-feira 09:00 | Chegou após o fechamento do negócio. A hora é definida para a hora de chegada. |
Envio de receitas negativas
Eventos com um valor negativo de receita podem ser enviados. Por exemplo, se uma compra foi cancelada. O parâmetro af_revenue
pode ter valores negativos para registrar isso.
Se você preencher uma af_quantity
, poderá preenchê-la com um valor negativo, dependendo da lógica do sistema. A AppsFlyer não utiliza af_quantity
.
Solução de problemas
Eventos não são exibidos no painel
- Ponto final: verifique se o ponto final usado está correto.
- Verifique se o payload contém os parâmetros obrigatórios. Veja aqui.
- Certifique-se de que o ID da AppsFlyer que você está usando para disparar o evento é um appsflyer_id real e que está realmente instalado no aplicativo específico. Veja aqui.
- Os eventos S2S não oferecem suporte a vários eventos em uma solicitação S2S. Cada evento deve ser enviado como um evento separado.
- Os eventos podem ser enviados com método assíncrono para facilitar o tempo de resposta.
- No painel de visão geral, o período está relacionado à data de instalação do aplicativo (LTV) e não à data do evento.
- Certifique-se de selecionar o período correto.
- Certifique-se de que o período do painel corresponde à data de instalação do dispositivo (appsflyer_id) e não à data do evento.
- Relatórios de dados brutos do evento: o período está relacionado à data do evento e não à data da instalação.
Eventos não contêm receita
Se você enviar eventos S2S, mas sua receita não for registrada: certifique-se de que o JSON que você envia está em formato de sequência. A parte mais importante é o parâmetro do valor do evento no JSON. Deve estar em sequência como mostrado no exemplo a seguir.
"{\"af_revenue\":\"6\" ,\"af_content_type\":\"wallets\"}"
Se não estiver em sequência, o valor do evento não será processado corretamente e a receita não será gravada.
Os valores da receita não devem ser formatados. Eles podem conter um ponto decimal. Não inclua sinais de moeda ou códigos, nem delimitadores como ,
. A receita pode ser precedida por um -
- Os exemplos de valores válidos são:
123
,-123.45
,123.456
- Exemplo de valores ilegais:
1,234.56
,1,234
Nem todos os campos são preenchidos nos eventos S2S
Os campos de dados brutos são preenchidos usando o valor enviado na chamada S2S e alguns campos são preenchidos usando o evento de instalação. Comportamento semelhante, mas não idêntico, é observado para eventos no aplicativo relatados usando o SDK da AppsFlyer. Existem algumas diferenças, como os seguintes campos, que não são preenchidos para eventos S2S:
- WiFi
- Operator
- language
- Modelo do dispositivo
- Categoria de dispositivo
- Versão do aplicativo: você pode usar
app_version_name
- Nome do aplicativo
- Agente do usuário