Как страница SalesMachine получила реальные данные вместо заглушки
Публичная витрина SalesMachine показывала ошибку загрузки метрик. Разобрали, откуда взять реальные цифры, и подключили их за один день.
Публичная страница SalesMachine — системы лидогенерации и автоматизации B2B-продаж, которая каждый день рассылает холодные письма клиникам и бизнесам с предложением автоматизации через страницу услуг — показывала посетителям не цифры, а блок с ошибкой “Не удалось загрузить метрики”. Backend отвечал заглушкой “not implemented yet”. Витрина, которая должна демонстрировать, что продукт реально работает, вместо этого демонстрировала обратное.
Данные были, просто не туда доходили
Первое, что выяснилось при разборе: считать метрики было не нужно с нуля. SalesMachine временно работает не на основном сервере, а на резервной машине, и там уже существовал полностью рабочий скрипт, который правильно вычисляет нужные показатели из логов ответов, базы лидов и истории отправок. Проблема была не в вычислении цифр, а в том, что этот скрипт стучался в мёртвый адрес — старый домен, который на текущем сервере вообще не обслуживается. Получал в ответ ошибки уровня “метод не поддерживается” или “не найдено”, потому что принимающей стороны на сервере попросту не существовало. Показательный момент: заглушка на публичном API и мёртвый адрес у отправителя — два независимых симптома одной и той же более широкой проблемы, миграции продукта на новый домен, которая где-то осталась незавершённой.
Почему ошибка легко было принять за более крупную проблему
Столкнувшись с “приёмного конца нет вообще” легко предположить, что нужно строить целую новую инфраструктуру для приёма метрик — отдельный сервис, отдельный деплой, отдельный мониторинг. На деле у соседнего проекта портфеля уже был общий backend, обслуживающий похожую задачу для другого продукта — оставалось добавить туда два новых маршрута: один отдаёт сохранённые метрики наружу, второй принимает их с авторизацией по токену и сохраняет в тот же файл, который читает публичная витрина. Nginx уже проксировал нужный путь на этот backend — менять конфигурацию сервера не пришлось вообще, только код за уже существующим адресом. Переиспользование готовой инфраструктуры вместо новой сэкономило не столько время написания кода, сколько избежало ещё одного отдельного сервиса, за которым потом придётся отдельно следить.
Мелочи, которые ломают интеграцию между разными машинами
По пути всплыли ещё две мелкие, но обязательные для реальной работы детали. В коде backend’а был захардкожен CORS-заголовок со старым доменом — без правки браузер просто заблокировал бы запросы с актуального домена как обращение с чужого источника, и метрики продолжали бы не загружаться уже по новой причине. А в конфигурации на резервной машине оказался незамеченный дубликат одной и той же переменной окружения с токеном — при такой коллизии побеждает первое совпавшее значение, а не последнее, и итоговый токен без явной проверки мог тихо оказаться не тем, что ожидалось.
Реальные цифры вместо блока ошибки
После починки обеих сторон — приёмника на основном сервере и отправителя на резервной машине — прогнали интеграцию вживую, а не понадеялись, что раз обе части по отдельности выглядят правильно, значит и вместе они сработают. Скрипт отчитался об успехе, а публичная страница получила настоящие данные: 1484 отправленных письма, 72 ответа, 23 заинтересованных лида, 5 готовых к встрече, 1 подтверждённая бронь, 2298 лидов ещё в резерве, доля ответивших 4,85%. Не круглые, не отредактированные для красоты цифры — ровно то, что реально накопилось в базе к этому моменту.
Решение осознанно временное: запуск ручной, не по расписанию, потому что SalesMachine пока работает на резервной машине как переходный вариант. Для регулярного автоматического обновления понадобится либо периодически перезапускать скрипт руками, либо отдельно настраивать автоматизацию именно на той машине, где сейчас крутится продукт — это уже следующий шаг, а не часть этой задачи. Разница между “починили один раз, чтобы витрина ожила сегодня” и “построили постоянный конвейер обновления” здесь принципиальна: первое можно сделать за один день, второе требует решения, где именно в итоге будет жить сам продукт — а этот вопрос ещё открыт.
Про то, зачем вообще появилась страница, на которую теперь можно уверенно ссылаться в письмах, — в посте про страницу услуг для холодных писем.
Рассылка новых статей
Выберите, куда присылать новые статьи и разборы — без спама, только новые материалы.
Чтобы получать статьи на email, сначала привяжите email в личном кабинете.
Чтобы получать статьи в Telegram, войдите через Telegram-кнопку на странице входа.
Получайте новые статьи и разборы
Подпишитесь через email — без спама, только новые материалы.