API de eventos de servidor para servidor (S2S mobile) para mobile

Quando a AppsFlyer processa eventos in-app S2S, os campos de atribuição são preenchidos usando o AppsFlyer ID para identificar o evento de instalação anterior aos eventos in-app.

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.

A lógica do backend é necessária para obter os valores e preencher o parâmetro. Veja a seguir como você pode obter o AppsFlyer ID:

• O AppsFlyer ID é obrigatório e é usado para atribuir eventos.
• Ele é gerado quando um usuário instala o aplicativo mobile pela primeira vez.
• Para mapear o seu CUID com AppsFlyer ID, você deve definir o CUID no aplicativo. 

Para que seja mais fácil saber qual usuário executou qual evento, implemente o fluxo abaixo:

• Defina o customer user ID quando o usuário instalar o aplicativo.
• Os relatórios de dados brutos da AppsFlyer contêm o CUID e o AppsFlyer ID. Use uma das ferramentas de entrega de dados para obter essa informação ou use a Push API da AppsFlyer. 
• Use os relatórios de dados brutos para combinar o CUID com o AppsFlyer ID. 
• O AppsFlyer ID está disponível no SDK integrado ao seu aplicativo (Android/iOS).
• Mapeie o AppsFlyer ID para o customer user ID em seus sistemas internos (importante para uso futuro).

Depois de mapear o ID da AppsFlyer com o seu 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.

appsflyer_id é um parâmetro obrigatório em mensagens de eventos 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 o ID usando um dos seguintes métodos:

• No dispositivo mobile, chame a AppsFlyer SDK API:
  Android nativeiOS nativeUnityReact Native

  getAppsFlyerUID

  getAppsFlyerUID

  getAppsFlyerId

  getAppsFlyerUID

• Na plataforma AppsFlyer, usando uma dessas opções: Pull API, Push API, Export raw data installation.

Quando os eventos S2S chegam em massa à AppsFlyer, eles recebem um timestamp de data/hora com base nos seus valores da propriedade eventTime e na hora de chegada. A propriedade eventTime indica o momento em que o evento ocorreu no aplicativo.

Na chegada, os eventos são marcados com a hora da seguinte forma:

• Se o parâmetro eventTime não estiver incluído no registro do evento, a data/hora do evento será definida como a hora de chegada da mensagem HTTP.
• Eventos que chegam antes das 02:00 UTC recebem o timestamp com o valor eventTime. Ou seja, para que os eventos sejam marcados com eventTime, eles devem ser reportados no próprio dia do evento ou no dia seguinte até às 02:00 UTC.
• Eventos que ocorreram no dia anterior ou antes, e chegam após 02:00 UTC, são carimbados com a hora de chegada (a hora da chamada da API).
• Eventos que chegam com um valor eventTime futuro (eventTime > hora de chegada):
  • Se o eventTime relatado e a hora de chegada forem o mesmo dia do calendário, o evento é marcado com o valor eventTime.
  • Se o eventTime relatado for o dia seguinte, o evento é marcado com a hora de chegada.
• Os eventos com valor eventTime inválido recebem a marcação com a hora de chegada da mensagem HTTP.

Exemplo

• Um evento é enviado com eventTime = Monday 21:00.

Eventos com um valor de receita negativo podem ser enviados. Por exemplo, se uma compra for cancelada. O parâmetro af_revenue pode assumir valores negativos para registrar esse tipo de situação. 

Se você preencher af_quantity, poderá optar por introduzir um valor negativo conforme a lógica do seu sistema. A AppsFlyer não utiliza af_quantity.

• Endpoint: Verifique se o endpoint utilizado está correto.
• Verifique se o payload contém os parâmetros obrigatórios. Consulte aqui.
• Certifique-se de que o AppsFlyer ID que você está usando para disparar o evento é um appsflyer_id real e que de fato corresponde a uma instalação do aplicativo. Consulte aqui.
• Os eventos S2S não oferecem suporte a vários eventos em uma solicitação S2S. Cada evento deve ser enviado separadamente.
  • Os eventos podem ser enviados com método assíncrono para melhorar o tempo de resposta.
• No dashboard de visão geral, o período de datas mostrado 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 mostrado no dashboard corresponde à data de instalação no dispositivo (appsflyer_id) e não à data do evento.
• Relatórios de dados brutos do evento: o período mostrado está relacionado à data do evento e não à data da instalação. 

Se você enviar eventos S2S, mas sua receita não for registrada, certifique-se de que o JSON que você enviou está em formato de string. A parte mais importante é o parâmetro do valor do evento no JSON. Ele deve estar em strings, como mostrado no exemplo a seguir.

"{\"af_revenue\":\"6\" ,\"af_content_type\":\"wallets\"}"

Se não estiver em formato de strings, 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 de forma alguma. Eles podem conter um ponto decimal. Não inclua sinais de moeda ou códigos nem delimitadores como ,. A receita pode ser prefixada por um -.

• Exemplos de valores válidos: 123, -123.45, 123.456. 
• Exemplos de valores inválidos: 1,234.56, 1,234.

Os campos de dados brutos são preenchidos exclusivamente com os valores enviados na chamada S2S (ao contrário dos campos de postback, que podem ser preenchidos com valores do evento de instalação).

Os seguintes campos não podem ser reportados através da S2S API e, portanto, não são preenchidos para eventos S2S em relatórios de dados brutos:

• WIFI
• Operador
• Idioma
• Modelo do dispositivo
• Categoria do dispositivo
• Versão do aplicativo: você pode usar app_version_name.
• Nome do aplicativo
• User Agent

Os eventos S2S, como os de início de sessão, podem chegar à AppsFlyer logo que o aplicativo é instalado e o é SDK iniciado. No entanto, se esses eventos chegarem antes da AppsFlyer concluir o processamento do evento de instalação, que geralmente demora 20 a 30 segundos ou mais, eles podem ser marcados como eventos orgânicos não atribuídos.

Recomendamos um pequeno atraso antes de reportar aos nossos servidores eventos in-app S2S que ocorrem imediatamente após a instalação.