Как трекинг в MailWizz съел слеш и не только

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

Начну с небольшого предисловия. Заказывали мы недавно рассылку по большой базе и получили в итоге ноль, такой большой и жирный. По итогам исполнитель, который вроде собаку съел на рассылках, прислал даже отчеты: кто прочитал и кликнул, кто отписался, до кого почта не дошла по техническим причинам. У меня же в линки были встроены utm-метки, то есть если бы люди кликали, то я бы их увидел в Google Analytics и Яндекс.Метрике. И я их даже потом увидел, но на пару порядков меньше, и самое главное со странным пользовательским поведением — смотрят 1 странуцу, 100% отказов, время на сайте 0 минут 0 секунд. И я даже догадываюсь в чем дело было. Люди кликали, попадали на редирект и … попадали в яму, с которой столкнулся и я, когда настраивал свою систему рассылки.

Эксперты рекомендуют разносить сервер рассылщик (PowerMTA, например) и сервер управления рассылками (MailWizz, например). Чтобы, если ваш сервер-рассылщик настигнет ненастье, то данные все сохранятся. Ещё умные люди советуют, чтобы в письме, которое идет SMTP сервера, ссылки вели бы на тот же домен, на котором он располагается. Т.е. есть хост snd.domain.com, с него уходят письма в которых ссылки имеют вид https://domain.com/komu-na-rusi-zhit-horosho/ можно и на поддомен ссылаться, например, https://www.domain.com или https://cdn.domain.com Всё здорово, но как мониторить переходы, открытия, …? Эксперты из MailWizz советуют сделать для домена domain.com запись в DNS: cdn.domain.com. CNAME app.example.com. 3600, где app.example.com — это хост, где и сидит система управления рассылками.

Кликая на ссылку вида https://cdn.domain.com/page123/ вы будете автоматически попадать на https://app.example.com/page123/.

В идеале, я так понимаю, app.example.com лучше располагать даже за CloudFlare, мол это дает защиту от антиспам роботов, которые пытаются пройти до целевой страницы и не могут. Другие эксперты говорят, могут, всё могут… Но не важно, главное хоть какие-то правила игры соблюсти.

Логика работы всего этого награмождения в следующем.

У вас письмо, в нем ссылка на www.super-puper-product.com/oversome-baida/. MailWizz перепаковывает все такую ссылку в новый вид — https://cdn.domain.com/traking-code-1x2y3z/. Человек получает письмо с domain.com с такой ссылкой, кликает по ней, браузер понимает, что настоящий домен app.example.com и делает запрос по адресу https://app.example.com/traking-code-1x2y3z/.

MailWizz знает, что traking-code-1x2y3z — это в реальности https://www.super-puper-product.com/oversome-baida/ перенаправляет пользователя на целевую страницу, одновременно учитывая его в своей статистике.

Все чудесно в теории :). На практике первый затык в том, что на этапе подмены домена по CNAME браузер говорит: «Вах-Вах нехороший человек хочет тебя нагреть — нужет сертификат cdn.domain.com, а в наличии сертификат app.example.com. Как результат — посетитель потерян, ибо никто решать ваши проблемы не будет.

Выход нашелся в том, чтобы MailWizz использовал для ссылок http. Тогда вопросов о несовпадении сертификатов не будет. Нет сертификата — нет проблем.

Но сайт-то упправления app.example.com плохо держать на http. А и не надо. Надо редирект у Apache2/Nginx сделать для всех входящих по http на https.

Сказано — сделано. Вернее все было сделано ещё ранее. Вот только эффект оказался неожиданным.

Ссылка http://cdn.domain.com/traking-code-1x2y3z/ неожиданно превращалась в https://app.example.comtraking-code-1x2y3z/

Я выпал в аут. Это сейчас понятно, что проблема была в редиректе с http на https, а сначала концов видно не было. Гуглил до посинения, пока не задал правильный вопрос и не получил хороший ответ.

Вместо файла вируального хоста такого вида (у меня Apache2):

<VirtualHost *:80>
    ServerName app.example.com
    Redirect / https://app.example.com
</VirtualHost>

<VirtualHost _default_:443>
    ServerName app.example.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateChainFile /etc/letsencrypt/live/app.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/app.example.com/privkey.pem
    SSLCertificateFile /etc/letsencrypt/live/app.example.com/cert.pem

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

надо сделать такой файл:

<VirtualHost *:80>
    ServerName app.example.com
    RedirectMatch permanent /(.*) https://app.example.com/$1
</VirtualHost>

<VirtualHost _default_:443>
    ServerName app.example.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateChainFile /etc/letsencrypt/live/app.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/app.example.com/privkey.pem
    SSLCertificateFile /etc/letsencrypt/live/app.example.com/cert.pem

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

После этого слэш перестал пропадать. Ссылка https://app.example.com/traking-code-1x2y3z/ системой транслируется в www.super-puper-product.com/oversome-baida/ и человек попадает на нужную страницу (http или https она — не важно).

Итого. Важно.

В MailWizz для трекинг сервера выставить транспорт http
Прописать нужный редирект в файле виртуального хоста.

Примечание: в процессе борьбы с проблемой поставил себе на domain.com wildcard сертификат Let’s encrypt, но он вроде автоматом не обновляется и выдается на 90 дней. Это была идея получить сертификат и на фейковый домен cdn. надо проверить, может я зря это сделал 🙂 и простого достаточно.

UPD. Простого сертификата достаточно.