13 publicações com a etiqueta "analytics"

Documento SSR auth-agnóstico — useAuthGate e o expurgo de dado de usuário dos loaders​

• Janela desta entrada — cobre 20/07 a 26/07 (171 commits em main-7k, a semana mais movimentada do trimestre). Foi também a semana em que main-fix e main-7k foram cruzadas nos dois sentidos (PR #1770 e PR #1773), então muitos assuntos aparecem duas vezes no histórico com SHAs diferentes — cada item abaixo cita um SHA só.
• O documento SSR deixa de saber quem é o usuário (PR #1808, branch feat/user-data-out-of-ssr) — 6b1f32a90 remove auth e smarticoHash do loader de routes/_layout, e cb1b41c26 introduz o gate canônico app/hooks/useAuthGate.ts, client-side e sem snapshot SSR: o SSR sempre pinta convidado, o cookie is_authenticated serve como sinal otimista pós-mount e a store reativa assume depois da hidratação. Regra que nasce daqui: visibilidade e comportamento de UI nunca devem ser decididos com useRouteLoaderData("routes/_layout"), porque aquele é um snapshot SSR que não atualiza quando o login/logout acontece por modal.
• Loaders per-user desmontados um por um — d006a45fc (wallet, fetch 100% client-side), 62fd7b064 (rewards e income-report), 7de40d656 (página de favoritos), f17975eff (favoritos e recentes da home), 5683cdb3c (a página de jogo passa a serializar só a contagem pública de voteState; o userVote vira client-side), e23934b23 (bootstrap do álbum via /api/album/bootstrap). 28366ffca é a reescrita larga do caminho de dado de usuário no SSR.
• Guardrail em teste, não em revisão — 282070eca cria o leak-canary: loaders públicos não podem serializar dado de usuário, e o teste falha se voltarem a fazê-lo. e06e384a0 fecha um furo do próprio guardrail (o canary passou a resolver todos os campos-promise do _layout, não só os síncronos). f8d6acf53 testa o useAuthGate contra a store real e f4d4eb059 deduplica React e Zustand no vitest.config — a resolução source-direct estava trazendo uma segunda cópia de React pela via de alias.
• Reconciliação do Smartico — 7c5659fba mantém o smarticoHash correto em login e logout dentro da sessão SPA agora que o doc é auth-agnóstico, e 338c824b0 adiciona guard de corrida no fetch dele (além de corrigir comentários que descreviam o gate SSR antigo).

Semana de 29/06 a 05/07, na branch main-7k do front-web-base. Semana mais leve em volume (47 commits filtrados), mas com duas decisões estruturais de tracking.

Semana 29/06–05/07 — anaLayer: uma segunda camada de tagueamento GA4, paralela à existente​

• Fundação da camada (1fceb0672): implementa o tagueamento GA4 do guia Ana Gaming num container GTM secundário próprio, com dataLayer isolado chamado anaLayer, rodando em paralelo e independente da stack de analytics atual (dataLayer/registry + Meta, Kwai e os demais). A config é brand-gated com default null, então a invariante é que nenhuma brand dispara sem container declarado. Inclui registry tipado dos 32 eventos, helper pushAnaLayerEvent, campos padrão (user_id, user_id_hash como SHA-256 do CPF, platform, profile_type, event_timestamp), event_id determinístico, AnaLayerProvider/useAnaLayer e um AnaLayerInitializer espelhando o Consent Mode v2 do initGTM. 21 testes.
• Wiring de 22 eventos no mesmo commit — page_view, login, sign_up, modal_viewed, begin_checkout, add_payment_info, deposit_pix_generated/copied, purchase, deposit_pix_expired, withdrawal_started/requested, kyc_started/completed, form_error, view_item_list, select_item, view_promotion/select_promotion, select_content e search — disparados em paralelo aos eventos legados, lendo IDs reais das APIs. Bloqueados de propósito, com scaffold e TODO: game_opened e game_session_ended (aguardando game_session_id no StartGameResponse do core), além de refund, o ciclo de saque pós-requested, aprovação/rejeição de KYC e cashback, que são observados no backend e ficam registry-only. Nada é disparado com dado sintético.
• Alvo trocado de 7k pra vera e depois configurado por brand — fba166367 reaponta a camada pra vera em vez do 7k; b621f558e faz o useAnaLayer degradar pra no-op fora do provider; e 4bf4ebabd adiciona a flag enabled à AnaLayerConfig, criando o estado "configurado mas desabilitado": o gate passa a exigir enabled === true e containerId. Resultado no fim da semana: vera-bet-br é a única com enabled: true; 7k-bet-br e cassino-bet-br ficam com container declarado e enabled: false. Os IDs de container vivem só nos overrides de cada brand.

Semana de 22/06 a 28/06, na branch main-7k do front-web-base.

Semana 22–28/06 — Consent Mode v2: default invertido pra granted e consent cosmético como padrão​

• O baseline de boot do Google Consent Mode v2 foi invertido pra granted (16bf59fee). Isto reverte o comportamento descrito no changelog de 23/04/2026. A política antiga emitia gtag('consent','default', { ...tudo denied, wait_for_update: 500 }) e só depois, se houvesse cookie salvo, aplicava um update. A nova emite gtag('consent','default', { ...tudo granted }) sempre, sem wait_for_update. O único caminho que ainda rebaixa sinais é cookieConsentCosmeticOnly === false e cookie salvo indicando rejeição total, caso em que o initGTM dispara um update imediato pra denied. Matriz implementada: cosmético true → granted (qualquer cookie ignorado); cosmético false sem cookie ou com aceite → granted; cosmético false com rejeição total → default granted + update imediato pra denied. Arquivos: app/utils/metrics/consent.ts (injectConsentDefaults com opts.applyDenied) e app/utils/metrics/gtm.ts (decide applyDenied = !cosmetic && userRejectedAll), com 4 casos de teste. A justificativa registrada no commit é paridade com o app Nuxt legado, que nunca gateava tracking, e a eliminação da janela cega de 500ms do wait_for_update, apontada como causa suspeita da queda de performance em Google Ads e Meta Ads após a migração.
• cookieConsentCosmeticOnly passa a ter default true no base (be0518d91). Antes o default global era false, então brand que não declarasse a flag honrava a rejeição do usuário. As 7 brands que já declaravam true seguem idênticas; as 8 que herdavam false (casateste-com, donald-bet-br, pb-bet, ph-state77-com, pt-state77-com, rj-bet, state77-com, x2b-bet) passaram a declarar false explicitamente no próprio override — comportamento preservado bit a bit, com o ganho de que cada override é agora a fonte autoritativa da política de consent daquela brand, sem depender do default do base.
• Nota de revisão pendente: as duas mudanças acima descrevem o que o código faz hoje. A política resultante — consent concedido por padrão, tratamento cosmético como default e ausência de botão de rejeição total no banner — ainda depende de confirmação do responsável por LGPD antes de ser publicada como política oficial. Registrado aqui como fato técnico, não como posição de conformidade.
• Eco do gtag duplicando eventos do dataLayer corrigido em ea9b09a68.

Semana de 15/06 a 21/06. Daqui pra frente o changelog é semanal (arquivos YYYY-MM-DD-weekly.md, datados no último dia coberto). A fonte de verdade do front-web-base é a branch main-7k — a main está defasada e não reflete o que foi pra produção.

Semana 15–21/06 — cache overhaul: CACHE_GENERATION como token único de rotação​

• front-ops/config/cache/generation.yml vira a fonte operacional de verdade (ops f00c642): o arquivo carrega current: apcsrasj-v3, é lido no deploy e injetado como --var CACHE_GENERATION no wrangler deploy. Bumpar pelo workflow novo bump-cache-generation flipa de uma vez a namespace do Cache API do platform-cache, o cacheKeyPrefix do api-client e o GLOBAL_VERSION do front-service-api; sem o arquivo, o deploy cai no default in-source (fail-open). É separado do BUILD_ID, que já rotaciona a cada deploy — o CACHE_GENERATION é o "nuke from orbit" que o padrão legado de pasta-nova-por-deploy fornecia. cache-status.yml complementa como leitura read-only.
• Base conectado à máquina nova (b445a6b5a): binding declarado no worker-configuration.d.ts; app/services/platform-cache.server.ts mantém um storesByGeneration chaveado pelo token, então o cache de isolate rotaciona atomicamente; app/services/api.server.ts deriva cacheKeyPrefix como api-cache-<gen> e liga delegateCaching: true nas rotas já cacheadas na camada platform-cache, eliminando o drift de TTL duplo que causou o postmortem de /payment-providers em 05/2026. app/routes/api/cache/purge.ts passa a delegar ao createPurgeHandler do core (mesmo contrato de tag/glob/scope/dry_run, com extractApiError no lugar de [object Object]) e nasce app/routes/api/cache/inspect.ts, endpoint GET que lista recursos, tags e namespace corrente e, com ?include=state, sonda o Cache API.
• TTLs apertados e falhas de fallback visíveis (239651ff4): KV_SSR_TTL cai de 12h pra 1h (o valor antigo era resquício da premissa "rebuild a cada 12h"), entra MAX_API_CACHE_TTL = 3600 com clamp em getApiCacheRule, e erros de fallback de asset em KV e R2 passam a ser logados — antes eram engolidos em silêncio, deixando problema de permissão ou bucket invisível no Logpush. public/_headers reduz /icons/* de 1 ano pra 30 dias.
• Defaults e purge seletivo no front-ops (b36e445): brandConfig sai de 3600s e homeRows de 7200s, ambos pra 60s + SWR 300s, então mudança de backoffice reflete em menos de 60s; toda resource ganha tags pra o purge mirar fatias em vez de derrubar tudo; staleIfErrorSeconds capado em 6h. manual-cache-purge.yml sobe pra v3 com tags (CSV), glob, scope e dry_run. 8645ac2 cria config/cache/service-api-defaults.yml com 19 regras consumidas no deploy do service-api — base e service-api passam a compartilhar a mesma taxonomia de tags.
• skip_post_deploy_purge por environment (ops 2d83a4c, aplicado em 0d4437e e 64f130f): workers atrás de Cloudflare Access devolvem 404 no purge pós-deploy porque o curl segue o redirect de login sem service token. Até os service tokens entrarem no workflow, o environment pode sair do purge por segmento — a rotação do CACHE_GENERATION já torna as entradas anteriores inalcançáveis — e um step de notice registra o skip no run summary.
• front-service-api com política externalizada (f80791d): DEFAULT_GLOBAL_VERSION = apcsrasj-v3, getGlobalVersion(env) lendo CACHE_GENERATION → BUILD_KEY → default, política vinda de env.SERVICE_API_CACHE_POLICY_JSON (era hardcoded) e /v2/cache/purge com o mesmo contrato do base. scripts/build-cache-policy.mjs resolve o YAML por --file, FRONT_OPS_PATH ou irmão ../front-ops. 27 testes novos, com 8d9fe4f documentando o fluxo no README.

Semana 18–24/05 — Álbum v2 portado e endurecido​

• Substituição integral do módulo pela v2 — a079bcfab troca app/components/album/** pela versão v2 do drop-in: subdiretório share/ novo (15 arquivos) com pipeline de compartilhamento social por figurinha, URL canônica, card de OG safe pra Satori e helpers de UTM; três componentes novos (CheckinSuccessModal, MissionTypeChoiceModal, PackSummaryPhase); StickerCard e StickerRevealStack extraídos como reusáveis; check-in consolidado em CheckInState com dois tipos de claim (diário e de conclusão); e a novidade estrutural — trilhas duplas (casinoMissions / sportbookMissions mais missionType, um gate bloqueante de escolha no primeiro acesso). O hook público passa a ser useAlbumProgress; useProgressSync, CheckInTier e AlbumBootstrap.checkInDays saem do contrato.
• Handshake de auth próprio, server-side — 7644499ec. O BFF do álbum exige fluxo de auth distinto do JWT do cookie HttpOnly do host: POST {STICKER_API_URL}/auth/token com { encryptedUserId, brandId, campaign } devolvendo { accessToken, tokenType, expiresAtUtc }, e Authorization: Bearer em todas as demais chamadas. A versão anterior passava o JWT do cookie direto, o que não funcionava contra o BFF real. loadAlbumBootstrap agora faz o handshake antes do Promise.all de endpoints e retorna null quando ele falha — feature degradada em silêncio em vez de rota quebrada. 459b1b0d5 adiciona cache de token cross-request e fd8690a9b projeta o apiCampaign no servidor antes de mandar pro client.
• Auditoria de porte com 53 achados — 3a2a0eab6 compara a v2 portada contra o harness do sticker-book, o Swagger oficial do BFF e os contratos consumidos pelo módulo: 19 críticos, 31 médios, 3 baixos. Os commits seguintes endereçam os 19 críticos — entre eles ff17d4230 (sincronizar state.checkIn a partir de data.checkIn após refetch), d78a718a9 (blindar loadAlbumPageData contra throws inesperados), def9b3f41 (gatear o polling de 60s em document.visibilityState), 9066c2284 (alinhar os handlers de rota ao Swagger) e 819b5dd03 (adapters de mutação, retry de 401, tipos de API compartilhados).
• Kill-switch por marca e gating de acesso — 93b3d1312 cria albumConfig.enabled fail-closed: o código fica disponível pra todas as marcas mas só executa pra quem declara enabled: true explicitamente, com guard no loader de /vip/album que redireciona pra home antes de qualquer chamada ao BFF. Só o 7k liga. 72bf89007 adiciona modo preview, splash, gating de feature flag, entrada de sidebar e endurecimento de cache; b7157c1e6 esconde a entrada pra usuário deslogado; a13218eae faz o deslogado fechar pelo X e pelo backdrop em vez de abrir login.
• Missões vindas do Smartico e do BFF, mescladas por id — dc868194f passa a carregar "Suas Missões" da seção ALBUM_FIGURINHAS do Smartico, 07672c7ae cai em todas as missões quando a seção não existe, 0d0fed93e mescla Smartico e BFF por id e 8dca06afd remove /users/me/missions (deprecado — o Smartico é autoritativo).
• Renderização de flip-book e polimento visual — b64d23165 (capa centralizada, tag de faixa de páginas, backgroundImageUrl), 7b84ca712 (continuidade do flip: fatia da lombada, imagem de curl, lombada antecipando o BACK), 746803a4c (tap-to-flip nas bordas), bac022447 (thresholds assimétricos de commit FORWARD/BACK), 253ed4f2e (watermark central nos cards travados), b0a8d3c51 / bc9f28802 (dimensões, centralização e escalas proporcionais no mobile). d392f4072 fecha a semana com a LP de compartilhamento, download de composição e preview anônimo. Testes em c26c5af85, ad332e995 e 9340a8888 cobrem handshake, orquestração, os seis endpoints /api/album/* e os gates de degradação do loader.
• Chaves album.* de i18n foram adicionadas como overrides do host em vez de irem pro core (e251c0d09), e 8d78a79d7 troca nomes de placeholder por versões neutras na config base.

Semana 11–17/05 — Álbum de figurinhas entra no base​

• Módulo album portado do harness pro host — 86435c4a9 traz o drop-in modules/album do repositório do sticker-book pra app/components/album/ (59 arquivos: Album.tsx, AlbumModal.tsx, páginas Missions / CheckIn / Stickers / Terms / PackOpener, context, hooks, reducer, types e utils) já cabeado na infraestrutura do base — rota gamification.album → /vip/album registrada em todos os paths.ts de override, loader com auth gate e AlbumBootstrap. biome.json passa a excluir app/components/album/**, porque é código de módulo terceiro. Branch feat/album-integration.
• Camada de proxy e serviço server-side — cinco rotas novas em app/routes/api/album/ (open-pack, open-all-packs, checkin, claim-prize, claim-featured) e o serviço app/services/album.cache.server.ts, que dispara um burst paralelo de 5 endpoints do BFF do álbum (stickers, packs, dias de check-in, featured, missions) chaveado na env ALBUM_API_URL e retorna null quando a env não está configurada — feature simplesmente não aparece em vez de quebrar a rota.
• Overrides de tema por marca — 7k (navy + amarelo), cassino (azul + ciano) e vera (verde + lima) ganham config própria; o default em app/config/gamification/album.ts fica num slate escuro neutro.
• Dois fixes de integração no mesmo dia — 24d73ebe1 remove um import circular introduzido nos overrides de marca e c2db1cd2b move a rota pra fora do layout VIP, porque a página não deve depender de gamificationConfig.modules pra existir.

Analytics — Mixpanel Deposit + AppsFlyer S2S​

• Novo evento Mixpanel Deposit Requested (useAnalytics.trackDepositRequested) disparado quando /wallet/add-credit retorna 200 OK. Espelha o legado DefaultLayout.vue das brands 7k/cassino/vera (props Amount em unidades inteiras + DepositMethod). Continua complementar ao evento de funil já existente (pix_generated no GTM e PixGenerated no Facebook).
• Bugfix crítico nos eventos S2S do AppsFlyer (sendRegister, sendFTD, sendRebill). Os três estavam dentro do guard if (!shouldLoadTrackers) return do useAnalytics, mas o gate é o inverso do gate do AppsFlyer (shouldLoadTrackers = !isAppMode && !isBot, useAppsFlyer.ready = enabled && isAppMode) — resultado: nenhuma das chamadas server-to-server disparava nem na web (gate externo bloqueia) nem dentro do APK (early return do gate externo cortava o caminho). Agora as três chamadas são disparadas antes do guard e o S2S funciona em produção. Coberto por useAppsFlyer.test.ts (202 linhas) e useAppMode.test.ts (72 linhas).
• useAppMode agora reconhece ?is_twa=true além de ?app=true. Os APKs em produção da família 7k/cassino/vera (publicados antes do rename do query param) continuam injetando o legado em cada landing — sem isso isAppMode ficava false pra users do app e desativava todo o pipeline de tracking S2S silenciosamente.
• Valor do deposit GTM corrigido pra unidades inteiras (amountCents / 100) ao invés de cents puros — paridade com o legado e com a expectativa dos dashboards de BI.

Jornada FTD — Refatoração Completa e Novas Brands​

• D0 e D1 desacoplados — antes, ativar o template vera-legacy do D0 (cashback) ligava implicitamente o modal de anúncio do D1 (check-in). Agora cada brand habilita as três etapas independentemente: ftdCashback.enabled, ftdCheckin.enabled e a flag nova ftdCheckin.announcement.enabled. Quatro combinações possíveis — só D0, só D1, ambos ou nenhum.
• Copy e assets configuráveis por brand no template vera-legacy — FtdCashbackConfig ganhou copy.{firstBonusToastTitle,cashbackModalTitle,cashbackModalDescriptionHtml,cashbackModalCtaText} + templateAssets.{firstBonusToastImage,cashbackModalImage}. FtdCheckinConfig ganhou announcement.copy.{title,descriptionHtml,ctaText} + templateAssets.image. Todos opcionais — fallback é o copy PT-BR + CDN da Vera (zero regressão).
• 16 tokens de tema novos para o template e o toast — ftd-offer.template-{shell-bg,title-text,title-shadow,image-bg-from,image-bg-to,highlight-bg,highlight-border,highlight-text,cta-bg,cta-text} e ftd-offer.toast-{bg-from,bg-to,border,icon-bg-from,icon-bg-to,icon-border}. FtdOfferModalTemplate e FtdOfferInGameToast agora leem essas cores via CSS custom properties inline (Tailwind JIT não consegue gerar classes a partir de tokens dinâmicos).
• 7k-bet-br ativa a jornada completa — D0 cashback, D1 check-in (com modal de anúncio "Garanta sua diversão!") e oferta-relâmpago pré-FTD, todos via template unificado. Quatro assets brand-specific da CDN do 7k substituem os fallbacks da Vera (toast, modal cashback, anúncio D1 e modal de oferta).
• cassino-bet-br ativa a jornada completa — paleta + assets próprios, brand_id: 2 no Dark Verifier/Freedom (paridade com useFtdCashback.ts:52 do legado), kill-switches feFtdD0Cassino / feFtdD1Cassino, tabela bonusTiers de 35 níveis portada verbatim do legado (R$ 5 → R$ 3000+, cap em R$ 800), autoDepositModal abre o drawer de depósito automaticamente no login quando saldo ≤ R$ 0,10. Inclui lista de jogos elegíveis em cashback/eligible-games.ts.
• cl-bet7k-com ativa D0 + D1 com identidade chilena — brandId: 4, kill-switch feFtdD07KCl (compartilhado D0/D1), tabela bonusTiers de 11 níveis em CLP (CLP 850 → CLP 510 000, cap CLP 136 000), 6995 IDs elegíveis portados 1:1 do legado, copy em espanhol chileno ("¡Sigue jugando para ganar un cashback!"). Moeda renderiza sem decimais ($50.000) via useFormatMoney() + CountryConfig.displayDecimalDigits. D1 começa desabilitado no primeiro rollout.
• STT 2 (saldo bônus) com kill-switch remoto — saldoBonus.featureFlags?: { legacy?, configcat? } permite desligar a STT 2 instantaneamente via ConfigCat ou FF legado sem deploy. O hook useFtdCashbackFlow computa saldoBonusRemoteKillSwitchPass (closed-by-default enquanto a API está em voo, mesma semântica do D0/D1). Cassino declara feFtdSaldoBonus + feFtdSaldoBonusCassino.

Topbar de Notificações​

• Redesign completo da TopbarNotification (PR #333): novo layout com botão de fechar (X) à esquerda, ícone em chip arredondado com tokens dedicados (topbar.icon-bg / topbar.icon-text), pilha de título + subtítulo no centro e CTA pill à direita, com altura de 72 px alinhada às barras modernas de instalação de app. Os ícones emoji foram substituídos por componentes do lucide-react (Smartphone, Bell, Gift, Send, Trophy, ShieldAlert) e o tipo TopbarDefinition.icon virou LucideIcon. Os modos default e restricted foram unificados num TopbarShell compartilhado, e a topbar deixou de ser sticky — agora rola junto com a página enquanto o header permanece fixo no topo do viewport. Tooltip de instalação iOS foi reancorado para o rodapé do viewport com safe-area-inset-bottom para que a seta inferior alinhe com a barra de endereços do Safari.
• Centralização do conteúdo no desktop (PR #334): o TopbarNotification recebeu um container interno max-w-[460px] mx-auto envolvendo close/ícone/texto/CTA. O fundo continua preenchendo edge-to-edge, mas em viewports largos o X e o CTA não escorregam mais para os cantos deixando um espaço vazio gigante no meio. Em mobile (< 460px) o comportamento é idêntico ao anterior — o container preenche naturalmente toda a largura.
• Refresh de tokens de tema da topbar em todos os overrides (PR #347): sincronizou o override 7k-bet-br (que estava sem icon-bg e icon-text), padronizou a paleta com fundo mais suave (lifted bg-primary), chip do ícone tingido com primary e CTA combinando com o botão primário da brand. Ajustes manuais aplicados nas variantes 7k, state77, vera-bet-br, betpontobet-bet-br e cassino-bet-br. Altura interna da linha do TopbarNotification reduzida de 68 px para 62 px para compactar o footprint vertical.

Consentimento de Cookies / LGPD​

• Banner de consentimento de cookies com Google Consent Mode v2 chega ao base. O CookieConsentBanner (fixado no canto inferior esquerdo, animado, z-60) e o painel CookieConsentDetails (abas Configurações/Sobre, toggles por categoria, tabela de cookies) injetam os defaults do GCM antes do GTM inicializar e gravam a preferência no cookie cactusCookiesConsent. Mapeamento de categorias: performance → analytics_storage, functionality → functionality_storage, demais → ad_storage + ad_user_data + ad_personalization. Bypass para bots via useIsBot(). Feature flag brand.features.cookieConsentPopup controla a exibição por marca, sem build-time config.
• Paridade total com o legado Vue (base + 7k + cassino + vera): adicionado o sétimo sinal do GCM v2 (security_storage: granted) para auditorias Lighthouse/CMP enxergarem o contrato completo; COOKIE_TABLE expandida de 6 para 19 entradas cobrindo Cloudflare, GA4, Clarity, Meta Pixel, Kwai, Amplitude, Smartico e cookies de funcionalidade (current_lang, topbar_closed, install_app_popup_closed); migração transparente do formato legado (array JSON de strings) para o novo objeto, sem reprompt de usuários existentes.
• UX e visual: o banner se posiciona acima do MobileBottomNav em mobile (h-14), some quando o drawer está aberto, fica print:hidden, e tem split 50/50 entre [Personalizar | Recusar] e [Aceitar todos]. Cores 100% via tokens de tema (bg-secondary, text-texts, bg-primary), eliminando bg-white/* e border-white/* hardcoded. O botão "Salvar" dentro do painel de detalhes se torna "Aceitar todos" quando só a categoria necessária está marcada — replica o saveButton() do legado.