Сбор отзывов через email после покупки: реализация на Laravel

Сбор отзывов о покупке через email

После успешной покупки клиент часто забывает оставить отзыв. Письма, отправленные сразу после оплаты, игнорируются — пользователь ещё не успел воспользоваться товаром. Если же отправить запрос слишком поздно, покупатель теряет интерес. Мы решаем эту проблему с помощью отложенной отправки письма через 14 дней после покупки, с прямой оценкой в теле письма и умным роутингом: высокая оценка ведёт на Google или Trustpilot, низкая — на форму приватного отзыва. Такой подход повышает конверсию в отзыв на 40% по нашим кейсам, а количество негативных публичных отзывов снижается на 60%.

Почему email — лучший канал для сбора отзывов?

Email обеспечивает персональный контакт: письмо приходит в личный ящик, содержит контекст покупки и не требует дополнительных действий от клиента. В отличие от всплывающих окон на сайте или push-уведомлений, email не блокируется и читается в удобное время. По нашим данным, конверсия в отзыв через email в 2.5 раза выше, чем через pop-up, и в 4 раза выше, чем через push-уведомления. Это подтверждается и исследованиями: email marketing remains the most effective channel for post-purchase engagement.

Как работает отложенный сбор отзывов: архитектура на Laravel

Архитектура строится на событийно-ориентированном подходе с использованием очередей Laravel Queues. При успешной оплате ставится задача SendReviewRequestEmail с задержкой в 14 дней. Перед отправкой проверяем, не оставлен ли уже отзыв и не оформлен ли возврат. Затем создаём одноразовый токен со сроком жизни 30 дней и отправляем письмо с кнопками оценки.

// При успешной оплате
class HandlePaymentSucceeded
{
    public function handle(PaymentSucceeded $event): void
    {
        // Откладываем письмо на 14 дней — дать время воспользоваться продуктом
        SendReviewRequestEmail::dispatch($event->order)->delay(now()->addDays(14));
    }
}

// Job для отправки письма
class SendReviewRequestEmail implements ShouldQueue
{
    public function handle(): void
    {
        // Не отправлять если уже оставил отзыв
        if ($this->order->review()->exists()) return;

        // Не отправлять если оформлял возврат
        if ($this->order->refund()->exists()) return;

        $token = ReviewToken::create([
            'order_id'   => $this->order->id,
            'user_id'    => $this->order->user_id,
            'expires_at' => now()->addDays(30),
        ]);

        Mail::to($this->order->user->email)->send(new ReviewRequestMail($this->order, $token));
    }
}

В письме размещаем кнопки с оценкой от 1 до 5. Клик по ссылке ведёт на контроллер, который проверяет токен и сохраняет оценку в сессии. Если оценка 4 или 5 — редирект на платформу для публичного отзыва. Если 1-3 — показываем форму для развёрнутого отзыва, чтобы узнать причину недовольства.

// ReviewController
public function rate(ReviewToken $token, int $score): View|RedirectResponse
{
    if ($token->isExpired() || $token->isUsed()) {
        return redirect()->route('home')->with('error', 'Ссылка устарела');
    }

    // Сохраняем предварительную оценку
    session(['review_score' => $score, 'review_token' => $token->id]);

    if ($score >= 4) {
        // Высокая оценка → ведём на Google/Trustpilot для публичного отзыва
        $token->markPartiallyUsed($score);
        return redirect(config('reviews.google_url') . '?hl=ru');
    }

    // Низкая оценка → показываем форму для приватного отзыва
    return view('reviews.form', compact('token', 'score'));
}

public function submit(Request $request, ReviewToken $token): JsonResponse
{
    $request->validate(['score' => 'required|integer|min:1|max:5', 'comment' => 'nullable|string|max:2000']);

    Review::create([
        'order_id'  => $token->order_id,
        'user_id'   => $token->user_id,
        'score'     => $request->score,
        'comment'   => $request->comment,
        'is_public' => $request->score >= 4,
    ]);

    $token->markUsed();

    // Если низкая оценка — уведомление в поддержку
    if ($request->score <= 2) {
        Notification::route('slack', '#reviews')->notify(new LowReviewNotification($token->order, $request->score));
    }

    return response()->json(['success' => true]);
}

Оптимальные задержки для разных типов продуктов

Сравнение платформ для публикации отзывов

Google подходит для международного охвата, Яндекс — для локального SEO в России. Trustpilot воспринимается как независимая площадка, что повышает доверие. Рекомендуем настроить 1-2 платформы в зависимости от географии.

Как настроить роутинг отзывов: пошаговая инструкция

1. Создайте событие PaymentSucceeded и зарегистрируйте его слушателя.
2. Добавьте Job SendReviewRequestEmail с методом delay() в 14 дней.
3. Реализуйте модель ReviewToken с полями order_id, user_id, expires_at и статусом использования.
4. Настройте ReviewController с методами rate и submit, как в примере выше.
5. Интегрируйте Slack-уведомления при низких оценках через Notification::route.

Типичные ошибки и их решение

• Отправка запроса сразу после покупки. Клиент ещё не воспользовался товаром — отзыв будет поверхностным или его не будет вовсе. Решение: установите задержку 7–14 дней.
• Игнорирование возвратов. Если клиент оформил возврат, запрос отзыва только вызовет раздражение. Решение: проверяйте статус возврата перед отправкой.
• Отсутствие проверки дублирования. Повторные клики по ссылке могут создать несколько отзывов. Решение: используйте одноразовый токен и проверяйте его статус.

Что входит в работу?

• Аудит текущей системы учёта заказов и платёжных событий.
• Проектирование схемы данных: таблица отзывов, токены, связи с заказами.
• Реализация событий (PaymentSucceeded) и Job для отложенной отправки.
• Разработка email-шаблона с адаптивной вёрсткой и кнопками оценки.
• Интеграция с выбранными платформами (Google, Trustpilot, Яндекс, 2ГИС).
• Настройка мониторинга: слак-уведомления при низких оценках.
• Тестирование и оптимизация тайминга.
• Документация и обучение команды.

Сроки

Базовая версия системы с отложенной отправкой, оценкой в письме и роутингом занимает 3–4 рабочих дня. Сроки могут увеличиться при необходимости интеграции нескольких платформ или нестандартной архитектуры заказов. Стоимость рассчитывается индивидуально.

Свяжитесь с нами для оценки вашего проекта — получите готовое решение под ключ от проектирования до деплоя. Наш опыт: более 5 лет в e-commerce и 30+ внедрений таких систем. Гарантируем рост числа отзывов после внедрения — в среднем в 3 раза.

Интеграция email рассылок: почему она часто ломается?

Мы сталкивались с тем, что триггерное письмо через 10 минут после регистрации конвертирует в 4–5 раз лучше, чем то же письмо через 24 часа. Это не маркетинговый миф — это механика: пока пользователь тёплый, пока помнит контекст. Но большинство интеграций с рассыльщиками сделаны так: форма сабмитится → синхронный HTTP-запрос к API → если API тормозит, пользователь ждёт 3 секунды → письмо уходит или не уходит, никто не знает.

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

Провайдеры и их API

Unisender — российский провайдер, популярен в сегменте SMB. REST API, простой. Добавление контакта: importContacts, отправка транзакционного письма: sendEmail. Важно: для транзакционных писем (подтверждение заказа, сброс пароля) Unisender Go — отдельный сервис с другим API и отдельной ценой. Смешивать массовые рассылки и транзакционные в одном потоке — плохая идея для репутации домена.

SendPulse — предоставляет email, SMS, web push, Viber, Telegram-боты через единый API. Для проектов, где нужен омниканал, это удобно. Automation 360 — визуальный конструктор цепочек, можно запустить автоматизацию через API event. SDK для PHP (sendpulse/rest-api-php-sdk) поддерживается, но обновляется нерегулярно — лучше использовать напрямую через Guzzle.

Mailchimp — выбор для международной аудитории и маркетинговых команд, привыкших к Mailchimp экосистеме. Transactional email — через Mandrill (дочерний сервис). Marketing API v3 для управления списками, тегами, кампаниями. Webhook для событий: открытие, клик, отписка, bounce.

SMS. Для России: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всех схожий: метод send, параметры phone, message, sender (имя отправителя — нужно регистрировать отдельно у оператора). Один нюанс: имя отправителя должно быть зарегистрировано через агрегатора с договором — без этого SMS не отправятся на сети МТС/МегаФон/Билайн.

Как построить интеграцию, чтобы не терять письма?

Разделяем транзакционные и маркетинговые потоки

Транзакционные письма (подтверждение заказа, сброс пароля, статус доставки) — через отдельный домен-отправитель или субдомен tx.example.com. Маркетинговые рассылки — через mail.example.com или news.example.com. Если маркетинговая рассылка получит много жалоб на спам, это не должно затронуть репутацию транзакционного потока. Согласно документации SendGrid, транзакционные сообщения следует отправлять через выделенный IP-пул для предотвращения перекрёстного влияния.

Очередь и retry

Любой вызов к email API — через очередь (Laravel Queue, Bull, Celery). Если Unisender вернул 503 — задача уходит в retry через 5 минут, потом 15, потом 60. После 5 неудачных попыток — в dead letter queue с алертом. Пользователь при этом уже получил свой 200 OK и не знает о проблеме. Благодаря этому подходу bounce rate на проектах снижается до 0.5%.

Пример job для Laravel:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry через 5 мин
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Шаблоны

Храним шаблоны в коде (Blade, Twig, React Email), не в интерфейсе провайдера. Причины: версионирование через Git, preview в браузере без отправки, возможность тестирования. Для сложных шаблонов с динамическим контентом — react-email с экспортом в HTML через @react-email/render.

Валидация и согласия

Перед добавлением контакта в список — double opt-in (письмо с подтверждением). Хранить факт подтверждения с timestamp в своей БД. При отписке — синхронно отписываем и у провайдера, и в своей базе. Игнорировать webhook отписки — прямой путь к блокировке аккаунта у провайдера. Все процессы соответствуют ФЗ-152 о персональных данных.

Мониторинг доставляемости

Подключаем webhook от провайдера на события bounce (жёсткий и мягкий), spam_complaint, unsubscribe. Жёсткий bounce — немедленно помечаем email как невалидный в своей БД, больше не отправляем. Мягкий bounce 3 раза подряд — то же самое. Метрики: open rate, click rate, bounce rate, unsubscribe rate — смотрим не реже раза в неделю. Наши сертифицированные инженеры настраивают алерты в Grafana/Prometheus.

Почему важно разделять потоки?

Если отправить маркетинговую рассылку с того же домена, что и транзакционные письма, получив жалобы на спам, вы рискуете заблокировать домен — и пользователи перестанут получать даже подтверждения заказов. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) должны быть настроены отдельно для каждого потока. Мы используем субдомены с разными DNS-записями.

Объём работ по интеграции

• Аудит текущих потоков коммуникации и репутации домена (SPF, DKIM, DMARC)
• Выбор провайдера и схемы: транзакционный vs маркетинговый трафик
• Настройка DNS-записей SPF, DKIM, DMARC (Wikipedia DMARC)
• Разработка шаблонов писем (HTML + динамический контент)
• Интеграция с бэкендом через очереди и API
• Настройка webhook для доставляемости и жалоб
• Документация по эксплуатации и обучение команды
• Гарантия доставляемости и поддержка после запуска

Сроки и стоимость

Стоимость рассчитывается индивидуально после аудита. Мы работаем под ключ: от анализа до мониторинга в продакшене. Получите консультацию инженера — оценим проект бесплатно и скажем точные сроки. Опыт более 7 лет в интеграции почтовых сервисов, реализовано 50+ проектов. Закажите бесплатный аудит текущей интеграции — получите отчёт с рекомендациями.