Выводы с прожарки КП

Сегодня в клубе Галера в прямом эфире я с коллегами-экспертами разбирал два десятка коммерческих предложений (КП) диджитал агентств.

Рефлексирую полученный опыт в виде чеклиста:
- На обложке КП нужно написать русским по белому какая именно услуга предлагается, название клиента и название агентства.
- После обложки хорошо бы кратко представить агентство и вызвать доверие логотипами клиентов, рейтингами и значимыми цифрами.
- Если показываете фотографию одного только основателя, агентство воспринимается как лавочка фрилансера. Покажите групповое фото или кружочки с командой.
- Дизайн продаёт без слов. Возьмите на создание шаблона КП лучшего дизайнера, которого только сможете себе позволить — это быстро окупится.
- КП нужно адаптировать под клиента и писать на языке клиента. Многие КП сделаны на языке агентства и клиенту не понятны.
- Смету, медиаплан, десяток подробных кейсов, аудит и даже концепцию можно приложить дополнительными документами и дать ссылки.
- Подрядчики на трафик любят делать разбор рынка клиента и его конкурентов. Выглядит, как будто агентство напрашивается на проверку домашки.
- Агентства склонны сильно раздувать КП. Клиент не будет читать 40 слайдов, у него лежит целая пачка таких же КП. Нужно учиться зацепить клиента в 10 слайдов, включая обложку.
- На последнем слайде — контактные данные менеджера по продажам и название агентства ещё раз. На этом слайде больше ничего не нужно.
- Цена должна быть на одной из первых или последних страниц. Если она спрятана в середину КП, её будет очень сложно найти.
- Не стесняйтесь писать цену большим шрифтом и заметно. Клиент ожидает, что вы назовёте цену, не нужно её прятать в таблицах.
- Цена должна содержать полную стоимость для клиента: со стоимостью услуг агентства, рекламным бюджетом и НДС. Часто указывают только стоимость услуги, хотя клиент будет оплачивать всё вместе.
- Окупаемость нужно считать исходя из полных затрат, включая услуги агентства, а не только из рекламного бюджета.
- Указывайте на какой системе налогообложения вы работаете. Клиентам с НДС это важно.

Вижу, что формат прожарки КП очень популярен в клубе. Так и просится собрать набор универсальных правил) Вместе с тем, я понимаю, что КП может успешно продавать своему покупателю и нарушать при этом все правила.

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если полезно
🏆 Жми на кубок, если делаешь КП

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

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

Порядок действий:
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) Пишем в поддержку найденного хостинга с просьбой восстановить доступ. В идеале — с официального ящика компании, указанного на сайте. Может понадобиться запрос на бланке организации или визит с паспортом в офис.

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

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

❤️ Жми сердечко, если интересно
⚡️ Жми на молнию, если полезно
🧑‍💻 Жми на ботана, если умеешь также

WordPress устарел, но это легко исправить

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

Чего не хватает в WordPress?
- Поддержку git каждый придумывает самостоятельно, потому что нет общих рекомендаций. Держать в репозитории только тему или всю папку? Что делать с плагинами? Должно ли быть ядро в репозитории? Непонятно.
- Нет поддержки composer — нет управления зависимостями. Чтобы воспроизвести такой же сайт, нужно выписать все названия и версии плагинов, а затем устанавливать их вручную. Нет способов поставить внешнюю библиотеку. Разные плагины тянут за собой зависимости, которые могут конфликтовать друг с другом.
- Конфигурация задаётся через файл. Нет поддержки переменных среды ENV, нет поддержки нескольких окружений. Работать с CI/CD и контейнерами практически невозможно.
- Весь код находится в публичной папке сервера. В зависимостях WordPress много кода, который можно было бы спрятать в папку vendor ради безопасности.

В общем, упущены все базовые вещи, которые есть в популярных фреймворках Laravel, Symfony, Next, Django, Ruby on Rails.

Все эти упущения исправляет бесплатная сборка Bedrock от коллектива разработчиков Roots. Это тот же WordPress, но он уже больше похож на фреймворк. В нём есть git, composer, env, поддержка Docker и CI/CD. Он использует те же плагины, темы оформления и тот же базовый WordPress в качестве ядра. Изменена структура папок и метод загрузки конфигурации. Всё остальное работает точно так же.

Я использую Bedrock уже несколько лет, он отлично себя зарекомендовал в продакшине. Обновления с локальной среды разработчика оказываются на тестовом сервере после git push. Сразу устанавливаются те же версии WP и плагинов, обновляется тема оформления, сбрасывается кэш, импортируются настройки.

Bedrock может открыть WordPress с другой стороны для разработчиков, которые привыкли к "взрослому" миру фреймворков. Более того, у Roots есть пакет Acorn, который добавляет в WordPress пакеты из Laravel. Как тебе такое, Илон Маск Мэтт Мулленвег?

❤️ Жми сердечко, если интересно
⚡️ Жми на молнию, если узнал новое
🧑‍💻 Жми на ботана, если делаешь сайты

Книга с полки: От нуля к единице

Стэнфордский университет, весна 2012 года. Студент Блейк Мастерс ведёт очень подробные заметки по курсу лекций "Computer Science 183: Startup". Автор курса — Питер Тиль, сооснователь и генеральный директор PayPal, а также участник мафии PayPal. У Питера захватывающая для бизнесмена биография — например, он самый первый инвестор в Facebook. В фильме "Социальная сеть" роль Тиля сыграл Джастин Тимберлейк.

Главная ценность курса — Питер передаёт своё мировоззрение основателям стартапов. Он не рассказывает о формуле успеха и не даёт практических знаний, как в MBA. Зато очень ценно узнать от практика, что основатель должен искать "нечестное" конкурентное преимущество, которое не смогут повторить конкуренты.
Одна из основных мыслей книги — технологические инновации делают необычные люди необычными способами. Но часто пионеры зарабатывают меньше, чем те, кто приходит следом и масштабирует проверенные решения. Ещё он уже тогда рассказывал о сверхчеловеческом ИИ и его влиянии на производительность труда.

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

Заметки с этого курса публиковались на tumblr и стали очень популярными среди стартаперов и фондов. Помню, что поставил закладку в браузере и проверял новые выпуски несколько раз в неделю, настолько это отличалось от другого контента.

Через некоторое время заметки отредактировали и издали в виде книги. На русском языке она вышла в Альпине под названием "От нуля к единице. Как создать стартап, который изменит будущее".

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если будешь читать
🏆 Жми на кубок, если уже читал

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

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

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

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

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

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если узнал новое
🧑‍💻 Жми на ботана, если работаешь с S3

Телеграмошная

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

Несколько каналов с нуля подросли до 1000 подписчиков, а один даже свыше двух тысяч.

Вступай и забирай пять полезных лайфхаков для канала, они в закрепе: https://t.iss.one/+Q95bpbFAwRBkYzky

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

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

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

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

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

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если узнал новое
🎉 Жми на рупор, если маркетолог

Я чайник!

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

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

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

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

❤️ Жми на сердечко, если понравилось
⚡️ Жми на молнию, если узнал новое
🧑‍💻 Жми на ботана, если понимаешь коды ответа веб-сервера

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

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

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

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

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

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

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

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

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

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если узнал новое
🏆 Жми на кубок, если победитель стресса

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

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

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

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

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

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

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

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если полезно
🏆 Жми на кубок, если пользуешь тепловыми картами

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

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

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

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

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

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если узнал новое
🧑‍💻 Жми на ботана, если занимаешься отладкой

Машина времени для интернета

Помните фразу "интернет всё помнит"?
Проект Wayback Machine, известный среди вебмастеров как Веб Архив, сохраняет копии сайтов. Интереса ради можно посмотреть как выглядели известные сайты в прошлом. А можно найти свои старые сайты, в том числе те, которые уже недоступны. В архиве хранятся копии, сделанные в разные даты, поэтому можно отследить эволюцию дизайна или как постепенно добавлялся контент.

Частая боль веб-студий — сданные клиентам сайты со временем исчезают. Клиенты не продлевают домен, теряют доступ к хостингу, закрывают компании. Или новая команда изменяет оригинальный сайт так, что дизайнеру становится стыдно. Также вебмастеры используют этот проект, чтобы воскресить свои утерянные сайты или восстановить контент на выкупленном домене. Бэкэнд уже не восстановить, но можно сохранить вёрстку и статьи.

Архив не совершенен: бывает, что не сохранились картинки, какой-то скрипт или не воспроизводится устаревший флэш-ролик. Да и смотрим мы эти сайты уже другими браузерами, поэтому они не всегда воспроизводятся как раньше. Зато у нас есть возможность вернуться назад во времени и посмотреть, как это выглядело раньше. А это по-настоящему бесценно.

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если узнал новое
🧑‍💻 Жми на ботана, если твои сайты есть в Веб Архиве

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

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

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

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если узнал новое
🧑‍💻 Жми на ботана, если тоже публикуешь код

План развития веб-блога

Небольшой список, что я считаю необходимым сделать с моим сайтом:
- Рассортировать посты по категориям и поставить теги.
- Сделать навигацию с категориями.
- Добавить в навигацию пост "Обо мне" и "Контакты".
- Вывести теги в посты.
- Поставить SEO-плагин и прописать мета-теги ко всем постам.
- Сгенерировать sitemap, чтобы поисковики видели все страницы.
- Добавить Open Graph, чтобы пересылаемые ссылки в соцсетях отображались с картинкой и описанием.
- Настроить отображение картинок к постам, чтобы они не обрезались.
- Конвертировать все картинки в webp.
- Настроить кэширование и ускорение сайта всеми доступными способами.
- Добавить вывод в конце поста похожих постов, динамически их подбирая по тегам.
- Подтянуть Google Page Speed. Быстродействие вывести в зелёную зону (значение этого показателя плавает), а остальное довести до 100 из 100.
- Бот для Telegram, который будет копировать посты из канала в блог. Почему-то хочется, чтобы он работал именно в таком направлении.
- Форму подписки на email-рассылку с новыми постами. И автоматическую рассылку для подписчиков.

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

Также хочу настроить кросс-постер в социальные сети. Сам думаю про ВК, буду рад вашим идеям, в каких соцсетях могут меня читать. Напишите в комментариях.

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если почерпнул идеи
🙈 Жми на мартышку, если ничего не понятно

50/50

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

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

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

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

Что делать?

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

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

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если полезно
🏆 Жми на кубок, если ведёшь переговоры по цене

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

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

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

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если полезно
🙉 Жми на мартышку, если изучаешь свои искажения

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

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

❤️ Жми на сердечко, если интересно
⚡️ Жми на молнию, если полезно
🧑‍💻 Жми на ботана, если считаешь доверительные интервалы