{"user_id":{"customer_user_id":"15667737-366d-4994-ac8b-653fe6b2be4a"},"event_name":"af_purchase","event_revenue":49.99,"event_revenue_currency":"USD","af_customer_event_id": "550e8400-e29b-41d4-a716-446655440000","event_value":{"af_content_id":"SKU-001","af_quantity":2,"custom_parameters":{"promo_code":"SUMMER10"}},"event_url":"https://example.com/checkout/success","timestamp":1712000000000,"ip":"35.244.183.10","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ...","email_hashed":"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"}

{"user_id":{"appsflyer_id":"1234567890abcdef","customer_user_id":"15667737-366d-4994-ac8b-653fe6b2be4a"},"event_url":"https://example.com/products/sneakers","timestamp":1712000000000,"ip":"35.244.183.10","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...","http_referrer":"https://www.google.com/","email_hashed":"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"}

Uma visita contém os parâmetros de atribuição dos quais todo evento subsequente depende, e o sistema espera uma visita antes de qualquer evento de usuário. Se você envia um evento antes de uma visita, o sistema classifica-o como orgânico.

Como você não usou o Web SDK para definir o cookie afUserId, você mesmo precisa atribuí-lo e gerenciá-lo, como um HTTP cookie definido no cabeçalho da resposta Set-Cookie, e não como um cookie do lado do cliente escrito em JavaScript.

Isso é importante porque um cookie do lado do cliente (definido via document.cookie) expira rapidamente: tão rápido quanto 7 dias no Safari ou 24 horas em domínios sob ITP. Depois que ele expira, o identificador é redefinido, e um visitante recorrente parece novo. Um cookie definido pelo seu servidor não está sujeito a essa limitação e pode permanecer armazenado até o período máximo permitido pelo navegador (o Chrome permite até 400 dias). Também pode ser marcado como HttpOnly, para que os scripts da página e os bloqueadores de anúncios não possam acessá-lo nem removê-lo, e ele não depende da execução de nenhum script na página.

Para configurá-lo e acessá-lo:

1. Na primeira solicitação de um visitante sem cookie, gere um ID estável e único no seu servidor (por exemplo, um UUID).

2. Retorne-o em um cookie first-party:

   Set-Cookie: af_web_id=<generated-id>; Max-Age=34128000; Path=/; Secure; HttpOnly; SameSite=Lax

3. Em cada solicitação posterior, leia o valor do cabeçalho do cookie recebido e reutilize-o. Não o gere novamente.
4. Envie esse valor para a AppsFlyer em todas as chamadas como parte de appsflyer_id do objeto user_id da solicitação.

Você pode nomear o cookie como quiser; a AppsFlyer lê o valor que você envia, não o nome do cookie. Apenas certifique-se de que você o definiu a partir do seu próprio domínio first-party.

Cada chamada precisa de um objeto user_id com pelo menos um appsflyer_id (o valor do cookie) ou customer_user_id (seu ID de usuário interno). O envio de ambos, quando disponíveis, melhora a resolução de identidade.

Lembre-se: as visitas são, em sua maioria, anônimas, por isso sempre envie o valor do cookie. Para eventos no local, adicione o customer_user_id assim que o usuário for identificado e continue enviando o cookie junto a ele. Para eventos que não têm origem no navegador, o customer_user_id único é suficiente, desde que a AppsFlyer já conheça esse usuário de uma sessão identificada anteriormente.

O objeto user_id é obrigatório em cada solicitação. É necessário fornecer pelo menos um dos seguintes identificadores.

Os eventos e visitas devem ser recebidos até, no máximo, 00h30 do dia seguinte, considerando o fuso horário do aplicativo. Eventos enviados com atraso utilizam como referência o horário em que foram recebidos pelo servidor.

Todos os campos de dados pessoais devem ser codificados com hash SHA256 antes do envio. Normalize o texto (convertendo-o para letras minúsculas e removendo os espaços em branco no início e no fim) antes de calcular o hash. Cada hash deve conter exatamente 64 caracteres hexadecimais (sem distinção entre maiúsculas e minúsculas).

• Padrão para todos os campos com hash: ^[a-fA-F0-9]{64}$
• Os números de telefone que utilizam o campo phone_number_e164_hashed devem ser compatíveis com o formato E.164 (por exemplo,+14155552671) antes do hash.

• O parâmetro afUserId é um identificador exclusivo definido pelo Web SDK quando um usuário visita seu site pela primeira vez.
• Se você precisar de afUserId, use um dos métodos a seguir.

Obtenha afUserId do cabeçalho do cookie HTTP

• O afUserId é enviado pelo navegador do visitantes em chamadas para o seu site.
• Extraia-o do cabeçalho do cookie HTTP, se necessário.

Como visualizar o afUserId no navegador do visitante

• Visualize o afUserId no navegador do visitante para solução de problemas e depuração.
• Para que ele esteja disponível, o visitante precisa ter acessado uma página com o Web SDK pelo menos uma vez.
• O cookie que contém afUserId é um cookie first-party em relação ao seu domínio.
• O procedimento a seguir foi preparado usando o Chrome 81. Pode haver diferenças entre navegadores e sistemas operacionais.

Para obter o afUserId do navegador do visitante:

1. No seu navegador, acesse seu site.
2. Clique com o botão direito do mouse e selecione Inspecionar. A janela de inspeção de elementos do navegador é aberta.
3. Vá para a aba (A) Aplicativo.
4. No menu lateral (B), expanda Cookies.
5. Selecione o seu site. Se ele não for exibido, atualize o navegador.
6. No campo (C) Filtro, insira afUserId. O valor de afUserID é exibido.

A AppsFlyer ainda não tem um destino da Segment pré-configurado para a API S2S, então você precisará configurar isso como um destino personalizado na Segment que envie cada evento para o endpoint S2S. Há duas formas de fazer isso, dependendo de quanto controle você precisa sobre o formato dos dados.

Opção 1: destino Webhooks (Actions)

Este é o ponto de partida recomendado. Não requer código, e toda a configuração é feita na interface do usuário da Segment.

Para configurar:

1. Na Segment, adicione o destino Webhooks pelo catálogo de destinos.
2. Conecte-o à fonte que coleta os eventos que você quer enviar.
3. Para cada tipo de evento, crie um mapeamento que defina a URL da AppsFlyer, configure o método como POST, adicione os cabeçalhos obrigatórios e monte o payload JSON com base nos campos do evento.

Opção 2: Destination Function

Use esta opção apenas se o mapeamento do Webhooks não conseguir produzir o formato de payload de que a AppsFlyer precisa. Uma Destination Function é uma pequena função JavaScript executada dentro da Segment, que recebe cada evento e o envia ao endpoint da AppsFlyer usando fetch.

Use esta opção quando:

• O payload precisa de uma estrutura aninhada, por exemplo, colocando user_id dentro de um objeto user, que a interface do usuário de mapeamento do Webhooks não consegue criar.
• Os dados do evento precisam ser transformados antes do envio, como converter um timestamp para um formato diferente.

Independentemente da configuração que você usar, aponte para este endpoint:

POST https://events.appsflyer.com/v2.0/s2s/inapps/app/web/website-{your_domain}

Authorization: Bearer {s2s-token}
Content-Type: application/json

Obtenha sua chave da API S2S na página de gerenciamento de tokens da AppsFlyer (consulte Autenticação). No caminho, use o App ID do aplicativo web (por exemplo, website-www.your_domain), não o UUID do Web SDK ID na página de configurações do aplicativo.

Monte o corpo JSON de cada evento mapeado com estes campos:

{
  "user_id": {
    "customer_user_id": "<your internal user ID>",
    "appsflyer_id": "<afUserId cookie value, when available>"
  },
  "event_name": "signup",
  "event_url": "<page URL where the event happened>",
  "ip": "<end-user IP>",
  "user_agent": "<end-user user agent>",
  "af_customer_event_id": "<Segment messageId>"
}

1. Mantenha o SDK web em execução no site de marketing: ele registra as visitas, e o Segment encaminha os eventos. Como explicado na introdução desta seção, um usuário precisa de uma visita antes de um evento, ou o evento será atribuído como orgânico. Se você quiser uma configuração totalmente do lado do servidor, sem nenhum SDK web, siga Configurar uma integração totalmente do lado do servidor.
2. Cada chamada também precisa dos identificadores corretos: envie a mesma combinação de appsflyer_id ou customer_user_id descrita em Enviar os identificadores corretos em cada chamada.

Quando o destino e o payload estiverem prontos, faça a implementação em três etapas:

1. Mapeie um ou dois eventos no Segment (o evento de cadastro é um bom primeiro candidato) e envie um evento de teste pelo testador de mapeamento.
2. Verifique se eles chegam corretamente no relatório bruto e correspondem à visita no site de marketing.
3. Depois da confirmação, expanda o mapeamento para os eventos restantes.

Quando o destino e o payload estiverem prontos, faça a implementação em três etapas:

1. Mapeie um ou dois eventos no Segment (o evento de cadastro é um bom primeiro candidato) e envie um evento de teste pelo testador de mapeamento.
2. Verifique se eles chegam corretamente no relatório bruto e correspondem à visita no site de marketing.
3. Depois da confirmação, expanda o mapeamento para os eventos restantes.