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

Visão geral: envie eventos de seus servidores para a AppsFlyer para mensurar eventos mobile que ocorrem fora do aplicativo.

S2S_us-en.png

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:

 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 com eventTime, 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 valor eventTime.
    • Se o eventTime relatado for no próximo dia do calendário, o evento será sinalizado com a hora de chegada.

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.45123.456 
  • Exemplo de valores ilegais: 1,234.561,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