Session Replay — Triggers condicionais

Gravar SÓ sessões críticas com URL/event trigger + ring buffer 60s pré-evento. Reduz storage 60-90%.

Quando habilitar. Sem trigger, o recorder começa em t=0 e grava 100% das sessões amostradas (sampleRate). Com trigger, o recorder buffera em memória até o gatilho disparar — só então o conteúdo dos últimos 60s começa a subir para R2. Resultado: 60-90% menos storage e custo.

Três modos

Modo	trigger config	Quando dispara
init	Ausente (default)	t=0 — recorder sempre ativo desde o load
url	urlMatchRegex set	Quando location.pathname casa o regex (boot OR SPA navigation)
event	eventMatch set	Quando iGamingSDK.capture(eventMatch, ...) é chamado

Apenas um disparo por replay_id. Após disparar, recorder fica em modo streaming contínuo. Trigger seguintes são ignorados.

Ring buffer (60s pré-trigger)

t=0 ─── t=30s ─── t=60s ─── t=90s ─── t=120s (TRIGGER) ─── stream
        [─────── ring buffer 60s ────────]
                                          ↑
                                          flush para sender + começa streaming

Eventos rrweb dos últimos 60s ficam num buffer circular. Eventos mais antigos são automaticamente descartados (briefing v4 §5.6). Quando o trigger dispara:

1. Buffer é flushed → chunk enviado para R2 com chunk_seq=0
2. Recorder muda para modo streaming (eventos vão direto para sender)
3. Próximos chunks têm chunk_seq=1, 2, ...

Cutoff inteligente: se houver um full snapshot dentro da janela de 60s, buffer corta tudo antes — porque eventos antes do full snapshot ficam irreproduzíveis.

Modo URL trigger

Caso clássico: gravar SÓ sessões que chegam em /deposito ou /saque.

window.iGamingSDK.init({
  // ... core ...
  sessionReplay: {
    enabled:    true,
    sampleRate: 1.0,  // amostrar 100% — o trigger filtra naturalmente
    trigger: {
      urlMatchRegex: '/(deposito|saque|cadastro|kyc)',
      bufferBeforeMs: 60000   // padrão; ajustável até 300000 (5min)
    }
  }
});

Comportamento:

• Jogador entra em /cassino/slots → recorder buffera mas nada sobe pro R2
• Jogador navega /cassino/slots → /deposito (SPA: history.pushState)
• SDK detecta route change (via PageViewCollector.onRouteChange)
• triggers.checkUrl() roda urlMatchRegex.test('/deposito') → ✅ true
• Buffer flush → chunk_seq=0 contém os 60s anteriores (/cassino/slots + navegação)
• A partir daqui, streaming contínuo

Regex válidos (compilados via new RegExp(...) no SDK):

// Match exato:
urlMatchRegex: '^/deposito$'

// Múltiplas rotas:
urlMatchRegex: '/(deposito|saque|cadastro)'

// Sub-rotas:
urlMatchRegex: '/deposito(/.*)?'

// Excluir cards de marketing:
urlMatchRegex: '/cassino/(?!banner)'

Regex inválido NÃO quebra o SDK — o trigger faz fallback para modo init (always-on) e o operador recebe console warn. Sempre teste regex no regex101.com (flavor JavaScript) antes de subir.

Modo Event trigger

Caso clássico: gravar SÓ sessões com bet.placed acima de R$ 5k.

window.iGamingSDK.init({
  // ... core ...
  sessionReplay: {
    enabled: true,
    sampleRate: 1.0,
    trigger: {
      eventMatch: 'bet.placed.high_value'
    }
  }
});

// Em outro ponto do app, quando o jogador confirma uma aposta:
function onBetConfirm(bet) {
  if (bet.amount_brl >= 5000) {
    window.iGamingSDK.capture('bet.placed.high_value', {
      bet_id: bet.id,
      amount: bet.amount_brl,
      game:   bet.game_slug
    });
  }
  // Para apostas <5k, evento normal é capturado mas NÃO dispara trigger.
  window.iGamingSDK.capture('bet.placed', { ... });
}

Comportamento:

• Operador chama iGamingSDK.capture('bet.placed.high_value', {...})
• Core SDK envia o evento Tipo 1 para /v1/sdk-events (canal normal)
• Core SDK ALSO emite via sdkEventListeners fanout para listeners externos
• ReplayTriggerManager.handleSdkEvent('bet.placed.high_value') → match → fire
• Buffer flush + streaming

Funciona com qualquer evento custom ou catálogo (page.viewed, error.occurred, etc).

Combinando URL + Event

Não há suporte nativo para múltiplos triggers em paralelo (briefing v4 §5.6 mantém intencionalmente simples). Workaround: usar eventMatch + capturar o evento custom em qualquer URL que importe.

// Habilita trigger pelo evento "critical.path"
sessionReplay: {
  trigger: { eventMatch: 'critical.path' }
}

// No app, dispara o evento em múltiplos pontos críticos:
['enter_deposito', 'enter_saque', 'enter_kyc'].forEach((checkpoint) => {
  document.addEventListener(checkpoint, () => {
    iGamingSDK.capture('critical.path', { checkpoint });
  });
});

Custo comparado

Operador 150k DAU, 12min sessão média:

Estratégia	Sessões gravadas/dia	Storage/mês	Custo R2/mês
Sem trigger (sampleRate: 0.1)	15k	90 GB	$1.40
Sem trigger (sampleRate: 1.0)	150k	900 GB	$13.50
urlMatchRegex: /(deposito|saque) + sampleRate: 1.0	~12k (8% dos 150k vão para deposito/saque)	75 GB	$1.12
eventMatch: 'bet.placed.high_value' + sampleRate: 1.0	~3k (high-rollers)	18 GB	$0.27

Em geral: prefer trigger + sampleRate 1.0 sobre sampleRate baixo sem trigger. Trigger amostra POR CONTEXTO (página crítica = relevante), enquanto sampleRate amostra ALEATÓRIO — você pode perder o replay exatamente da sessão que precisava.

Inspecionar trigger no Dashboard

-- Quais triggers dispararam mais hoje?
SELECT trigger_source, count() AS replays
FROM atlas.tbt_sdk_replay_events
WHERE event_date = today()
GROUP BY trigger_source
ORDER BY replays DESC;

trigger_source é um dos 3 valores: init, url, event. Propagado pelo SDK no envelope de cada chunk e replicado no row Gold.

Próximos passos

Masking & PII

Sempre revise masking antes de subir sample rate.

Network & Console

O que mais é capturado durante o replay.