Comments 21
А как на сервисе происходит одобрение списка рассылки? Т.е. как вы защищаетесь от спамеров, которые с вашей системы рассылают спам?
В общем ответ на ваш вопрос — вручную. В следующих статьях распишу процесс подробнее.
Если почтовый клиент по этой причине разочаровывается в вашем пикселе, он просто вырежет его из письма и вы не узнаете о том, открыл ваш адресат письмо или нет.
Т.е. почтовый клиент не пойдет по ссылке после того, как сходил по ссылке и ему не понравился ответ?
Также в некоторых email-клиентах такие пиксели не вырезаются, но тем не менее запросы браузера к реальным src картинок блокируются прокси-сервисом почтового сервиса.
$hash = md5($user_id . config::sys('mail.solt1') . $email . config::sys('mail.solt2') . $mail_id);
$link = SITEURL . '/r/' . base64url_encode($mail_id . '/' . $email . '/' . $user_id . '/' . $hash);
И я специально передаю все параметры, чтобы потом в скрипте можно быстро проверть их на валидность, без выполнения запросов к БД.
А вот рассылка писем — это вообще отдельная песня. Я сдела так, что в базу заносятся список SMTP серверов, и по ним происходит равномерная расылка писем.
Примерно так screenshotlink.ru/e2defa882bb7715eb0da43b7b4f7d621.png
И соответственно использовать бесплатные почтовые службы.
Вопрос, а поему бы не пойти "ленивым" путем по учету открытия пикселя — то есть считать это по логам nginx?
Кроме того парсинг логов это плохо, потому что нужен realtime. Пользователь хочет знать когда прочитали письмо, а не когда парсер получил ивент из логов.
ну у парсера будет задержка 5-10 минут, а если грамотно класть логи, например в тот же elasticsearch, то все будет зависеть от скорости реиндекса. У меня около 30 секунд. На объемы от 100ГБ до пары-тройки Тб. И тут API будет дергать ES, именно когда клиент запрашивает. То есть почти рилтайм. А при открытии API нагрузка на бекэнд машины будет меньше.
Представьте, куча пользователей ломится по ссылке — а перейти не может, потому что бекенд и база заняты записью перехода пользователя.
Поэтому сейчас подобный лог пишется nginx`ом, а дальше по крону разгребается хоть раз в 5 минут.
> Пользователь хочет знать когда прочитали письмо, а не когда парсер получил ивент из логов.
Уточните у пользователя, что ему важнее — узнать ровно в тот же момент, что письмо прочитано и пользователь перешел на статью, или чтобы все желающие пользователи прочитали статью. :)
В первом случае он моментально узнает о всех, кто пробился на сайт, во втором о всех, но с задержкой в несколько минут. Я думаю, все выберут второй вариант.
Ну вот коллега el777 верно говорит. Я рассматриваю тут ситуацию как системщик, а не разработчик. стоимость связки nginx-elastic-api будет ощутимо дешевле, чем любые варианты с celery/rabbit/DB. Собственно жто вопрос разделяемых ресурсов. Когда писем не очень много — это не важно, когда начинаешь масштабироваться — то вопрсо встает совсем под другим углом.
В любом случае — совсем realtime не выйдет никогда. Либо вам нужно будет очень крутое и дорогое решение. Обновляйте лог раз в минуту — и будет счастье.
Это же email даже не мессенджер — его когда прочитают, тогда и прочитают. Вы можете отправить сейчас и прочтут через пару часов. И кому тут важна задержка в 5 минут?
чтобы злые люди не могли досить по ней или генерировать их
Каждый пользователь моего сервиса может сгенерировать форму подписки для определенного списка подписчиков и встроить на сайт. Процедура подписки через эту форму включает double-opt-in авторизацию. Соответственно, человек подписавшийся через эту форму сразу попадает в определенный список подписчиков.
Что означает «Проверка подтверждения рассылки перед отправкой»?
Репутацию доменов я проверяю через mx-toolbox, пока вручную, попозже напишу робота.
Проверка подтверждение — это отсутствие возможности отправки по базе не прошедшей процесс double opt-in. Если домен попадет в СПАМ фильтр, залогированный факт того, что получатель сам согласился на рассылку — один из немногих «рычагов» выведение домена из-под фильтра. Обычно его требуют при разборках с владельцами почтового сервиса.
Плюс клиент может разместить в теле письма ссылку на его веб-версию, и тогда получатель сможет открыть его на сайте, там все картинки будут на месте.
Что нам стоит сервис email-маркетинга построить? Взгляд изнутри, часть первая