Зачем боту сайт с полем для файла
Расклад по спросу простой. По Вордстату «транскрибация» это около 47 тысяч запросов в месяц, «расшифровка аудио» около 20 тысяч, и больше 25 тысяч из них со словами «онлайн» или «бесплатно». Формулировок с «бот», «тг» или «телеграм» около 600. Люди ищут поле, куда можно бросить файл, а не бота, которого надо найти, открыть и запустить.
Первые три дня сайт был витриной: лендинг, сравнение семи ботов и пачка инструкций, где каждая кнопка вела в Telegram. Из поиска за это время пришёл 1 показ в Search Console и 0 кликов. Индексация медленная, это ожидаемо. Неожиданным было другое: даже когда человек дочитывает инструкцию, ему всё равно надо уйти из браузера в мессенджер. Я решил, что сайт должен сам показывать результат, а бот должен быть следующим шагом, а не первым.
Как это устроено
24 октября в 14:03 ушёл коммит «Launch web transcription on the site», виджет появился на 47 из 69 страниц сайта. Правила для анонимной пробы:
- 3 расшифровки в день на посетителя;
- из любого файла расшифровываются первые 180 секунд;
- общий потолок на весь сайт 120 минут в день, чтобы один скрипт не сжёг мне бюджет на распознавание.
Посетителя я узнаю по двум ключам: хеш IP и хеш идентификатора устройства из localStorage. Оба хешируются с секретом, сырые адреса в базу не попадают. Плюс отдельная строка «global» на каждый день, где копится общий расход. Всё это лежит в одной таблице web_trials: день, ключ, число использований, секунды.
После результата под текстом стоит строка «Конспект и задачи по записи делает бот» и кнопка «Открыть @Voicepad_bot» со ссылкой ?start=src_site. Идея: человек видит, что качество нормальное, упирается в 3 минуты и идёт в бота за 15 бесплатными минутами в месяц.
Длинные файлы и ссылки на YouTube на сайте работают только после входа через Telegram, минуты тогда списываются с баланса в боте. Тут первый провал: для кнопки «Войти через Telegram» нужно привязать домен в BotFather командой /setdomain, а я этого до сих пор не сделал. Кнопка показывает «Bot domain invalid». То есть всё, что длиннее трёх минут, на сайте сейчас недоступно.
Что показывала метрика
Каждое утро у меня отдельная задача снимает цифры из прод-базы и пишет строку в growth-log. Вот что там было:
- 24 октября: «4 пробы, 6 запусков, 0,5 мин»;
- 25 октября: 0 проб;
- 26 октября: «6 проб, 9 запусков, 7,2 мин, лучший день». В графе «лучший источник» впервые стояло «сайт».
На фоне бота это выглядело как надежда. В боте за 24, 25 и 26 октября 0 расшифровок, за три дня один новый пользователь (25 октября в 22:17, без метки источника). А сайт вроде бы растёт: от 6 запусков к 9 и от половины минуты к семи.
Что было на самом деле
Сегодня, когда сел писать этот текст, я открыл web_trials руками. Там 10 строк:
- 24 октября: 2 ключа устройства по 1 использованию, 1 ключ IP с 2 использованиями, строка global: 2 использования, 10 секунд;
- 26 октября: 3 ключа устройства, 2 ключа IP, строка global: 3 использования, 144 секунды.
Запрос в метрике суммировал все строки дня. А каждая проба пишется трижды: в ключ IP, в ключ устройства и в global. Отсюда «6 запусков» вместо 2 и «9 запусков» вместо 3, 30 секунд вместо 10 и 432 секунды вместо 144. Метрика врала ровно втрое, и я три дня принимал по ней решения. В недельном ревью 26 октября сайт фигурировал как единственный живой канал.
Честные цифры за три дня такие: 5 проб, 154 секунды, то есть две с половиной минуты аудио. Одна проба на 128 секунд, остальные четыре на 3, 7, 7 и 9 секунд. Четыре из пяти пришли с одного IP, и одно устройство появляется оба дня. Ключи хешированы, поэтому я не могу сказать, это один заинтересованный человек или мои собственные проверки виджета после деплоя. Подозреваю второе хотя бы частично. Тогда сторонних проб может быть одна: та самая на 128 секунд.
Переходов в бота с сайта 0. Тут даже сломанные метки источников не мешают: после 25 октября в боте нет ни одного нового пользователя вообще.
Почему так вышло
Ошибка с метрикой банальная, но поучительная. Я проектировал таблицу под проверку лимитов, а не под аналитику. Для лимитов удобно, что все ключи лежат в одной таблице: одним запросом видно, исчерпал ли посетитель три пробы по любому из ключей. Для подсчёта это ловушка: строк втрое больше, чем событий. Задача метрик получила описание «посчитай пробы в web_trials» и честно посчитала строки. Правильный запрос берёт только key = 'global'.
Вторая причина, почему нет переходов, скорее всего в самом пороге. 180 секунд хватает, чтобы проверить качество на голосовом. Но 2,5 минуты за три дня говорят, что люди с длинными записями до сайта просто не доходят: трафика почти нет. Поисковик показал сайт 1 раз. Яндекс Вебмастер всю неделю в инциденте, данных по Яндексу нет совсем.
Третья причина: у пробы на сайте нет связи с ботом. Если человек нажмёт «Открыть @Voicepad_bot», он придёт с меткой src_site, но у users.source сейчас пусто у всех 8 пользователей, и это отдельная поломка, которую я ещё не нашёл. Даже если переход случится, я его не увижу.
Что я поменяю
- Метрика сайта считает только строку global, а число уникальных посетителей по ключам устройства, отдельно и с пометкой, что это верхняя оценка. Запрос уже исправлен в описании задачи метрик.
- Свои проверки виджета записываю со временем и вычитаю из дневных цифр, а потом сделаю тестовый режим, который не пишет пробу в
web_trials. На таких объёмах я иначе сам себе делаю статистику. /setdomainв BotFather, чтобы вход через Telegram заработал и на сайте можно было расшифровать лекцию целиком. На этой неделе сегмент студенты и лекции, а лекция идёт полтора часа, трёхминутная проба им ничего не доказывает.- Чиню сохранение метки источника в боте. Без неё любой канал, включая сайт, выглядит как ноль.
Главный вывод для себя: на маленьких числах ошибка в запросе заметнее, чем кажется. Разница между «9 запусков» и «3 запуска» не косметическая. В первом случае канал оживает, во втором это я и, может быть, ещё один человек.
Попробовать расшифровку без регистрации можно на сайте: voicepad.qupport.io. Бот: https://t.me/Voicepad_bot?start=src_site, там 15 минут в месяц бесплатно и файлы до 20 МБ.