스트리밍·소셜 애널리틱스 확장

비어 있는 차트와 0으로 가득한 차트는 서로 다른 의미이고, 둘 중 하나만 사실일 수 있습니다. Boomplay는 스트림 수와 국가별 스트림 수를 제공하지만 저장 수는 제공하지 않습니다. 그래서 Boomplay의 저장 차트에는 0으로 평평한 선을 그려 아무도 이 음원을 저장하지 않은 것처럼 보이게 하는 대신, 이 스토어가 저장 수를 제공하지 않는다고 적어 주어야 합니다.

이 구분은 7월에 공개한 애널리틱스 확장 업데이트 전체에 깔려 있습니다. LabelGrid 애널리틱스는 이제 애널리틱스 피드를 보내오는 모든 스토어를 다룹니다. Spotify, Apple Music, Deezer, Audiomack, Boomplay, AWA, 그리고 Tencent의 세 서비스인 Kugou, Kuwo, QQ Music입니다. 카탈로그를 둘러싼 소셜 및 UGC 활동도 그 옆에 나란히 표시되며, SoundCloud부터 Snapchat과 Meta 앱까지 이어집니다. 스트리밍 데이터는 이제 공개 API와 오픈소스 MCP 서버를 통해 프로그래밍 방식으로도 가져올 수 있습니다.

데이터를 보내오는 스토어, 그리고 스토어별 제공 지표

유통 범위는 이 목록보다 넓습니다. 아래는 LabelGrid가 애널리틱스 피드를 수집하는 스토어 목록이며, 이 차이는 알아 둘 만합니다. 정산서와 애널리틱스는 서로 다른 파이프라인으로 처리되기 때문에, 애널리틱스 피드를 공개하지 않는 스토어의 활동도 로열티 정산서에는 그대로 반영됩니다.

스토어	주기	제공 지표
Spotify	매일	가장 폭넓은 지표: 스트림, 리스너, 저장, 스킵, 공유, 참여율, 스트림 유입 경로, 기기, 인구통계
Apple Music	매일	스트림, 리스너, 라이브러리 추가, 에디토리얼 플레이리스트 추가, Shazam, 도시별·스토어프런트별 세부 지표
Deezer	매일	스트림, 지역, 기기, 리스너 인구통계, 평균 청취 시간, 플레이리스트 등재
Audiomack	매일	스트림, 리스너, 저장, 지역
Boomplay	매일	스트림, 국가별 스트림
AWA	매일	스트림
Kugou, Kuwo, QQ Music	매주	스트림

이 표의 모양이 핵심입니다. 스킵, 공유, 스트림 유입 경로, 시간대, 오디오 포맷은 Spotify만 제공합니다. Shazam, 라이브러리 추가, 에디토리얼 플레이리스트 추가는 Apple Music만 제공합니다. Shazam은 다른 곳에 같은 지표가 없는 Apple 고유의 신호이기 때문입니다. 재생 횟수가 아니라 사람 수를 세는 리스너 인구통계는 Spotify와 Deezer가 제공합니다. 국가별 스트림은 Spotify, Apple Music, Deezer, Boomplay, Audiomack은 제공하지만 AWA는 제공하지 않습니다. AWA의 피드에는 ISO 국가 코드 대신 일본 내 하위 지역 코드가 담겨 있기 때문입니다. 이 내용을 외울 필요는 없습니다. 대시보드가 스토어별로 어떤 지표를 지원하는지 보여 주고, API도 같은 매트릭스를 데이터로 제공합니다.

플레이리스트 등재도 같은 방식입니다. Spotify 행에는 플레이리스트 이름과 소유자, 스트림 수가 담깁니다. Apple Music 행에는 에디토리얼 플레이리스트의 이름과 곡이 올랐던 최고 순위가 표시되는데, 일부 행에는 재생 횟수가 아예 없어 '미제공'으로 표시됩니다. Deezer 행은 ID가 확인되면 공개 플레이리스트로 연결됩니다.

스토어를 합쳐서 보거나, 비교하거나, 하나씩 살펴보세요

사람들이 이 데이터로 하는 일은 대부분 세 가지 보기 모드로 해결됩니다. 통합 모드는 모든 스토어를 하나의 수치로 합산합니다. 비교 모드는 스토어를 나란히 놓고 보여 주며, 전체 비교 모드는 새로 추가된 스토어를 알아서 포함하므로 기존 비교에 새 스토어를 따로 넣어 줄 필요가 없습니다. 개별 모드는 스토어 하나의 상세 화면으로 바로 들어갑니다. 차트는 일, 주, 월 단위로, 또는 자동으로 볼 수 있습니다. 성과 상위 목록은 지표별 탭으로 나뉘어 있고, 플레이리스트 등재에는 스토어별 필터가 있습니다.

Tencent 스토어는 주 1회 데이터를 보냅니다

Kugou, Kuwo, QQ Music은 주 단위로 보고합니다. 한 주에 곡마다 데이터 포인트가 하나 생기고, 리포트가 다루는 날짜로 기록되며 그 한 주 전체의 수치를 담습니다. 주간 합계를 임의로 만든 일별 값으로 쪼개는 일은 없습니다. 그래서 일별 차트에서는 이 세 스토어가 일주일에 하루만 값이 채워지고 나머지 날짜는 비어 있습니다.

이 빈 날짜는 누락이 아니라 정상입니다. 기간 합계는 그대로 맞고, 보고 주기는 대시보드와 API 응답에 표시되므로 연동 시스템도 주 단위로 보고하는 스토어와 활동이 없어 비어 있는 스토어를 구분할 수 있습니다.

지표에 '사용 불가'라고 표시될 때

대시보드에서는 스토어가 제공하지 않는 지표에 플랫폼별로 그 사실이 표시됩니다. API에서는 지원 현황 매트릭스가 0으로 채운 시계열 대신 해당 칸을 not_available_for_platform으로 반환합니다. 가장 뚜렷한 사례는 플레이리스트 등재 화면입니다. Apple Music의 에디토리얼 행에는 플레이리스트 이름과 곡이 올랐던 순위는 있어도 그 옆에 재생 횟수가 없을 수 있는데, 이는 '미제공'을 뜻합니다. 이를 0으로 바꾸면 수치의 의미 자체가 달라지고, 그 값으로 계산한 모든 평균이 실제가 아닌 바닥값 위에 놓이게 됩니다.

개인정보 보호 기준도 방향만 반대일 뿐 같은 논리로 작동합니다. 인구통계와 지역별 분석은 k-익명화를 거치기 때문에, 최소 청취자 수 기준에 못 미치는 칸은 아예 빠집니다. 기타 항목으로 묶지도 않고, 가려진 수치를 역산할 수 있는 합계를 공개하지도 않습니다. 규모가 작은 카탈로그는 보통 Apple의 도시별 분석과 도시별 Shazam에서 이를 먼저 알아차립니다. 스트림은 충분한데 도시 차트는 비어 있는 경우입니다. 의도된 설계이고 예외 설정은 없습니다. 예외를 두면 몇 안 되는, 신원을 알아볼 수 있는 청취자에 관한 정보를 공개하게 되기 때문입니다.

수치는 얼마나 최신이고, 왜 달라지는지

스토어는 시차를 두고 보고하고 피드마다 발행 일정도 다릅니다. 그래서 같은 날이라도 어떤 지표는 다른 지표보다 더 최근 날짜까지 반영되어 있을 수 있습니다. 지표마다 날짜가 두 개 붙는 이유입니다. 데이터가 있는 가장 최근 날짜인 보고 기준일, 그리고 최종 수치로 봐도 되는 가장 최근 날짜인 확정 기준일입니다. 두 날짜 사이 구간은 아직 채워지는 중이어서 대시보드가 부분 집계로 표시하고, 덕분에 절반만 보고된 하루가 급락처럼 보이지 않습니다. 나중에 다시 열어 보면 차트의 끝부분이 올라가 있을 수 있습니다. 차트가 보고 기준일에서 끊긴다면 스토어가 그 이후 날짜를 아직 보고하지 않았다는 뜻입니다.

과거 데이터의 깊이도 피드에 따라 갈립니다. Spotify와 Apple Music은 몇 년 전까지 거슬러 올라갑니다. 이번에 추가된 Deezer, Boomplay, AWA, Audiomack과 Tencent의 세 서비스는 피드가 들어오기 시작한 2026년 1월 말경부터의 이력이 있습니다.

카탈로그를 둘러싼 소셜 및 UGC 활동

소셜 지표는 DSP 밖에서 사람들이 내 음악으로 무엇을 하는지 보여 주며, 플랫폼마다 제공하는 범위가 다릅니다.

SoundCloud 재생 수, 리포스트와 좋아요, 그리고 각각의 지역별 분포
Snapchat 콘텐츠 생성 수(음악이 사용된 횟수)와 지역별 조회 수·도달 범위
Instagram과 Facebook의 지역별 콘텐츠 생성 수와 조회 수, 아티스트 계정의 팔로워 및 참여도 증가
WhatsApp과 Messenger의 지역별 콘텐츠 생성 수와 조회 수(계정 피드는 없음)
Threads는 조회 수와 도달 범위만 제공(피드가 콘텐츠 생성이 아니라 소비를 보고하기 때문)

이 지표들은 스트리밍과 피드도 다르고 플랫폼 구분도 달라서 별개의 계열로 두고, 섞지 않습니다. UGC 조회나 콘텐츠 생성이 DSP 스트림 합계에 들어가는 일은 없습니다. 대시보드에서만 제공하고 공개 API에는 일부러 노출하지 않으므로, /analytics/*를 읽는 연동 시스템에서는 SoundCloud나 Meta 수치를 찾을 수 없습니다.

37개 섹션 키, 그리고 이를 한데 모으는 엔드포인트 하나

스트리밍 데이터는 공개 API로 제공되며, 내 레이블로 범위가 한정되고 식별자 필드에는 ISRC가 들어갑니다. GET /analytics/summary는 종합 엔드포인트입니다. 필수 파라미터인 metrics[]로 37개 섹션 키 중 1개에서 12개를 골라 요청합니다. 이 파라미터를 빼면 의도적으로 422를 반환하고, 12개를 넘겨 고르면 거부되므로 여러 요청으로 나눠야 합니다. 요청마다 캐시는 따로 적용됩니다. 개별 시계열은 15개의 독립 엔드포인트가 맡습니다. 스트림과 리스너부터 저장, 스킵, 완주율, 기기별 비율, 유입 경로별 비율은 물론 인구통계와 지역별 분석까지 포함됩니다. 리더보드 엔드포인트는 레이블, 아티스트, 릴리스, 트랙으로 필터링한 상위 N개 순위를 돌려주고, 플레이리스트 등재는 플랫폼별로 필터링할 수 있습니다.

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]에는 SPOTIFY, APPLE_MUSIC, DEEZER, BOOMPLAY, AWA, AUDIOMACK, KUGOU, KUWO, QQMUSIC을 넣을 수 있고, 생략하면 계정에 데이터가 있는 모든 플랫폼이 돌아옵니다. 종합 응답에는 해당 플랫폼의 보고 주기가 meta.platform_cadence에, 섹션별 최신성 날짜 두 개가 meta.sections_as_of와 meta.sections_complete_through에 담깁니다. 클라이언트는 이를 보고 아직 채워지는 날짜를 잠정치로 표시하고 기간 합계에서 빼 둘 수 있습니다.

조회 기간은 종합 엔드포인트와 15개 시계열 엔드포인트에서 최대 400일입니다. 1년 전체에 비교 기간까지 한 번의 호출에 담을 수 있는 길이입니다. 리더보드와 플레이리스트 등재는 180일까지입니다. 짧은 구간을 이어 붙여서 더 긴 기간의 순위를 정직하게 만들어 낼 수는 없기 때문입니다. 90일을 넘는 요청에는 기본 애널리틱스 한도 위에 더 엄격한 두 번째 요청 한도가 함께 적용되고, 90일 이하 요청은 영향을 받지 않습니다.

위에 적은 스토어별 세부 사항을 하드코딩하기 전에 GET /analytics/availability를 먼저 호출해 보세요. 파라미터가 없고 정적이어서 캐시할 수 있으며, 섹션별 플랫폼 지원 현황 매트릭스 전체와 보고 주기 맵을 한 번에 반환합니다. 이를 기준으로 개발하면 피드에 새 스토어가 들어와도 코드를 고치는 대신 데이터만 바뀝니다.

AI 어시스턴트에게 물어볼 수도 있습니다

LabelGrid MCP 서버는 같은 공개 API를 타입만 입혀 얇게 감싼 래퍼입니다. 그래서 Claude Desktop, Claude Code, Cursor 같은 Model Context Protocol 클라이언트라면 카탈로그의 성과를 바로 읽어 올 수 있습니다. "지난달 독일에서 성장한 트랙은 무엇이고, 어느 스토어에서였나"를 내보내기 파일 네 개를 맞춰 보는 대신 질문 한 번으로 해결합니다. 이 래퍼는 지원 현황 규칙, 주 단위 보고 주기, 최신성 날짜까지 위 내용을 그대로 물려받고, 빠진 것도 그대로 물려받습니다. 소셜 수치는 API에 없으니 여기에도 없습니다. 설정 방법과 권한 모델은 MCP 출시 게시글에서 다룹니다.

모두 지금 대시보드에서 쓸 수 있습니다. 고급 지표까지 포함한 애널리틱스는 모든 스탠더드 플랜에 들어가고, API와 MCP 이용은 LabelGrid의 API 플랜에서 제공됩니다. 스토어별 세부 내용은 애널리틱스 페이지에, 플랜 구성은 요금 페이지에 있습니다.

자주 묻는 질문

LabelGrid는 어떤 스토어의 스트리밍 애널리틱스를 보여 주나요?

Spotify, Apple Music, Deezer, Audiomack, Boomplay, AWA는 매일, Tencent의 세 서비스인 Kugou, Kuwo, QQ Music은 매주 보고합니다. 이 스토어들이 LabelGrid가 애널리틱스 피드를 수집하는 대상입니다. 유통이 닿는 스토어는 이보다 많고, 나머지 스토어의 활동도 로열티 정산서에는 그대로 나타납니다. 정산서와 애널리틱스가 서로 다른 파이프라인으로 처리되기 때문입니다.

어떤 스토어는 지표를 보여 주는데, 다른 스토어는 왜 사용 불가라고 나오나요?

스토어마다 보고하는 항목이 다르기 때문입니다. Spotify는 스킵과 공유, 스트림 유입 경로를 보고하고, Apple Music은 Shazam, 라이브러리 추가, 에디토리얼 플레이리스트 추가를 보고합니다. 리스너 인구통계는 Deezer와 Spotify가 제공하고, Boomplay는 스트림과 국가별 스트림을, AWA는 스트림을 보고합니다. 스토어가 보고하지 않는 지표는 LabelGrid가 0을 그려 넣지 않고 해당 플랫폼에서는 사용할 수 없다고 표시합니다. 인구통계와 지역별 분석에는 k-익명화도 적용되므로, 규모가 작은 카탈로그는 스트림이 충분한데도 인구통계나 도시 차트가 비어 있을 수 있습니다. 최소 청취자 수 기준에 못 미치는 칸은 아예 빠지며, 기타 항목으로 묶지도 않고 가려진 수치를 역산할 수 있는 합계도 공개하지 않습니다.

Kugou, Kuwo, QQ Music은 왜 주당 데이터 포인트가 하나뿐인가요?

이 세 스토어가 주 단위로 보고하기 때문입니다. 한 주에 곡마다 데이터 포인트가 하나 생기고, 리포트가 다루는 날짜로 기록되며 그 곡의 한 주 전체 수치를 담습니다. LabelGrid는 주간 합계를 임의로 만든 일별 값으로 나누지 않으므로, 일별 차트에서는 일주일에 하루만 값이 채워지고 나머지 날짜는 비어 있습니다. 이 빈 날짜는 누락이 아니라 정상이고, 기간 합계는 그대로 맞으며, 대시보드와 API 응답 모두 보고 주기를 알려 줍니다.

지난주 수치가 제가 본 뒤에 왜 올랐나요?

스토어는 시차를 두고 보고하고, 피드가 하루치를 다 보내기 전에 일부만 먼저 넘기기도 합니다. 모든 지표에는 데이터가 있는 가장 최근 날짜인 보고 기준일과, 최종 수치로 봐도 되는 가장 최근 날짜인 확정 기준일이 있습니다. 두 날짜 사이는 아직 채워지는 중이라 부분 집계로 표시되니, 나중에 다시 보면 차트 끝부분이 올라가 있을 수 있습니다. 차트가 보고 기준일에서 끊긴다면 스트림이 멈춘 것이 아니라 스토어가 그 이후 날짜를 아직 보고하지 않았다는 뜻입니다.

API나 AI 어시스턴트로 애널리틱스를 가져올 수 있나요?

스트리밍 데이터는 가능합니다. 공개 API에는 37개 섹션 키를 다루는 종합 summary 엔드포인트, 15개의 독립 시계열 엔드포인트, 그리고 리더보드와 플레이리스트 등재용 엔드포인트 2개가 있습니다. 별도의 availability 엔드포인트는 섹션별 플랫폼 지원 현황 매트릭스 전체와 보고 주기 맵을 한 번의 호출로 반환합니다. summary와 시계열은 최대 400일, 리더보드와 플레이리스트 등재는 180일까지 조회할 수 있습니다. 오픈소스 MCP 서버가 같은 API를 감싸고 있어 Claude나 Cursor 같은 어시스턴트도 API가 내주는 내용을 그대로 읽습니다. 소셜 및 UGC 수치는 대시보드에서만 제공되며 공개 API에는 의도적으로 넣지 않았습니다.