Analytics ampliado de streaming e redes sociais: todas as lojas que reportam em um só painel

Um gráfico vazio e um gráfico cheio de zeros dizem coisas diferentes, e apenas um dos dois pode estar certo. O Boomplay reporta streams e streams por país. Não reporta salvamentos. Então um gráfico de salvamentos do Boomplay deveria dizer que a loja não reporta esse dado, em vez de traçar uma linha reta no zero e deixar que você conclua que ninguém salvou o lançamento.

Essa distinção guia toda a atualização de analytics que lançamos em julho. O analytics da LabelGrid agora cobre todas as lojas que nos enviam um feed de analytics: Spotify, Apple Music, Deezer, Audiomack, Boomplay, AWA e os três serviços da Tencent, Kugou, Kuwo e QQ Music. A atividade nas redes sociais e de UGC em torno do seu catálogo aparece ao lado, do SoundCloud ao Snapchat e aos apps da Meta. Os dados de streaming também já podem ser lidos por código, pela API pública e pelo servidor MCP de código aberto.

As lojas que reportam e o que cada uma reporta

A distribuição chega a mais lojas do que esta lista. Estas são as lojas cujos feeds de analytics nós importamos, e vale conhecer a diferença: a atividade de qualquer loja entra nos seus extratos de royalties, tenha ela um feed de analytics ou não, porque extratos e analytics seguem fluxos separados.

Loja	Periodicidade	O que reporta
Spotify	Diária	O conjunto mais completo: streams, ouvintes, salvamentos, pulos, compartilhamentos, taxas de engajamento, origens dos streams, dispositivos e dados demográficos
Apple Music	Diária	Streams, ouvintes, adições à biblioteca, adições a playlists editoriais, Shazams, além de detalhamento por cidade e por loja regional
Deezer	Diária	Streams, geografia, dispositivos, dados demográficos dos ouvintes, tempo médio de audição, posicionamentos em playlists
Audiomack	Diária	Streams, ouvintes, salvamentos, geografia
Boomplay	Diária	Streams, streams por país
AWA	Diária	Streams
Kugou, Kuwo, QQ Music	Semanal	Streams

O desenho dessa tabela é justamente o que importa. Pulos, compartilhamentos, origens dos streams, hora do dia e formato de áudio vêm só do Spotify. Shazams, adições à biblioteca e adições a playlists editoriais vêm só do Apple Music, porque o Shazam é um sinal da Apple, sem equivalente em nenhuma outra loja. Os dados demográficos de ouvintes, que contam pessoas e não reproduções, vêm do Spotify e do Deezer. Streams por país cobrem Spotify, Apple Music, Deezer, Boomplay e Audiomack, mas não o AWA, cujo feed traz códigos de regiões subnacionais do Japão em vez de países ISO. Ninguém precisa decorar nada disso: o painel mostra o que cada loja oferece, e a API publica a mesma matriz em forma de dados.

Os posicionamentos em playlists seguem a mesma lógica. As linhas do Spotify trazem o nome e o dono da playlist junto com a contagem de streams. As do Apple Music incluem playlists editoriais pelo nome, com a melhor posição que a faixa alcançou, e algumas dessas linhas não trazem nenhuma contagem de reproduções, o que aparece como não reportado. As do Deezer levam à playlist pública quando o id é reconhecido.

Combine as lojas, compare entre elas ou veja uma de cada vez

Três modos de visualização cobrem a maior parte do que se faz com esses dados. O modo Combinado soma todas as lojas em um único número. O modo Comparar coloca as lojas lado a lado, e o comparar-tudo já inclui automaticamente as lojas recém-adicionadas, então você nunca precisa acrescentar uma loja nova a uma comparação que já existe. O modo Individual abre o detalhamento completo de uma loja só. Os gráficos aceitam granularidade diária, semanal, mensal ou automática. Os melhores desempenhos ficam em abas por métrica, e os posicionamentos têm filtro por loja.

Um ponto por semana nas lojas da Tencent

Kugou, Kuwo e QQ Music reportam semanalmente. Cada semana gera um ponto de dados por faixa, datado do dia a que o relatório se refere e com o total da semana inteira. Nunca dividimos um total semanal em valores diários inventados, então, num gráfico diário, essas três mostram uma data preenchida por semana, com lacunas entre elas.

As lacunas estão corretas, não são dados faltando. Os totais do período continuam fechando, e a periodicidade vem indicada no painel e na resposta da API, então uma integração consegue distinguir uma loja semanal de uma loja sem movimento.

Quando uma métrica diz “indisponível”

No painel, a métrica que uma loja não reporta recebe esse rótulo, por plataforma; na API, a matriz de disponibilidade devolve a célula como not_available_for_platform, em vez de uma série de zeros. O caso mais delicado está na visão de posicionamentos, em que uma linha editorial do Apple Music pode informar a playlist e a posição que a faixa alcançou sem nenhuma contagem de reproduções ao lado. Isso quer dizer “não reportado”. Se você transformar isso em zero, muda o significado do número e coloca um piso falso em toda média calculada a partir dele.

Os limites de privacidade seguem a mesma lógica, pelo lado oposto. Os detalhamentos demográficos e geográficos usam k-anonimato, então células abaixo de um limite mínimo de audiência são descartadas por completo, sem um grupo “outros” e sem um total publicado que permita deduzir o valor suprimido. Os detalhamentos por cidade da Apple e os Shazams por cidade costumam ser o primeiro lugar onde um catálogo menor percebe isso: streams saudáveis e um gráfico de cidades vazio. Isso é intencional e não existe exceção, porque a alternativa seria publicar algo sobre um punhado de ouvintes identificáveis.

Até que ponto os números estão atualizados, e por que eles mudam

As lojas reportam com atraso, e cada feed sai em um ritmo diferente, então, em um mesmo dia, uma métrica pode estar atualizada até uma data mais recente que outra. Por isso cada métrica traz duas datas: uma data de último reporte, a data mais recente com dados, e uma data de dados completos, a data mais recente que pode ser tratada como definitiva. O que fica entre as duas ainda está sendo preenchido, e o painel marca esses períodos como parciais, para que um dia reportado pela metade não pareça uma queda. É normal que a ponta final de um gráfico suba quando você voltar a olhar. Um gráfico que cai na data de último reporte significa que a loja ainda não reportou as datas seguintes.

A profundidade do histórico acompanha a mesma divisão dos feeds. O Spotify e o Apple Music têm anos de histórico. As lojas que entraram nesta atualização, Deezer, Boomplay, AWA, Audiomack e os três serviços da Tencent, têm histórico desde aproximadamente o fim de janeiro de 2026, quando seus feeds começaram a chegar.

Atividade nas redes sociais e de UGC em torno do seu catálogo

Os dados de redes sociais acompanham o que as pessoas fazem com a sua música fora dos DSPs, e cada plataforma reporta a sua parte:

• Reproduções no SoundCloud, além de reposts e favoritos, com os territórios correspondentes
• Criações de conteúdo no Snapchat (ou seja, usos da música), além de visualizações e alcance por território
• Criações e visualizações por território no Instagram e no Facebook, além do crescimento de seguidores e de engajamento na conta do artista
• Criações e visualizações por território no WhatsApp e no Messenger, sem nenhum feed de conta por trás
• No Threads, só visualizações e alcance, porque o feed dele reporta consumo, e não criações

Elas formam uma família separada do streaming, com feeds diferentes e outro eixo de plataforma, e continuam separadas: uma visualização de UGC ou uma criação de conteúdo nunca entra no total de streams de um DSP. Ficam só no painel e, de propósito, não são expostas na API pública, então uma integração que leia /analytics/* nunca vai encontrar números do SoundCloud ou da Meta ali.

37 chaves de seção e um endpoint que as mapeia

Os dados de streaming estão na API pública, restritos aos seus próprios selos e identificados por ISRC no campo de identificador. GET /analytics/summary é o endpoint composto: você escolhe de uma a doze das 37 chaves de seção, com o parâmetro obrigatório metrics[]. Se ele faltar, a resposta é um 422, de propósito, e uma seleção com mais de doze é rejeitada, então você divide em várias requisições, que têm cache independente. Quinze endpoints avulsos cobrem as séries individuais, de streams e ouvintes a salvamentos, pulos, taxa de conclusão, divisão por dispositivo e por origem, além dos recortes demográficos e geográficos. Os rankings trazem os top-N filtrados por selo, artista, lançamento ou faixa, e os posicionamentos podem ser filtrados por plataforma.

GET /api/public/analytics/summary
  ?metrics[]=streams
  &metrics[]=listeners
  &metrics[]=streams-by-country
  &filter[platform]=SPOTIFY
  &filter[start_date]=2026-01-01
  &filter[end_date]=2026-07-01

filter[platform] aceita SPOTIFY, APPLE_MUSIC, DEEZER, BOOMPLAY, AWA, AUDIOMACK, KUGOU, KUWO e QQMUSIC e, se for omitido, devolve todas as plataformas com dados na sua conta. Cada resposta de resumo traz a periodicidade da plataforma em meta.platform_cadence e, por seção, as duas datas de atualização em meta.sections_as_of e meta.sections_complete_through, para que o cliente possa exibir como provisórias as datas ainda em preenchimento e deixá-las fora dos totais do período.

Os períodos vão até 400 dias no resumo e nos quinze endpoints de séries, o que dá um ano inteiro mais um período de comparação em uma única chamada. Rankings e posicionamentos param em 180 dias, porque um ranking de um intervalo mais longo não pode ser montado de forma honesta a partir de janelas menores. Requisições que passam de 90 dias são contabilizadas em um segundo limite de taxa, mais restrito, somado ao limite padrão de analytics; requisições de 90 dias ou menos não são afetadas.

Antes de fixar no código qualquer detalhe por loja descrito acima, chame GET /analytics/availability. Ele não recebe parâmetros, é estático e pode ficar em cache, e devolve a matriz completa de seção por plataforma mais o mapa de periodicidade em uma única resposta. Se você construir em cima dele, uma loja nova que aparece no feed vira uma mudança de dados, e não de código.

Ou pergunte ao seu assistente

O servidor MCP da LabelGrid é uma camada fina e tipada sobre essa mesma API pública, então qualquer cliente do Model Context Protocol, como Claude Desktop, Claude Code ou Cursor, consegue ler diretamente o desempenho do seu catálogo. “Quais das minhas faixas cresceram na Alemanha no mês passado, e em qual loja” vira uma pergunta que você faz, em vez de quatro exportações que você precisa conciliar. A camada herda tudo o que está acima, inclusive as regras de disponibilidade, a periodicidade semanal e as datas de atualização, e herda também as ausências: os números de redes sociais não estão na API, então também não estão lá. O post de lançamento do MCP explica a configuração e o modelo de permissões.

Tudo isso já está no ar no painel. O analytics, incluindo o conjunto avançado, vem com todos os planos padrão; o acesso à API e ao MCP faz parte dos planos de API da LabelGrid. A página de analytics traz o detalhamento por loja, e a página de preços mostra o mapa de planos.

Perguntas frequentes