Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
В чём оплата за каждый продукт ошибается насчёт того, как используются API
Откройте журнал запросов почти любого приложения, использующего данные о местоположении, и вы не найдёте там один тип поиска, работающий изолированно. Форма регистрации геокодирует адрес, проверяет IP на примерное совпадение сети и проставляет в записи часовой пояс, и всё это за одни и те же несколько сотен миллисекунд. Это не три отдельных сценария, у которых случайно общий провайдер API. Это один рабочий процесс, затрагивающий три вида данных.
Раздельная оплата по продуктам делает вид, что это не так. Она устанавливает цену на геокодирование в одном тарифе, на поиск по IP в другом, а данные о часовых поясах или высоте предлагает как дополнительные опции с отдельной платой, словно компании, которой нужно одно из этого, вряд ли понадобится остальное. На практике всё наоборот: потребность в одном из них обычно говорит о том, что вам нужно ещё как минимум одно. Оформление заказа в интернет-магазине, которое геокодирует адрес доставки, почти наверняка хочет знать и часовой пояс, в котором планировать окно доставки. Антифрод-проверка, которая смотрит на IP-адрес, обычно хочет сверить его с адресом из профиля.
Мы сделали My Geocode одним продуктом с одной ставкой. Каждый эндпоинт, геокодирование, определение IP, часовой пояс, высота, почтовый индекс, и каждый совместимый хост стоит ровно столько же за запрос. Нет отдельного прайс-листа, который нужно сверять, нет тарифа, добавляющего данные о часовых поясах только после того, как вы уже оплатили тариф геокодирования. Запрос есть запрос, к какому бы эндпоинту он ни обращался.
Это не просто удобство для клиента. Это отражает то, как на самом деле выполняется работа. Поиск через один эндпоинт при масштабах, на которых работает большинство приложений, не обходится в обработке радикально дороже, чем поиск через другой. Разделение их на отдельные продукты с отдельными ценами не отражает реальной разницы в стоимости ответа на запрос. Оно отражает, сколько отдельных строк провайдер может поместить в счёт.
Раздельная оплата по продуктам к тому же усложняет понимание собственного использования. Если геокодирование оплачивается одним способом, а поиск по IP другим, оценка счёта на следующий месяц означает отслеживание двух счётчиков по двум тарифным структурам в надежде, что соотношение вызовов не сдвинется так, что итог непредсказуемо изменится. Единая фиксированная ставка сводит эту оценку к одному числу: общее количество запросов, умноженное на одну цену. Любой, кто составляет бюджет для своей интеграции, может посчитать это на обороте конверта.
В раздельной оплате по продуктам скрыто более глубокое допущение, которое мы считаем просто неверным: будто разные виды данных о местоположении обслуживают разных клиентов. По нашему опыту, они обслуживают одного и того же клиента на разных этапах одного и того же запроса. Логистическая платформа, процесс регистрации и антифрод-система объединяют данные геокодирования, IP и часовых поясов в одно решение. Ценообразование, которое делает вид, что это отдельные рынки, вынуждает клиентов либо переплачивать за пакет, который они используют неравномерно, либо жонглировать несколькими поставщиками, чтобы этого избежать. Одна ставка и один список эндпоинтов являются более простым и честным ответом.