Как мы работаем с данными и для чего был написан сервис

Отчеты готовятся с использованием АПИ счетчиков, серверных данных, парсинга на сервер с БД и с крутящимися на сервере скриптами для анализа и обработки потока.

На основе работы скриптов строятся отчеты + периодически производятся дополнительные кастомные исследования в среде Юпитер Ноутбук.

Так например происходит объединение в тематические кластеры поисковых запросов и запросов из платного поиска (ML, работа по признакам) с дальнейшем расчетом эффективности по каждому кластеру. Или другой пример — по такому пути, в бесконечном цикле парсится выдача поисковых систем и отслеживаются конкуренты в платном поиске с расчетом их объемов показа по разным часам и дням недели и т.п.

Клиентам конечные данные предоставляются в виде развернутых дашбордов в Google Data Studio и в формате быстрых авто-репортов с помощью телеграм-ботов и решений на Matplotlib. Если ко второму вопросов нет, и тема с доставкой компактных отчетов ботами устраивает полностью, то со Студией периодически возникают недопонимания.

Из-за периодических багов Студии, отчеты иногда требуется доводить до ума руками. Это не очень комфортно и отнимает дополнительное время, которого всегда нет. Плюс не стоит исключать, что для клиентов в России в какой-то момент Google Data Studio может быть заблокирован.

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

Так и появилось желание сделать свою платформу отчетов с функционалом загрузки данных и перевода выгруженных данных в графики — без избыточного функционала и с большей простотой обращения (все что мне было нужно от студии — визуализация подготовленных данных, взаимодействие по АПИ и ничего более).

Интерфейс проекта

В рамках структуры сервиса все объекты внутри разделены на дашборды, контейнеры данных и контейнеры графиков.

Пошаговая работа с сервисом

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

Вторым этапом создаются контейнеры данных.

Данные заполняются:

• посредством АПИ-запроса к сервису;
• руками (загрузка CSV-файлов в формате utf-8 и разделителем “;”, или копирование данных из файлов CSV напрямую в соответствующее окно).

Строки отображаются в верхнем изменяемом контейнере + выстраиваются в таблицу внизу контейнера.

Валидность загруженных данных можно сразу проверить внизу контейнера (данные отобразятся в формате таблицы — если таблица не поломалась, то все хорошо).

Третьим этапом на основе данных в контейнерах собираются соответствующие графики. Для MVP я воспользовался опенсорс-библиотекой ChartJS, которая предоставила наиболее нужные сущности для генерации графиков (линии, столбцы, пироги и т.п.).

Настройка графика. Все настройки появляются только после того, как график будет подключен к данным.
В настройке графиков я предусмотрел работу с несколькими линиями данных и другие очевидные вещи, которым разумно было сделать настройки. Количество данных по Y можно задавать любое кол-во.

Доп.функционал

Т.к. собираемые дашборды делаются для клиентов, предусмотрел систему социальных связей между пользователями, в рамках которых возможно делиться дашбордами с графиками для просмотра с другими пользователями.

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

Пример дашборда:

Стек проекта:

• Бекенд сервиса реализован на Django;


• Фронтенд выполнен на нативном JS;


• DRF используется только для загрузки в контейнеры данных по API;


• В АПИ используется авторизационный токен с реализацией через библиотеку Djoser;


• На стороне визуала графиков используется опенсорс-библиотека ChartJS.

Доступен по ссылке:
intervals.ru