Ну что, продолжим пост выше, как я обещал.

Итак, если единственный "лог", который офлайн генерирует сам по себе, это чек... Значит надо добавлять контрольные события! Пока мы не поставим камеру, датчик в кофемашину или хотя бы пока гость не авторизуется (с чем как бы часто наблюдаются... легкие проблемы, ибо авторизация – большое благо и везение для нас, мало кто это делает, особенно вне мобильного приложения) мы остаемся "без глаз"... Или не совсем?

Однако, не будем драматизировать. Кое-что у нас есть: жалобы. И это большая ценность! Однако, жалобы это не финальные данные о проблемах, а верхушка айсберга: на одну поданную жалобу приходится порядка 26 недовольных, которые промолчали и просто не вернулись. В ситуация вообще плоховатая, потому что жаловаться физически неудобно: очередь, обед за пятнадцать минут, что-то пошло не так, да и ну его, "просто не приду больше". Для нас любая жалоба это подарок (мы даже стимулировали жалобы, кек). При этом, отсутствие жалоб не означает отсутствие проблем, возможно, люди просто разочаровались окончательно. Пподдержка (в таком свете) не кост-центр, а наши "приборы".
Но жалобы жалобами, а у вас тут жалуются не так часто, как хотелось бы, и нам этого точно недотстаточно для того, чтобы объективно что-то обмерять, оценивать и вообще принимать решение о том, как идут наши дела в бизнесе.

Потому мы тут придумали свою систему измерений: получился такой трехслойный пирожок.

Первый слой – операционные input-метрики. Скорость обслуживания, точность сборки заказа, чистота, доступность позиций меню, аптайм каналов заказа. Чисто то, что контролируем ежедневно и на что реально можем влиять. Классные метрики, только мерить их – серьезная проблемка. Угадаете, как оценивать точность сборки заказов на выдаче в ресторане?) Чуть позже расскажу, в третьем посте (да-да, все увешаем камерами) 🙂

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

Самое последнее, куда прорастают наши тесты и изменения (третий слой) – это возвращаемость когорты первого визита: вернулся в первый месяц, в третий, потерян в шестой. Ну и тут простраивается нормально LTV, и мы можем прикинуть, обгоняется ли шан CAC тот самый LTV, который мы накопили, ну и GMV тоже посчитать из LTV мы можем, да?

Казалось бы, все кайф. Но проблема в том, что между слоями месяцы лага: изменения прорастают в ретеншн супееееер долго. Поэтому управляем по первому слою, валидируем корреляции с третьим на когортах и стараемся не обманывать себя вторым. Это другая практика принятия решений, ближе к работе с retention-когортами в подписке, чем к классическим АБ.
Ну и личная боль: у нас в экспериментах юнит рандомизации это не пользователь, коих миллионы, а ресторан, и их 1300 (+-).
Кластерные дизайны, гео-сплиты, подобранные пары точек, маленькая статистическая мощность, полный кайф, да? Плюс часть эффектов физически нельзя показать половине гостей: чистоту зала не включишь только для тестовой группы. Это конечно не отменяет нормальной методологии, просто все сложнее и дольше: чтобы провести тесты на киоске, где у вас нет конкретного юзера и четкой сесии, надо сплитануться по похожим ресторанам, а не сплитануться между киосками в одном рестике, потому что, банально, один юзер... может походить и позаказывать по разным киоскам, ну например. Или киоски стоят один удобнее, а на другом экран от солнца бликует...).

В целом, мы более менее разобрались, на что мы смотрим в метриках. Но соль то в том, что все, что я перечислил надо как-то мерить. А это уже прям сложно, раз уж мы "не в телефоне". Потому в следующем посте я расскажу как мы все это обмеряем, и причем тут AI и что мы вообще делаем. Вот, ждите!