Catálogo unificado de eventos

Esta página é o mapa canônico de todos os eventos que o front rastreia, organizados por fase do funil com a matriz de destinos (quem recebe o quê). Substitui o antigo eventos-gtm.md (que listava apenas o canal GTM).

Fonte de verdade

Type registry: repos/front-web-base/app/analytics/events.ts — discriminated union de todos os eventos. Adicionar evento novo = uma variant aqui.
Matrix: repos/front-web-base/app/analytics/destinations.ts — mapa EventId → DestinationMap. Marketing pede destino novo num evento existente = uma linha aqui.
Dispatcher: repos/front-web-base/app/analytics/dispatch.ts — fan-out engine. Lê a matriz e chama os adapters non-null.

Princípios

Front mapeia o que o front observa. Eventos backend-only (pix paid via webhook PSP, bet placed via game iframe webhook, dormant detection via cron) NÃO estão aqui — vão pra Contract BFF.
Adicionar um destino é uma linha na matriz. Se a Meta quer receber viewed_casino como ViewContent, marketing pede e dev troca meta_pixel: null por meta_pixel: { name: "ViewContent", payloadFn: ... }.
Dispatch é exhaustivo at compile time. TypeScript erra se evento novo entra no registry sem destino mapeado.

Canais de destino (10 hoje)

Canal	Como é dispatched	Status
`gtm`	`dataLayer.push({ event, ... })`	✅ Ativo (todas as brands com `gtmId`)
`meta_pixel`	`fbq("track", name, params)`	✅ Ativo (brands com `pixelId`)
`kwai`	`kwaiq.instance(id).track(name)`	✅ Ativo (brands com `kwaiPixelId`)
`taboola`	`_tfa.push({ notify: "action", name })`	✅ Ativo (brands com `taboolaId`)
`tiktok_pixel`	`ttq.track(name, params)` direto	🟡 Hoje só via GTM custom HTML (matriz desligada por enquanto pra evitar duplicidade)
`mixpanel`	`mixpanel.track(name)`	🟡 Hoje chamado direto no `useAnalytics` (matriz desligada durante transição)
`smartico`	SDK próprio	🟡 Fluxo separado
`webtrends`	A/B testing	🟡 Fluxo separado (não consome eventos)
`audience_cookie`	`addAudienceTag(name)` no `<rmkBrand>_aud`	✅ Ativo (brands com remarketing flag)
`bff_capi`	`external_id` no body de signup/deposit pro BFF	🟡 Roadmap (depende do BFF — ver Contract BFF)

Mapa por fase do funil

A. Pré-cadastro (visitor anônimo)

Evento	Trigger no front	Destinos ativos
`page_view`	toda navegação SPA	gtm, meta_pixel (PageView), kwai (contentView)
`view_modal_login`	abrir modal de login	gtm
`view_modal_cadastro`	abrir modal de cadastro	gtm
`viewed_casino`	rota sob `casino`	audience_cookie
`viewed_live_casino`	rota `casino.live`	audience_cookie
`viewed_game_detail`	rota `casino.play`	audience_cookie
`viewed_sports`	rota sob `sports`	audience_cookie
`viewed_promotions`	rota sob `promotions`	audience_cookie
`played_demo` 🆕	clique no botão "Demo" no `GameIframe`	gtm, audience_cookie
`clicked_register`	abertura do modal de register	audience_cookie
`started_register` 🆕	user digita em email/document do modal	gtm, audience_cookie
`abandoned_register`	modal fecha sem auth completa	audience_cookie
`viewed_app_install_banner` 🆕	banner PWA/APK aparece (surface: footer hoje)	gtm, audience_cookie
`scrolled_to_payment_seals` 🆕	viewport hit nos seals do footer (após scroll)	gtm, audience_cookie

B. Pós-cadastro / pré-FTD

Evento	Trigger no front	Destinos ativos
`sign_up`	BFF `/auth/register` retornou OK	gtm, meta_pixel (Lead), kwai (completeRegistration), taboola, bff_capi
`login`	BFF `/auth/login` retornou OK	gtm
`registered`	modal de register fechou + auth bem-sucedida	audience_cookie
`viewed_deposit_modal`	abertura do modal de deposit	audience_cookie
`abandoned_deposit`	modal de deposit fecha (sempre — set-once)	audience_cookie
`home_deposit_login`	clique no CTA de deposit (logado)	gtm
`home_deposit_register`	auto-open de deposit pós-register	gtm
`deposit_initiated`	submit do form de deposit	gtm (pix_generated/astropayDeposit/etc), meta_pixel (PixGenerated custom)

C. Pós-FTD / engajado

Evento	Trigger no front	Destinos ativos
`deposit_confirmed`	polling do BFF retorna `approved`	gtm (pix_confirmado/pix_confirmado_ftd)
`first_deposit`	quando `deposit_confirmed.isFirstDeposit === true`	gtm, meta_pixel (Purchase), kwai (purchase), taboola, bff_capi
`second_deposit`	quando `deposit_confirmed.isFirstDeposit === false`	gtm
`purchase`	versão legacy do FTD (compat)	gtm, meta_pixel (Purchase), kwai (purchase), taboola
`ftd_completed`	derivado de `first_deposit`	audience_cookie
`multi_deposit`	derivado de `second_deposit`	audience_cookie
`withdraw`	submit do form de saque	gtm (`saque`)

Behavior

Evento	Trigger no front	Destinos ativos
`search`	submit de busca (jogo ou esporte)	gtm
`view_game_page`	abrir página de detalhe do jogo	gtm
`game_page_deposit`	clique em deposit dentro do iframe do jogo	gtm

Ecommerce (GA4 + interno)

Evento	Trigger no front	Destinos ativos
`view_item_list`	seção entra no viewport (interno)	gtm
`view_item_list_ga4`	seção entra no viewport (GA4 ecommerce padrão)	gtm
`select_item`	clique num card de jogo	gtm
`view_promotion`	banner/promoção entra no viewport	gtm
`select_promotion`	clique no banner/promoção	gtm

🆕 = adicionado na refatoração do registry (2026-05).

Como adicionar evento novo

Caso 1 — evento novo que o front pode observar

Adiciona a variant em app/analytics/events.ts (AnalyticsEvent).
Adiciona o ID no array ANALYTICS_EVENT_IDS (TS força — vai erra se faltar).
Adiciona a phase em EVENT_PHASE.
Adiciona entrada em app/analytics/destinations.ts (DESTINATIONS) com cada canal explicit (null ou slot).
No componente que observa o trigger, importa pushMetricEvent de ~/utils/metrics/index e chama pushMetricEvent({ type: "...", ...payload }).
Atualiza esta tabela.

Caso 2 — destino novo num evento existente

Marketing pede "agora viewed_casino também vai pra Meta como ViewContent":

// destinations.ts
viewed_casino: {
  // ...outros canais
  meta_pixel: { name: "ViewContent" }, // ← era null
  // ...
}

Adapter pushFacebookEvent precisa de uma case pra viewed_casino se o payload for não-trivial — quando vazio (fbq("track", "ViewContent") direto), basta destravar a matriz. Adiciona case em app/utils/metrics/facebook.ts.

Caso 3 — evento backend-only

Não vai pra cá. Vai pra Contract BFF. Front não vê.

User fields enriquecidos (em todos os eventos GTM)

Todos os eventos GTM são enriquecidos automaticamente via gtmUserParams(user):

{
  // base do evento
  event: "first_deposit",
  user_id: "12345",
  // ...

  // user fields injetados
  user_email: "user@example.com",
  user_phone: "+5511999999999",
  user_first_name: "João",
  user_last_name: "Silva",
  user_dob: "1990-01-01",
  affiliate_btag: "AFIL1",
}

Permite tags GTM enviarem Enhanced Conversions (hashed PII) pro Google Ads / Meta CAPI / TikTok Events API (quando configuradas).

Schema customizável por brand (renomear no GTM)

O analyticsSchemaConfig continua existindo e brands podem renomear nomes de evento GTM:

{
  events: {
    firstDeposit: "first_deposit",     // ← pode ser "ftd_legacy" em brand específica
    pixGenerated: "pix_generated",     // ← pode ser "pix_brl_v2" em outra
  }
}

Útil pra GTM containers legacy (7k, etc) com triggers já configurados em event names específicos. Renomeação acontece no adapter GTM — outros canais (Meta, Kwai, Taboola) usam os nomes da matriz direto.

Como debuggar

dataLayer manual

window.dataLayer.filter(e => e.event === "first_deposit")
window.dataLayer.filter(e => e.event === "rmk_audience_tag")

DevTools → Application → Cookies → <rmkBrand>_aud (JSON com tags).

Console em dev

window.__rmk
// → { id: "...", ts: ..., tags: [...], ... }

Pixel helpers

Anti-patterns

Adicionar evento custom só no GTM tag. Sem entry no registry, o front nunca dispara.
Mudar nome de evento sem atualizar GTM. Quebra trigger no container — eventos viram silenciosos.
Disparar Purchase em deposit_initiated. Infla conversão (depósito gerado mas não pago vira Purchase). A matriz já segrega — deposit_initiated só vai pra GTM + Meta (PixGenerated custom). Purchase real vem de first_deposit/purchase.
Logar PII em campo não-hashado direto no dataLayer. Use Enhanced Conversions / hashed values.
Adicionar case num adapter sem atualizar a matriz. Adapter dispara mesmo se matriz disser null na ordem dos eventos. Usa o registry como SoT.
Esquecer da matriz quando declarar evento novo. TS pega — Record<AnalyticsEventId, DestinationMap> força exhaustividade.

Histórico

2026-05 — Migração pro registry unificado. MetricEvent virou alias de AnalyticsEvent. Audience tags do RemarketingCapture passam pelo registry. 4 flags MVP novas (played_demo, started_register, viewed_app_install_banner, scrolled_to_payment_seals). Doc reescrita pra refletir matriz multi-canal.
Anterior — Doc cobria apenas GTM (mapeamento legacy 7k Vue → React 19).

Fonte de verdade​

Princípios​

Canais de destino (10 hoje)​

Mapa por fase do funil​

A. Pré-cadastro (visitor anônimo)​

B. Pós-cadastro / pré-FTD​

C. Pós-FTD / engajado​

Behavior​

Ecommerce (GA4 + interno)​

Como adicionar evento novo​

Caso 1 — evento novo que o front pode observar​

Caso 2 — destino novo num evento existente​

Caso 3 — evento backend-only​

User fields enriquecidos (em todos os eventos GTM)​

Schema customizável por brand (renomear no GTM)​

Como debuggar​

dataLayer manual​

Audience cookie​

Console em dev​

Pixel helpers​

Anti-patterns​

Histórico​