Рубрика: Uncategorized

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

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

    Мы получили 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 раз отмерь, один отрежь. И да простят меня математики.

  • Когда опыт мешает

    Когда опыт мешает

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

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

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

    В чем вызов: осознать, что попадаешь под действие этого эффекта. Не применять поспешные решения, основанные на своём прошлом опыте. Ставить прошлый опыт под сомнение, задавать провокационные вопросы, включать “мышление новичка”, искать свои слепые зоны. Особенно, если сразу знаешь, как решать возникшую проблему.

  • 50/50

    50/50

    По-моему, нет хуже схемы оплаты для услуг, чем 50/50. Эта схема создаёт проблемы для обеих сторон.

    Если у исполнителя маржа ниже 50% (в диджитале это обычно 15%–30%), то он уходит в минус и ждёт приёмки, потому что аванса не хватит на покрытие себестоимости.
    Финальная приёмка может откладываться заказчиком из-за мелких правок. Заказчик хочет полную готовность, а исполнитель при этом ждёт момента выхода из кассового разрыва. Это сильно ухудшает атмосферу на проекте.

    При появлении дополнительных работ, заказчику сложно психологически провести финальную приёмку, ведь финал наступит только после проведения дополнительных работ. Поэтому он не будет принимать проект и будет ожидать выполнения всего объёма. У исполнителя в этот момент ещё увеличивается риск — себестоимость растёт, а оплата откладывается.

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

    Что делать?

    Вариант 1: До подписания акта все перечисленные исполнителю деньги — это деньги клиента на счету исполнителя, а не выручка. Поэтому, если сумма и сроки небольшие, то договариваемся на 100% предоплату. Утром деньги — вечером стулья. Зачем разводить бюрократию?

    Вариант 2: Все работы разбиваются на небольшие этапы и каждый этап заказчик оплачивает 100% предоплатой и подписывает акт по сдаче этапа. Безопасность и комфорт для всех участников.

    Вариант 3: Если заказчик настаивает на поэтапной оплате, а работа на этапы не разбивается, то делим платёж на 40%/30%/30%. Аванс 40% получаем сразу, 30% в момент готовности со стороны исполнителя, а последние 30% — после подписания акта со стороны заказчика. В этом случае у исполнителя не возникает кассовый разрыв на затянутой приёмке. Оптимальная схема, чтобы продавать сайты по фиксированной цене.

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

  • Добро пожаловать!

    Добро пожаловать!

    Наконец, выдался свободный день и я развернул блог по адресу https://fullstackfounder.ru.

    Блог работает на WordPress:
    – Сборка Bedrock с composer
    – Тема оформления TwentyTwentyFive, идущая в комплекте к WordPress в этом году
    – Тёмная цветовая палитра Dracula, популярная у разработчиков
    – Шрифты Roboto и Roboto Mono через Google Fonts
    – Фавиконка робота
    – Docker для локальной работы, адаптировал привычный мне пакет Sail из Laravel

    На копирование сборки, разворачивание WordPress на сервере и настройку блога ушла пара часов. Предстоит ещё много работы, чтобы я был доволен, но сайт уже заработал.
    Код сайта выложил на Github.

    Чтобы не копировать контент вручную, навайбкодил небольшое консольное приложение для импорта постов на питоне. Также придумал названия категорий и тегов для постов, положил их в качестве справочника. Приложение берёт экспорт постов с моего телеграм-канала в формате JSON. Обрабатывает текст, вырезает из поста лишние строчки с “Жми на эмозди”, заливает картинку, пробует определить категорию и теги, отделяет заголовок от текста. И отправляет всё это в WordPress по API. Справился за полтора часа от идеи до протестированного кода, который залил все мои посты. Категории и теги скрипт присвоил кое-как, поэтому их всё равно нужно будет переопределить вручную. Зато тексты уже опубликованы!

    Код импортёра тоже выложил на Github.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Бенчмарк для LLM: работа в роли бухгалтера с данными реальной компании

    Бенчмарк для LLM: работа в роли бухгалтера с данными реальной компании

    Бенчмарк для LLM: работа в роли бухгалтера с данными реальной компании.

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

    Полное описание бенчмарка, системный промпт, тестовые данные:
    https://accounting.penrose.com/

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

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

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

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

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

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

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

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

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

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

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

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

  • Я чайник!

    Я чайник!

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

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

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

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

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

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

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

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

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

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

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

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