API de eventos de servidor para servidor para dispositivos móveis (S2S-mobile)

Visão geral: Envie eventos dos seus servidores para a AppsFlyer para monitorizar eventos móveis que ocorrem fora da aplicação.

altS2S_us-en.pngalt

API de eventos de servidor para servidor para dispositivos móveis

Para aplicações iOS, a partir do iOS 14, deve enviar o parâmetro do sistema operativo (os). 

A plataforma AppsFlyer atribui e regista eventos de aplicações móveis enviados tanto pelo SDK da AppsFlyer como por APIs. Use a API S2S para reportar eventos que ocorrem fora da aplicação, como quando um utilizador renova a sua subscrição através da sua interface web. Os eventos S2S, uma vez registados, estão disponíveis em toda a plataforma, incluindo dashboards, dados brutos e análises. Para eventos web PBA, veja Web S2S para PBA.

A AppsFlyer completa os eventos S2S com:

  • Valores enviados na mensagem S2S
  • Alguns valores de atribuição de instalação da AppsFlyer, como o momento da instalação e a fonte de média.

Para enviar eventos via API, peça ao seu programador para seguir as instruções da API de eventos de servidor para servidor.

Preenchimento de parâmetros

Diferença entre orgânico e não orgânico

Quando a AppsFlyer processa eventos S2S na aplicação, os campos de atribuição são preenchidos utilizando o ID da AppsFlyer para identificar o evento de instalação associado que ocorreu antes dos eventos na aplicação.

Isto significa que alguns dados que a AppsFlyer associa a eventos in-app S2S não orgânicos não são associados a eventos in-app S2S orgânicos.

Exemplo

Por exemplo, ao comparar relatórios de dados brutos de eventos in-app S2S não orgânicos e orgânicos, os eventos não orgânicos conterão dados que os orgânicos não têm.

Os eventos não orgânicos na aplicação incluem informações sobre fonte de média, campanha, tipo de toque atribuído e tempo de toque atribuído.

Os eventos orgânicos na aplicação, por outro lado, estão ligados a uma instalação orgânica. As instalações orgânicas não incluem dados relacionados com campanha, fonte de média, tipo de toque atribuído e momento da instalação.

Mapeamento do ID da AppsFlyer com o ID do utilizador do cliente (CUID)

É necessário lógica de backend para obter os valores necessários para preencher o parâmetro. Segue-se uma descrição de como pode obter o ID da AppsFlyer:

  • O ID da AppsFlyer é um requisito essencial e é utilizado para atribuição de eventos.
  • Este é gerado quando um utilizador instala a aplicação móvel pela primeira vez.
  • Para mapear o seu CUID com o ID da AppsFlyer, é necessário definir o CUID na aplicação. 

Para facilitar a identificação do utilizador responsável por cada evento, implemente o fluxo seguinte:

  • Defina o ID do utilizador do cliente no momento da instalação da aplicação.
  • Os relatórios de dados brutos da AppsFlyer incluem o CUID e o ID da AppsFlyer. Utilize uma das ferramentas de entrega de dados para obter esta informação ou use a API Push da AppsFlyer. 
  • Utilize os relatórios de dados brutos para correlacionar o CUID com o ID da AppsFlyer. 
  • O ID da AppsFlyer está disponível no SDK integrado na sua aplicação (Android/iOS).
  • Associe o ID da AppsFlyer ao ID do utilizador do cliente nos seus sistemas internos (é importante para uso futuro).

Depois de mapear o ID da AppsFlyer com o seu CUID, pode vincular o utilizador aos eventos realizados. Pode então obter outros valores (como valor do evento, moeda do evento, hora do evento, etc.) e enviar o evento da aplicação no servidor para o servidor.

Obtenção do ID da AppsFlyer

appsflyer_id é um parâmetro obrigatório em mensagens de eventos de servidor para servidor. A AppsFlyer utiliza este parâmetro para atribuir o evento ao dispositivo original e à fonte de mídia atribuída. Pode obter o ID através de um dos seguintes métodos:

Carimbo de tempo Eventos S2S

altdiagrama lógico de carimbo de tempoalt

Quando os eventos S2S chegam em massa à AppsFlyer, recebem uma marcação de data/hora baseada nos seus valores da propriedade eventTime e na hora de chegada. A propriedade eventTime indica o momento em que o evento ocorreu na aplicação.

Ao chegar, os eventos são marcados com a hora da seguinte maneira:

  • Se o parâmetro eventTime não estiver incluído no registo do evento, a data/hora do evento será definida como a hora de chegada da mensagem HTTP.
  • Os eventos que chegam antes das 02:00 UTC recebem a marcação com o valor eventTime. Ou seja, para que os eventos sejam marcados com eventTime, 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 depois das 02:00 UTC são marcados com a hora de chegada (hora da chamada API).
  • Eventos que chegam com um valor eventTime futuro (eventTime > hora de chegada):
    • Se o eventTime relatado e a hora de chegada forem no mesmo dia do calendário, o evento é marcado com o valor eventTime.
    • Se o eventTime relatado for no 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 = segunda-feira às 21:00.
Chegou à AppsFlyer Marca de tempo da AppsFlyer Observação
Terça-feira 01:00 Segunda-feira 21:00 Chegou antes do encerramento do dia. O tempo é definido com o valor eventTime.
Quarta-feira 09:00 Quarta-feira 09:00 Chegou após o encerramento do dia. A hora é definida como a hora de chegada.

Envio de receita negativa

Podem ser enviados eventos com valor de receita negativo. Por exemplo, se uma compra for cancelada. O parâmetro af_revenue pode assumir valores negativos para registar este tipo de situação. 

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

Aumentar o volume de transações de dados

Ao utilizar o escalonamento gradual, a AppsFlyer pode suportar um elevado volume de transações por segundo (TPS) através de soluções de auto-escalonamento. Por exemplo:

  • Inicie com 10 mil transações por segundo (TPS) e aumente gradualmente, com base em intervalos mínimos de 1 minuto.
    • 00:00:00 - enviar 10 mil TPS (valor base)
    • 00:01:00 - aumentar para 12 mil TPS
    • 00:02:00 - aumentar para 14 mil TPS
    • 00:03:00 - aumentar para 16 mil TPS
    • 00:04:00 - aumentar para 18 mil TPS
  • Implemente um mecanismo de reintento para ser utilizado ao receber erros.

Resolução de problemas

Os eventos não estão a ser exibidos no painel

  • 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 ID da AppsFlyer que está a utilizar para acionar o evento é um appsflyer_id real e está relacionado a uma instalação real de uma aplicação. Consulte aqui.
  • Os eventos S2S não suportam múltiplos eventos num único pedido S2S. Cada evento deve ser enviado separadamente.
    • Os eventos podem ser enviados de forma assíncrona para melhorar o tempo de resposta.
  • No painel de resumo, a faixa de datas refere-se à data de instalação da aplicação (LTV) e não à data do evento.
    • Assegure-se de selecionar o período correto.
    • Certifique-se de que a faixa de datas do painel corresponde à data de instalação do dispositivo (appsflyer_id) e não à data do evento.
  • Nos relatórios de dados brutos de eventos, a faixa de datas refere-se à data do evento e não à data de instalação. 

Os eventos não contêm receita

Se enviar eventos S2S, mas a receita não for registada, certifique-se de que o JSON que envia está em formato string. A parte mais importante é o parâmetro de valor do evento no JSON. Deve ser transformado em string conforme mostrado no exemplo a seguir.

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

Se não estiver em formato string, o valor do evento não será processado corretamente e a receita não será registada.

Os valores de receita não devem ser formatados de nenhuma forma. Podem conter um ponto decimal. Não inclua símbolos ou códigos de moeda nem delimitadores ,. A receita pode ser precedida por um -.

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

Nem todos os campos são preenchidos em eventos S2S.

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 API S2S 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 da aplicação: Pode utilizar app_version_name.
  • Nome da aplicação
  • Agente do utilizador

Os eventos S2S na aplicação são incorretamente atribuídos como orgânicos.

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

Recomendamos um pequeno atraso antes de reportar eventos S2S na aplicação que ocorrem imediatamente após a instalação nos nossos servidores.