Збір відгуків після покупки через email на Laravel

Збір відгуків про покупку через email

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

Чому email — найкращий канал для збору відгуків?

Email забезпечує персональний контакт: лист приходить в особисту скриньку, містить контекст покупки і не вимагає додаткових дій від клієнта. На відміну від спливаючих вікон на сайті або push-повідомлень, email не блокується і читається в зручний час. За нашими даними, конверсія в відгук через email у 2.5 рази вища, ніж через pop-up, і в 4 рази вища, ніж через push-сповіщення. Це підтверджується і дослідженнями: email marketing залишається найефективнішим каналом для залучення після покупки.

Як працює відкладений збір відгуків: архітектура на 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=uk');
    }

    // Низька оцінка → показуємо форму для приватного відгуку
    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+ проєктів. Замовте безкоштовний аудит поточної інтеграції — отримайте звіт з рекомендаціями.