Session Replay

Gravação pixel-perfect da sessão do jogador via rrweb. Opt-in, sample-based, com masking by default.

Tipo 2 — disponível em beta v2. Chunk lazy-loaded sdk-replay.min.js (~60 KB gzipped, carregado apenas se a sessão for amostrada). Bundle core permanece em ~9 KB. Sem rrweb-player no SDK — replay vive no Dashboard Atlas.

O que é

O Session Replay captura cada interação do jogador (DOM mutations, clicks, scroll, inputs mascarados) e reconstrói a sessão como vídeo no Dashboard Atlas. Use para:

• Investigar fraude / abuse (sequência exata até o evento)
• Debug de UX em /deposito, /saque, /kyc (etapas que estão travando)
• Treinar atendimento (CRM revê última sessão antes do chamado)
• Análise de funil qualitativa (por que jogadores abandonam após cadastro?)

Diferenças vs Tipo 1 (eventos comportamentais)

	Tipo 1 (events)	Tipo 2 (Session Replay)
O que captura	Eventos discretos (page.viewed, rage.click)	Stream contínuo de DOM + interações
Bundle	~9 KB gzip (core)	+60 KB gzip (chunk lazy)
Endpoint	POST /v1/sdk-events	POST /v1/sdk-replay-snapshots
Storage	Kafka atlas.sdk-events + ClickHouse tbt_sdk_events	Cloudflare R2 (blob) + ClickHouse tbt_sdk_replay_events (metadados)
Sampling default	100% (tudo)	10% (sampleRate: 0.1)
Retenção	90 dias	7 dias (Growth) / 30/90/180 dias (Compliance)
Custo	Incluso no plano	~$1.40/mês por 150k DAU
Player	Charts no Dashboard	rrweb-player no Dashboard

Ativação

1. Adicionar bloco sessionReplay no init

   window.iGamingSDK.init({
     organizationId: 'org_SEU_ID',
     brandId:        'brand_SEU_ID',
     endpoint:       'https://ingest.atlas.io/v1/sdk-events',
     sessionReplay: {
       enabled:    true,
       sampleRate: 0.1,                              // 10% das sessões
       endpoint:   'https://ingest.atlas.io/v1/sdk-replay-snapshots',
       minimumDurationMs: 5000,                      // descarta replays <5s
       masking: { maskAllInputs: true }              // default — sempre on
     }
   });
   
2. Verificar no DevTools

   Recarregue a página em modo anônimo. Em 10% das sessões deve aparecer:

   • sdk-replay.min.js baixado após o core (lazy)
   • POST /v1/sdk-replay-snapshots a cada ~10s (status 202)
   • Evento replay.started em /v1/sdk-events no canal Tipo 1
3. Cruzar com Tipo 1 no Dashboard

   Dashboard → Web Analytics → Replays → filtrar por user_ext_id ou distinct_id. Listagem mostra duração + último URL + eventos críticos (rage clicks, errors) embedded.

Ciclo de vida (13 fases)

O recorder passa por estados bem definidos. Conhecer ajuda a debugar.

Fase	O que acontece	Disparado por
1	init() chamado	Operador
2	Visitor + Session resolvidos	Bootstrap
3	isReplayEligible() rodada (hash session_id < sampleRate)	Bootstrap
4	Chunk sdk-replay.min.js injetado (lazy)	Auto se eligible
5	window.iGamingReplay.init({...}) chamado	Auto
6	Recorder rrweb iniciado, full snapshot capturado	Auto
7	Evento replay.started enviado via Tipo 1	Auto
8	Eventos rrweb fluem → ring buffer (se trigger) ou sender (se sem trigger)	Loop
9	Full snapshot forçado a cada 60s (checkpoint reproduzível)	Timer
10	visibilitychange:hidden → pausa recorder	DOM event
11	pagehide/beforeunload → sender.flush(‘unload’) via sendBeacon	DOM event
12	iGamingSDK.stopSessionReplay() chamado	Operador (opcional)
13	Evento replay.ended enviado via Tipo 1 + replay_id rotacionado	Auto após 1h ou stop

API pública

window.iGamingSDK.startSessionReplay();      // força início (mesmo sem opt-in inicial)
window.iGamingSDK.stopSessionReplay();        // pára imediato; emite replay.ended
window.iGamingSDK.isSessionReplayActive();    // true durante phases 6-11
window.iGamingSDK.get_session_replay_url();   // string ou null — atalho p/ dashboard

Estimativa de custo

Benchmark briefing v4 §5.11 (operador médio, 150k DAU, 10% sample, 12min sessão).

Métrica	Valor
Sessões gravadas/dia	15k
Bytes/sessão (gzip)	~200 KB
Storage diário	~3 GB
Storage mensal	~90 GB
Custo R2	~$1.40 / mês / operador

R2 = $0.015/GB armazenado. Egress =$0 (player consome via signed URL sem cobrança extra). Comparação S3 Standard: ~$2.00/mês com egress equivalente.

Reduzir custo: combine sampleRate: 0.1 (default) com trigger.urlMatchRegex para gravar SÓ sessões críticas (deposito, saque). Veja Session Replay — Triggers.

Limitações conhecidas

Esses pontos vêm do upstream rrweb 2.0-alpha — Atlas não consegue resolver unilateralmente. Documentar é a única mitigação.

• Cross-origin iframes: por default não são capturados. Browser bloqueia via Same-Origin Policy. Para habilitar, o iframe alvo precisa enviar Access-Control-Allow-Origin + cooperar com o config recordCrossOriginIframes: true.
• Shadow DOM dinâmico: nós inseridos via attachShadow() após o primeiro snapshot podem não ser observados em algumas versões do rrweb.
• WebGL / Canvas heavy: por default canvas é OFF. Habilitar gera 5-10× o storage normal (alto custo) — usar SÓ se análise visual de game frames for indispensável. Configurar via canvas.recordCanvas: true + canvasFps: 4.
• Service Workers em modo restrito: alguns browsers (Brave, Safari Lockdown) bloqueiam Worker compression. SDK cai em fallback usando CompressionStream nativo do navegador — funciona em Chrome 80+/Firefox 113+/Safari 16.4+. Browsers fora dessa faixa enviam Content-Encoding: identity (sem gzip).

Próximos passos

Masking & PII

Hierarquia block/mask/ignore + classes CSS Atlas + proteções hardcoded.

Triggers condicionais

Modo always-on vs URL/event trigger + ring buffer 60s pré-evento.

Network & Console

fetch/XHR capture metric-only + scrubURL + console levels.

LGPD & privacidade

Consent flow + denylist + opt-in. Aplica também a Session Replay.