Как превратить посетителей сайта в ваших клиентов?

Секрет успешных продаж очень прост: он заключается в понимании психологии клиента, того, как он думает и чего хочет. Предлагаем вам 10 способов замотивировать клиента, которые базируются на актуальных психологических исследованиях. В них объясняется, как повлиять на максимальное количество посетителей, чтобы они начали использовать ваш продукт. Ниже первые пять из них.

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

NB: Микрокопия — небольшие фразы или даже отдельные слова, которые добавляют вашему сайту индивидуальности, повышают лояльность клиентов и побуждают их совершить целевое действие.

Landing page важны потому, что именно при взгляде на них потенциальный клиент за секунды решает, хочет ли он купить ваш продукт. А значит, лендинги — ключевой элемент маркетинговой стратегии, который нужно улучшать для повышения конверсии. Продолжаем делиться советами по созданию лендингов, на этот раз — вторая часть статьи Peep Laja, написанной от первого лица. Из нее можно узнать, как выбрать копирайтера для лендинга, и почему стоит избегать использования шаблонов при написании текста и при выборе его дизайна.

Текст на продающей странице – это самое главное

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

Много лет назад я был назначен ответственным за пожарную безопасность в одном офисе IT-компании. Выглядело это так: «Распишись здесь и здесь, всё, твою фамилию на щитке повесим, больше ничего не надо». Проблема была в том, что я нашёл, что же действительно означает такая роспись. И начал «строить» всех в офисе по соблюдению правил безопасности. Если вы не пробовали, сообщаю — зачастую очень сложно делать в обычных условиях. В чём проблема? В том, что большая часть людей считает эту норму условностью. Все нарушают, и мы будем.

Теперь представьте, что вы вводите правило, которому невозможно следовать. Или которому не будут следовать, потому что привыкли делать иначе. И не обеспечиваете жёсткий контроль за каждым случаем. Ну, вроде как форума, где материться по правилам нельзя, но модератору плевать. За примерами чуть покрупнее далеко ходить не надо, но не будем сегодня об этом. Представили?

Знаете, что мы в результате только что сделали внутри компании или отдела? Мы создали ситуацию, в которой виноват каждый человек отдельно, но никто в целом. И это очень важный и жестокий инструмент контроля.

Даже прекрасно владея английским, те, у кого этот язык — неродной, могут допускать досадные этические оплошности при деловом общении c клиентами, партнерами, инвесторами, коллегами. Манеры учтивого общения в русском и английском языках различаются; о некоторых нюансах практического взаимодействия с англоговорящими клиентами — в переводе статьи предпринимателя и международного эксперта по продажам Гранта Кардона. Кое-какие советы, впрочем, следует хорошенько обдумать, прежде чем взять на вооружение: давайте обсудим спорные тезисы в комментариях.

Переведено в Alconost.

Какие языки лучше выбрать для локализации своего продукта? Этот вопрос часто ставит разработчиков в тупик. А от правильного ответа на него могут зависеть самые важные показатели – величина прибыли, количество скачиваний или посетителей. Что ж, спешим поделиться с вами любопытной статистикой на эту тему.

Здравствуй, Хабр.

Лето на дворе, скоро отпуск и появилось немного свободного времени поделиться наработками, каким-то опытом по написанию Web приложений на Java платформе. Как основной язык я буду использовать Scala. Это будет похоже на небольшой гайд, как человеку с опытом Java постепенно начать использовать Scala и не отказываться от уже имеющихся у него наработок.

Это первая часть из серии статей, в которой мы уделим внимание базовой структуре приложения. Ориентирована на людей знающих Java, работавших со Spring, Hibernate, JPA, JSP и другими 3-4ех буквенными сокращениями. Я попытаюсь рассказать как максимально быстро и безболезненно начать использовать Scala в ваших проектах и по-другому проектировать ваше новое приложение. Все это будет вокруг проекта, который должен выполнять ряд требований:
1. Приложение полностью закрыто, работаем только после авторизации
2. Наличие удобного API (REST мы забудем (он уже история) и напишем что-то вроде Google AdWords API, со своим SQL like запросником)
3. Возможность запуска на сервере приложений так и без него
4. i18n
5. Миграция БД
6. Среда для разработки должна разворачиваться через Vagrant
7. И, по мелочи, логирование, развертывание…

Все это нужно сделать так, чтобы сопровождать и развивать наше приложение было очень легко, чтобы не возникло такой ситуации, когда при добавление нового справочника программист оценивает это сроком в 2 дня. Если я вас заинтересовал, прошу под кат.

Нас всё время спрашивают: какова погрешность сбора данных в Google Analytics? Какому счетчику лучше доверять? Нельзя ли избавиться ото всех несовпадений и получить точные цифры посещаемости?

Мы всегда отвечаем: погрешность обычно около 10%, явного лидера по точности нет, убрать все ошибки невозможно — так уж устроена технология.

Практически никто не понимает, что неточный сбор данных — это не единственная ошибка, влияющая на результат анализа. Даже идеально собранные данные не позволят нам точно подсчитать нужные показатели на сайте (прежде всего, процент конверсии). Собранных данных может быть недостаточно! Это понимает каждый: если на сайт пришли всего 15 посетителей и ни один из них не заполнил форму заявки на кредит, о конверсии говорить рано. Так подсказывает нам здравый смысл; но в какой момент можно сказать, что данных хватает? Ждать ли еще 100 посещений? 200? 500?

Исповедь 1

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

Весь мой опыт программирования складывается из университетских работ и пары лет пребывания в различных компаниях. Критикующие меня люди неоднократно говорили мне, что в целом я разбираюсь в теме, так что я далеко не клинический случай, как можно было подумать. Однако, очевидно, я выработал совсем не те программистские привычки (как минимум, на взгляд работодателя) и мне нужно срочно изменить их. Везде, где бы я ни работал, мои решения, использующие иерархии мелких классов с делегированием поведения, признавались плохими. Говорят, будто так и надо писать, но это не так. Потому что всё это «как надо» может стоить мне работы.

Мы продолжаем цикл статей о том, как построить стартап, — рассказываем о каждом шаге на собственном примере. Мы уже описали, как придумать идею и как собрать команду, теперь поговорим о бизнес-модели.

Дисклэймер: мы, проект Witget, развиваем собственный сервис инструментов повышения конверсии. Cтараемся находить и обобщать опыт более старших и успешных товарищей на темы интернет-маркетинга и юзабилити. Представляем вам список из 7 самых типичных ошибок при создании лендингов, подготовленных на основе материалов из блога SiteTuners. Статья дополнена примерами и советами от нашей команды.

Лендинги часто незаслуженно игнорируют. Статистика показывает, что на оптимизацию трафика тратится в среднем в 83 раза больше средств, чем на оптимизацию лендингов. Однако трафик – это полдела, главное конвертировать посетителей сайта в покупателей. Лендинги могут в значительной степени формировать вашу прибыль, поэтому игнорировать оптимизацию этих страниц не стоит.

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

Рассказав в одной из предыдущих статей про 7 вещей в оптимизации лендингов, которые часто делают неправильно, хотим продолжить тему, связанную с улучшением веб-сайтов. Однако, на сей раз мы посмотрим на нее с иной стороны. Если ваша работа связана с оптимизацией конверсии, вы уже знаете, насколько важно Usability-тестирование. В конце концов, если посетителям сайта неудобно пользоваться его интерфейсом, шансы на то, что они конвертируются в покупателей, невелики. На сегодняшний день маркетологи могут пользоваться услугами постоянно растущего общества удаленных usability-тестировщиков. В этой переводной статье рассказывается о шести, на взгляд автора оригинальной публикации, наиболее интересных площадках для этой цели.

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

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

Возможно, эти события и не были такими удивительными для опытных ИТ-гуру (эка невидаль, когда одна компания покупает 700 инженеров у другой), но для автора, на тот момент управлявшего небольшим отделом о 17 человеках, эти события послужили источником многочисленных наблюдений и выводов о работе с людьми.

В частности о том, как обсуждать собственную зарплату с руководством – на эту тему сегодня и поговорим, потому что из того, что приходится наблюдать на тренингах – 90% людей совершают одни и те же ошибки, получая минусы в карму и тормозя собственную карьеру (правильный ответ на вопрос, как это делать – в конце статьи).

«Как она могла так поступить со мной?» — спрашивал я себя. Каждый день. Все время.

В 2011 году, когда еще были популярны градиенты, а Ай-ОС иконки задавали направление в дизайне и люди пользовались дезодорантами, я был в депрессии из-за своего развода.

К счастью, я оказался достаточно находчивым, чтобы выбраться из нее. (Еще мне помогли замечательные люди, которые меня окружали.)

* * * * *

Как-то раз, я пришел в офис и взглянул на свой монитор. Все было классно, пока я не увидел это сообщение:

Ваш пароль устарел.
Кликните на кнопку «Изменить пароль», чтобы изменить пароль.

Да ладно! А я-то думал кнопка «Изменить пароль» предназначена для чего-то другого.

Я прочитал это дурацкое сообщение про себя голосом ворчливого старика: «Чертов пароль устарел».

На моей работе Microsoft Exchange Server требовал менять пароль каждые 30 дней у тысяч сотрудников.

Это был полный бред: было необходимо использовать в пароле хотя бы одну заглавную букву, хотя бы одну строчную букву, хотя бы один символ и хотя бы одно число. Общее количество символов должно было быть больше восьми. И я не мог ввести пароль, который использовал за последние три месяца.

Я был в ярости этим утром вторника в 9:40. На улице было настолько жарко, что я вспотел еще до того как приступил к работе. Я опоздал. Я был все еще в своем шлеме. Я забыл позавтракать. Во рту был вкус напоминающий сигарету. Мне предстояло разобраться с этим до начала совещания в 10 часов. Впереди меня ожидала необходимость потратить на это кучу своего времени.

* * * * *

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

Вскоре, немного успокоившись, я вспомнил про метод, который слышал от своего бывшего начальника Расмуса. Он объединил список дел с паролями. А я решил использовать расширенный вариант этого метода.

Я решил использовать пароль, чтобы изменить свою жизнь.

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

На них будут показывать пальцем, плевать и топтать ногами. Так, наверно, думает каждый, кто мается сомнениями по поводу — описывать свои неудачи или нет. Да, конечно, легко задним умом судить. Принимать решения, находясь внутри ситуации, гораздо тяжелее.

Я очень долго не решался это сделать, но что-то меня настойчиво подвигало. Я думаю, это было естественное желание помочь другим людям — в данном случае хотя бы советом, как делать не нужно.

В Яндекс.Браузере, как и в любой другой многофункциональной программе, есть возможности, о которых знают далеко не все. Причем проигрывают от этого не только сами пользователи, но и продукт в целом — его потенциал в результате не раскрывается перед всей аудиторией. Можно сколь угодно долго шлифовать дизайн, наполнять справочные материалы и писать статьи на Хабр, но основная масса пользователей по-прежнему не будет знать обо всех возможностях. Нам нужен был новый, более умный и точный, инструмент, позволяющий аккуратно обучить пользователя. В этой статье мы поделимся своим опытом создания подобного, и, возможно, он пригодится вам при разработке своих продуктов.



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

Помимо Справки существует такая вещь, как стартовая страница (мы ее называем «welcome page») с описанием нескольких наиболее ярких возможностей. Но возможностей много, а терпения у пользователя не очень. Поэтому нужно было придумать что-то еще. Не будем вам говорить, что в результате мы изобрели всплывающие подсказки. Их ведь применяют в различных программах уже очень давно. Вспомните хотя бы всемирно известную Скрепку из одного очень популярного офисного пакета, у которой были как сильные стороны, так и некоторые досаждающие моменты. Вот эту идею мы и взяли за основу, чтобы на базе нее построить свою систему умных подсказок. А дальше началось самое веселое.

Можно ли ответить на вопросы клиента еще до того, как он их задаст? Общаться с клиентом по-свойски или в официальном тоне? За какое время надо отвечать на вопросы в почте? Как сделать клиента счастливым и постоянным?

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

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

Java приложения — значит в современном Java мире возможность встретить такое процентов на 90%, а то и больше (рассматриваем самые распространённые окружения, HotSpot based JVM версии от 1.6)
которое нельзя остановить — приложение работает, и перезапускать его по тем или иным причинам категорически нельзя
экзотика — нечто такое этакое, что не каждый день в голову взбредёт поймать (определённая последовательность вызова методов, диковинные комбинации значений параметров, ...)
доступными средствами — бесплатно, работоспособно, эффективно, легко, просто и т.д и т.п. В данной статье рассмотрен замечательный инструмент BTrace kenai.com/projects/btrace

И само собой в код Java приложения заранее ничего специально не добавлено касательно средств дебага…

Извиняюсь за заголовок в стиле «for Dummies», но это именно то, о чем я хочу сегодня поговорить — о монетизации. В двух словах о себе: занимаюсь инди-геймдевом с 2010 года, на данный момент у меня около десятка изданных игр на Play Store с общим количеством загрузок чуть-чуть не дотягивающим до 20 млн. Я не люблю распространяться о финансовой стороне, но понимаю что в теме о деньгах, без этого никак. На КДПВ вы можете видеть мою статистику за несколько последних дней (на момент написания статьи). В общем, бывало хуже, но бывало и лучше! Цифры не из тех, что поражают воображение, но, согласитесь, довольно неплохие. Особенно, учитывая что я всего лишь любитель, клепающий игры по вечерам.



В этом топике, я попробую поделиться выводами и наработками, которые сделал за это время. На всякий случай disclaimer: мое мнение не претендует на истину и основано лишь на моем субъективном опыте. Я всегда готов поучиться у более опытных коллег, так что если я в чем-то ошибаюсь — прошу в комменты. И второе: это взгляд на геймдев с точки зрения бизнеса, если вы не разработчик, вам может не понравиться то что я скажу.

Мы продолжаем цикл статей о том, как построить стартап, где рассказываем о каждом шаге на собственном примере. В первой статье мы рассказали о том, как придумать идею, теперь поговорим о команде.