Персонализация в письмах обычно повышает кликабельность на 15-20%. Это существенный прирост и он с лихвой покрывает возможный негатив. С которым, впрочем, тоже можно работать. См. мой комментарий выше про стандартный кейс работы с негативом.
1. Нет, эксклюзив для сервисов email-маркетинга. Сейчас поправим в статье. Для любых других сервисов, конечно, она в полном распоряжении.
2. Точность и скорость. Сергей должен выложить обзор по скорости и точности определения в ближайшее время. Мы эту библиотеку любим именно за качество.
Мы прогнали тесты по адресным базам клиентов — неопределенных не более 2% — это достаточная погрешность. Тогда как персонализация дает прирост открытий и кликов в 15-20%. В e-commerce вполне оправдано. Прирост от увеличения конверсии существенно выше, чем потери от исковерканного обращения.
Тем более, есть стандартный кейс: люди, видя такое, пишут гневный отклик отправителю и тут вступает «топ-менеджер», который «разруливает» ситуацию, давая персональную скидку и принося «личные извинения». Все взято в кавычки, т.к. понятно, что от имени топа выступает обычный сотрудник поддержки.
С иностранными фамилиями, безусловно, есть проблема. Но, как вы правильно заметили, проблема не только в автоматике, но и в ручном определении. Можно задавать значение по-умолчанию для таких неопределившихся, например, «Уважаемый клиент!».
Да, подобные имена вводят в ступор. Но вводят в ступор и машину и человека. Разницы нет. Как мы писали, просить пользователей задавать пол самостоятельно — утопия, особенно в ecommerce, где важны десятые доли % конверсии. Поэтому, использование автоматического определения дает экономию в скорости простановки пола.
Если у вас есть готовое решение, мы бы с радостью на это посмотрели. К сожалению, решений, которые одновременно бы качественно работали с xls и xlsx, мы не нашли.
Данные PHPExcel читал, конечно же, не загружаются все в память. Грузится по 4072 строки. (Результаты видны на графиках).
К сожалению, использование приложения для телефона не так универсально, как смс.
1. Есть немало людей, для которых установить и использовать приложение действительно сложно.
2. Если Ваш телефон стоит 700 руб., или, например, выпущен 10 лет назад, то java-приложение может не работать.
3. На простых телефонах обычно нельзя отсканировать QR-код, по-этому, при настройке Google Authenticator придётся вручную вбить ~20 символов секретного ключа.
Из-за этих ограничений на практике среди способов двухфакторной авторизации использование смс является самым популярным. Очень часто расходы на смс ниже, чем финансовые потери от неудобств клиентов, которые возникнут при переходе на приложение для телефона.
Сейчас на «старых» каналах с цифровым именем отправителя типичная цена от 30 коп./смс при малых объемах до 10 коп./смс при больших объемах. Найти провайдера с ценой 10 коп./смс при малых объемах было бы здорово, но вряд ли такие есть.
OAuth действительно кажется применимым, и в MagicLogin используются некоторые принципы его работы. К сожалению, этот протокол существенно шире, чем требуется в данной задаче. Если применить OAuth, то код клиентской серверной части заметно увеличится, что крайне не желательно из-за сложностей с переносимостью и поддержкой.
Если сделать тестовый аккаунт для админки, то на нём придется отключить двухфакторную авторизацию. Это не понятно, не наглядно и криво в реализации. По-этому, по просьбе трудящихся клиентская часть модуля на гитхабе: github.com/magiclogin/magiclogin
Если коротко, то мы сами так и делали, но оказалось слишком много проблем.
Во-первых, шлюзы по 10 коп. за смс используют «старые» каналы с цифровым именем отправителя. По нашему опыту на таких каналах процент задержек и недоставок слишком большой. Мы отказались от дешевых каналов в пользу каналов с буквенным именем отправителя, на которых характерная характерная цена 50 коп. за смс., т.е. как у нас. Получается, что MagicLogin стоит столько-же.
Во-вторых, опыт показывает, что сделать свой велосипед качественно не так просто. На деле это займёт существенно больше, чем пол-дня, скорее около недели. Смена телефона, время жизни смс-пароля, время повторной оправки, защиты от скликивания, резервирование и мониторинг отправки смс — всё это так или иначе придется реализовать. Если использовать MagicLogin, то эти вопросы уже будут решены за Вас.
В третьих, пользователи всех сайтов, которые подключили модуль, будут пассивно искать баги и проблемы. А наш первый приоритет их оперативно исправлять. Таким образом, решение получается более надёжным, чем если Вы будете делать это для одного своего сайта.
Это идеологически проще, но мы специально отказались от использования БД на стороне сайта. Во-первых, взят прицел на поддержку всевозможных платформ, а поддержка различных БД и всевозможных обёрток поверх БД в разных фреймворках добавила бы сложностей.
Во-вторых, чем меньше кода на стороне сайта, тем ниже вероятность найти в нём баг. Баги на стороне нашего сервера мы можем исправлять оперативно и без участия владельцев сайтов. Баги на стороне сайта исправлять намного сложнее.
Показываете ли Вы номера кому-нибудь, например мне, как владельцу сервиса?
Пользователь модуля в админке может видеть телефоны своих пользователей.
Предоставляете ли Вы какие-либо гарантии против утечки телефонных номеров из Вашей базы?
Гарантий от утечки в явном виде нет. Можно утешаться тем, что в случае утечки MagicLogin получит существенный ущерб от плохого имиджа и, вероятно, закроется, т.е. потеряет вложенные в проект деньги и время. Можно прописать штраф в договоре, но как подтверждать факт утечки данных?
Gmail настолько дебильная с точки зрения коммуникации с ними и требованиями своего спам-фильтра служба, занимающая ничтожное значение в нашем трафике, что в нашем RoadMap решение проблем с ними стоит в среднесрочной перспективе (3 до 6 месяцев).
2. Точность и скорость. Сергей должен выложить обзор по скорости и точности определения в ближайшее время. Мы эту библиотеку любим именно за качество.
Тем более, есть стандартный кейс: люди, видя такое, пишут гневный отклик отправителю и тут вступает «топ-менеджер», который «разруливает» ситуацию, давая персональную скидку и принося «личные извинения». Все взято в кавычки, т.к. понятно, что от имени топа выступает обычный сотрудник поддержки.
Данные PHPExcel читал, конечно же, не загружаются все в память. Грузится по 4072 строки. (Результаты видны на графиках).
1. Есть немало людей, для которых установить и использовать приложение действительно сложно.
2. Если Ваш телефон стоит 700 руб., или, например, выпущен 10 лет назад, то java-приложение может не работать.
3. На простых телефонах обычно нельзя отсканировать QR-код, по-этому, при настройке Google Authenticator придётся вручную вбить ~20 символов секретного ключа.
Из-за этих ограничений на практике среди способов двухфакторной авторизации использование смс является самым популярным. Очень часто расходы на смс ниже, чем финансовые потери от неудобств клиентов, которые возникнут при переходе на приложение для телефона.
Во-первых, шлюзы по 10 коп. за смс используют «старые» каналы с цифровым именем отправителя. По нашему опыту на таких каналах процент задержек и недоставок слишком большой. Мы отказались от дешевых каналов в пользу каналов с буквенным именем отправителя, на которых характерная характерная цена 50 коп. за смс., т.е. как у нас. Получается, что MagicLogin стоит столько-же.
Во-вторых, опыт показывает, что сделать свой велосипед качественно не так просто. На деле это займёт существенно больше, чем пол-дня, скорее около недели. Смена телефона, время жизни смс-пароля, время повторной оправки, защиты от скликивания, резервирование и мониторинг отправки смс — всё это так или иначе придется реализовать. Если использовать MagicLogin, то эти вопросы уже будут решены за Вас.
В третьих, пользователи всех сайтов, которые подключили модуль, будут пассивно искать баги и проблемы. А наш первый приоритет их оперативно исправлять. Таким образом, решение получается более надёжным, чем если Вы будете делать это для одного своего сайта.
Это идеологически проще, но мы специально отказались от использования БД на стороне сайта. Во-первых, взят прицел на поддержку всевозможных платформ, а поддержка различных БД и всевозможных обёрток поверх БД в разных фреймворках добавила бы сложностей.
Во-вторых, чем меньше кода на стороне сайта, тем ниже вероятность найти в нём баг. Баги на стороне нашего сервера мы можем исправлять оперативно и без участия владельцев сайтов. Баги на стороне сайта исправлять намного сложнее.
Гарантий от утечки в явном виде нет. Можно утешаться тем, что в случае утечки MagicLogin получит существенный ущерб от плохого имиджа и, вероятно, закроется, т.е. потеряет вложенные в проект деньги и время. Можно прописать штраф в договоре, но как подтверждать факт утечки данных?
Gmail настолько дебильная с точки зрения коммуникации с ними и требованиями своего спам-фильтра служба, занимающая ничтожное значение в нашем трафике, что в нашем RoadMap решение проблем с ними стоит в среднесрочной перспективе (3 до 6 месяцев).