Гgosha_techspec15 сентября

Время на прочтение 11 минОхват и читатели

Хабы: CRM-системы, API, Email-маркетинг, Визуализация данных

Аналитика рассылок в GetCourse: как собирать статистику сейчас и чего ждать от нового API

Меня зовут Георгий, я техспец и больше пяти лет настраиваю GetCourse для онлайн-школ, в том числе собираю для них статистику рассылок. За это время поработал примерно с десятком проектов: фитнес, психология, инвестиции, обучение профессиям, детское образование, эзотерика. Кроме настройки платформы пишу код и много работаю с нейросетями, в основном с ChatGPT и Claude.

Аналитика рассылок нужна почти каждой школе. В кабинете GetCourse у каждой рассылки есть своя карточка со статистикой: сколько сообщений ушло и дошло, сколько было просмотров, кликов и отписок, какие ошибки вернули почтовые сервисы. Чего в кабинете нет, так это общего отчёта, где все рассылки за период стоят рядом: чтобы сравнить письма между собой, увидеть динамику по неделям или отделить почту от Telegram, цифры приходится собирать самому. Ниже мой нынешний способ собирать эти цифры и мысли о том, что поменяет официальный метод для рассылок в API, который GetCourse обещает выпустить в ближайшее время.

Зачем школам статистика рассылок из GetCourse

Чаще всего статистику просит маркетолог. Ему нужно понять, какие письма прогрева читают, и показать это на планёрке. Собственник приходит с тем же вопросом реже, обычно после запуска, когда выручка оказалась ниже плана и хочется найти место, где потерялись люди. Продюсеры в последний год всё чаще спрашивают про Telegram: многие школы перенесли туда часть касаний и хотят сравнить его с почтой.

Внутри GetCourse у каждой рассылки есть своя статистика: сколько сообщений отправлено и доставлено, сколько было просмотров, кликов, ответов и отписок, какие ошибки вернулись. Подробно этот раздел описан в базе знаний, в статье «Статистика в рассылке». Чтобы проверить одно письмо, этого хватает. Трудности начинаются, когда нужно сравнить десятки рассылок между собой или посмотреть, как менялись цифры по неделям.

Самый показательный случай был в начале сентября. Школа проводила запуск и отправила в один день 16 писем, каждое под свой сегмент базы. Через пару дней собственник открыл отчёт и спросил, куда делись пять тысяч человек: в сегментах было 19 тысяч, а писем ушло 14,8 тысячи. Ничего не потерялось, но чтобы это объяснить, пришлось восстанавливать цепочку по шагам. К этой истории я вернусь в разделе про сегменты.

Как я собираю статистику рассылок сейчас

Официального метода для рассылок в API GetCourse пока нет. В API GetCourse есть выгрузка пользователей, заказов и платежей, в Tech API есть заказы, пользователи, диалоги, уроки и вебинары. Рассылок нет ни там, ни там.

Поэтому для школ я делаю небольшой сервис, который берёт цифры из того же списка рассылок, что видит администратор в разделе «Рассылки». Работает он под учётной записью сотрудника школы, с его обычными правами. Вход подтверждает человек, пароль сервис не видит и не хранит.

Список рассылок в GetCourse со статистикой по каждой рассылке — Список рассылок в аккаунте GetCourse: у каждой строки уже есть отправленные, просмотры, клики и отписки

Устроено это так:

Сервис живёт на VPS и каждый день в 05:20 по Москве проходит по вкладке «Черновики и отправленные». В одной из школ там около двух тысяч рассылок, это двадцать страниц по сто строк и примерно 45 секунд работы.
Цифры у свежих рассылок растут ещё несколько дней после отправки. Однажды я десять минут смотрел на одно письмо, и просмотры за это время выросли с 471 до 479. Поэтому рассылки за последние 45 дней сервис перепроверяет каждый день, а первого числа месяца проходит весь список целиком.
GetCourse показывает только текущие значения. Историю сервис ведёт сам: новая запись появляется, когда у рассылки поменялась хотя бы одна цифра.
Готовые данные уходят в дашборд, где их смотрят маркетолог и собственник.

Технически это сервер на Node.js и дашборд на React. Данные лежат в файле на сервере в России, так проще с персональными данными. Большую часть кода я писал вместе с Claude и ChatGPT. Нейросеть быстро собирает рабочий черновик, а я проверяю логику в тех местах, где она ошибается чаще всего, особенно в датах и пустых значениях.

Схема сбора статистики рассылок GetCourse в дашборд — Как цифры попадают из GetCourse в дашборд

Какие показатели рассылок нужны для нормальной аналитики

В отчёт у меня попадают отправленные и доставленные сообщения, ошибки доставки, просмотры, переходы и отписки. Набор небольшой, но по нему уже видно, в каком месте проблема. Дальше важнее то, как эти цифры считать.

Сначала складываю числа, потом считаю проценты

В карточке рассылки GetCourse общее количество сообщений складывается из доставленных, сообщений с ошибками и запрещённых, и процент просмотров посчитан от доставленных. Для одного письма этого достаточно. Когда я свожу данные за месяц или запуск, то сначала складываю просмотры и доставленные по всем рассылкам и только потом делю одно на другое. Если усреднять готовые проценты, письмо на 300 человек весит столько же, сколько рассылка на 40 тысяч, и средняя открываемость получается далёкой от реальной.

У кликов в карточке рассылки GetCourse показывает два процента, например «38 кликов (0.1% / 3.4%)». Первый посчитан от всех сообщений, второй от просмотров. Второй полезнее: он показывает, сколько людей из открывших письмо дошли до ссылки.

Карточка рассылки GetCourse: статистика рассылки и статистика пользователей — Карточка одной рассылки: доставлено, ошибки, просмотры, клики и отписки с причинами

Открытиям доверяю меньше всего

Некоторые почтовые сервисы загружают письмо сами, ещё до того, как его увидел человек. Так делает, например, Apple Mail с включённой защитой конфиденциальности. GetCourse засчитывает это как просмотр. Поэтому открываемость я использую только для сравнения писем одной школы между собой, а выводы делаю по переходам и отпискам.

У Telegram-рассылок нет открытий

Здесь я сначала ошибся сам. У Telegram-рассылок в списке есть и просмотры, и клики, и эти числа всегда совпадают. Оказалось, что оба означают переходы по ссылкам, причём появляются они только там, где включено отслеживание ссылок. В одной школе за май–июль такое отслеживание было включено у 147 рассылок из 265. Если считать открываемость Telegram так же, как у почты, получаются странные цифры. В дашборде у Telegram открываемости нет вообще, а переходы считаются только по рассылкам с включённым отслеживанием.

«Нет статистики» не означает ноль

У части рассылок GetCourse пишет «нет статистики». В одной из школ таких нашлось 253 из 1 856, почти все в Telegram. Если записать их как ноль просмотров, средние показатели проседают без всякой причины. Такие рассылки я в расчёт процентов не беру.

Сегментация: как сделать аналитику рассылок полезной

Средняя открываемость школы за месяц мало что говорит. Польза появляется, когда те же цифры можно разложить по каналам, категориям и запускам.

По каналам

Почта и Telegram у меня всегда идут разными линиями на недельном графике. Сравнивать их в лоб нельзя из-за разных знаменателей, зато хорошо видно, когда школа начала переносить касания в Telegram и как после этого вела себя почта.

Недельный тренд переходов по почте и Telegram в дашборде рассылок — Сводка и недельный тренд по каналам. Цифры демонстрационные

По категориям рассылок

У рассылки в GetCourse можно указать категорию. Если школа договорилась проставлять их всегда (прогрев, продажа, сервисные письма), в дашборде появляется разбивка по категориям. Обычно по ней сразу видно, что сервисные письма читают почти все, а у продающих рассылок к третьему письму подряд заметно растут отписки.

Лучшие и худшие письма

Рейтинг писем по открываемости я строю только по рассылкам, в которых доставлено больше 500 писем. Пока порога не было, наверху списка оказывалось письмо на 36 адресов с открываемостью 34%, и никакого вывода о тексте из этого сделать нельзя.

Рейтинг лучших и худших писем по открываемости с порогом по доставленным — Лучшие и худшие письма периода. Цифры демонстрационные

По запуску и сегментам базы

Теперь про пять тысяч человек. Запуск резали на 16 писем под разные сегменты, и отчёт по обычному списку рассылок тут не помогал: в нём видно письмо, но не видно, какому сегменту оно ушло. Для запусков я сделал отдельную панель, где рядом стоят четыре числа:

29 422 человека во всех сегментах вместе, с пересечениями;
19 057 после того, как из каждого сегмента убрали людей, попавших в соседние;
15 253 адреса, которые GetCourse отобрал для отправки;
14 788 писем отправлено.

Больше всего теряется на переходе от людей к адресам, около 20%. У части людей нет почты, часть отписалась, а два человека с одним адресом превращаются в одну строку. В базе этой школы доля таких совпадений составляет 15–20%. Когда все четыре числа видны сразу, вопрос «где пять тысяч» больше не возникает.

Разбивка запуска по сегментам: люди в сегментах, адреса и отправленные письма — Панель запуска: путь от людей в сегментах до отправленных писем. Названия сегментов и разбивка по ним условные

Размеры сегментов нужно записывать в день отправки. Сегменты в GetCourse динамические, и через неделю тот же фильтр покажет другое число.

Почему текущий способ упирается в ограничения

Главная слабость в том, что путь неофициальный. Сервис читает страницу, сделанную для людей, и зависит от того, как она устроена.

Вход действует 31 день и от работы сервиса не продлевается. Раз в месяц сотрудник школы входит заново, дашборд напоминает об этом за неделю.
Любое изменение интерфейса может сломать сбор. В сентябре свежие рассылки перестали появляться на дашборде. Выяснилось, что для писем, отправленных сегодня и вчера, GetCourse пишет дату словами, например «сегодня 10:23». Сервис такой формат не понимал, рассылка оставалась без даты и не попадала ни в один период. Через день-другой дата в списке становилась обычной, письмо появлялось само, и поэтому ошибку долго не замечали. Первым её увидел собственник школы.
Список отдаёт не больше ста рассылок на страницу, так что у большой школы полный проход занимает десятки запросов.
Данные по отдельным получателям (кто и когда открыл письмо или перешёл по ссылке) в интерфейсе есть, но собирать их таким способом слишком тяжело. В дашборде только сводные цифры по рассылкам.

Как я выстраиваю сбор данных, чтобы дальше всё работало автоматически

После пары поломок у меня сложилось несколько правил.

Сбор должен падать заметно. Если на странице не нашлось ни одной строки, сервис останавливается с ошибкой. Если бы он молча записал нули, дашборд выглядел бы рабочим и показывал неправду.

Строки без даты считаются отдельно. Если таких больше десятка, в лог уходит предупреждение. Скорее всего, GetCourse снова поменял формат, и лучше узнать об этом в тот же день.

Правила расчёта живут в одном месте. Сбор только переписывает цифры, а то, как складывать проценты и что делать с Telegram, описано один раз. Когда у школы появился второй дашборд, он стал запрашивать готовые цифры у первого и ничего не собирает сам. Два сервиса под одной учётной записью мешали бы друг другу.

Данные хранятся на российском сервере, наружу смотрит только дашборд под паролем.

Что изменится с появлением официального API GetCourse

В начале сентября в партнёрском чате GetCourse спросили, будут ли методы для статистики рассылок. Команда ответила, что метод выпустят в ближайшее время и он будет аналогичен getMailings. Это метод из SDK Chatium, платформы для приложений поверх GetCourse, и по его описанию уже можно понять, чего ждать.

getMailings отдаёт список рассылок с фильтрами по названию, категории, каналу и типу. У каждой рассылки есть блок info со счётчиками:

cnt_sent — отправлено;
cnt_viewed — просмотрено;
cnt_clicked — переходы;
cnt_unsubscribed — отписки;
cnt_errors — ошибки;
счётчики сообщений в очереди, отменённых, ограниченных и ответов.

Это те же цифры, которые мой сервис сейчас берёт из списка рассылок. На 15 сентября в документации Tech API раздела про рассылки ещё нет, поэтому названия полей и параметры в итоговом методе могут отличаться.

Почему после выхода API такие задачи станет решать проще

Когда метод появится, я переведу сбор на него и уберу из схемы самые хрупкие места.

Вместо входа раз в месяц будет ключ API. Настроил один раз и забыл. Выгрузка заказов у GetCourse ограничена ста запросами за два часа на весь аккаунт, а запросы к Tech API в моей практике в эту квоту не упирались.
Изменения интерфейса перестанут ломать сбор. Ошибок вроде той, с датой «сегодня 10:23», станет гораздо меньше.
Школам без программиста станет проще. Статистику можно будет забирать в Google Таблицу скриптом по расписанию или через сервисы интеграций, когда они добавят поддержку метода.

Часть работы всё равно останется. Судя по описанию getMailings, метод отдаёт текущие счётчики, значит историю по дням придётся хранить у себя. Правила расчёта тоже остаются на стороне школы: API отдаст просмотры у Telegram-рассылок, а интерпретировать их как переходы придётся самому. Размеры сегментов на день отправки через API тоже не восстановить.

Я слежу за документацией и, как только метод выйдет, перенесу на него сбор в своих проектах. Если вы уже собираете статистику рассылок GetCourse своим способом, расскажите в комментариях, как это устроено у вас.

Георгий, техспец онлайн-школ. Автоматизирую GetCourse кодом и нейросетями. Telegram: @Georgiy_dev