TV 3.0: como devs podem explorar a camada broadband do Google

Quando li a notícia sobre a estratégia da Google para a TV 3.0 brasileira, minha primeira reação como dev não foi sobre televisão. Foi sobre pipelines de dados. Sobrepor uma camada web em cima de um sinal broadcast tradicional — com anúncios personalizados, gráficos interativos e checkout embarcado — exige resolver problemas que a maioria dos devs web nunca enfrentou na carreira: latência imprevisível, ausência de DOM “padrão”, engines proprietárias rodando em firmware de 2018, e sincronização temporal entre um sinal RF e recursos HTTP. A proposta parece simples. A engenharia por trás é tudo, menos simples.

Segundo o Eurisko.com.br, durante a IBC 2026 em Amsterdã, a Google detalhou como pretende ocupar justamente a camada broadband da TV 3.0 (DTV+) — aquela que conecta o sinal tradicional aos recursos digitais das Smart TVs. É, na prática, o mesmo movimento arquitetural que o HbbTV fez na Europa há mais de uma década, só que agora com um player sentado em cima de uma quantidade absurda de dados comportamentais e com um poder de fogo financeiro que muda completamente a equação.

O que é, de fato, a camada broadband da TV 3.0

A TV 3.0 (DTV+), padronizada pelo Fórum SBTVD, é herdeira direta do ATSC 3.0 norte-americano, mas com adaptações para o espectro brasileiro e para o nosso mercado. O sinal broadcast segue existindo — é o que entrega vídeo e áudio em alta qualidade para receptores que nem precisam de internet. A grande mudança é que o mesmo sinal carrega, em paralelo, um canal de metadados que aponta para aplicações e recursos hospedados em servidores web.

Funciona assim, em alto nível:

Sinal broadcast: vídeo/áudio em HEVC ou VVC, chegando via RF na velocidade da luz, sem depender de ninguém.
Canal de dados: dentro do próprio fluxo de transporte, o broadcaster embute um manifesto (algo próximo de um arquivo .m3u8 turbinado) que descreve os assets interativos disponíveis.
Camada broadband: quando a TV tem internet, ela baixa esses assets — HTML, JS, CSS, manifests de anúncios — e renderiza por cima (ou ao lado) do vídeo.

Para quem vem do streaming tradicional, isso é meio chocante. No Netflix, Disney+ ou YouTube, tudo passa por HTTP, então “personalizar” é trivial: você muda o payload da resposta. No broadcast, o sinal chega idêntico para 10 milhões de pessoas ao mesmo tempo. A personalização tem que ser resolvida na borda — ou seja, dentro da TV do usuário. É aí que a Google entra com todo o seu stack de ads, machine learning e dados de comportamento.

Por que isso não é novidade — e por que com a Google é diferente

Esse modelo já existe. O HbbTV (Hybrid Broadcast Broadband TV) está em produção na Alemanha, França, Espanha e Itália desde 2012. A grande operadora europeia é a Red Bee Media, e os maiores cases que eu conheço de fábrica são TV interativa com botão vermelho no controle remoto, telepromoção clicável e catch-up de programas. Funciona, mas o uso é medíocre porque ninguém nunca teve incentivo financeiro forte o bastante para empurrar hard.

A diferença aqui é que a Google quer monetizar cada segundo da experiência broadcast brasileira. Em minha análise, três vetores explicam por que essa investida é mais séria do que parecem:

Stack unificado: a Google controla o Android TV/Google TV, o Ad Manager, o Display & Video 360, o Campaign Manager e o YouTube como inventário cativo. Isso é uma ad-tech stack vertical que nenhum broadcaster europeu consegue replicar.
Dados first-party: com políticas de cookies já bem encaminhadas para o fim, ter dados de comportamento direto na TV (login Google, Android ID, dados de Android TV) é ouro. É basicamente um cookie-stitching em hardware onde o usuário não tem como limpar via DevTools.
Aposta no e-commerce: a camada broadband com “compras diretamente pela televisão” não é acidental. É a Google usando o broadcast como funil de topo para o seu próprio grafo de merchant e Shopping Graph.

Repare que, ao contrário do que o discurso oficial sugere, isso não é uma evolução “para o consumidor”. É uma redistribuição de margem — sai o intervalo comercial genérico do SBT, entra um leilão em tempo real com personalização comportamental. O broadcaster vira mero fornecedor de inventário bruto.

Na Prática: como um “shoppable moment” funciona tecnicamente

Imagine um programa de novela onde a atriz usa um vestido. No meio da cena, o espectador vê um overlay discreto com “Toque OK no controle para comprar”. Por baixo, o que acontece é isto:

O broadcaster emite junto com o vídeo um trigger temporal (timestamp em PTS — Presentation Time Stamp) e um URL de aplicação no manifest broadband.
A TV recebe, casa o trigger com o relógio do stream (RFC 8216 / SCTE-35 estendido para DTV+) e dispara a aplicação interativa.
A aplicação (basicamente um SPA web) abre uma sessão com a ad-tech, busca variantes criativas e renderiza.
O usuário navega com o D-pad do controle remoto. Nada de touch, nada de hover. Tudo é foco + click + teclado direcional.

Se eu fosse arquitetar isso hoje, num projeto real, eu separaria em três serviços bem distintos:

{
  "sessionId": "tv3-92a1-7c3f",
  "device": {
    "type": "smart-tv",
    "osVersion": "GoogleTV/ATV-14",
    "capabilities": ["dvb", "hdr10+", "hevcc"]
  },
  "broadbandSignaling": {
    "manifestUrl": "https://broadcast.example.com/dtv3/manifest.json",
    "triggers": [
      {
        "pts": 8423000,
        "duration": 15000,
        "appUrl": "https://shoppable.example.com/overlays/novela-vinganca/look-01",
        "fallback": "companion://qr"
      }
    ]
  },
  "adSlot": {
    "id": "house-impulse-7004",
    "floorPrice": 1.85,
    "currency": "BRL",
    "personalization": {
      "allow": true,
      "restrictions": ["lgpd:opt-out", "minor"]
    }
  }
}

Esse JSON é o tipo de payload que trafega entre o receiver (app nativo da Google na TV) e os bidders. Repare em três detalhes que devs que vêm de web puro erram o tempo todo:

O pts é baseado em clock de transporte, não em wall clock. Sincronizar exige um SID (System Identification) estável por canal.
O fallback: "companion://qr" é crítico: se a TV for antiga ou não tiver a app instalada, o usuário escaneia QR com o celular e cai num companion-app. É a rede de segurança.
O bloco personalization.restrictions tem que ser avaliado antes de qualquer bid request sair. LGPD não é checkbox no final do projeto.

Erros comuns que devs cometem ao pensar em TV interativa

Já revisei código de três projetos de shoppable TV (dois americanos, um europeu) e os bugs se repetem. Anota aí:

Tratar a TV como um browser. Ela não é. O “engine” varia entre WebKit, Blink, Gecko, e em alguns casos um fork proprietário tipo o do Tizen ou WebOS. APIs como WebRTC, Service Worker, IndexedDB e até localStorage podem ser parciais ou ausentes.
Ignorar o controle remoto. Não existe hover, não existe cursor fino. Existe navegação por foco. CSS como :focus-visible e :focus-within deixa de ser boa prática e vira requisito funcional. Teste com Tab, setas e Enter. Sempre.
Confundir broadcast com streaming. No streaming, se o usuário pular um ad, o ad foi pulado. No broadcast, o sinal continua chegando. Sua lógica de “exibição única” precisa tolerar replay de DVR, time-shift e pause. Estude SCTE-35.
Métricas de “viewability” mal calibradas. O padrão MRC define viewability em TV interativa de forma específica (50% dos pixels visíveis por 2 segundos consecutivos). Não é a mesma definição de IAB para web. Implemente medição que sobreviva a anúncio de áudio-pause.
Subestimar a LGPD. TV é território novo, mas a ANPD já sinalizou que personalização comportamental em TV aberta exige consentimento granular. Construa o consent management server-first, não como overlay no final.

O que muda para quem produz web, na prática

Se você trabalha com frontend, prepare-se: alguns dos jobs mais bem pagos dos próximos anos vão envolver construir e manter “TV apps” que são essencialmente SPAs com constraints duros. Performance budgets de 250 KB de JS comprimido, sem fontes externas sem whitelist, sem WebGL em firmware antigo, com suporte a TTS e legendagem oculta. É um nicho onde web devs geralmente tropeçam, e quem dominar isso antes vai surfar a onda cedo.

Se você está do lado de dados/ad-tech, vale estudar OpenRTB 2.5+, especialmente as extensões de TV (TV extensions da IAB). O leilão em tempo real em broadcast é mais desafiador que em mobile porque o “impression” não é confirmado por pixel — é previsto pela sinalização do broadcaster.

E, se você é dev de infra/streaming, ignore essa camada broadband à sua custa. As oportunidades em CDN edge, manifest delivery e observabilidade cross-layer (RF + HTTP) são exatamente onde os bons salários vão aparecer.

Perguntas que um dev real faria (FAQ)

1. Isso é igual ao ATSC 3.0 dos EUA ou é realmente uma coisa brasileira?

É baseado no ATSC 3.0, mas com adaptações específicas — codec prioritário (HEVC, com caminho para VVC), camada de interação adaptada ao HbbTV 2 com perfil brasileiro, e middleware pensado para o parque de TVs instaladas aqui. Padrão internacional, customização local.

2. Posso rodar React/Vue/Next nessa camada broadband?

Pode, mas vai sofrer. Engines são antigas, memória e heap são limitados, e o orçamento de banda é compartilhado com o vídeo. Use Svelte, Solid ou Preact. Hidratação pesada vai te travar em TVs de 2019.

3. Como faço teste local sem ter um transmissor?

Use o simulador de referência do SBTVD (disponível no repositório deles) ou emule o manifest num servidor estático + player HTML5 com a extensão tv3-emulator. Em produção, peça para o broadcaster fornecer um canal de teste IP-based.

4. Qual é o impacto real da LGPD aqui?

Significativo. Personalização comportamental em TV aberta exige consentimento granular, opt-out trivial e retenção limitada. Plus, a integração com a camada Google adiciona transferência internacional de dados — tudo tem que ser documentado no RIPD.

5. Quando isso vira realidade palpável no Brasil?

A previsão do mercado é rollout operacional entre 2027 e 2028, com testes em São Paulo e Rio antes da expansão. A IBC 2026 foi didática, mas a regulação da Anatel e os contratos com broadcasters vão ditar o ritmo real.

—

Pra mim, o mais interessante desse movimento não é a parte “shopping na TV”, que é meio truque de marqueting. É a consolidação de uma stack onde um player controla o inventário broadcast, a camada broadband e o device. Isso muda completamente a superfície de ataque, o modelo de negócio e — inevitavelmente — o trabalho de quem constrói software pra essas plataformas. Na minha experiência, sempre que um player verticaliza assim, surgem brechas, dívidas técnicas e oportunidades de carreira que pagam bem para quem entende a fundo o que está rolando por baixo.

Gostou? Me segue no GitHub e deixa um comentário aqui se quiser que eu aprofunde algum ponto — seja a parte de SCTE-35, a integração com Ad Manager ou os truques que vou aprendendo testando isso em apps de Smart TV.