Requisitos de Integração de Dados

Público-alvo

Este artigo é para a equipe técnica responsável por configurar a integração dos seus dados de eventos. Ele cobre o seguinte:

• Os eventos necessários para usar a Inteligência Xtremepush

• Como as categorias de eventos se mapeiam para o modelo de Inteligência

• Como se preparar antes do início da etapa de mapeamento de dados

Para o processo de integração e o cronograma, veja a Visão Geral da Configuração. Para mecânicas de integração, veja a seção Escolhendo seu método de integração abaixo.

O que a Inteligência precisa dos seus dados

A inteligência classifica cada evento que vem em duas coisas:

1. Categoria: Domínio comercial do evento (cassino, esportes, bingo, depósito, e assim por diante)

2. Quatro extrações de carga útil: Os valores específicos necessários para calcular métricas: valor monetário, chave de transação, indicador de dinheiro real vs. bônus e dimensão do item

A categoria é determinada durante a etapa de mapeamento de dados com base nos nomes e estrutura dos seus eventos. Os quatro extratos são campos que você precisa garantir que estejam presentes nos seus payloads de eventos.

Categorias de eventos suportadas

O Xtremepush mapeia seus eventos existentes para as categorias abaixo durante a etapa de mapeamento de dados.

Categorias que exigem um par de débito e crédito (cassino, esporte, bingo) precisam que tanto o evento de aposta quanto o evento de pagamento ou liquidação sejam enviados, cada um com a mesma chave de transação, para que o cálculo do GGR funcione.

Classificação subvertical

Cassino é uma única categoria que abrange vários tipos de jogo. Não existe uma categoria separada para dealer ao vivo, esportes virtuais ou jogos de mesa, todos eles são enviados como casino eventos. Use o campo de itens (nome do jogo ou código do jogo) para carregar o detalhe subvertical.

Isso significa que um único stream de evento de cassino cobre todo o seu produto de cassino. O campo de itens é o que alimenta a análise por jogo nos conjuntos de dados pré-construídos.

As quatro extrações necessárias de carga útil

Para que a Inteligência calcule GGR, métricas de depósito e outros agregados, quatro informações devem estar presentes dentro do objeto do value evento. Os nomes dos campos são específicos do cliente, a Inteligência corresponde ao que seu sistema usar, mas todos os quatro devem estar presentes para cobertura total da métrica.

1. Valor monetário

O valor do stake ou pagamento como um valor numérico.

• Eventos de débito de cassino / esportes / bingo: o valor da aposta ou do valor do stake

• Eventos de crédito em cassino / esportes / bingo: o valor do pagamento ou do pagamento

• Depósitos: o valor do depósito

• Saques: o valor do saque

2. Chave da transação

Um identificador único que vincula uma aposta ao seu pagamento correspondente. A mesma chave deve aparecer tanto no evento de débito (aposta feita) quanto no evento de crédito (pagamento ou liquidação). É isso que torna possível o cálculo do GGR.

• Para cassino: normalmente um ID de rodada, ID de sessão de jogo ou ID de aposta

• Para esportes: a referência da aposta ou ID de liquidação

• Para bingo: o ID da atividade do jogo ou ID do ticket

• Para depósitos e saques: o ID da transação ou do livro razão

Se seus eventos de aposta e pagamento usarem identificadores diferentes, sinalize isso durante a etapa de mapeamento de dados, existem opções para lidar com isso.

3. Distinção entre dinheiro real e bônus

A inteligência acompanha o dinheiro real e o jogo bônus separadamente. Sem isso, o GGR será superestimado pelas apostas bônus e não pode ser corrigido retroativamente.

Não há um nome de campo obrigatório para isso, Inteligência corresponde ao mecanismo que sua plataforma já utiliza. As abordagens comuns são:

• Um campo booleano ou de status no evento: por exemplo, um campo que indica se a aposta usou fundos reais ou um bônus. Se esse campo já existir nos seus dados sob qualquer nome, a equipe de dados irá mapeá-lo.

• Nomes separados de eventos: se sua plataforma lançar nomes diferentes para atividades em dinheiro real vs. bônus (por exemplo, uma aposta real e uma aposta grátis como tipos distintos de evento), esses podem ser mapeados independentemente.

• Um tipo ou campo de origem com valores distinguíveis: por exemplo, um campo que indica método de pagamento ou tipo de carteira, onde apostas bônus têm um valor consistentemente identificável.

Se seus dados atualmente não distinguem dinheiro real de atividade de bônus de nenhuma dessas formas, você precisará adicionar um indicador antes que a integração seja ativada. Qualquer campo consistente e consultável funciona, o nome específico não importa. Sinalize isso durante a etapa de mapeamento de dados e a equipe aconselhará sobre a abordagem mais simples para sua plataforma.

4. Dimensão do item

O nome do jogo, nome do esporte ou sala de bingo a que o evento se refere. Este campo é opcional no sentido de que omiti-lo não quebra as métricas principais, mas é obrigatório se você quiser:

• Análise de cassino por jogo nos conjuntos de dados pré-construídos

• Distribuição de apostas por esporte

• Análise de bingo por sala

Envelope de eventos

Tanto a API REST quanto a integração com Kafka usam a mesma estrutura. O value objeto carrega todas as propriedades específicas de evento, a Inteligência lê dos campos que você usa dentro dele.

Os nomes dos campos dentro value são ilustrativos, seu sistema usará os nomes que já existem na sua carga útil. A etapa de mapeamento de dados estabelece como cada campo se mapeia para Inteligência.

Exemplo: evento de aposta em cassino

{
  "event": "casino_bet",
  "user_id": "player_12345",
  "timestamp": "2024-06-01 14:32:00.000",
  "value": {
    "stake": 5.00,
    "round_id": "rnd_abc789",
    "game_name": "Starburst",
    "is_real_money": true
  }
}

Stake é o valor monetário, round_id é a chave de transação, game_name é a dimensão do item, is_real_money é o indicador bônus, usando os nomes de campo próprios deste cliente.

Exemplo: evento de apostas esportivas

{
  "event": "sports_wager",
  "user_id": "player_12345",
  "timestamp": "2024-06-01 14:35:00.000",
  "value": {
    "wager_amount": 20.00,
    "bet_id": "bet_xyz456",
    "sport": "Football",
    "is_free_bet": false
  }
}

wager_amount é o valor monetário, bet_id é a chave da transação, o esporte é a dimensão do item is_free_bet é o indicador bônus.

Estrutura de eventos bônus

Eventos bônus suportam uma subcategoria para indicar a qual vertical o bônus está vinculado. Isso permite a atribuição de bônus por vertical nas suas análises.

As subcategorias são configuradas durante a etapa de mapeamento de dados e não exigem alterações no esquema do seu evento.

Eventos não transacionais

Os seguintes tipos de eventos podem ser enviados e irão fluir para o armazenamento de eventos de Inteligência, mas não alimentam atributos computados dos jogadores (GGR, depósitos, métricas de aposta):

Esses eventos são válidos e úteis para segmentação de campanha via condições brutas de evento, mas não aparecerão no seu total de GGR, depósito ou apostas.

Escolhendo seu método de integração

A API REST e as integrações Kafka usam a mesma estrutura de envelope de eventos, o value conteúdo dos objetos é idêntico independentemente do transporte que você use.

Lista de verificação pré-integração

Preencha o formulário de mapeamento de dados fornecido pela equipe da sua conta antes ou durante a integração. O formulário cobre as perguntas abaixo. Ter respostas claras acelera significativamente a etapa de mapeamento dos dados.

Cobertura de eventos

• Quais nomes de eventos no seu sistema correspondem a cada categoria de Inteligência (aposta em cassino, aposta esportiva, aposta no bingo, depósito, saque, bônus concedido, bônus usado)?

• Você envia eventos separados para aposta e pagamento/liquidação, ou um evento único?

• Você tem o bingo como produto? Se sim, quais nomes de eventos cobrem apostas e pagamentos de bingo?

Conteúdo da carga útil

• Qual nome de campo contém o valor monetário (valor do stake, valor do pagamento, valor do depósito)?

• Qual é o nome do seu campo da chave de transação, o ID que aparece tanto na aposta quanto no pagamento?

• Como diferenciar dinheiro real de eventos bônus, um campo de bandeira, nomes separados de eventos ou outra abordagem?

• Qual campo carrega o nome do jogo, o nome do esporte ou a sala de bingo?

Disponibilidade de dados

• Existem dados históricos de eventos? Se sim, de que data?

• Existem lacunas conhecidas em dados históricos (migrações de plataforma, mudanças de esquema)?