Вы ведёте рекламу в трёх кабинетах и хотите видеть все расходы в одном месте. Готовый отчёт этого не показывает, потому что данные лежат в разных системах. Очевидное решение — каждую ночь складывать их в Google Таблицу и строить сверху графики.
#Почему таблица — правильный первый шаг
Начинать с базы данных не стоит. Таблица даёт то, чего не дают готовые отчёты: заказчик видит данные сразу и может их менять. Он добавляет колонку и пишет свою формулу. За неделю такого использования становится понятно, какие цифры ему на самом деле нужны, а какие он просил «на всякий случай».
Это самый дешёвый способ выяснить требования. Мы и дальше начинаем с таблицы, когда задача новая.
Но она должна быть черновиком, а не решением.
#Где таблица перестаёт работать
Объём. Один кабинет за месяц — это несколько тысяч строк. Три кабинета за год — далеко за сотню тысяч. Таблица технически выдерживает, но формулы на таком объёме пересчитываются десятки секунд, а открытие файла превращается в ожидание.
Хрупкость. Отчёт держится на формулах, которые ссылаются на диапазоны. Заказчик вставляет колонку посередине — половина формул начинает считать не то. Ошибки нигде не видно: цифры просто становятся другими. Самая дорогая поломка — та, которую не отличить от нормальной работы.
История. Таблица хранит состояние, а не историю. Если ключом в ней стало название кампании — а так выходит почти всегда, потому что название видно, а id нет, — то после переименования вчерашние цифры уже нечем сопоставить с сегодняшними.
Права. Дать доступ к дашборду обычно означает дать доступ и к сырым данным: защищённые диапазоны и доступ «только просмотр» спасают не всегда, а отдельные права на отдельные строки в одном файле сделать нечем.
#Что ставить вместо таблицы
Три слоя вместо одного файла.
Сбор. Сценарий каждую ночь забирает данные из каждого кабинета через API и складывает в базу. У каждой строки есть дата, кабинет, кампания и стабильный идентификатор — не название. Переименование больше ничего не ломает.
База. Postgres. История накапливается, старые данные не переписываются. Сравнение периодов становится обычным запросом, а не отдельным листом в файле.
Показ. Отдельная страница на своём домене: графики, фильтры, выгрузка. Заказчик видит цифры и не видит сырых таблиц. Права разграничивают: кому смотреть, кому править.
Сверху при необходимости добавляют админку под конкретный процесс: изменить ставку, пометить кампанию, оставить комментарий ко дню.
#Сколько стоит замена
Больше на старте и меньше дальше.
Таблица — это несколько часов. Собственное решение — один-два дня: сбор, схема базы, страница показа. Дальше расходы сводятся к хостингу.
Момент перехода виден по конкретным признакам. Если узнаёте хотя бы два пункта — таблица уже стоит вам дороже, чем замена:
- отчёт открывается дольше десяти секунд;
- кто-то хотя бы раз сломал формулы, вставив колонку;
- вы не можете сравнить этот месяц с прошлогодним;
- доступ к дашборду приходится давать вместе с сырыми данными;
- цифры в таблице и в кабинете расходятся, и никто не знает почему.
#Каких ошибок не делать
Не переносите формулы в базу. Логика отчёта должна быть в одном месте — в запросе или в коде страницы. Половина в SQL, половина в формулах — это та же хрупкость, только сложнее.
Не храните агрегаты вместо сырых данных. Складывать можно всегда, раскладывать обратно — нет. Пишите в базу дневные строки, а суммы считайте в запросе.
Не выбрасывайте таблицу совсем. Выгрузка в неё — нормальная функция дашборда. Заказчик привык считать там, и забирать эту возможность незачем.
#Выводы
- Таблица — самый дешёвый способ выяснить, какие цифры нужны. Как черновик она правильная.
- Ломается она на объёме, на формулах, на отсутствии истории и на правах доступа.
- Замена — три слоя: ночной сбор, база с историей, отдельная страница показа.
- Ключ в данных — идентификатор, а не название кампании.
- Выгрузку в таблицу стоит оставить: заказчик привык считать именно там.
#Частые вопросы
#Можно ли остаться на таблице, если кабинет один?
Да. Один кабинет и несколько тысяч строк таблица держит нормально. Проблемы начинаются со вторым источником и с первым годом истории.
#Не проще ли взять готовый BI-сервис?
Часто проще, и мы так делаем, когда задача типовая. Собственное решение выигрывает тогда, когда нужны действия, а не только просмотр: изменить ставку, пометить кампанию, свести рекламу со сделками в CRM.
#Что делать с данными, которые уже накопились в таблице?
Перенести один раз в базу. Это разовый скрипт: история сохраняется, и сравнение с прошлыми периодами остаётся возможным.
#Источники
- Google Sheets API — Limits — ограничения на запросы и объём
- Из собственного опыта