30 сентября 2013 г.

Seed-мониторинг доставляемости почты

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

Однако мне кажется не менее важным вовремя обнаруживать проблемы с доставкой емейлов. Ведь зачастую о них узнают от пользователей через дни или даже недели после начала. Тут потери зависят не от скорости решения, а от скорости обнаружения.

Для такого мониторинга ничего лучше рассылок по seed-адресам так не придумали. Выбор соответствующих сервисов небольшой:
  • старый-добрый Return Path с совершенно дикими расценками (готовьте десяток тысяч долларов за год, если у вас большое число языков-рассылок);
  • недорогой российский Email Stream с кучей мелких полезных фишек;
  • багнутый и при этом не дешёвый Delivery Watch;
  • ряд перепродающих в России сервис Return Path локальных игроков.

В паре проектов я наблюдал попытку создать собственные системы сид-мониторинга. Обычно это заканчивается тем, что спустя год всё-таки переходят на сторонний сервис, т.к. свой поддерживать дороже, чем заплатить за полноценный чужой. О цене нескольких месяцев потраченных впустую разработки я и вовсе говорить не буду.

24 сентября 2013 г.

Как добавить иконку в mail.ru к своей емейл рассылке

Периодически меня об этом спрашивают. Раньше (году в 2010) всё было сложно - надо было написать по специальному адресу в Mail.Ru, сидящий за ним человек долго думал, и, спустя месяц, у вашей рассылки появлялась иконка.

Теперь же всё просто, иконку можно загрузить напрямую в postmaster.mail.ru на специальной странице по клику на "Изменить аватар".

10 сентября 2013 г.

Интересный случай скрытия повторяющегося контента в Gmail

В Гмейле есть фича, скрывающая ту часть сообщения, которая представляет собой цитату более раннего письма из этой же переписки. Сделано это для того, чтобы получатель по умолчанию видел только ответ, а не всю историю переписки по данному вопросу на несколько страниц.

Однако в случае писем-уведомлений эта фича любит вырезать контент письма, в результате часть сообщения может "исчезнуть". Обычно вырезается одна часть, но сегодня мне попался совсем удивительный пример, когда были спрятаны целые три части письма, включая основную кнопку.

Так выглядело письмо, когда я его открыл:


А вот оно же в развёрнутом состоянии:


Думаю, бороться с этим не имеет смысла, т.к. случаев полного совпадения содержания письма в целом немного. Должно совпасть имя, фотография, тип письма.

9 сентября 2013 г.

Перенос фокуса с емейлов на пуш-уведомления

Хотмейл уже несколько лет старательно раскладывает письма в папки по типам, хоть и показывает их до сих пор в едином инбоксе. Gmail выкатил на всех пользователей версию с табами, где в счётчике новых писем учитываются только самые важные, без апдейтов от соцсетей, предложений купонаторов и т.п.

Для емейл маркетинга это означает снижение числа читающих и кликающих в письмах людей, а также увеличение среднего интервала между отправкой письма и реакцией на него получателя.

Очевидно, в свете таких изменений пора искать и укреплять альтернативные каналы для связи с клиентами. Тут, конечно, можно вспомнить об SMS, ведь у них вероятность прочтения предельная - на уровне 100%, но всё-таки их отправка заметно дороже. Что остаётся? Верно, push-нотификации.

С push-уведомлениями всё проще технически, если сравнивать с емейлами, но всё-таки имеется пара know how, которые требуется знать. Отдельный вопрос – это интеграция пуш уведомления с емейлами и прочими существующими каналами связи. Когда слать пуши, когда емейлы, а может быть и пуши емейлы вместе? Обычно это всё решается отдельно для каждого проекта, идеального рецепта нет. Но есть несколько общих моментов, как то осторожность с отправкой пушей по ночам.

Большим плюсом для маркетологов является то, что владельцы смартфонов не имеют таких эффективных средств работы с пушами, которые имеются в почте. Нет priority inbox, нет кнопки "Это спам", нет автоматического раскладывания пушей по папкам, на Android'е даже не присутствует простая возможность отключать пуш-уведомления от приложений.

Я вижу как емейл маркетинг очень медленно, но становится менее эффективным, а push-уведомлениям российские проекты по-прежнему не уделяют внимания. В целом отсутствует какая-либо шумиха по этому глобальному изменению, всё ограничивается старыми, набившими оскомину рецептами про оптимизации писем для просмотра на мобильных. А жаль!

7 сентября 2013 г.

Контент писем в виде картинок и медленный интернет

Думаю, заголовок поста говорит сам за себя, но всё же. Вот что я видел в течение первых 10 секунд после открытия письма на телефоне:


Человек проверяет свой емейл с телефона на бегу, обнаруживает нежданное промо-письмо, в котором ничего не видно в течение 10 секунд - угадаете, чем дело кончится? :)

А ведь буквально неделю назад я показывал, как другие ребята справились с ситуацией, где картинки отключены в принципе. Чехам бы хватило указания размера картинок и alt-текста.

6 сентября 2013 г.

Оценка эффективности продуктовых изменений

Как правильно оценивать продуктовые изменения? Да-да, любое продуктовое изменение, связано оно с почтой или нет. Другой цвет кнопок в письмах, обновлённый дизайн формы поиска, новая платная услуга – как убедиться, что действительно стало лучше, а не говорить себе "вроде бы сработало"?


В различных проектах мне неоднократно приходилось сталкиваться с ситуациями, когда у продакт менеджера появлялась понятная и простая идея, такая, про которую все говорили - “как же мы не догадались раньше!”. Например, слать уведомления о новых сообщениях вдвое чаще для того, чтобы увеличить число сессий на сайте и число отправленных сообщений.

Такое изменение внедрялось, целевая метрика заметно росла, однако через несколько месяцев фичу отменяли. Почему отменяли? Потому что слишком часто приходящие емейлы через какое-то время “доставали” пользователей, в результате чего они выключали емейл-уведомления, бывшие основным каналом поддержания активности, после чего происходило массовое отмирание аккаунтов.

Поэтому я уверен, что A/B тестирование – единственный работающий подход, позволяющий получить достоверные результаты, а не искать выход на ощупь.


Что же такое A/B тестирование и как его делать правильно? Думаю, вы это и так знаете, но на всякий случай я дам ссылку на статью в википедии и расскажу в паре предложений сам. Итак, A/B тест – это когда вы тестируете два варианта страницы, фичи (старый и новый), или сам факт наличия фичи (нет или есть) на двух группах людей. Тут есть два важных момента:

  • группы должны быть однородными (например, в обеих только парни из Москвы);
  • каждый пользователь должен на протяжении всего теста видеть только один вариант из двух.

Как только вы разделили людей таким образом и собрали данные об их активности/конверсии и т.п., у вас достаточно сведений, чтобы понять, даёт ли предлагаемое изменение позитивные результат.

Что такое A/B тест мы разобрались, теперь надо понять, как правильно его выполнить.

Любое крупное изменение, даже самое очевидное, достойно тестирования

В эту пользу говорит несколько аргументов. Часто бывает так, что тест проводится в виде “включим его только в такой-то стране/городе, а если там всё будет хорошо, то включим везде”. Так поступать нельзя, потому что:

  1. Во время тестирования в этой стране была очень плохая погода, поэтому люди сидели дома и проводили больше времени на сайте (внимание, это пример из реальной жизни!) - а вы посчитаете, что тест удачный.
    В случае, если бы вы проводили A/B тест, то вы бы наблюдали действительную картину, сравнивая 2 группы людей в плохой погоде, а не группу людей в хорошую погоду и группу людей в плохую.
  2. Получив хорошие результаты в стране А вы не имеете никакой гарантии, что в целом по всему проекту это изменение также даст положительный эффект. Правильным было бы провести тест на 5-50% (в зависимости от ваших ожиданий об успешности теста) от всех пользователей.
    Пример из реальной жизни: люди из западных стран, особенно UK и US, неохотно пользуются фичами рассылки инвайтов, в то время как в Восточной Европе и Латинской Америке это прекрасно работает. В результате, проведя тест только в UK и US, можно отказаться от фичи, которая прекрасно сработает в других странах.


Следует смотреть не только на показатели, относящиеся непосредственно к изменяемой фиче, но и на все базовые метрики в целом

Другая ошибка, допущенная в описанном в начале этого раздела случае (учащение отправки уведомлений о сообщениях) заключается в том, что по результатам изменения смотрели исключительно на метрики чата, который пытались оптимизировать, но совсем не обратили внимание на процент юзеров, возвращающихся на сайт спустя неделю/месяц после регистрации. Очевидно, что правильным было бы рассматривать все базовые метрики, чтобы убедиться, что никакая из них заметно не просела, в то время как целевые показатели улучшились.


Такое вот категоричное мнение у меня сложилось. Может быть у вас другой опыт? Есть что сказать – пишите в комментариях.

2 сентября 2013 г.

Чёрный список email-адресов: как долго хранить проблемные адреса?

В любом проекте с развитой почтовой рассылкой имеется список адресов, на которые письма слать нельзя, часто называемый чёрным списком. Пополняется он, главным образом, несуществующими адресами по факту получения баунс-сообщений, а также по информации о жалобах пользователей на спам (FBL-уведомлениям).

Стоит ли хранить их вечно? Наверное, нет, ведь задача состоит в том, чтобы в разы сократить отправку писем на проблемные адреса, но не свести её к полному нулю.

Итак, какие бывают ситуации, когда адрес попадает в чёрный список?

1. Баунс "нет такого адреса". Очевидно, вероятность того, что ошибочно введённый или заброшенный и удалённый адрес вскоре появится, низка. Поэтому я обычно рекомендую установить период хранения таких адресов в несколько месяцев.

2. FBL-уведомление, которое обычно приходит в случае инвайта, если такая система есть в проекте. Мой опыт показывает, что есть весьма хороший шанс, что пользователь, нажавший "Это спам!" сегодня с радостью зарегистрируется по приглашению через полгода. Если же зарегистрированный пользователь невзлюбил ваши письма, то я бы рекомендовал попробовать написать ему заново через примерно тот же срок. Поэтому таймаут получается примерно тот же - несколько месяцев.