Профессиональные сервисы рассылок: emailVision, exactTarget, intelligentEmails.
Полупрофессиональные сервисы рассылок: Pechkin-mail, SmartResponder, mailigen, mailChimp, epochta, Subscribe, justclick, unisender.
Письма с подтверждениями люди открывают чаще всего. Не забывайте о «взрослении» аудитории.
Принципы (элементы) копирайтинга:
1.Заголовок должен заставить человека прочесть первый абзац. Шрифты в заголовке отлично привлекают внимание в вызывают больше доверия. Ровным числам 10, 20, 30 люи доверяют меньше, чем неровным 15, 17, 21.
2. Подзаголовок раскрывает суть заголовка.
3. Короткое первое предложение.
4. Заголовки параграфов помогают быстро оценить текст.
5. Первый абзац простой и понятный.
6. Снимок или рисунок (текст с изображением больше привлекает внимание).
7. Подпись под изображением мощная фраза.
8. Описание продукта.
9. Технические характеристики.
10. Отзывы, свидетельства, награды (нельзя подделывать!).
11. Цена.
12. Вид обратной связи для вопросов.
13. Предугаданные возражения.
14. Итоги.
15. Призыв к действию (чего хотите от читателя?).
16. Причина реагировать сейчас.
17. Способы оплаты можно платежный агрегатор.
18. Гарантия.
19. Постскриптум.
Максимальное внимание привлекает первый квадрат 500 на 500 пикселов.
Не более 3-х шрифтов в письме.
Самые читаемые четырех-пятистрочные абзацы.
Оптимальная ширина письма 600 пикселей, или 6080 символов 1012 pt.
Фон в письме белый или светлых оттенков.
С HTML можно создать уникальный дизайн или фирменный стиль писем, чтобы сразу понимали, что речь идет о вашей компании, можно вставить в письмо кнопки соцсетей.
С картинкой в письме обязательно должен быть текст.
Вопросы для проверки своего письма: что хотите сообщить заказчику; почему вам должно быть это интересно; что вы хотите, чтобы сделал подписчик; куда попадают ваши подписчики после переходов по ссылкам в письме; не перегружает ли дизайн текст или другие объекты.
Проверять письмо в разных браузерах до отправки и проверять ссылки.
Рассылать разную рекламу для проверки реакции на содержимое.
B2B на вы.
B2C на ты или вы.
Обязательна ссылка в письме, но не более 3-х.
Рассылка должна быть регулярной.
Чем больше о вас знают потенциальные клиенты, тем лучше.
В 2016 году в мире будет отправляться более 192 млрд писем в день.
Разбивать аудиторию хотя бы на 3 группы.
Чем больше вы знаете о подписчиках, тем лучше.
Переподписка раз в несколько месяцев.
В e-mail маркетинге важны взаимоотношения с клиентом, а не хитрости и уловки.
Отписываться будут всегда.
Чем больше неактивных клиентов, тем чаще письма будут попадать в спам, поэтому неактивных лучше удалять самостоятельно.
Рассылку надо планировать на 36 месяцев.
Анализировать отношение открытий к переходам.
Полезные высказывания из книги «Чистый код» Мартина
В разделе приведены цитаты из [3].
Единственный способ выдержать график постоянно поддерживать чистоту в коде.
Поэтому нужно развивать «чувство кода».
Чистый код:
элегантный и эффективный;
логика прямолинейна;
зависимости минимальные;
обработка ошибок полная;
производительность близкая к оптимальной;
решает одну задачу;
поддерживается в чистоте с течением времени.
Следующая книга «Agile software development; Principles, patterns, and practices», 2002.
Содержательные имена:
имена всех объектов должны отвечать на все главные вопросы: почему существует, что делает и как используется, не требуют дополнительных комментариев, содержательные, передают намерения программиста;
код очевиден, контекст следует из самого кода;
не содержат ложных ассоциаций, затемняющих смысл кода;
не используются слова со скрытыми значениями, отличными от предполагаемого;
лучше обойтись без кодирования типа контейнера в имени.
Имена не содержат малозаметных различий, непохожи друг на друга излишне.
Имена не дезинформируют.
0 не равен O, 1 не равна l.
Используется правильный шрифт.
Используются осмысленные различия.
Имена не дублируют зарезервированные слова с незначительными изменениями.
Если имена различаются, они должны обозначать разные понятия.
Различия имен содержательны.
Префиксы используются, если создают осмысленные различия.
Не содержат неинформативных, избыточных слов.
Имена не отличаются только суффиксами.
Читателю кода понятен смысл различающихся имен нет соблазна использовать 2 похожих имени по одному назначению.
Имена удобопроизносимы.
Программирование социальная деятельность.
Не должны состоять из одних сокращений.
Состоят преимущественно из слов разговорной речи.
Удобны для поиска.
Легко находимы в большом объеме кода.
Относительно редкие.
Длинные имена лучше коротких.
Однобуквенные используются только для локальных переменных в коротких методах.
Длина имени соответствует размеру его области видимости.
Имя не содержит информации о типе или области видимости.
Не создает хлопот при расшифровке.
Неразумно заставлять каждого нового работника изучать очередной «язык» кодирования.
Имя остается понятным даже в случае опечатки.
Имя не усложняет изменение типа переменной.
Типы в именах не кодируются.
Переменные классов без префиксов.
Классы и функции компактны можно обойтись без префиксов.
Имя не содержит балласта.
Имена интерфейсов без префиксов.
Имена не содержат лишней информации.
Не заставляют мысленно преобразовывать имена в другие.
Используются имена из пространств задачи и решения.
Счетчик цикла с малой областью видимости можно назвать 1 буквой это традиция.
Ясность превыше всего.
Код понятен для других людей.
Имена классов и объектов существительные и их комбинации без глаголов, не содержат обобщенных понятий Manager, Processor, Data, Info.
Имена методов глаголы или глагольные словосочетания.
Методы чтения или записи и предикаты образуются из значения и префикса get, set и is.
При перегрузке конструкторов использовать статические методы-фабрики с именами, описывающими аргументы (принудительное инспользование таких методов).
Нет остроумных шуток.
Ясность предпочтительнее развлекательной ценности.
Нет просторечий и сленга.
Нет шуток.
Одно слово для каждой концепции.
Имена функций законченные и логичные.
Нет эквивалентных методов с именами fetch, retrieve, get в разных классах.
Нет controller, manager, driver в одной кодовой базе.
Имена различны принципиально.
Единый согласованный лексикон.
Не используется одно слово в двух смыслах.
Две разные идеи не обозначены одним термином.
Нет каламбура.
Мысли в коде выражаются доступно.
Используются имена из пространства решения: термины из области информатики, названия алгоритмов, паттернов, математические термины, технические имена.
Используются имена из пространства задачи (клиентские): если нет подходящего программиста, узнаются у специалиста в предметной области.
Разделение концепций из пространств задачи и решения.
Несодержательные сами по себе имена помещаются в определенный контекст для читателя кода классы, функции и пространства имен с правильно выбранными названиями.
В крайнем случае контекст уточняется префиксом.
Контекст не должен вычисляться.
Функции разделяются на меньшие смысловые фрагменты.
Нет избыточности контекста.
Нет работы против собственного инструментария.
Короткие имена лучше длинных, если только их смысл понятен читателю кода.
Имена экземпляров более точные.
Развивать описательные навыки и единый культурный фон.
Не должно быть опасения возражений при переименовании.
Функции:
Первый уровень структуризации.
Длина не избыточна.
Не содержит повторяющихся фрагментов кода.
Один уровень абстракции.
Функции компактны.
Функции еще компактнее.
Функции желательно не более 20 строк.
Все функции предельно очевидны.
Блоки в командах if, else, while и так далее должны состоять из 1 строки, в которой обычно вызов функции.
Функции не содержат вложенных структур.
Не более 12 отступов.
Функция должна выполнять только одну операцию. Она должна выполнять ее хорошо. И ничего другого она делать не должна.
Если функция выполняет только те действия, которые находятся на одом уровне под объявленным именем функции, то эта функция выполняет одну операцию.
Функции пишутся прежде всего для разложения более крупной концепции (иначе говоря, имени функции) на последовательность действий в следующем уровне абстракции.
Чтобы определить, что функция выполняет более 1 операции, надо попробовать извлечь из нее другую функцию, которая бы не являлась простой переформулировкой реализации.
Функцию, выполняющую только одну операцию, невозможно осмысленно разделить на секции.
Все команды функции находятся на одном уровне абстракции.
За каждой функцией должны следовать функции следующего уровня абстракции.
Switch, длинные цепочки if-else скрывать в низкоуровневом классе и не дублировать в коде (использовать полиморфизм).
Принцип единой ответственности (single responsibility principle).
Принцип открытости-закрытости (open-closed principle).
Программа не содержит неограниченного количества других функций с аналогичной структурой (можно использовать абстрактную фабрику).
Имя точно описывает, что делает функция.
Длинное имя функции лучше короткого невразумительного.
Не бойтесь расходовать время на выбор имени функции.
В именах функций использовать те же словосочетания, глаголы и существительные, что и в модулях.
В идеальном случае количество аргументов функции равно нулю.
Использовать функции 1 аргумента:
для проверки некоторого условия, связанного с аргументом;
для обработки аргумента, его преобразования и возвращения;
для события (вход есть, выхода нет);
должно быть предельно ясно, что перед читателем событие;
остальных форм функций с 1 аргументом лучше избегать;
не использовать аргументы-флаги.
Бинарные функции оправданны, если оба аргумента упорядоченные компоненты одного значения.
Использовать все доступные способы для сведения функций к унарной форме.
Аргументы должны иметь естественную связь и естественный порядок.
Хорошо подумать перед созданием тернарной функции.
Упаковывать аргументы в объекты.
Если переменное количество равноправных аргументов упаковать в List.
Хорошее имя функции способно объяснить смысл функции, порядок и смысл ее аргументов.
В унарных функциях функция и аргумент должны образовывать естественную пару «глагол существительное».
Функция не делает чего-то скрытно от пользователя.
Нет побочных временных привязок функции.
Нет побочных эффектов.
Нет причин лишний раз обращаться к сигнатуре функции (нет повторных заходов).
Выходных аргументов следует избегать.
Функция может изменять состояние только владельца.
Функция либо что-то делает (команда), либо отвечает на какой-либо вопрос (запрос).
Функция либо изменяет состояние объекта, либо возвращает информацию об этом объекте.
Исключена неоднозначность имен функций.
Функции-команды не возвращают коды ошибок.
Вместо возвращения кодов ошибок используются исключения.
Тела блоков try/catch выделены в отдельные функции.
Функции выполняют 1 операцию.
Обработка ошибок одна операция.
Нет магнитов зависимостей классов или перечислений, импортируемых и используемых многими другими классами.
Нет дублирования алгоритмов.
Уменьшена вероятность ошибки.
Goto не используется.
Много return, break, continue допускается в компантных функциях.
В коде сначала излагаются мысли, а затем «причесываются».
Система рассматривается как история, которую нужно рассказать.
Комментарии неизбежное зло.
Только код может правдиво сообщить, что он делает.
Свести использование комментариев к минимуму.
Комментирование причина повысить качество кода.
Вместо юридических комментариев ссылки на них.
Информацию лучше передавать в имени функции.
Использовать комментарии для информации о намерении.
Комментарии в случае неудобочитаемых форм данных.
Комментарии для предупреждения о последствиях.
Комментарии TODO на будущее.
Комментарии для подчеркивания важности обстоятельства.
Не делать комментарии на скорую руку.
Комментирий не приводит к поиску расшифровки в других модулях.
Использовать аналог Javadoc.
Не комментировать бормотанием.
Не комментировать избыточно.
Комментарии точнее кода.
Комментарии точные и соответствуют коду.
Комментарий не вводит в заблуждение и не дезинформирует.
Бессмысленные или обязательные комментарии исключены.
Комментарий не повышает риск обмана и недоразумений.
Длинные журналы комментариев исключены.
Комментарии не загромождают и не усложняют код.
Комментарии-шумы исключены.
Комментарии не утверждают очевидное, не предоставляя новой информации.
Комментарии не бесполезны.
Комментарии не вызывают желания игнорировать их.
Комментарии не содержат эмоций.
Комментарии делают работу приятной и эффективной.
Комментарии не используются там, где можно использовать функцию или переменную.
Заголовки в комментариях применяются, когда приносят ощутимую пользу.
Закрывающие скобки не комментируются.
Ссылки на авторов в комментариях заменяются использованием системы контроля версий.
Нет закомментированного кода.
Нет HTML-комментариев.
Комментарии описывают код, к которому отнесены.
Комментарии не содержат дискуссий, исторических подробностей, не относящихся к делу.
Связь между комментарием и его кодом очевидна.
Цель комментария объяснить код, который не объясняет сам себя.
Комментарий не нуждается в объяснении.
Комментарии для API общего пользования не помещаются в коде, не предназначенном для общего потребления.
Комментарий упрощает понимание алгоритма пользователем.
Код должен быть хорошо отформатирован.
Форматирование облегчает передачу информации.
Маленькие файлы понятнее больших.
Типичная длина файла 200 строк, предел 500.
Исходный файл выглядит как статья.
Имя файла простое, но содержательное.
Имени файла достаточно, чтобы определить. этот модуль нужен или нет.
Начальные блоки файла описывают высокоуровневые концепции и алгоритмы.
Степень детализации увеличивается к концу файла.
В конце файла собираются все функции и подробности низшего уровня.
Код читается слева направо и сверху вниз.
Законченные мысли отделяются пустыми строками.
Строки кода с тесной связью должны быть сжаты по вертикали.
Тесно связанные концепции не находятся в разных файлах.
Следует избегать запущенных переменных.
Читателю не нужно прыгать туда-сюда по исходным файлам и классам.
Переменные объявляются максимально близко к месту использования.
Переменные перечисляются в начале каждой функции.
Управляющие переменные циклов объявляются внутри конструкции циrла.
Переменные экземпляров объявляются в начале класса.
Если одна функция вызывает другую, то они располагаются вблизи друг друга по вертикали.
Вызывающая функция располагается над вызываемой.
Концептуально родственные фрагменты кода располагаются близко друг к другу по вертикали.