Привет, Хабр!

Хотел было назвать эту статью «Защитные метрики», но тут такая штука — погуглил в рунете, а там тишина (ну, почти). Пришлось пойти по классике и оставить название на английском — guardrail metrics.

Guardrail metrics — это метрики, которые используются в A/B тестировании для предотвращения нежелательных побочных эффектов. Их основная цель — следить за тем, чтобы изменения, которые вы вносите для улучшения определенных показателей, не повредили другим важным аспектам продукта.

Рассмотрим подробнее.

Типы guardrail metrics

Какие вообще бывают эти метрики?

Финансовые guardrail metrics

Когда дело касается денег, ошибки недопустимы. Улучшение UX, интерфейсов или скорости загрузки сайта ничего не значит, если при этом падают доходы или сокращается средний чек. Поэтому финансовые метрики являются первыми и важнейшими в списке guardrail metrics.

Пример:

Допустим, вы тестируете новый интерфейс страницы оплаты, который должен ускорить процесс заказа. Тест показал, что время оформления заказа сократилось на 20%, и всё кажется идеальным... до тех пор, пока не выясняется, что процент завершённых транзакций упал. Это сигнализирует, что пользователи, возможно, путаются на новом этапе оплаты, и это напрямую отражается на доходах.

Примеры финансовых метрик:

• Процент завершённых транзакций. Если он падает, это плохой знак — что‑то в UX не работает.

• Средний чек. Уменьшение среднего чека говорит о том, что пользователи стали покупать меньше или реже.

Пример в Python:

from sqlalchemy import create_engine, func
from sqlalchemy.orm import sessionmaker

# Настройка подключения к базе данных
engine = create_engine('sqlite:///ecommerce.db')
Session = sessionmaker(bind=engine)
session = Session()

# Подсчёт завершённых транзакций и среднего чека
completed_transactions = session.query(func.count()).filter_by(status='completed').scalar()
total_transactions = session.query(func.count()).scalar()
average_order_value = session.query(func.avg(Order.amount)).scalar()

completion_rate = (completed_transactions / total_transactions) * 100
print(f"Completion rate: {completion_rate}%")
print(f"Average Order Value: {average_order_value}")

Метрики пользовательского опыта

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

Примеры таких метрик:

• Скорость загрузки страниц. Долгая загрузка приводит к тому, что пользователи теряют терпение и уходят.

• Количество ошибок и крашей. Больше ошибок — меньше доверия у пользователей.

• Время на сайте. Сокращение времени, проведённого пользователем на сайте, говорит о том, что что‑то идёт не так.

Пример реализации мониторинга метрик в Python:

import time
import requests

def monitor_page_load(url):
    start_time = time.time()
    response = requests.get(url)
    load_time = time.time() - start_time
    if response.status_code == 200:
        print(f"Load time for {url}: {load_time:.2f} seconds")
    else:
        print(f"Error loading {url}, status code: {response.status_code}")

monitor_page_load("https://example.com")

Стратегические метрики

Теперь самое интересное — стратегические метрики. Это те метрики, которые отражают долгосрочные цели компании. Они могут быть не такими очевидными, как деньги или скорость сайта.

Например, удержание пользователей — это стратегическая метрика. Если в результате теста пользователи начали уходить, то это может говорить о неправильном курсе.

Другие примеры:

• Рост активной базы пользователей — показатель, как быстро растёт твоя пользовательская база, особенно важен для сервисов с подписочной моделью.

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

Дополнительные метрики

Кстати, еще можно добавить несколько интересных метрик:

• Коэффициент возвратов. Пример: на сайте e‑commerce ты внедрил новую функциональность, которая увеличила покупки, но количество возвратов товаров тоже подскочило. Это явный признак, что продукт или UX где‑то подводят.

• Уровень удовлетворенности пользователей. Тут тебе в помощь классические NPS‑опросы или что‑то вроде рейтингов в приложении. Изменил функционал? Проверь, что пользователи по‑прежнему довольны.

Связь между метриками

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

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

Поэтому метрики никогда не живут отдельно. Вот как можно действовать:

• Проверяй побочные эффекты. Увеличил конверсии? Замечательно! Но проверь, что время загрузки страниц не выросло до бесконечности. Никто не будет ждать, пока сайт наконец догрузится. Улучшил одну метрику? Убедись, что остальные не страдают.

• Настрой автоматическое реагирование метрик. В больших системах можно настроить автоматическую проверку и связь между метриками. Например, можно настроить систему так, чтобы при росте конверсий автоматически проверялись пользовательские метрики и показатели доходов. Это может быть сделано через API с PostHog, Grafana и т. д.

• Метрики с условием. Иногда увеличение одной метрики может ухудшить другую. Например, конверсия выросла, а процент возвратов тоже увеличился? Это уже звоночек: возможно, твой продукт хорош на словах, но не дотягивает до ожиданий клиентов.

• Прогнозирование и контроль. Установи пороговые значения для каждой метрики и настрой систему для их мониторинга. Например, если скорость загрузки страниц упала на 20%, система должна тебе немедленно об этом сигнализировать — даже если конверсии растут как на дрожжах. Это как раз тот случай, когда один показатель тянет одеяло на себя, а другие начинают страдать.

Пример автоматической проверки связей между метриками:

import time
import requests
from statistics import mean

# Функция для проверки конверсии и скорости загрузки страниц
def monitor_metrics(urls):
    conversion_rate = check_conversion_rate()  # допустим, это функция, которая отслеживает конверсию
    load_times = []

    for url in urls:
        start_time = time.time()
        response = requests.get(url)
        load_time = time.time() - start_time
        load_times.append(load_time)
    
    average_load_time = mean(load_times)
    
    if conversion_rate > 10 and average_load_time > 2:  # Условие, при котором мы проверяем баланс
        print("Конверсия хорошая, но сайт начал тормозить! Проверь пользовательский опыт.")
    elif average_load_time < 2:
        print("Скорость нормальная, можно продолжать эксперименты.")
    else:
        print("Проблемы как с конверсией, так и со скоростью. Время для полной ревизии!")

Таким образом, можно контролировать одновременно несколько метрик и реагировать на изменения в каждой из них.

Заключение

Метрики guardrail metrics позволяют избежать неприятных сюрпризов, сохраняя продукт на плаву. Запомните: успешный эксперимент — это не только улучшение одной метрики, но и сохранение стабильности всех остальных аспектов продукта.

Экспериментируйте, но будьте осторожны!

В завершение расскажу про открытый урок 24 октября — «Секреты метамоделей: как бизнес-аналитики создают успешные информационные системы». О чём пойдёт речь:

— Понятие метамодели
— Метамодель в основе проектирования
— Конценция view и viewpints
— Выбор представлений и определение стейкхолдеров
— Разбор практического примера проектирования ис с разных точек зрения

Записаться можно по ссылке.