С аналитикой подкастов всё очень не очень. Мы полгода занимаемся разработкой бесплатной платформы для подкастеров mave.digital и в этой статье собрали все откровения и подводные камни по подкастерской статистике.
Ключевые выводы:
- Все цифры врут. Некоторые больше, некоторые меньше.
- При выбора подкаста обязательно уточняйте его хостинг, разные платформы считают прослушивания по разному.
- Soundcloud может завышать число реальных прослушиваний в 2 раза, особенно у длинных эпизодов.
- Anchor может завышать прослушивания и не отображает корректно источники трафика
- Собственный хостинг может завышать прослушивания на 30% и больше.
- Доверять стоит IAB-стандарту и платформам, работающим на нём: mave.digital, simplecast, libsyn.
Как вообще работает аналитика подкастов?
Чтобы пользователь смог прослушать подкаст, аудиофайл должен быть размещён на любом хостинге (свой сайт, платформы). Загрузить подкаст напрямую в Apple или Google Podcasts, Яндекс.Музыку или Spotify нельзя.
К хостингу, на котором лежит аудио-файл стриминговая платформа обращается каждый раз, как пользователь включает подкаст. Эти обращения и учитываются в статистике.
Это позволяет собирать:
- Географию прослушиваний (страна/город)
- Статистику по распределению платформ прослушивания
- Операционную систему и тип устройств
- Число прослушиваний, уникальные прослушивания и устройства
Пока всё просто. Но уже встречаются нюансы:
- Не все стриминговые сервисы обращаются за аудио-файлом каждый раз. Яндекс.Музыка, ВКонтакте, Spotify (последний пока не актуален для СНГ) скачивают файл 1 раз и дальше раздают его самостоятельно, не обращаясь больше к хостинг-платформы. Поэтому данные по числу прослушиваний оставляют у себя.
- Пользователь может начать воспроизведение подкаста несколько раз.
- Apple и их экосистема (об этом поговорим отдельно).
- Технические запросы.
- Данные по по полу и возрасту аудитории есть только у стриминговых сервисов (не у всех).
Все врут: сколько прослушиваний на самом деле?
Не каждое обращение к серверу является реальным прослушиванием. Сейчас мы в mave фильтруем 26% от всех запросов, которые к нам поступают. Под фильтрацией имеем в виду, что не записываем их в фактически прослушивания подкастов.
Почему это важно знать? Мы работаем по стандартам и рекомендациям IAB. Так делают не все. А даже те, кто так делает, может искажать статистику.
Ниже статистика одного и того же подкаста на двух платформах Anchor и mave:
Полтора месяца переписок с технической поддержкой Anchor не пролили свет на появление 59% неразмеченных прослушиваний подкаста.
Откуда берутся 59% «неизвестных прослушиваний» по мнению сервиса:
1. Вы вставляете свой подкаст на сторонние ресурсы (нет)
2. Пользователи слушают ваш подкаст через мобильный браузер (что?)
3. Прослушивания приходят из источников, которые Anchor не можем определить
После того, как этот же подкаст мы перенесли на mave и проанализировали источники прослушиваний, этого «неизвестного трафика» найти не удалось.
Неожиданным оказалось ещё и то, что одинаковый подкаст на Anchor и mave собирал разное число прослушиваний. В Anchor прослушиваний было в среднем на 30% больше за аналогичный период времени в ежедневном подкасте, где сложно говорить о «зашёл выпуск и не зашёл».
Если прибавить в статистику тестируемого подкаста весь фильтруемый трафик, который вообще нельзя относить к реальным прослушиваниям, показатели по числу прослушиваний начинали совпадать, из чего мы теперь сомневаемся ещё и в качестве фильтрации трафика Anchor.
Для того, чтобы на 100% убедиться в правдивости своей гипотезы, мы перенесли этот же подкаст ещё и на simplecast, статистика показала аналогичный с mave результат:
Откуда берутся «лишние прослушивания» и почему их надо фильтровать?
Практически у каждой платформы есть бот, который обращается к сервису для выгрузки или для проверки доступности подкаста. Например, такой бот есть у Яндекс.Музыки, Spotify, Deezer, Google Podcasts, Amazon, Overcast и прочих.
Что это значит на практике: к серверу регулярно могут обращаться UserAgent вроде Ya.Music/2020-12-21.trunk.7706547, Spotify 1.0, Googlebot-Video и т.д. Подобные обращения ни в коем случае нельзя считать за прослушивания.
У нас фильруется около 90 различных UserAgent в данный момент. Каждый запрос от UserAgent из этих 90 — это ненастоящее прослушивание. От одного такого UserAgent может прийти как 1 запрос, так и 10/100.
Также фильтруем запросы от Apple: Apple клиенты – Официальное приложение Apple Podcasts делают запросы объемом в 2 байта (диапазон 0-1), такие запросы должны всегда исключаться из обработки. Эти запросы делает Apple, чтобы убедиться, что файл можно скачать, используя байт-запросы и они всегда сопровождаются еще одним или несколькими запросами следом. Лучше всего – полностью игнорировать все запросы в диапазоне 0-1 байта.
Плюс под фильтр попадают запросы с IP-адресов, которые не входят в white list
— IP адреса, не принадлежащие реальным пользователям.
— IP адреса, которые инициируют большие объемы скачиваний/обращений к хостингу, должны проверяться на потенциальные мошенничества. На текущий момент в нашем списке более 500 IP-адресов и он обновляется каждые 10 дней.
Что считать прослушиванием?
Любое обращение к серверу за аудио-файлом нельзя считать прослушиванием. Разные платформы за воспроизведение принимают разные параметры.
Google и Apple Podcasts считают прослушиванием воспроизведение в течении 5 секунд, Яндекс разделяет прослушивания на Старты и Стримы. Старт - любая инициация воспроизведения, Стрим - прослушивание больше 120 секунд, при этом учитываются воспроизведения только от авторизированных пользователей. У ВКонтакте похожая система, где старты - любой запуск подкаста, а Слушатели - прослушивание от минуты.
А в SoundCloud прослушиванием считается любое нажатие на кнопку Play, что приводит к тому, что статистика по подкастам на SoundCloud может завышаться в 2 раза и более. Да и накрутить туда прослушивания проще всего, от 100 рублей за 500 прослушиваний и полетели.
И это только верхушка разночтений учёта прослушиваний подкастов.
Так что делать и кому верить?
На наш взгляд, самый адекватный подход к аналитике подкастов это рекомендации IAВ.
На основе IP и UserAgent мы трекаем сколько раз пользователь слушал подкаст в течение 24 часов и записываем только один раз.
Например, пользователь слушал эпизод подкаста с того же устройства и IP-адреса вначале в 10:00, потом в 16:00, потом в 20:00 в этот же день. Тогда мы запишем в прослушивания 1. Но если он послушает в 10:00 во вт, скажем, а потом в 11:00 в среду, то это уже будет 2 прослушивания, но 1 уникальное.
Интересная вещь про Apple Podcasts. На подкасты слушатели подписываются.
А Apple радостно скачивается новые выпуски подкастов, на которые оформлена подписка. Поэтому на 100% определить реальное ли это прослушивание с Apple или скачивание по умолчанию не получится. Кроме того, все устройства Apple объединённые одним Apple ID, на которых есть приложение подкастов (а это все устройства), всё также радостно скачивают новый эпизод.
Пример: у меня есть айфон и макбук. Apple скачает эпизод на все устройства. При этом, если у пользователя есть еще Мак с тем же Apple ID, что и на iPhone, то придет 2 запроса к серверу: с Мака и Айфона.
1 из запросов мы фильтуем, записываем только 1. Фильтруем тот, который пришел второй, практически всегда — это Мак.
Плюс мы вообще не учитываем прослушивания с Apple Watch. Это рекомендация IAB, подробнее тут, но смысл тот же. Правда так поступают пока не все. Simplecast, который сертифицирован по IAB, должен был начать фильтровать такие запросы с 1 октября 2020, но не делает этого.
Как реально посчитать прослушивания подкаста для покупки рекламы?
Не все подкаст-платформы одинаково полезны. Часть завышает данные, часть просто не фильтрует лишние обращения.
- Мы рекомендуем доверять IAB-стандарту, по которому сейчас работают mave.digital, Libsyn, SimpleCast (учитывает Apple Watch завышая прослушивания немного). Таких площадок куда больше, чем 3 перечисленные, полный список тут на второй вкладке.
- Прослушивания с SoundCloud часто можно делить на 2.
- Собственный хостинг на WP или другом решении самый
«ненадёжный» формат для учёта аналитики подкастов. Статистику можно исправить вручную, а заниматься фильтрацией запросов по аналогии с подкаст-платформами, специализирующимися на этом, вряд ли станет рядовой подкастер. А это значит, что завышение числа фактически прослушиваний относительно реальных на 30%+ практически гарантированно.
С другой стороны в такую связку можно поставить плагин Blubrry, или пропускать трафик через podtrac или chartable и статистика будет корректной. - Anchor, самый популярный бесплатный хостинг для подкастов, может завышать фактические прослушивания. Вероятно они не фильтруют часть запросов от ботов и не следуют всем рекомендациям IAB.
- К статистике самой хостинг-платформы дополнительно придётся суммировать стримы с Яндекса и ВКонтакте.
Статья написана командой подкаст-платформы mave.digital, предоставляющей бесплатный и безлимитный хостинг для подкастеров с отслеживанием чартов Apple Podcasts, расширенной статистикой и переносом статистики при миграции с Anchor.