От калькулятора до SaaS: история создания SEO-прогноза

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

Глава 1: Математическое ядро

В основе любого прогноза лежит декомпозиция. Нельзя просто провести линию через исторические данные. Трафик — это сумма нескольких компонентов:

Компонент 1: Тренд. Общее направление роста или падения, очищенное от всех колебаний. Для его построения была выбрана простая, но надежная линейная регрессия — метод, который строит прямую линию, наилучшим образом описывающую набор данных.

Компонент 2: Сезонность. Регулярные годовые циклы (например, падение спроса на кондиционеры зимой). Сезонность рассчитывалась классическим методом с усреднением по месяцам.

Компонент 3: Брендовый и небрендовый трафик. Трафик по брендовым запросам (например, 'купить озон') ведет себя иначе, чем небрендовый ('купить холодильник'). Модель разделяет их и применяет процент роста от SEO только к небрендовой части прогноза.

Глава 2: Проблема 'Дня сурка'

Инструмент был полезен, но страдал амнезией. Каждый раз, когда пользователь обновлял страницу, все его данные, настройки и результаты исчезали. Задача превратилась из «сделать калькулятор» в «построить приложение с бэкендом».

Глава 3: Выбор стека — Firebase to the Rescue

Создавать свой бэкенд с нуля для такой задачи — избыточно и долго. Выбор пал на Firebase, который закрывал сразу все потребности: аутентификацию, облачную базу данных и хостинг.

Глава 4: Аутентификация — грабли веб-версии

Казалось бы, что может быть проще, чем добавить кнопку «Войти через Google»? Но именно здесь начались самые большие трудности, связанные со спецификой Flutter Web.

Проблема: Постоянно меняющееся API Google Sign-In. Старые туториалы перестали работать. Новые версии требовали сложной, асинхронной инициализации и работы через потоки событий, особенно для веба.

Решение: Создание гибридной системы. В main.dart была добавлена ранняя инициализация GoogleSignIn.instance.initialize(). В AuthService была встроена логика, которая слушает authenticationEvents. Для веба используется специальный виджет google_sign_in_web.renderButton(), а для мобильных — кастомная кнопка.

Глава 5: Хранение и шаринг отчетов

Когда аутентификация была решена, оставалось «просто» сохранять данные.

Firestore: структура и запись. Для хранения отчетов была создана коллекция forecast_reports. Каждый документ в ней — это объект ForecastReport. В качестве ID документа используется уникальный UUID.

Ключевым моментом стала возможность поделиться отчетом. Но как сделать его публичным, но защищенным от редактирования? Решение: Правила безопасности Firestore. Было написано правило, которое разрешает чтение одного документа любому, но запись - только владельцу этого документа.

Заключение: От идеи до работающего сервиса

Этот путь наглядно показывает, как простая утилита может эволюционировать в полноценный сервис. Главными уроками стали: не бояться бэкенда (BaaS-платформы помогают); платформенные различия — это реальность; безопасность — не опция. В итоге, инструмент прогнозирования стал не просто калькулятором, а полезным рабочим инструментом с памятью и возможностью совместной работы.