Таргетолог ведёт 15 клиентов: отчёты и креативы на одном сервере

MAATRIX

Пятнадцать клиентов — это пятнадцать папок с отчётами, пятнадцать наборов креативов в разных стадиях согласования и пятнадцать чатов, где кто-то просит «скинуть ещё раз баннер, тот, что заходил лучше всех». Рано или поздно вы отправляете макет клиента А клиенту Б, теряете креатив, который просили доработать три недели назад, или полчаса ищете отчёт за июнь среди файлов с именами вида «отчет_финал_2.pdf». Дальше — про то, как собрать всё это в одну структуру на своём сервере, чтобы каждый клиент был на своей полке, а вы тратили время на рекламу, а не на архивариуса.

Где на самом деле теряется время

Стандартный набор инструментов таргетолога — это Google Drive для одних клиентов, Яндекс.Диск для других (кто-то из клиентов настоял), плюс WhatsApp и Telegram, куда падают срочные правки к креативам, плюс личный ноутбук, где скопилось «на всякий случай» ещё одна копия всего. Проблема не в том, что где-то не хватает места — проблема в том, что у каждого сервиса своя логика папок, свои права доступа и своя история версий, а у вас в голове одна закладка «где это лежало».

Типичные потери времени, которые складываются в часы за неделю:

• поиск нужного варианта креатива среди пяти файлов с похожими именами;
• переспрашивание клиента, какой отчёт он имел в виду, потому что у вас их три с разными датами в названии;
• случайная отправка не тому клиенту — ссылка на диск скопирована из старого чата;
• восстановление доступа, когда клиент сменил телефон и не может открыть ссылку из общего диска;
• ручное сведение креативов, присланных дизайнером, дизайнером-фрилансером и самим клиентом — в трёх разных местах.

Отдельная головная боль — конфиденциальность. Клиент А не должен видеть, какие результаты и бюджеты у клиента Б, даже случайно, даже если это соседняя папка на одном диске. Публичные облака с расшаренными ссылками для этого плохо приспособлены: ссылка живёт вечно, если её не отозвать вручную, а вспомнить, кому и что вы дали доступ полгода назад, невозможно.

Идея: один сервер, чёткая структура, отдельная зона на каждого клиента

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

Практический каркас, который работает для агентства на 10-20 клиентов:

/clients
  /client-ivanov-mebel
    /01_brief          — бриф, ТЗ, договорённости
    /02_creatives
      /active           — то, что сейчас крутится
      /archive          — снятые с показа, но нужны для истории
      /drafts           — на согласовании
    /03_reports
      /monthly
      /weekly
    /04_access          — скриншоты кабинетов, доступы (если разрешено хранить)
  /client-petrov-stomatologiya
    ...

Ключевое здесь — не сама структура (у вас может быть своя логика), а то, что она *одинаковая* для всех клиентов и живёт в одном месте. Когда структура предсказуема, вы за секунду понимаете, где искать, даже если не открывали папку клиента месяц.

Разворачиваем хранилище: Nextcloud на своём сервере

Проще всего собрать такую систему на Nextcloud — это открытое файловое хранилище с веб-интерфейсом, синхронизацией и гибкими правами доступа, которое ставится на обычный VPS. Подробный пошаговый разбор установки есть в отдельном материале — как установить и настроить Nextcloud на VPS, здесь остановлюсь на том, что специфично именно для работы с рекламными кабинетами клиентов.

После установки создаёте структуру папок из предыдущего раздела прямо в веб-интерфейсе или через WebDAV — это быстрее для массового переноса существующих файлов:

# Подключаем Nextcloud как сетевой диск через WebDAV (Linux, davfs2)
sudo apt install davfs2
sudo mkdir /mnt/nextcloud
sudo mount -t davfs https://ваш-домен/remote.php/dav/files/ВАШ_ЛОГИН/ /mnt/nextcloud

После монтирования перенос старых файлов с диска или из облака — обычное копирование через rsync, что удобно, если у вас уже накопился архив за пару лет:

rsync -avh --progress /home/user/Отчеты_старые/ /mnt/nextcloud/clients/

Для каждого клиента заводите отдельного пользователя или группу в Nextcloud (Настройки → Пользователи), даже если реально с системой работаете только вы. Это не бюрократия — это заготовка под доступ, который вы дадите клиенту позже, без переноса файлов и без опасений, что он случайно увидит соседнюю папку.

Если у вас не один человек, а небольшая команда (SMM-специалист, дизайнер, ассистент), группы в Nextcloud позволяют дать дизайнеру доступ только к папкам 02_creatives во всех клиентах, а отчёты оставить закрытыми — права настраиваются на уровне папки, а не выдаются на всё хранилище целиком.

Доступ клиентам: показываем отчёт, не открывая всё остальное

Отдельная ссылка на файл или на общую папку клиента — это именно то, ради чего затевалась вся структура. В Nextcloud расшаривание работает через публичные ссылки с ограничениями, и это удобнее, чем механизм ссылок в потребительских облаках:

• ссылку можно выдать только на конкретную подпапку (/03_reports/monthly), не открывая доступ к брифам и черновикам других клиентов;
• можно поставить пароль на ссылку и срок действия — например, месяц, после чего доступ автоматически закроется;
• можно дать право только на просмотр (Read Only), чтобы клиент не мог случайно удалить или переименовать файл;
• в логах видно, кто и когда обращался к папке — полезно, когда клиент утверждает, что «отчёт не приходил».

Создать ограниченную ссылку из командной строки (пригодится, если хотите автоматизировать выдачу доступа):

sudo -u www-data php occ sharing:list-shares --uid=admin
sudo -u www-data php occ files_sharing:create \
  --path="/clients/client-ivanov-mebel/03_reports/monthly" \
  --shareType=3 --expireDate=2026-09-30 --permissions=1

(shareType=3 — публичная ссылка, permissions=1 — только чтение; точные флаги стоит свериться с версией Nextcloud, которая у вас установлена, — команда occ files_sharing:create --help покажет актуальный набор параметров).

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

Куда падают креативы без ручной раскладки

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

Во-первых, единый формат имени файла — задаётся один раз для всей команды и соблюдается всеми, включая дизайнеров-фрилансеров:

{клиент}_{формат}_{дата}_{версия}.{расширение}
ivanov-mebel_stories_20260825_v2.mp4

Во-вторых, папка-входящая (/00_inbox) в общей структуре, куда дизайнер или клиент скидывает всё новое без разбора по клиентам — а раз в день (или сразу после получения) вы переносите файлы в нужные подпапки. Это избавляет от ситуации, когда файл должен попасть точно в нужное место с первого раза под давлением дедлайна.

В-третьих, если объём действительно большой (баннеры, видео для нескольких клиентов одновременно), можно настроить простой скрипт, который раскладывает файлы по префиксу имени — это не заменяет ручную проверку, но снимает механическую часть:

#!/bin/bash
# sort-creatives.sh — раскладывает файлы из inbox по клиентским папкам
INBOX="/mnt/nextcloud/clients/00_inbox"
BASE="/mnt/nextcloud/clients"

for f in "$INBOX"/*; do
  fname=$(basename "$f")
  client=$(echo "$fname" | cut -d'_' -f1)
  dest="$BASE/$client/02_creatives/drafts"
  if [ -d "$dest" ]; then
    mv "$f" "$dest/"
    echo "Перемещён: $fname -> $dest"
  else
    echo "Клиент не найден для файла: $fname — оставлен в inbox"
  fi
done

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

Резервная копия: креативы клиента не должны пропасть из-за диска

Отдельный сервер снимает зависимость от чужого облака, но добавляет ответственность за резервные копии — теперь это ваша задача, а не задача Google или Яндекса. Минимальная схема, которая закрывает основной риск (сбой диска, случайное удаление):

• ежедневный снапшот дисков на уровне провайдера, если такая опция доступна для арендованного сервера;
• еженедельная выгрузка архива клиентских папок во внешнее S3-совместимое хранилище через rclone — это разносит копию географически и не зависит от состояния основного сервера;
• отдельное хранение договоров и брифов (текстовые документы весят мало, но стоят дороже всего при потере) — их имеет смысл дублировать даже чаще, чем креативы.

Настройка rclone для регулярной синхронизации в S3-совместимое хранилище и сам подход к такому резервному хранилищу подробно разобраны в материале про S3-совместимое хранилище у себя — если у вас уже есть второй сервер или объектное хранилище, синхронизация настраивается одной строкой в cron:

0 3 * * 0 rclone sync /mnt/nextcloud/clients remote:backup-clients --log-file=/var/log/rclone-backup.log

Отдельно про сам Nextcloud: у него есть встроенные механизмы бэкапа и восстановления конфигурации и базы данных, без которых бэкап одних файлов неполон — если сервер выйдет из строя целиком, важно восстановить не только содержимое папок, но и права доступа, пользователей и активные ссылки. Это отдельная тема, разобранная в материале про бэкап и восстановление данных Nextcloud.

Какой сервер для этого нужен

Для 15-20 клиентов с отчётами и креативами (видео в основном формате, баннеры, презентации) хранилище редко превышает несколько сотен гигабайт в первый год — но растёт стабильно, потому что архивные материалы никогда не удаляются, только копятся. Разумный старт — VPS с 4 ГБ RAM и SSD-диском на 200-500 ГБ, с возможностью нарастить диск позже без переустановки системы. Нагрузка на процессор у Nextcloud с файловым хранилищем невысокая — это не видеомонтаж и не рендеринг, основная нагрузка приходится на дисковые операции при синхронизации и на редкие пиковые моменты, когда несколько клиентов одновременно скачивают отчёты.

Если параллельно с хранилищем вы держите на том же сервере рекламные трекеры или свою аналитику, конфигурацию стоит пересчитать отдельно — этому посвящён материал про то, сколько ресурсов нужно VPS для маркетолога и трекера, там же разобран выбор между российским и зарубежным размещением с точки зрения доступа к рекламным кабинетам.

Локацию сервера стоит выбирать исходя из того, откуда чаще заходят клиенты и вы сами: для аудитории в основном из России и СНГ ближе будет сервер в РФ или в европейской локации с низкой задержкой, для работы с зарубежными кабинетами — UK или US, особенно если часть рекламных платформ и так требует стабильного зарубежного IP для работы кабинетов.

Частые вопросы