Re: Массовые почтовые рассылки best practices

А еще он может не увидеть кнопку "больше не хочу" и нажать знакомую
кнопку "spam". Или он может не верить в то, что кнопка "больше не
хочу" реально работает.

Вы просто не в теме, Сергей, видимо.

Задача не в доставке письма до ближайшего к получателю MTA максимально
эффективным способом. Задача в том, чтобы получатель прочел и выполнил
нужное отправителю действие.

Вернее, чтобы максимально большой процент получателей прочел и
выполнил.

И это хочется мониторить. Понимать этот процент, следить, чтобы
среднее значение не падало, а росло. Еще хорошо бы отправлять
кастомизированные письма, проводить A/B тесты, все это надо трекать.

Кроме того, банальное - у каждого webmail (gmail, yahoo, msn, mail.ru,
yandex, etc) свои особенности в смысле антиспама. Вы получаете от них
"250 Ok", а увидит ли получатель письмо - неизвестно.

Тут много экспертизы зарыто.

On Sep 7, 12:31 am, Sergey Petrov <rubywie...@gmail.com> wrote:
> On Sep 6, 11:00 pm, Val <v.alekse...@gmail.com> wrote:
>
> > Без open/click tracking и соотвествующего A/B testing, вы будете
> > отсылать письма не имея никакого представления насколько они
> > эффективны и как их улучшить. Насчет rate limiting вам Олексей уже
>
> Не понятно, зачем "улучшать письма". Нужно чтобы они доходили и больше
> ничего. Какое отношение имеет клик на ссылке в письме в почтовом
> клиенте к MTA?
>
> > написал, в некоторых продуктах есть даже динамический, который
> > пытается подобрать максимальное количество сообщений которое можно
> > отправить с этого IP конкретному провайдеру. Автоматическая обработка
> > bounces и spam complains, new IPs warmup, mapping queues to IPs (в
> > нашем случае выставляем X-class flag что позовляет нам отсылать письмо
> > одного класса через определенные IP, поскольку они разного
> > "качества"), и много еще чего полезного.
>
> Задача - обыкновенная рассылка как можно большему количеству народу в
> единицу времени. Если бы я сходу хотел покупать что-то проприетарное -
> так неужели бы я пользовался rails на линукс-серверах и задавал бы
> такие вопросы в группу? В теме написано "best practices", что
> подразумевает наилучшее решение, в том числе и по стоимости владения.
> Если возникает вопрос о том, что оказывается нельзя отправить с
> определённого IP столько-то писем в сутки так и надо копать в эту
> сторону а не бросаться бездумно покупать MTA только из-за того, что
> там какой-то дядя написал пятиминутный скрипт, который запоминает,
> сколько писем было отправлено с этого IP за сегодня. Чего там
> "подбирать", один счетчик? Всякие bounces и spam complains вообще не
> стоят на повестке т.к. это легальная рассылка, естественно
> (пользователь ткнул галочку "Хочу получать" и может ткнуть ссылку
> "Больше не хочу").

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ

Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru