Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
уведомления об ответе на посты и комментарииУ меня на сайте они на Jabber рассылаются, очень удобно и не захламляет мыло пользователям. За счёт того, что приходят они практически в реальном времени, скорость общения местами догоняет чаты.
И это хорошо. Но статья — именно про использование электронной почты, а не про возможности уведомления )))
Про это, по потребности, могу отдельно написать.
Про это, по потребности, могу отдельно написать.
Статья полезная, несмотря на множество прописных истин. Было бы здорово почитать еще и про составление самого письма. Помню, вот тут: habrahabr.ru/blogs/webdev/106387/ про проблемы верстки HTML-писем хорошо рассказали.
Думаю, нельзя упускать и вопросы форматирования текста для удобного чтения, а так же того, как вообще нужно эти материалы готовить для удобства читателей.
Думаю, нельзя упускать и вопросы форматирования текста для удобного чтения, а так же того, как вообще нужно эти материалы готовить для удобства читателей.
Угнич, ты? :)
спасибо за статью. как раз сейчас реализую проект в котором потребуется частое уведомление пользователей и при проектировании пришел к выводу что если пользователь сейчас на сайте то и уведомление он должен увидеть на сайте(например хтмл-попап над своим профилем или ящиком для лс в шапке) и только если пользователь оффлайн — высылать письмо.
А вот на счет включения новостей сервиса в письма всех типов — пожалуй не соглашусь. Возьмем для примера хабр — если я получаю письмо о ответе к моему посту или коменту, то в уведомлении я ожидаю прочитать сам ответ и ссылку на него. А если там будут еще какие то новости, касательно сайта, а не моих постов/коментов — я скорее всего их просто пропущу. Как по мне лучше сделать отдельную ОДНОРАЗОВУЮ рассылку с новостями проекта, чем надоедать новостями пользователю в каждом письме предназначенном совсем для другого. А в случаях когда вы уверены что пользователь в любом случае зайдет на сайт можно обойтись и без новостной рассылки, просто на самом сайте акцентировать внимание юзера на новых фичах.
А вот на счет включения новостей сервиса в письма всех типов — пожалуй не соглашусь. Возьмем для примера хабр — если я получаю письмо о ответе к моему посту или коменту, то в уведомлении я ожидаю прочитать сам ответ и ссылку на него. А если там будут еще какие то новости, касательно сайта, а не моих постов/коментов — я скорее всего их просто пропущу. Как по мне лучше сделать отдельную ОДНОРАЗОВУЮ рассылку с новостями проекта, чем надоедать новостями пользователю в каждом письме предназначенном совсем для другого. А в случаях когда вы уверены что пользователь в любом случае зайдет на сайт можно обойтись и без новостной рассылки, просто на самом сайте акцентировать внимание юзера на новых фичах.
Ну я, собственно, и имел ввиду небольшие одностроковые сообщения внизу письма при наличии их необходимости.
конкретно вы можете и не заметить их, а кто-то прочитает, а кто-то из прочитавших — уделит этому особое внимание.
К примеру: «А ещё на нашем сайте появилась возможность отправлять ваши посты в твиттер. До новых встреч!» Со ссылочкой с нужных слов.
Такой новости можно уделить особое внимание в общем списке новостей проекта, но не обязательно рассылать как отдельную новость. А списки новостей читают не все.
Но это всё необязательно и на усмотрение владельцев проекта.
конкретно вы можете и не заметить их, а кто-то прочитает, а кто-то из прочитавших — уделит этому особое внимание.
К примеру: «А ещё на нашем сайте появилась возможность отправлять ваши посты в твиттер. До новых встреч!» Со ссылочкой с нужных слов.
Такой новости можно уделить особое внимание в общем списке новостей проекта, но не обязательно рассылать как отдельную новость. А списки новостей читают не все.
Но это всё необязательно и на усмотрение владельцев проекта.
просто от того же хабра в день я получаю от от 5 до нескольких сотен писем и приписка в каждом меня бы начала раздражать. в тоже время если я получаю так много писем значит я активный юзер и на сайт захожу, а значит тонкую инфо-растяжку с уведомлениями в шапке я увижу. вот в нее я бы и написал что то типа: «Новости проекта: у нас появился раздел кулинария(ссылка), если вас это не интересует нажмите сюда(ссылка убивающая уведомление)»
Опять таки… Подписка единственный раз, конечно же )))
Ну и несколько сотен писем с сервера — тоже перебор, было бы легче получать коллекцию событий в одном письме, чем кучу писем по каждому комментарию и ЛС.
Ну и несколько сотен писем с сервера — тоже перебор, было бы легче получать коллекцию событий в одном письме, чем кучу писем по каждому комментарию и ЛС.
Как по мне лишние сложности если реализовать приписку только один раз — это и дополнительный шаблон письма(или его модификация) и лишний учет высылалось письмо с припиской или нет.
Насчет нескольких сотен писем это надо админам хабра написать, благо у меня гуглопочта и все уведомления складываются в цепочки. без этой фичи я бы давно наверно отключил уведомления на почту от хабра.
Насчет нескольких сотен писем это надо админам хабра написать, благо у меня гуглопочта и все уведомления складываются в цепочки. без этой фичи я бы давно наверно отключил уведомления на почту от хабра.
Ну не такие это уж и заморочки.
Если вы программер, то вполне поймёте меня.
А вот за удобства работы пользователя с сервисом — лично я готов биться.
Готов к тому, что пользователь зайдёт на сайт не 50 раз, а всего 5-10, но при этом количество необходимых действий у него будет равнозначно или даже меньше, при количественно-качественном перевесе в положительную сторону.
«Думать о пользователе» — это должно быть основным девизом разработчиков и владельцев сервисов, а не как сейчас — «придумать как снять с этих олухов ещё немного бабла… Точно! Будем смайлики продавать!!!»
Если вы программер, то вполне поймёте меня.
А вот за удобства работы пользователя с сервисом — лично я готов биться.
Готов к тому, что пользователь зайдёт на сайт не 50 раз, а всего 5-10, но при этом количество необходимых действий у него будет равнозначно или даже меньше, при количественно-качественном перевесе в положительную сторону.
«Думать о пользователе» — это должно быть основным девизом разработчиков и владельцев сервисов, а не как сейчас — «придумать как снять с этих олухов ещё немного бабла… Точно! Будем смайлики продавать!!!»
ну я вполне понимаю как реализовать одноразовую приписку, но для этого в любом случае нужно завести таблицу в бд для учета тех кто получал, а кто не получал, либо дополнительное хитрое поле в таблице юзера в котором вести учет не отправленных ему уведомлений. Получаем лишние запросы к бд что при частых уведомления и большой аудитории вызовет неслабую дополнительную нагрузку на сервер.
Ну а на счет «Думать о пользователе» — согласен, сам стараюсь ставить себя на место пользователя когда что то пишу и в дополнение к этому обязательно проверяю свои задумки/реализацию на знакомых которые входят в целевую аудиторию аудиторию сайта, чтобы уж наверняка увидеть не очевидные для программистского мышления грабли.
Зарабатывать нужно на качественном сервисе, а не на «лохах»(компьютерно не грамотных) которым можно впаривать любой шлак обманом. ИМХО, яркий пример как не надо зарабатывать — одноклассники
Ну а на счет «Думать о пользователе» — согласен, сам стараюсь ставить себя на место пользователя когда что то пишу и в дополнение к этому обязательно проверяю свои задумки/реализацию на знакомых которые входят в целевую аудиторию аудиторию сайта, чтобы уж наверняка увидеть не очевидные для программистского мышления грабли.
Зарабатывать нужно на качественном сервисе, а не на «лохах»(компьютерно не грамотных) которым можно впаривать любой шлак обманом. ИМХО, яркий пример как не надо зарабатывать — одноклассники
Именно одноклассников я и имел ввиду, когда про продажу смайлов писал.
Что же касается «лишних» запросов и обработок — да, это так. Но также следует учитывать, что при грамотном сервисе и качественном удовлетворении пользовательских нужд — позрастут и прибыли, как следствие — средства на доп. оборудование и т.п.
Что же касается «лишних» запросов и обработок — да, это так. Но также следует учитывать, что при грамотном сервисе и качественном удовлетворении пользовательских нужд — позрастут и прибыли, как следствие — средства на доп. оборудование и т.п.
Некоторые моменты раскрыты немного поверхностно, оформлю в виде отдельных комментариев, чтобы удобно было обсуждать при желании.
1. Насчет уведомлений «прямо на сайте» — это все замечательно, но вот только нельзя достоверно сказать, прочитал пользователь уведомление или нет. У него может быть свернут браузер и т.д. Поэтому и дублируют по почте.
2. Насчет включения текста сообщения в письмо — многие не включают вовсе не потому, что хотят накрутить трафик (трафика там копеечное количество получается в большинстве случаев). А по другим причинам:
а) для отслеживания статуса «непрочитанное». Если текст есть и на сайте, и в письме, то статус непорчитанности раздваивается: прочитал письмо и текст в нем, «погасил» его, а потом — заходишь на сайт и снова видишь непрочитанное сообщение (сайт-то не знает, что оно прочитано в почте). Это дико раздражает.
б) потому что можно в письме написать «с момента вашего последнего захода на сайте появились непрочитанные сообщения». И все, БЕЗ УКАЗАНИЯ, сколько именно их там. Такая схема позволяет делать очень удобную вещь: высылается письмо-уведомление не по факту появления нового сообщения, а по факту появления ПЕРВОГО непрочитанного сообщения. Далее в момент прихода нового сообщения система смотрит: есть ли еще непрочитанные и, если есть, НЕ ВЫСЫЛАЕТ еще одного письма-уведомления (она же знает, что уже ранее выслала одно, а пользователь на сайт не пришел — значит, не надо ему еще раз надоедать).
Кроме того, я замерял «методом расчески» эффект от включения и невключения текста в письмо, и могу сказать, что невключение вызывает ГОРАЗДО большую активность пользователя (например, сообщения с невключенным в письмо текстом имеют в 2-3 раза бОльшую отвечабельность). Такой вот парадокс, но все так и есть — письма в почтовых ящиков имеют тенденцию «залеживаться» неделями без ответа (взгляните в свой ящик, вы в этом убедитесь).
а) для отслеживания статуса «непрочитанное». Если текст есть и на сайте, и в письме, то статус непорчитанности раздваивается: прочитал письмо и текст в нем, «погасил» его, а потом — заходишь на сайт и снова видишь непрочитанное сообщение (сайт-то не знает, что оно прочитано в почте). Это дико раздражает.
б) потому что можно в письме написать «с момента вашего последнего захода на сайте появились непрочитанные сообщения». И все, БЕЗ УКАЗАНИЯ, сколько именно их там. Такая схема позволяет делать очень удобную вещь: высылается письмо-уведомление не по факту появления нового сообщения, а по факту появления ПЕРВОГО непрочитанного сообщения. Далее в момент прихода нового сообщения система смотрит: есть ли еще непрочитанные и, если есть, НЕ ВЫСЫЛАЕТ еще одного письма-уведомления (она же знает, что уже ранее выслала одно, а пользователь на сайт не пришел — значит, не надо ему еще раз надоедать).
Кроме того, я замерял «методом расчески» эффект от включения и невключения текста в письмо, и могу сказать, что невключение вызывает ГОРАЗДО большую активность пользователя (например, сообщения с невключенным в письмо текстом имеют в 2-3 раза бОльшую отвечабельность). Такой вот парадокс, но все так и есть — письма в почтовых ящиков имеют тенденцию «залеживаться» неделями без ответа (взгляните в свой ящик, вы в этом убедитесь).
3. Почему ставят no-reply@ в адресе отправителя — не потому, что игнорируют пользователей. А, например, потому, что очень у многих нубов стоят автоответчики, которые моментально заспамливают весь ящик сообщениями типа «спасибо, письмо получил, отвечу позже» — с различными юмористическими вариациями.
Фильтры.
Это ни разу не оправдание. Пользователь должен мочь ответить на то письмо, которое ему сервис прислал с помощью нажатия на кнопку «ответить».
Зачем пользователю такая возможность? Вот пришло ему уведомление «У вас 3 новых сообщения от 2 людей». Зачем ему отвечать на это письмо?
А это и не должно вас волновать, мало ли зачем пользователь захочет с вами связаться получив это сообщение. Он просто должен иметь возможность ответить на письмо — это один из базовых принципов электронной почты.
noreply@ адрес даёт пользователю возможность «ответить на письмо — это один из базовых принципов электронной почты.» Т.е. ваше требование выполнено. Почему же вы тогда против noreply@?
noreply — не отвечайте. Для пользователя выглядит так, как будто его письмо, которое он отправит читать никто не будет (скорее всего так и произойдёт).
4. И еще ни слова не сказано про автологинящие ссылки в письмах. По каким правилам они должны работать и т.д. А ведь это очень важная вещь, которая в разы повышает эффективность письма.
>> зачем мне дублировать в почту уведомления, если я на данный момент сижу на сайте?
Дело в том что не возможно точно определить на сайте вы или нет.
Дело в том что не возможно точно определить на сайте вы или нет.
Самодостаточные механизмы уже реализованы.
Опять таки фейсбук.
Опять таки фейсбук.
зато возможно определить среагировал пользователь на уведомление на сайте или нет. Например у вас числится что пользователь онлайн, вы показываете ему уведомление о непрочитанных ЛС, если после этого непрочитанных не стало — мыло не шлем… если непрочитанные все таки есть то ждем время через какое проверка он/оффлайн покажет точное состояние юзера, ну и либо шлем мыло(юзер офф) либо ждем снова проверки он/офф. ведь юзер может быть онлайн но отошел например или пока изучает статью на сайте, а ЛС прочтет позже. В периоды ожидания проверки оставляем активным уведомление на сайте.
Вы хотя бы примерно представляете себе сложность реализации подобной схемы?
Есть мнение, что небольшие сайты не станут с ней возиться именно по причине её сложности.
Есть мнение, что небольшие сайты не станут с ней возиться именно по причине её сложности.
Сложность? Уважаемый, это многократно используемый и отработанный механизм.
Для программера средней руки использующего любой серверный язык и маломальски знающего HTML не составит труда прописать всю логику.
Про хомячников, конечно же, не говорю.
Для программера средней руки использующего любой серверный язык и маломальски знающего HTML не составит труда прописать всю логику.
Про хомячников, конечно же, не говорю.
Уважаемый, если вы относите себя к таким программистам, и в личку (или здесь) сможете досконально описать схему реализации вплоть до используемого ПО и примерные сроки её внедрения (включая программирование), то я вам поставлю плюс за комментарий, если не сможете — минус. Согласны?
Терпеть не могу кармодрочеров. Мне плевать, что вы там поставите.
Я уже высказался по этому поводу.
P.S.
Посмотрел на указанное место работы в профиле. Спасибо, поржал.
Я уже высказался по этому поводу.
P.S.
Посмотрел на указанное место работы в профиле. Спасибо, поржал.
лично я прекрасно представляю себе эту схему, так как именно ее сейчас реализую в своем проекте и ничего сверхсложного и необычного в ней нет. сейчас практически в каждой CMS/форуме в базовый функционал входит модуль «Кто онлайн», а то что я описал в коменте выше — просто небольшая его доработка. Естественно никто не говорит о точности определения до секунды — но до нескольких минут уже будет достаточно
Если онлайновость будете оопределять через дату последней загрузки любой страниця сайта, без необходимости клика (как в фпйсбуке), то не будет. Начнут теряться сообщения.
пока что я ничего лучше не придумал чем просто отслеживать активность юзера: при заходе на любую страницу ник/ид(любой однозначный идентификатор юзера) заносятся в мемкеш в котором настроено нужное время автоудаления старых записей. ну а дальше проще некуда — скрипт уведомлений проверяет есть ли объект юзера в мемкеше и на основании ответа уже либо шлет мыло, либо активирует уведомление на сайте.
А что делать дальше в ситуации, когда вы активировали уведомление на сайте, но пользователь его не прочел?
Очевидно, что при активации уведомления на сайте вам нужно поместить задание на отсылку письма в очередь, которое (задание) будет выполнено в заданное время. Если в течение заданного промежутка времени пользователь «прочитал» уведомление на сайте, то вам нужно удалить это задание из очереди, если не прочитал и настал час Х — выполнить это задание и послать письменное уведомление.
А теперь сложите всё вместе (отслеживание онлайновости через сохранение в мемкэше информации на каждый чих пользователя), создание системы уведомлений на сайте с возможностью пометки их «прочтенными», колбек на событие «прочтения» уведомления на сайте и очередь заданий на отсылку писем. И вы получите примерную оценку сложности подобной системы.
Очевидно, что при активации уведомления на сайте вам нужно поместить задание на отсылку письма в очередь, которое (задание) будет выполнено в заданное время. Если в течение заданного промежутка времени пользователь «прочитал» уведомление на сайте, то вам нужно удалить это задание из очереди, если не прочитал и настал час Х — выполнить это задание и послать письменное уведомление.
А теперь сложите всё вместе (отслеживание онлайновости через сохранение в мемкэше информации на каждый чих пользователя), создание системы уведомлений на сайте с возможностью пометки их «прочтенными», колбек на событие «прочтения» уведомления на сайте и очередь заданий на отсылку писем. И вы получите примерную оценку сложности подобной системы.
вы излишне усложняете, при активации сообщения на сайте не нужно никакой дополнительной очереди создавать — у вас и так есть очередь непрочитанных сообщений. достаточно проверять две вещи наличие непрочитанных(+статус отправлено уведомление на почту или нет) и статус пользователя — онлайн/оффлайн.
Есть непрочитанные(без пометки о уведомлении) и юзер онлайн — активный информблок на сайте, пока не пропадут непрочитанные.
Есть непрочитанные и юзер оффлайн — отправить письмо и поставить пометку о уведомлении.
и где тут сложность? довольно простая логика — главное правильно написать сам скрипт-чеккер чтобы не плодились тысячи запросов к бд.
Есть непрочитанные(без пометки о уведомлении) и юзер онлайн — активный информблок на сайте, пока не пропадут непрочитанные.
Есть непрочитанные и юзер оффлайн — отправить письмо и поставить пометку о уведомлении.
и где тут сложность? довольно простая логика — главное правильно написать сам скрипт-чеккер чтобы не плодились тысячи запросов к бд.
Похоже некоторые не представляют себе каким образом возможно проверить онлайн сейчас пользователь или нет.
Что ж, отлично. Затрону эту тему в следующем посте, который, судя по всему, будет посвящён уведомлениям в целом.
Что ж, отлично. Затрону эту тему в следующем посте, который, судя по всему, будет посвящён уведомлениям в целом.
Это и правда непросто. Способ не будет на 100% надежным для определенря, слать уведомление на почту или нет, даже если применять comet или постоянное соединение с сервером. Частично спасти может только схема, при которой пользователь должен кликнуть на сообщении при его выскакивании на сайте (а если не кликнул, то через 10 минут ушло письмо). Но это тоже не всегда удобно — пользователь может быть занят на сайте важным делом и вовсе не станет кликать по сообщению.
Так же как и может кликнуть для отмазки. Но это уже как раз его проблемы, если оно ему не надо.
Сообщение следует слать только после того, как человек не прочитав сообщение ушёл с сайта через какое-то время или не был на нём во время свершения события.
Возьмём, к примеру, визуальное отображение новых событий как и счётчик новых комментов в посте прямо здесь, на хабре. Человек видит, что появилось новое событие и либо кликает на функциональный элемент или нет. Не кликнул и ушёл — через ХХ минут отсылаем уведомление. Кликнул — получил псевдо-попап с уведомлением. Если уведомлений несколько — показываем полный список. Можно считать прочитанным. Если переживаем за то, что он не увидит конкретное — показываем сообщения по очереди с кликом по клавише «next» и каждое при появлении отмечаем на сервере как прочитанное. При этом можем сохранять историю, чтобы всегда можно было перейти по ссылке с уведомления, даже если мы его уже видели.
Но всё зависит от конкретики — что за сервис, как реализован. В следующей статье я постараюсь взять конкретизированный проект для рассмотрения.
Сообщение следует слать только после того, как человек не прочитав сообщение ушёл с сайта через какое-то время или не был на нём во время свершения события.
Возьмём, к примеру, визуальное отображение новых событий как и счётчик новых комментов в посте прямо здесь, на хабре. Человек видит, что появилось новое событие и либо кликает на функциональный элемент или нет. Не кликнул и ушёл — через ХХ минут отсылаем уведомление. Кликнул — получил псевдо-попап с уведомлением. Если уведомлений несколько — показываем полный список. Можно считать прочитанным. Если переживаем за то, что он не увидит конкретное — показываем сообщения по очереди с кликом по клавише «next» и каждое при появлении отмечаем на сервере как прочитанное. При этом можем сохранять историю, чтобы всегда можно было перейти по ссылке с уведомления, даже если мы его уже видели.
Но всё зависит от конкретики — что за сервис, как реализован. В следующей статье я постараюсь взять конкретизированный проект для рассмотрения.
Не совсем в тему сообщение, но где можно почитать про проблемы технический реализации всех этих рассылок? Все хорошо когда писем десятки или стони. Но когда надо разослать под сотню тысяч сообщений (не спама, прошу заметить), то очень резко возникаю проблемы недоставки писем изза бана почтовыми сервисами ии тому подобного. Может быть кто то встречал рекомендации как лучше построить все в этом случае? Очень не хочется ходить по одним и тем же граблям.
Есть whitelist'ы и специальные сервисы, рассылающие почту.
Загуглите, их много.
Загуглите, их много.
Сервисы конечно есть, но что делать если это нужно сделать самим? Или вы хотите сказать, что такие вещи стоит делать самим, только если уже совсем припрет?
почитайте тут habrahabr.ru/qa/1411/ какими средствами можно организовать объемные рассылки
Со спамоотбойниками и блеклистами вы сами не справитесь никак.
Только вайтлисты, ну или уже готовые сервисы.
Только вайтлисты, ну или уже готовые сервисы.
Ну зачем же так категорично. Не боги горшки обжигают. Тысячи сайтов по всему миру рассылают письма в больших количествах и уверен, не все из них, используют коммерческие сервисы.
Многие почтовые службы сами подробно рассказывают как правильно делать на них массовые почтовые рассылки. Например:
help.yahoo.com/l/us/yahoo/mail/postmaster/bulkv2.html
mail.google.com/support/bin/answer.py?hl=en&answer=81126
Так что думаю вполне можно делать и самим, но не хочется набивать шишки, если кто то уже с этим сталкивался.
Многие почтовые службы сами подробно рассказывают как правильно делать на них массовые почтовые рассылки. Например:
help.yahoo.com/l/us/yahoo/mail/postmaster/bulkv2.html
mail.google.com/support/bin/answer.py?hl=en&answer=81126
Так что думаю вполне можно делать и самим, но не хочется набивать шишки, если кто то уже с этим сталкивался.
О чём я и говорю — если не готовые сервисы, то вайтлисты.
Платить блеклистам, куда вы в итоге всё равно рано или поздно попадаете, придётся неоднократно, поэтому лучше сразу идти в белую сторону — это намного уменьшит вероятность попадания в блеклист.
Сервисы рассылок — это те же самые вайтлистовые рассыльщики со своим оборудованием и скриптами. Ну, по крайней мере те, что мы использовали, когда делали рассылки.
Других выходов не нашли.
Естественно, я всего не знаю, но только правильное составление письма и периодичность рассылки вас не спасут — и домен и IP зачернят. Разве что по прежнему будут доставляться письма на йаху и гугл.
Кстати, тут в посте мейлрушник бузил — так вот с ними ещё больше проблем будет.
Платить блеклистам, куда вы в итоге всё равно рано или поздно попадаете, придётся неоднократно, поэтому лучше сразу идти в белую сторону — это намного уменьшит вероятность попадания в блеклист.
Сервисы рассылок — это те же самые вайтлистовые рассыльщики со своим оборудованием и скриптами. Ну, по крайней мере те, что мы использовали, когда делали рассылки.
Других выходов не нашли.
Естественно, я всего не знаю, но только правильное составление письма и периодичность рассылки вас не спасут — и домен и IP зачернят. Разве что по прежнему будут доставляться письма на йаху и гугл.
Кстати, тут в посте мейлрушник бузил — так вот с ними ещё больше проблем будет.
Спасибо за объяснение! Думаю вы правы, вопрос не банальный. А можете подсказать проверенные сервисы для Рунета, которые вы использовали? Пока что смотрю в сторону smartresponder.ru/, но на практике еще не пользовался.
Данная статья показалась мне излишне категоричной, значительная часть утверждений действительна лишь для сайтов определённой направленности. Более подробный разбор полётов смотрите ниже.
Подобное правило очевидно недействительно для сервисов с большими объёмами отсылаемой почти (миллионы писем в месяц).
Для сайтов, основной сервис которых — обмен пользователей сообщениями данный совет неприменим, т.к. письмо-уведомление должно способствовать увеличению процента ответов на сообщения.
Не путайте тёплое с мягким, пожалуйста. Письма-уведомления (о новом сообщении, запросе на смену пароля и т.п.) нельзя приравнивать к обращению в суппорт.
Электронная почта должна приходить от имени представителя сервиса.
Подобное правило очевидно недействительно для сервисов с большими объёмами отсылаемой почти (миллионы писем в месяц).
Если с письмом пришло уведомление о новом комментарии или ЛС — необходимо включить сам текст в письмо. Дополнительные хиты на сайте — это хорошо, но забота о пользователе — ещё лучше
Для сайтов, основной сервис которых — обмен пользователей сообщениями данный совет неприменим, т.к. письмо-уведомление должно способствовать увеличению процента ответов на сообщения.
Стоит ли слишком много времени уделять рассмотрению данного вопроса? Сколько раз вам лично не ответила служба поддержки или администрация сайта?
Не путайте тёплое с мягким, пожалуйста. Письма-уведомления (о новом сообщении, запросе на смену пароля и т.п.) нельзя приравнивать к обращению в суппорт.
не туда ткнул. вот.
Подобное правило очевидно недействительно для сервисов с большими объёмами отсылаемой почти (миллионы писем в месяц).
С какого это перепуга?
Для сайтов, основной сервис которых — обмен пользователей сообщениями данный совет неприменим, т.к. письмо-уведомление должно способствовать увеличению процента ответов на сообщения.
Согласен, что не для одноклассников.
Не путайте тёплое с мягким, пожалуйста. Письма-уведомления (о новом сообщении, запросе на смену пароля и т.п.) нельзя приравнивать к обращению в суппорт.
А причём тут это? Я не приравнивал. Если обратите внимание — рассматривался вопрос рассылки электронных писем, а не электронных писем с уведомлениями (хоть в примерах они и есть по большинству).
Электронная почта должна приходить от имени представителя сервиса.
Возможно, я неверно понял смысл этого текста. Каков он? Если вы имеете в виду то, что должна присутствовать возможность выйти на связь с живым человеком, просто нажав «ответить» в контексте письма-уведомления, то это глупость по той причине, что кому-то живому свалится поток совершенно невменяемых писем. Юзеры давно умеют находить на сайте раздел contact us, чтобы решить свои проблемы.
рассматривался вопрос рассылки электронных писем
Вот именно, что рассматривался вопрос рассылки, а в конце вы неожиданно переходите на то, что кому-то не ответили из суппорта. Как факт ответа/неответа от суппорта связан с рассылкой писем я не понимаю.
Возможно, я неверно понял смысл этого текста. Каков он? Если вы имеете в виду то, что должна присутствовать возможность выйти на связь с живым человеком, просто нажав «ответить» в контексте письма-уведомления, то это глупость по той причине, что кому-то живому свалится поток совершенно невменяемых писем. Юзеры давно умеют находить на сайте раздел contact us, чтобы решить свои проблемы.
Вы бы хотя бы текст полностью осмыслили: Представителем сервиса может быть как частное лицо, так и юридическое. Может быть группа людей-единомышленников. Или ваш питомец, если сделали для него фан-сайт для узкого круга лиц.
Посыл пользователя к тому, чему он уже и так научился — это никак не забота о пользователях.
Вот именно, что рассматривался вопрос рассылки, а в конце вы неожиданно переходите на то, что кому-то не ответили из суппорта. Как факт ответа/неответа от суппорта связан с рассылкой писем я не понимаю.
Т.е. по вашему рассылка ответов на заданные вопросы никак не относится к рассылке электронной почты и вобще не имеет ничего общего с обсуждаемым? ооок…
Пока я читал статью, я был на 100% уверен, что речь идёт о автоматической рассылке писем. Т.е. письмах, отправляемых роботом. Роботом, а не частным лицом, юридическим лицом, группой людей или питомцем.
И да, ответы от живого суппорта у меня в голове не вяжутся с автоматической рассылкой, про которую, как мне кажется, вы вели речь в статье.
Если же вы считаете, что написали статью не об автоматической рассылке, то я сдаюсь.
И да, ответы от живого суппорта у меня в голове не вяжутся с автоматической рассылкой, про которую, как мне кажется, вы вели речь в статье.
Если же вы считаете, что написали статью не об автоматической рассылке, то я сдаюсь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Электронная почта на сайтах-сервисах