A Beta do Telegram para macOS Ganha Análise de Produto com Funis e Revogação de Consentimento

Desde outubro, a versão beta do Telegram para macOS tem expandido seu subsistema de análise de produto. Ele registra visualizações de tela, eventos em menus e configurações, funis com resultados e jornadas do usuário através de mídias, encaminhamentos e figurinhas. Ao lado disso, há regras de privacidade e consentimento revogável. Ainda não há um toggle na interface, e essas classes não são visíveis em outros clientes. No entanto, o Telegram Desktop lançado e a documentação da API já descrevem, desde a primavera de 2026, como o cliente informa ao servidor quanto tempo uma publicação permaneceu na tela e quantos segundos de uma música foram ouvidos.

O que apareceu na beta para macOS

A beta do macOS é distribuída através do feed de atualizações, e seu código-fonte não está publicamente disponível. A composição do subsistema é visível pelos nomes dos tipos no arquivo executável das builds — eles surgiram em três etapas.

Um funil na análise de produto é uma cadeia de passos em direção a um objetivo, com a indicação de em qual passo a pessoa desistiu: abriu o painel de figurinhas, selecionou, enviou ou fechou. Uma jornada (journey) é a mesma cadeia para um único cenário. Pelos nomes, são visíveis três cenários: mídia, encaminhamento e figurinhas. É registrado separadamente de onde veio a transição para o navegador integrado (BrowserAnalyticsOrigin) e em qual seção a galeria foi aberta (GalleryAnalyticsContext).

O bloco se comportou como um experimento. Menos de duas horas após a build 283338, a próxima build, 283342, foi lançada sem ele, mas em 23 de outubro ele retornou na 13.1.0.283362 e desde então permanece — nas builds de 26 de outubro e posteriores, todas as classes estão presentes.

Existe um interruptor?

Na interface — não. Nem nas strings do binário, nem no pacote de recursos, nem nas traduções do cliente para macOS há texto sobre análise, estatísticas de uso ou consentimento para coleta.

No código, há uma pista. AnalyticsPrivacy e AnalyticsRevocable pelos nomes — regras de privacidade e revogabilidade, AnalyticsParameterRule — regra sobre quais parâmetros de evento são permitidos transmitir, AnalyticsScope — escopo de ação. Esta é uma hipótese baseada nos nomes, sem o código: é assim que a análise geralmente é organizada, onde o usuário pode recusar a coleta, e o evento não carrega campos desnecessários.

Os nomes não dizem para onde os eventos vão. No esquema público da API, há muito tempo existe o método help.saveAppLog: ele aceita um pacote de eventos com tempo, tipo, interlocutor e JSON arbitrário. O coletor na beta é chamado AppLogEvent*, mas a conexão entre eles é uma suposição por semelhança sonora.

O que os clientes lançados já contam

Parte das medições não é mais um experimento há muito tempo. Na documentação da API, o método messages.reportReadMetrics é descrito: o cliente informa ao servidor quanto tempo cada mensagem permaneceu na área visível do chat. As regras são detalhadas até o milissegundo.

• uma visualização com menos de 300 ms não é contada;
• time_in_view_ms — quanto tempo a mensagem foi visível por pelo menos um pixel;
• active_time_in_view_ms — parte desse tempo, quando a pessoa estava ativa; os clientes oficiais consideram o usuário ativo por 15 segundos após qualquer ação;
• seen_range_ratio_permille — qual proporção da altura da publicação entrou na área visível, em milésimos;
• mais de cinco minutos de visualização contínua são cortados em visualizações separadas, as medições são acumuladas por chats e enviadas em lote com um atraso de 5 segundos.

Lá também é descrito messages.reportMusicListen — quantos segundos de uma música foram ouvidos. O Telegram Desktop envia ambas as medições desde março de 2026: o registro de visualizações de publicações e o registro de audições apareceram no código no mesmo dia, 25 de março.

Essas medições respondem à pergunta "o que as pessoas leem e ouvem", enquanto o novo subsistema responde à pergunta "como as pessoas usam o próprio aplicativo". O primeiro se refere a canais e conteúdo, o segundo a telas, botões e cenários.

Telemetria de rede e motor em Rust

A parte mais antiga, NetworkTelemetry, chegou em 3 de outubro junto com RecordingNetworkEngine e se refere a outra tarefa. Um dia antes, em 2 de outubro, o motor de rede em Rust — RustNetworkEngine, RustRequestService, RustEngineNetworkRouter — e a interface geral NetworkEngine com o toggle SwitchingNetworkEngine apareceram na beta. As strings «Rust (restart required)» e «Engine switch to rust refused» indicam que o motor muda com a reinicialização, e «Rust engine crash of» e «Rust panic» indicam que suas falhas são capturadas separadamente.

A telemetria armazena atrasos, interrupções e classes de erros, e o motor de gravação registra solicitações e respostas de qualquer uma das duas stacks. Juntos, isso parece um test bench para comparar o código de rede antigo com o novo em tráfego real. Não há um método no esquema que enviaria a telemetria de rede para o servidor — os relatórios podem permanecer locais.

Onde isso não está presente

Na beta do Telegram para Android 13.2.0 de 27 de outubro, não há Analytics* nem NetworkTelemetry. Tudo o que é chamado de analytics e telemetry lá pertence às bibliotecas integradas do Google: Cast, Play Services e Firebase Crashlytics. O método reportReadMetrics é descrito no código do Android, mas a chamada não é visível na beta.

No Telegram Desktop, a análise de produto também não está presente — lá existe apenas o registro de visualizações de publicações e audições de músicas, conforme descrito acima.