Сценарии использования

Разные цены на подписку для разных регионов

Единая цена везде не учитывает, насколько по-разному покупательная способность и конкуренция выглядят на разных рынках. Компания-разработчик ПО, продающая продукт по подписке, хотела снизить цену на одних рынках и сохранить её на других. Это достаточно распространённая стратегия, но для неё нужно было знать, на каком рынке на самом деле находится посетитель, ещё до того, как цена появится на странице.

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

Решение работало на стороне сервера, до того как страница цен отдавалась посетителю. /v1/ip принимал IP-адрес посетителя и среди прочих полей возвращал страну, по которой страница цен выбирала, какую таблицу цен отобразить. Посетитель с рынка со стандартной ценой видел стандартную цену. Посетитель с рынка, для которого компания установила региональную ставку, видел эту ставку, без выбора страны, без лишнего клика и без каких-либо видимых признаков того, что что-то вообще было определено.

Компания рассматривала определённую страну как отправную точку, а не как окончательный факт, поскольку посетитель, подключённый через корпоративный VPN или находящийся в поездке за границей, мог быть отнесён не к тому рынку, на цены которого он действительно имеет право. Вместо того чтобы жёстко кого-то блокировать, процесс оформления заказа позволял поддержке вручную изменить решение в редком случае, когда реальная страна оплаты клиента не совпадала с тем, что подсказывал IP. Это обрабатывалось как исключение, а не встраивалось в основной процесс, поскольку постоянные сомнения на странице цен ради пограничного случая, затрагивающего малую долю посетителей, свели бы на нет ту простоту, ради которой и затевалось всё изменение.

Одна деталь была достаточно важной, чтобы отдельно сообщить о ней финансовой команде: сам My Geocode везде, где работает, выставляет счета в EUR и не имеет собственных региональных цен, помимо стандартной бесплатной квоты, предоплаченного баланса и ключа Unlimited. Это отдельный вопрос от того, хочет ли компания, использующая API, применять региональные цены к своему собственному продукту: это решение целиком за бизнесом, построенным поверх API. Запрос лишь предоставляет сигнал о стране. Что компания делает с этим сигналом и как выстраивает вокруг него цены, остаётся её собственным решением.

Объём запросов соответствовал просмотрам страницы цен, обычно небольшой доле общего трафика сайта, поскольку большинство посетителей сайта компании-разработчика ПО при конкретном визите не изучают цены на продукт. Благодаря этому использование большую часть года с запасом укладывалось в бесплатную дневную квоту и переходило на предоплаченный баланс только в периоды необычно высокого трафика на странице цен, например в дни запуска продукта.

Хорошо сделанные региональные цены должны быть незаметны как механизм и очевидны как результат: правильная цена с первой отрисовки, без лишнего шага. Документация по эндпоинту находится на /docs/ipv4-lookup/ и /docs/ipv6-lookup/, а информация о ценах на сам API на /pricing/.