Основная цель проектов – зарабатывать деньги. Проект над которым мне довелось работать, не стал исключением.

Я разработчик компании Колёса Крыша Маркет и сегодняшний пост будет посвящен тому, как мы дифференцировали цены на платные услуги на нашем “classified”.

Наша компания разрабатывает 3 продукта, каждый под 3 платформы – web, android и ios. Пользователи могут применять к объявлениям различные платные услуги, например, платное продление срока жизни объявления или размещение в блоке горячих предложений.

Когда меня привлекли к этому проекту, у меня в голове еще до начала обсуждения держалась мысль, что за дифференцированные цены?

Дифференцированная цена — цена формирование которой зависит от характеристик объявления (регион, марка, модель, год и т.д.).

Перед командой стояла задача увеличить средний чек. Было принято решение “запилить” фичу, содержащую в себе функционал о котором дальше и пойдет речь. Смысл фичи был в том, что через админ-панель мы сможем изменять цену на любую платную услугу, опираясь на разные параметры.

На момент начала разработки мы уже имели микросервис написанный на Go. Сайты и приложения общались с ним через клиент, отправляя POST-запросом объект объявления, а далее, получив в ответ цены на какие-либо платные услуги, рендерили их пользователю.

В процессе изучения микросервиса выяснилось, что цены, которые отдаются пользователю, были захардкожены, то есть цена для размещения объявления в горячих предложениях описывалась переменной “hot”: 300, а результат ответа выглядел примерно так:

{
    status: "ok",
    data: {
        color-red: 45,
        hot: 300,
        paid-auto-re: 5,
        re: 0,
        s: 90,
        unset-auto-re: 0,
        up: 200
    }
}

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

Процесс разработки мы разделили на несколько этапов:

1. Выбор формата хранения данных.
2. Разработка админ-панели для регулирования цен.
3. Метод отдачи дифференцированной цены.

Выбор формата хранения данных

Изначально, согласно ТЗ, менеджер продукта хотел иметь возможность устанавливать цену на платную услугу из административной панели и это было одной из преимущественно важных задач. Передо мной встал вопрос, в каком формате хранить данные.

Я принял решение забить базу данных “правилами”, то есть, если категория объявления “Авто” и регион “Алматы”, то применяем для объявления следующею цену. Осталось разобраться с базой данных.

Первое, что пришло на ум, это база данных MySQL, где будет храниться таблица с правилами для цен. Например:

Id	catId	regionId	coeff	serviceName
1	13	14	1.4	hot

Согласно ТЗ было необходимо устанавливать цену исходя из региона и категории. Но, зная, как все эти “хотелки” работают, подумал, что цену понадобится менять не только для категории и региона, а еще и для определенной модели авто или ещё по какому-либо признаку.

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

В принципе, на момент разработки все наши объявления уже хранились в MongoDB. Скармливать правила для регулирования цен туда же было проще. На этом мы и остановились

Разработка админ панели для регулирования цен

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

Написали всё это дело мы на phalcon, так как эта админ-панель была лишь частью основной админки для сайта, работающего на phalcon. Также написали функционал в API, который валидировал и сохранял наши правила в коллекцию MongoDB.

Json-объект объявления выглядел вот так:

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

Функционал отдачи дифференцированной цены

Последним этапом нашей разработки был этап написания кода, который умел бы работать со всеми этими правилами и возвращал бы на запрос ответ с дифференцированной ценой.

Как раньше:

Как сейчас:

А где же рефакторинг и где же дифференцированные цены? А вот.

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

Алгоритм отдачи цен раньше работал так:

1. Формирование массива с ценами на услуги.
2. Обработка исключении по типу для этого раздела. Если услуга бесплатная, то отдать 0.
3. Отдача результата.

Сейчас все работает также, за исключением того, что перед возвратом ответа пользователю теперь идёт поход в метод дифференциации цены.

Первый подход к решению задачи, был следующим.

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

Метод “getPriceForService” возвращал цену и принимал следующие аргументы:

1. Объект объявления
2. Название услуги
3. Цена до обработки

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

Чтобы не проходить по каждому из полей объекта, была сделана выборка только из возможных правил. На следующем скрине, мы видим, процесс формирования запроса в MongoDB.

// Возвращает стоимость услуги для объявления
func getPriceForService(advert *Advert, serviceName string, basePrice int) (result int) {
    var mongoResult map[string]interface{}
    query := bson.M{}
    query["serviceName"] = serviceName
    query["$and"] = []bson.M{}

    //Генерируем поисковый запрос в монго
    for _, data := range getUsableValuesForPrice() {
        var value, err = advert.GetValueString(data.Rule)
        stringVal, err := getStringFromMixed(value)

        if err == nil {
            list := []string{"rules.", data.Rule}

            var str bytes.Buffer

            for _, l := range list {
                str.WriteString(l)
            }
            if err == nil {
                query["$and"] = append(query["$and"].([]bson.M), bson.M{"$or": []bson.M{bson.M{str.String(): stringVal}, bson.M{str.String(): nil}}})
            } else {
                checkErr(err)
            }
        }
    }

    //Получаем правила по нашему запросу
    err := mongo.GetSession().
        DB(mongo.GetDbName()).
        C("COLLECTION_NAME").
        Find(query).
        Sort("-priority").
        One(&mongoResult)

    if err == nil {
        stringResult, err := getStringFromMixed(mongoResult["coeff"])
        checkErr(err)

        coeff, err := strconv.ParseFloat(stringResult, 64)

        if err == nil {
            //Умножаем цену на полученный коэффицент
            return int(math.Ceil(coeff * float64(basePrice)))
        } else {
            checkErr(err)
        }
    }

    return basePrice
}

В конечном итоге мы получили запрос, который оставалось лишь выполнить и посчитать новую цену на услугу, используя полученный коэффициент.

Однако, после релиза этого кода в production, наша MongoDB умерла из-за того, что при одном запросе в микросервис он отдает результаты для всех услуг, а я вызываю метод при формировании массива для каждого элемента. То есть, я увеличил нагрузку на MongoDB в 7-8 раз и в поте лица занялся переписыванием своего кода.

Информация к сведению: Для работы с MongoDB, мы использовали mgo, которая позволяет с легкостью строить запросы в базу данных.

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

// Возвращает стоимости услуг массивом
func getPriceForServices(advert *Advert, serviceList Services) (result Services) {
    var mongoResult []map[string]interface{}
    var services []string
    for key, _ := range serviceList {
        services = append(services, key)
    }

    query := bson.M{}
    query["serviceName"] = bson.M{"$in": services}
    query["$and"] = []bson.M{}

    //Генерируем поисковый запрос в монго
    for _, data := range getUsableValuesForPrice() {
        var value, err = advert.GetValueString(data.Rule)
        stringVal, err := getStringFromMixed(value)

        if err == nil {
            list := []string{"rules.", data.Rule}

            var str bytes.Buffer

            for _, l := range list {
                str.WriteString(l)
            }
            if err == nil {
                query["$and"] = append(query["$and"].([]bson.M), bson.M{"$or": []bson.M{bson.M{str.String(): stringVal}, bson.M{str.String(): nil}}})
            } else {
                checkErr(err)
            }
        }
    }

    //Получаем коэффиценты по нашему запросу
    err := mongo.GetSession().
        DB(mongo.GetDbName()).
        C("Collection_name").
        Find(query).
        Select(bson.M{"serviceName": 1, "coeff": 1}).
        Sort("priority").
        All(&mongoResult)

    checkErr(err)

    //Собираем массив с ключ, значением
    for _, element := range mongoResult {
        coeff, err := getStringFromMixed(element["coeff"])
        checkErr(err)
        intCoeff, error := strconv.ParseFloat(coeff, 64)
        checkErr(error)
        serviceName, err := getStringFromMixed(element["serviceName"])

        if val, ok := serviceList[serviceName]; ok {
            price := int(math.Ceil(intCoeff * float64(val)))
            serviceList[serviceName] = price
        }
    }

    return serviceList
}

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

Этот подход исключил все лишние походы в MongoDB, тем самым мы перестали нагружать нашу базу и получили дифференцированные цены :) (profit).