Промокод в Тильде: настройка, ограничения и отслеживание

Промокод в Тильде - это не одна фича, а связка из трёх слоёв: встроенного модуля скидок в Tilda Store, кастомного JS-кода в корневых блоках сайта и внешней логики учёта, если нужна честная статистика по каждому купону. Я настраивал промокоды для десятков магазинов на Tilda - от простых сезонных скидок до программ с ограничением по email и категориям товаров - и в этой статье разберу, что умеет штатный функционал, где он упирается в потолок и как я закрываю эти дыры скриптом.

Как настроить промокод в Тильде через встроенный модуль магазина

В настройках сайта открываю раздел «Магазин» → вкладка «Промокоды». Модуль появляется, когда на сайте подключён Tilda Store (T‑Cart), и работает одинаково независимо от того, какой способ оплаты подключён - эквайринг банка, наличные при получении или оплата на реквизиты.

Что задаю при создании кода:

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

На практике для магазина на 200-300 товаров этого достаточно для разовой акции: скидка ко дню рождения бренда, промокод для рассылки, код для блогера-партнёра. Покупатель вводит код в корзине, сумма пересчитывается прямо в блоке T‑Cart без перезагрузки страницы.

Ограничения промокода в Тильде: с чем сталкиваюсь на реальных проектах

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

Отдельная проблема - валидация на клиенте. Расчёт скидки в штатном модуле происходит в браузере, и сумма заказа, которую видит эквайринг при оплате, формируется тем же JS. Для акций до 10-15% это не критично, но когда цена вопроса - сотни тысяч рублей оборота, я всегда рекомендую держать серверную проверку хотя бы для кодов с большим номиналом.

Кастомный скрипт для промокода в Тильде: когда встроенного модуля мало

Когда нужен персональный код, ограничение по категориям или защита от подбора, я пишу отдельный JS-блок, который подключается к событиям корзины T‑Cart (tcart:updateProducts, tcart:amount) и подменяет стандартную логику применения скидки. Код на клиенте только собирает данные и показывает результат - сама проверка и пересчёт суммы уходят на бэкенд.

document.addEventListener('tcart:updateProducts', function () {
  var promo = document.getElementById('promoInput');
  if (!promo) return;

  promo.addEventListener('change', function () {
    fetch('https://api.example.ru/promo/validate', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        code: promo.value,
        cart: window.tcart.products
      })
    })
      .then(function (r) { return r.json(); })
      .then(function (data) {
        if (data.valid) {
          window.tcart.amount = data.newAmount;
          tcart__reDrawCart();
        }
      });
  });
});

Бэкенд для такой проверки - это отдельный сервис, который хранит список кодов, лимиты и уже использовавшие код email в базе на сервере в РФ. Простая доработка вроде ограничения по одной категории товаров у меня стоит от 3 000 ₽, а комплексная интеграция с расчётом скидки, привязкой к CRM, эквайрингом и пересчётом стоимости доставки СДЭК - от 40 000 ₽, потому что там нужно синхронизировать минимум три системы и держать серверную валидацию на каждом шаге.

Готовые заготовки под похожие сценарии - с проверкой промокода, счётчиком остатка активаций и логированием - у меня собраны в библиотеке готовых скриптов для Tilda, оттуда обычно и стартую доработку под конкретный магазин.

Отслеживание промокодов: аналитика и статистика применения

Штатная статистика Tilda по промокодам - это счётчик активаций в списке кодов, без разбивки по датам, суммам заказов или источникам трафика. Для отчёта маркетологу или блогеру-партнёру этого мало, поэтому применение кода я обычно логирую отдельно.

Схема, которая у меня прижилась на большинстве проектов: событие применения промокода из блока корзины уходит вебхуком в n8n, оттуда запись падает в таблицу на своём сервере и параллельно летит уведомление в Telegram через бота на aiogram - так владелец магазина видит в реальном времени, кто и на какую сумму воспользовался кодом, не заходя в админку Tilda. Настройка такой цепочки в n8n у меня стоит от 25 000 ₽, отдельный Telegram-бот на aiogram - от 30 000 ₽, но чаще это делается в одном пакете вместе с доработкой самого промокода.

Если нужна просто привязка к рекламным кампаниям, а не полноценный учёт, хватает целей в Яндекс.Метрике на событие применения кода - без бэкенда, но и без данных о повторном использовании одним и тем же покупателем.

Промокод и оплата: T‑Bank, эквайринг и доставка СДЭК

Скидка по промокоду должна попадать в сумму, которую видит платёжный шлюз, иначе получится ситуация, когда клиент видит одну цену в корзине, а к оплате через Т‑Банк или другой эквайринг уходит другая. На встроенном модуле это работает штатно, но на кастомных скриптах - только если сумма пересчитывается до вызова платёжной формы, а не после.

Я всегда завожу пересчёт на этапе формирования заказа на сервере: клиентский JS применяет скидку визуально, а бэкенд перед отправкой в Т‑Банк ещё раз проверяет код, лимит и итоговую сумму. Так исключается ситуация, когда пользователь через консоль браузера подменяет параметр скидки в объекте корзины.

Отдельно обрабатываю промокоды на бесплатную доставку СДЭК - тут скидка идёт не на товар, а на стоимость доставки, которая на Tilda обычно считается динамически через виджет СДЭК. Код должен обнулять именно эту часть суммы после расчёта тарифа, а не вычитаться из общей стоимости заказа задним числом - иначе при разных весах и городах скидка либо не покрывает реальную доставку, либо наоборот занижает сумму к оплате.

Типичные ошибки при настройке промокода в Тильде

За несколько лет доработок повторяются одни и те же промахи:

• скидка считается только на клиенте - код можно применить бесконечное число раз через прямой запрос к API, минуя интерфейс;
• не выставлен лимит активаций - акция «первым 50 покупателям» без ограничения превращается в бессрочную скидку для всех;
• дата окончания не задана или задана без учёта часового пояса сервера Tilda;
• промокод тестируют сразу на боевом эквайринге - из-за этого в выписке появляются тестовые платежи с реальной скидкой;
• один и тот же код раздают через несколько каналов без разбивки - потом невозможно понять, кто из партнёров привёл больше заказов.

Большая часть этих проблем решается на этапе проектирования логики, а не патчами после запуска акции - закладывать лимиты, серверную проверку и логирование стоит сразу, если промокод рассчитан не на разовую акцию, а на постоянную работу.

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

Можно ли сделать в Тильде промокод только для одного покупателя?

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

Как ограничить промокод одной категорией товаров в Tilda?

Встроенными настройками - никак, скидка там применяется ко всей сумме заказа. Нужен скрипт, который перебирает товары в корзине через объект window.tcart.products, сверяет артикулы или категории с списком на сервере и пересчитывает скидку только для подходящих позиций.

Виден ли промокод в стандартной аналитике Tilda?

В статистике заказов видно, что промокод применён, и его название, но без разбивки по датам, суммам и источникам трафика. Для отчёта партнёру или маркетологу этого обычно недостаточно, поэтому применение кода я логирую отдельно - через n8n в собственную таблицу или базу на сервере.

Можно ли использовать один промокод на нескольких сайтах Tilda?

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