A/B тестирование в C#: как перестать гадать и начать зарабатывать

Почему ваш C# код работает вхолостую (и как это исправить)

Вы потратили недели на рефакторинг алгоритма рекомендаций. Новая версия RecommendationService выглядит безупречно, код чище, LINQ запросы быстрее. Вы выкатываете обновление на прод, а… конверсия падает на 15%. Знакомо? Если нет — вам повезло. Если да — вы только что потеряли деньги и время, потому что полагались на интуицию, а не на данные.

В мире C#-разработки есть золотое правило: «Никогда не доверяй своему мнению, доверяй статистике». Именно для этого существует A/B тестирование (или сплит-тестирование). Это не маркетинговая фишка — это инженерный подход к принятию решений. В этой статье мы разберём, как внедрить полноценное A/B тестирование в ваше C# приложение: от архитектуры до расчёта статистической значимости. И да, будет много кода.

Что такое A/B тестирование в контексте C#?

Представьте, что у вас есть два варианта одной и той же логики — контрольная группа A (старая версия) и экспериментальная группа B (новая версия). Вы случайным образом распределяете пользователей между ними, собираете метрики и с помощью математики определяете, какой вариант действительно лучше.

В C# это может касаться чего угодно:

• Изменение алгоритма поиска
• Новый дизайн платежной формы
• Разные варианты сортировки товаров
• Эксперименты с временем кэширования
• Тестирование ML-моделей

Ключевой момент: A/B тестирование в C# — это не про «поставить флажок в конфиге». Это про чистую архитектуру, рандомизацию и сбор метрик без багов.

Архитектура A/B тестирования: Layer Cake на C#

Давайте сразу перейдём к практике. Я покажу вам минимальную, но рабочую архитектуру. Она состоит из трёх слоёв:

1. Assigner — решает, в какую группу попал пользователь.
2. Feature Decision — какой вариант кода выполнить.
3. Tracker — записывает событие и результат.

Шаг 1: Assigner — кто ты, пользователь?

Самый частый баг — неправильная рандомизация. Использовать Random — плохая идея, потому что при перезапуске приложения группы «поплывут». Правильное решение — детерминированное распределение на основе UserId.

public interface IExperimentAssigner
{
    string GetVariant(string userId, string experimentName);
}

public class ConsistentExperimentAssigner : IExperimentAssigner
{
    public string GetVariant(string userId, string experimentName)
    {
        // Создаём стабильный хеш из userId + experimentName
        var hash = HashCode.Combine(userId, experimentName);
        // Берём модуль 100 — получаем процент
        var bucket = Math.Abs(hash) % 100;
        
        // Допустим, 50% в A, 50% в B
        return bucket < 50 ? "A" : "B";
    }
}

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

Шаг 2: Feature Decision — битва алгоритмов

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

public interface IPricingStrategy
{
    decimal CalculatePrice(decimal basePrice);
}

public class OldPricingStrategy : IPricingStrategy
{
    public decimal CalculatePrice(decimal basePrice) 
        => basePrice; // Без скидки
}

public class NewPricingStrategy : IPricingStrategy
{
    public decimal CalculatePrice(decimal basePrice) 
        => basePrice * 0.9m; // Скидка 10%
}

public class PricingStrategyFactory
{
    private readonly IExperimentAssigner _assigner;

    public PricingStrategyFactory(IExperimentAssigner assigner)
    {
        _assigner = assigner;
    }

    public IPricingStrategy GetStrategy(string userId)
    {
        var variant = _assigner.GetVariant(userId, "pricing_experiment_v2");
        return variant == "B" 
            ? new NewPricingStrategy() 
            : new OldPricingStrategy();
    }
}

Красота этого подхода — вы легко добавляете новые эксперименты, не трогая существующий код. Просто создаёте новую стратегию и новый Assigner.

Шаг 3: Tracker — сбор данных без боли

Без трекинга A/B тест — это просто случайное переключение кода. Вам нужно знать:

• Какой вариант сработал
• UserId
• Метрику (конверсия, время, доход)
• Timestamp

public class ExperimentEvent
{
    public string UserId { get; set; }
    public string ExperimentName { get; set; }
    public string Variant { get; set; }
    public string MetricName { get; set; }
    public double MetricValue { get; set; }
    public DateTime Timestamp { get; set; }
}

public interface IExperimentTracker
{
    Task TrackAsync(ExperimentEvent evt);
}

public class ConsoleTracker : IExperimentTracker
{
    public Task TrackAsync(ExperimentEvent evt)
    {
        Console.WriteLine($"[{evt.Timestamp}] User {evt.UserId} | " +
                          $"Exp: {evt.ExperimentName} | " +
                          $"Variant: {evt.Variant} | " +
                          $"{evt.MetricName}: {evt.MetricValue}");
        return Task.CompletedTask;
    }
}

В реальном проекте вы будете писать события в ClickHouse, Azure Event Hub или хотя бы в базу данных. Главное — асинхронность и не блокировать основной поток.

Интеграция в ASP.NET Core: middleware для эксперимента

Давайте соберём всё вместе. В ASP.NET Core удобно внедрить A/B тестирование через middleware. Он будет автоматически определять группу пользователя и прокидывать её через HttpContext.Items.

public class ExperimentMiddleware
{
    private readonly RequestDelegate _next;
    private readonly IExperimentAssigner _assigner;

    public ExperimentMiddleware(RequestDelegate next, IExperimentAssigner assigner)
    {
        _next = next;
        _assigner = assigner;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var userId = context.User?.Identity?.Name ?? "anonymous";
        var variant = _assigner.GetVariant(userId, "checkout_experiment");
        
        // Сохраняем в Items, чтобы использовать в контроллерах
        context.Items["ExperimentVariant"] = variant;
        
        await _next(context);
    }
}

// Регистрация в Program.cs
app.UseMiddleware<ExperimentMiddleware>();

Теперь в любом контроллере или сервисе вы можете получить вариант:

public class CheckoutController : ControllerBase
{
    [HttpPost]
    public IActionResult Checkout()
    {
        var variant = HttpContext.Items["ExperimentVariant"] as string;
        
        if (variant == "B")
        {
            // Показываем новую форму
        }
        else
        {
            // Старая форма
        }
        
        return Ok