Метка: рост

  • Точность растёт с объёмом

    Точность растёт с объёмом

    Мы получили 647 посетителей, 105 лидов и 17 продаж.

    Как понять, можно ли доверять полученным конверсиям из посетителя в лида и из лида в продажу? Не рано ли делать прогнозы или уже можно принимать судьбоносные решения?

    Применяем математику на практике — вычисляем погрешность. Нам нужно, чтобы погрешность была менее +/-5 процентных пунктов.

    Наши переменные:
    – Объём выборки 647 посетителей.
    – Текущее значение конверсии, 105 лидов / 647 посетителей * 100% = 16.2%.
    – Вероятность ошибки — каков шанс, что мы ошибаемся? Классический уровень для первого расчёта — 5%. Если нужна повышенная увереность при работе с важными данными, можно поставить вероятность ошибки 1%.

    Спрашиваем GPT: Рассчитай точность определения конверсии для 105 лидов на 647 посетелей при вероятности ошибки 5%

    Получаем ответ: Погрешность +/-2.8 п.п..
    Т.е. реальная конверсия может лежать в пределах от 13.4% до 19.0%. С такой точностью можно строить прогнозы и принимать решения.

    Если рассчитать погрешность для продаж из начала поста, то получится погрешность +/-10 п.п. Широкий интервал, но границы диапазона уже можно увидеть. Нужно добрать лидов, чтобы сузить интервал и сделать более точные выводы.

    Простой лайфхак:
    В начале сбора данных точность очень быстро растёт, а потом рост точности замедляется. Посмотрите на график: в зависимости от конверсии, точность 95% мы получим на выборке от 139 до 323 случаев.
    Можно использовать это как ориентир:
    – после 300 посетилей можно заниматься оптимизацией посадочной.
    – после 300 лидов — садиться переписывать скрипты.

    Так что, 300 раз отмерь, один отрежь. И да простят меня математики.

  • Sentry для отлова ошибок

    Sentry для отлова ошибок

    Пользователи жалуются, что на сайте возникает ошибка. У разработчика “всё работает”. В команде разработки никто ошибку не может воспроизвести ни на одном устройстве. Бывает, что в логах нет ничего, потому что ошибка произошла на фронте. Или записи не информативны. А пользователи продолжают жаловаться…

    Чтобы разбираться с этими случаями, в нашей веб-студии мы подключаем к проектам Sentry. Это мониторинг ошибок и производительности приложения. В отличие от обычных логов, Sentry показывает гораздо больше информации об ошибке:
    – новая ли это ошибка
    – сколько таких ошибок возникло за последние дни
    – весь стек вызова
    – чему были равны переменные окружения
    – какие библиотеки были подключены
    – какой браузер и устройство у пользователя
    – информацию о пользователе
    – содержимое запроса
    – что делал пользователь до ошибки
    – версию, релиз и коммит

    Это всё позволяет очень быстро найти реальную причину возникшей проблемы.

    Мы подключаем Sentry на фронт, это также просто, как установка обычного счётчика или npm-пакета. И подключаем отдельно на бэк — Sentry умеет интегрироваться с любым языком и фреймворком за счёт готовых SDK.

    Раньше мы пользовались SaaS-версией, но некоторое время назад всех РФ-пользователей попросили завершить обслуживание. Так что, я развернул бесплатную self-hosted версию на своей VDS. Система прожорливая, Docker Compose запускает три десятка контейнеров, поэтому требуется достаточно мощный сервер. Такой сервер у нас выходит на 4000 рублей в месяц, зато обслуживает десятки небольших проектов.

    Sentry — инструмент для быстрого поиска ошибок разработчиками. Не заменяет потоки логов и мониторинг инфраструктуры. Рекомендую всем, кому нужно ловить баги в продакшине.

  • Тепловая карта скролла

    Тепловая карта скролла

    Запустили лендинг и пустили на него трафик. Чтобы понять, хороший ли у нас лендинг, нужно посмотреть на конверсию. Если конверсия низкая, важно понять, на каком этапе пользователь теряет интерес. Поможет нам в этом тепловая карта скроллинга по нашей странице. Она показывает, сколько времени люди провели в каждом блоке и как глубоко прокрутили страницу. Блоки должны терять температуру с глубиной скролла. Так же, как при погружении в океан: на поверхности вода тёплая, а на глубине холоднее.

    Чтобы карта показала правдивый результат, на страницу должно зайти больше 200 человек. Смотрим, где нарушен порядок: между жёлтым и оранжевым блоком будет находиться зелёный. Это означает, что люди проматывают этот блок.
    Простое решение: переставить блоки по убыванию температуры.
    Хорошее решение: переработать или заменить холодный блок, чтобы его не пролистывали.
    Исправление проблемного блока нагревает блоки ниже, потому что посетители продолжают скроллить и не закрывают лендинг.

    Я анализировал много лендингов по RDB-модели и заметил, что для длинных лендингов обрыв температуры начинается после захвата лида в конце блока дифференциации. На небольших лендингах можно достичь достаточно равномерной температуры скролла вплоть до подвала.

    Карта скроллинга находится в Яндекс Метрике → Поведение → Карта скроллинга. Нужно включить Webvisor в настройках сайта и в коде счётчика.

  • Как победить стресс при перегрузке задачами

    Как победить стресс при перегрузке задачами

    Посмотрел советы бывшего шпиона ЦРУ о принятии решений в состоянии стресса. Захотелось поделиться со всеми, но видео на английском. Так что я сделал небольшой конспект.

    TL;DR: Когда завален задачами — делай самое простое следующее действие. Не пытайся решить всё сразу, освобождай пространство и возвращай контроль шаг за шагом. Практикуй эту технику, пока она не станет инстинктивным поведением в состоянии стресса.

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

    Правило “минус 2”: уменьшить количество одновременных задач. Подумай, сколько ты можешь задач затащить одновременно, и вычти две. Кажется, что ты можешь делать пять — вычти две и решай не более трёх задач одновременно. Это увеличивает количество твоих ресурсов на каждую задачу, а значит, ты их сделаешь лучше и быстрее.

    Прими, что ты уже перенасыщен задачами. Ты не сможешь сделать всё сразу, это уже факт. Отсортируй задачи по времени на их выполнение. Самые быстрые задачи должны оказаться сверху.

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

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

    Всё это работает потому, что так были устроены наши предки. Метод “делай следующую самую простую штуку” работал на их выживание, работает для нас и сейчас.

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

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

  • Я чайник!

    Я чайник!

    В 1990 году первым устройством, управляемым через интернет, стал тостер. А 1 апреля 1998 года был предложен шуточный стандарт RFC 2324 для управления кофе-машинами через HTTP-протокол.
    Браузер шлёт запрос на веб-сервер, а веб-сервер сообщает браузеру о своём состоянии кодом из трёх цифр. Для тех случаев, когда запрос на варку кофе получает чайник, был выделен специальный код статуса веб-сервера 418 — Я чайник. Он должен сообщить, что сервер не сможет сварить кофе, но вместо этого сервер сообщает, что он простой чайник. Ответ фактически правильный, но пользователю не помогает — ну, чайник, а мне что делать-то?

    Мы должны видеть страницу сайта или страницу с ошибкой и понятными инструкциями. Коды со статусом веб-сервера предназначены для программистов, сисадминов и SEOшников. Кодов более 60, с некоторыми из них вы наверняка сталкивались.
    404 — Страница не найдена. Самый известный код ответа. День вебмастера отмечается каждый год 4.04. Эти страницы часто оформляют веб-дизайнеры.
    301 — Документ переехал. Чаще всего этот статус появляется в результате работы SEOшника. Пользователя моментально перенаправляет на другой адрес.
    500 — Внутренняя ошибка сервера. Программист залил код с ошибками.
    502 — Шлюз недоступен. Позовите сисадмина.
    503 — Сервис недоступен. Позовите сисадмина и программиста.

    Разработчики веб-серверов умеют хорошо писать серверный код, а про красивые и понятные сайты только слышали от знакомых. Поэтому сотни тысяч людей каждый день фрустрированы созерцанием 500ых ошибок в тупиках интернета.

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

  • Модель RDB — инструмент для мышления маркетолога

    Модель RDB — инструмент для мышления маркетолога

    Все коммерческие предложения, лендинги, ТЗ на рекламные плакаты и вообще всю маркетинговую коммуникацию я уже много лет проектирую на основе модели RDB. Про неё я узнал из выступления Ильи Балахнина и тут же применил на одном из клиентских проектов. Удалось вырастить конверсию лендинга в 3 раза не прибегая к редизайну — я просто блоки переставил местами в соответствии с моделью.
    Модель даёт отличные результаты на практике, потому что позволяет выстраивать повествование про ваш бренд или предложение в понятном потребителю порядке.

    Resonance
    В резонансе нужно русским по белому написать ваше предложение на понятном клиенту языке. Запуск интернет-магазина для бренда одежды за 30 дней.
    Клиент узнаёт себя, чётко и ясно понимает вашу услугу. Важно, чтобы всё окружение резонанса транслировало сопутствующую атмосферу и атрибуты. Картинка с котятами не подойдёт — нужны картинки интерфейсов современных интернет-магазинов с одеждой, фэшн-фотографии и процесса оформления заказа. Шрифты, цветовая палитра, Tone of Voice — должны соответствовать резонансу. Не стесняемся лепить самую банальщину. Клиника — врачей в белых халатах, а не яблоки на тарелке или здоровых пациентов.

    Differentiation — отличие от других.
    Для B2C брендов нужно говорить про потребителя и как его индивидуальность будет подчёркивать этот продукт или услуга. Чем он будет отличаться от других после покупки.
    Для B2B рынка мы делаем ровно наоборот — доказываем, что мы такие же, как и все: соблюдаем стандарты, имеем лицензию, делаем по методологии. Корпоративный клиент не хочет рисковать, поэтому предпочтёт проверенное решение. Магазин на WordPress, а не самопис от нашей студии. Бухучёт по международному стандарту, а не по авторской методике.

    Belief — создаём доверие и внушаем веру в продукт или компанию. Размещаем логотипы и отзывы клиентов. Показываем производство и работников. Публикуем реквизиты компании. Даём значимые цифры, подтверждающие наш опыт и компетенции. 3 тысячи сайтов сделано, 20 тысяч клиентов выздоровело, 300 миллионов рублей потрачено.

    В ходе применения RDB и обратной связи я немного модифицировал формулу. Мой порядок применения модели: RBDB, — два раза используется Belief. Первый раз мы создаём доверие сразу после резонанса. Внимание покупателя захвачено, нужно сказать, что мы норм, чтобы следующий блок был встречен с предварительно сформированным доверием. Достаточно краткой полоски логотипов, фотографий людей и значимые цифры. Второй раз мы будем использовать весь арсенал — отзывы, фотографии, сертификаты и награды, видео-ролики и демонстрацию внутрянки. Этот Belief может быть огромным лонгридом для самых недоверчивых Осликов по матрице Винни-Пуха.

    Применение этой модели сильно снижает предстартовую фрустрацию и позволяет мне сразу создавать скелет эффективного КП или лендинга.

  • Файлы теперь лежат в ведрах

    Файлы теперь лежат в ведрах

    Раньше, когда пользователь загружал картинки на сайт, картинки сохранялись в папку на том же сервере. У популярных сайтов диски быстро заполнялись и требовалось следить за этим. Далее серверы начали упираться в ограничения на количество файлов в папке и на количество папок на диске.

    В 2006 Амазон запустили Simple Storage Service (S3) — сервис с простым хранением файлов в облаке, призванный решить все эти вопросы. Через API загружаем файл, сервис генерирует ссылку. Файл загружается в вёдро (bucket), а не на диск. Вёдра не имеют ограничений как у папок и могут быть распределены по разным серверам.

    Сейчас S3-сервис можно создать на многих хостингах в пару кликов. Также можно развернуть своё S3-хранилище с помощью Open Source, например MinIO.

    Для чего это нужно нам сейчас на практике?
    – Загружать и хранить бэкапы — первое с чего обычно начинают.
    – Хранить файлы отдельно от нод, обрабатывающих запросы.
    – Отдавать статические файлы сайта (картинки, скрипты, файлы для скачивания) с отдельного сервиса.
    – Избегать ситуации с переполненным диском на сервере за счёт переноса всех больших файлов в S3.
    – Организовывать безразмерные хранилища файлов на терабайты с открытым и закрытым доступом.
    – Для S3-хранилищ есть библиотеки на всех популярных языках.
    – Все S3-совместимые хранилища работают по образцу Amazon S3, поэтому ко всем хранилищам нужна одна библиотека.
    – Для разработки в docker-compose удобно использовать образ MinIO.

    Может тарифицироваться:
    – Стоимость хранения в гигабайтах.
    – Стоимость трафика загрузки в облако (чаще всего бесплатно)
    – Стоимость трафика выгрузки из облака.
    – Запросы к файлам.
    – Хранение старых версий файла (если работает с версионированием).

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

  • Клиент забыл, какой хостинг у его сайта

    Клиент забыл, какой хостинг у его сайта

    Два раза за последние сутки разыскивали потерянные хостинги для клиентов.

    Порядок действий:
    0) Домен-то вы знаете? 😆
    1) Нужно посмотреть в DNS куда направлена A-запись этого домена.
    Для консольщиков:
    Команды nslookup (Windows) или host (macOS/Linux).

    $ host fullstackfounder.ru  
    fullstackfounder.ru has address 46.173.18.24

    Для нормальных людей:
    Идём на сайт https://mxtoolbox.com/, выбираем режим DNS Lookup.
    Сразу видим IP-адрес и в чьём диапазоне он находится.

    2) Узнаём, за кем закреплён IP-адрес
    Идём на сайт https://ipinfo.io/ и вводим полученный IP-адрес.
    Тут написана компания, которая получила диапазон IP-адресов, а также email для жалоб. Из этого email очевидно, какой сайт у хостинга.

    Это может не сработать, если IP окажется в диапазоне Cloudflare или другого прокси. Тогда путь начинается с восстановления доступа к этому прокси — ищем в переписке по названию сервиса и пробуем попасть вначале туда. Там в панели будет DNS и настоящий IP-адрес.

    3) Пишем в поддержку найденного хостинга с просьбой восстановить доступ. В идеале — с официального ящика компании, указанного на сайте. Может понадобиться запрос на бланке организации или визит с паспортом в офис.

    Эта последовательность действий должна помочь выявить хостинг в большинстве случаев.

    Что-то на богатом:
    Просто спросите в вашем агентстве. Если вы работали с агентством по созданию сайта, разработке или продвижению, то у них должен храниться паспорт проекта с этой информацией.

  • Фуллстек парадокс

    Фуллстек парадокс

    В начале 2000-х в веб-разработке не было фронтэндов или бэкэндов.
    Была профессия вебмастер. Этот человек мог сделать сайт целиком. Он умел общаться с полиграфическим дизайнером про внешний вид сайта, верстать HTML таблицами, оптимизировать графику, писать java script. Стек был небольшой и было мало слоёв абстракции.
    Если было нужно что-то покруче, звали программиста и он писал CGI-скрипты на Perl, PHP или C.

    Прошло 25 лет. В этом году искал для клиента fullstack-разработчика. Вакансии такие на рынке есть. Например, одновременно с моей вакансией продвигали объявление от Теремка на такой же стек. На такую вакансию массово откликаются фронтэнд-разработчики. Почему так?

    В момент, когда фронт научился писать запросы к базе данных и создавать API-методы, он достиг своей полноты. В его мировоззрении всё жизненное пространство в этот момент освоено. Всё так, но для бэкэнд разработчика уровень фронтов на его территории — Intern или Junior.

    Современный бэкенд разработчик часто знает HTML, CSS и Java Script. Может так случиться, что был у него опыт разработки на React, но он не будет считать это значительным достижением. Хорошо, если в резюме укажет. Его территория упирается с одной стороны в серверное администрирование и облака, с другой находится уровень железа: производительность процессора, работа с памятью, операции чтения и записи на жесткий диск. Пляж фронтэндов находится на периферии его владений и занимает небольшой участок с выходом в море.

    Зрелый бэкенд разработчик может в море не плавает, но может залезть в код на фронте, сделать необходимое “чтобы работало” и пойти делать свои дела. Вряд ли он уделает фронта на его территории, но у него есть ощущения “тут всё понятно”.

    Количество абстракций в процессе разработки выросло. У пирога было три слоя, а в современном рецепте их пятнадцать. Изобретают новые фреймворки, меняются библиотеки и подходы. Рынок делает веб-программирование всё более абстрактным и сложным.

    Практические выводы:
    – Если вам нужен в команду разработчик с полным спектром знаний — ищите сеньора бэкендера, у которого был опыт работы на фронте. Вакансии Веб-разработчик, Программист или Backend-developer. Но делать фронт его руками очень дорого.
    – В команду нужно брать и фронтов и бэков. Бэки будут ворчать и не хотеть делать задачи фронтов, фронты не владеют всей картиной происходящего на бэке.
    – LLM уже сейчас помогает бэкендерам делать сносный фронтэнд. Скоро всё перемешается снова.

  • PNG наносит ответный удар

    PNG наносит ответный удар

    Прошло 20 лет с момента выхода графического формата PNG. Это был не очень понятный формат: JPG лучше сжимал фотографии, GIF можно было анимировать. Единственным явным преимуществом PNG была поддержка полупрозрачности. Помню, чтобы заставить его работать в Internet Explorer 6, приходилось добавлять на сайт дополнительный скрипт.

    На самом деле ценность PNG — в расширенной цветопередаче и компрессии без потери качества (в отличие от JPG).

    Этим летом Adobe, Apple, BBC, Comcast / NBCUniversal, Google, MovieLabs и консорциум W3C объединились и обновили спецификацию формата PNG.

    Что изменилось:
    – Добавлена поддержка HDR — расширенная цветопередача. Именно из-за этой фичи формат решили обновить, что интересно — в интересах субтитров для телетрансляций и кинофильмов.
    – Добавлена поддержка EXIF — метаданные в картинках.
    – Повсеместно внедрены анимированные PNG. Это предлагала Мозилла 20 лет назад, но их тогда не поддержали.
    – В целом, улучшили документацию стандарта.

    Обновленный формат уже поддерживается в Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer.

    Ожидается скорый выход новых редакций формата, в которых обещают ещё улучшения по цветопередаче и сжатию.

    Спецификация PNG ver. 3
    Статья как работают цветовые пространства от одного из создателей формата