Локализация цифрового продукта: что менять при выходе на новый рынок
Кнопка «Оплатить» в двух странах выглядит примерно одинаково. За ней могут стоять разные банки, договоры и правила хранения данных. На макете это два одинаковых прямоугольника. В бэклоге один из них довольно быстро просит отдельную инфраструктуру.
Мы сталкивались с этой границей в разных проектах: в сервисе консультаций она прошла через юрисдикции и платежи, у HOTZ — через общий каталог и разные витрины. Разберём, какие части продукта можно переиспользовать, что вынести в настройки и когда стране нужен отдельный контур.
Одна страна добавляет в бэклог больше, чем один язык
Локализация интерфейса заметна первой, поэтому с неё удобно начинать разговор. Перевели тексты, добавили валюту, поменяли телефон поддержки. Кажется, что основная работа уже описана.
Дальше приходит первый настоящий заказ. Товар недоступен в этой стране. Цена считается по другим правилам. Местный способ оплаты не умеет работать по привычному сценарию. Данные пользователя нельзя хранить там же, где данные остальных клиентов. Перевод остаётся небольшой частью запуска.
Локальная валюта влияет на решение о покупке. В опросе DHL 2026 года участвовали 29 тысяч онлайн-покупателей из 29 стран; данные собирали с 15 декабря 2025-го по 11 февраля 2026-го. 41% выбрали цены в местной валюте среди факторов, которые подтолкнули бы их купить за рубежом. Цифра объясняет, почему валюта входит в локальное предложение. Какой банк подключать, как проводить возврат и где хранить данные, опрос уже не подскажет: здесь начинается архитектура продукта.
Копия продукта для каждой страны решает вопрос быстро и создаёт следующий. Исправление приходится переносить в несколько кодовых баз, каталоги расходятся, а команда однажды обсуждает, почему кнопка в Казахстане ведёт себя как её российская родственница полгода назад.
Полностью универсальная система тоже обходится дорого. В ней растёт слой настроек, исключений и проверок. В какой-то момент форма добавления страны начинает напоминать анкету на ипотеку.
Мы раскладываем различия по трём уровням: общее ядро, настройки рынка и отдельная инсталляция. Этого хватает, чтобы оценить запуск без двух крайностей.
Один сценарий пришлось разнести по разным контурам
В одном из наших проектов пользователь выбирает специалиста, бронирует время и подключается к консультации. Этот путь одинаково понятен в любой стране. Архитектура вокруг него уже зависит от юрисдикции.
Для разных стран мы предусмотрели самостоятельные развёртывания платформы. Пользовательские данные остаются внутри своего контура, а платёжные интеграции подключаются отдельно для каждого рынка.
Общими остаются основные сущности и правила: пользователь, специалист, слот, консультация, роли и доступы. Локально живут инфраструктура, платёжная интеграция и требования к данным. Пользователь по-прежнему хочет одного — попасть к выбранному специалисту вовремя. География всей конструкции его интересует примерно до первой ошибки.
Отдельные инсталляции увеличивают стоимость поддержки. Обновления, миграции и мониторинг приходится проводить в нескольких контурах. В этом проекте такая цена оправдана границами данных и платежей. Делить систему только потому, что в списке стран появился новый пункт, мы бы не стали.
HOTZ показывает другую границу: каталог общий, витрины разные
HOTZ — мультбрендовый проект. Четыре продуктовые линии работают на одной платформе. У каждой свой визуальный язык и контент, а каталог, данные и путь покупки общие.
Русскую и английскую версии сотрудники заполняют отдельно. При этом новая вкладка в административной панели ещё не превращается в новый бренд. Уникальный внешний вид требует дизайна и разработки, повторяемые блоки и данные продолжают работать на общей модели.
Для выхода на несколько рынков мы используем похожее разделение. У товара остаётся одна базовая карточка. Рядом появляется предложение для конкретной страны: доступность, цена, валюта, перевод, документы и доставка. Один и тот же товар можно продавать по разным правилам, не создавая трёх независимых каталогов.
Это разделение полезно и за пределами интернет-магазинов. У услуги тоже есть общее ядро и локальное предложение: состав, цена, способ оплаты, ограничения и документы. Меняется рынок, а аналитика и интеграции по-прежнему видят один продукт.
Три коробки для любого отличия рынка
На старте мы буквально раскладываем требования по трём коробкам.
Общее ядро
Сюда попадает то, без чего продукт перестанет быть собой: учётная запись, товар или услуга, заказ, роли и статусы. Здесь же остаются правила обмена данными между системами и события аналитики. Эти части развиваются вместе для всех рынков.
Настройки рынка
Здесь живут язык, валюта, локальный ассортимент, цены, способы оплаты, доставка, тексты документов и контакты поддержки. Их можно менять независимо, сохраняя общую модель.
Отдельный контур
Он появляется, когда страна меняет место хранения данных, юридическое лицо или счёт продавца у платёжного провайдера. Сюда же относятся особые требования к доступности сервиса и другой сценарий заказа или услуги. Такой контур получает собственную инфраструктуру, секреты и процедуру выпуска.
Критерий простой: смотрим на цену ошибки. Неверный перевод можно быстро исправить. Неверная цена, деньги на чужом юридическом лице или данные в другой юрисдикции требуют более жёсткой границы.
Один заказ проверяет архитектуру лучше десяти экранов
После раскладки берём один заказ и проводим его целиком. Пользователь открывает карточку, регистрируется, видит цену, оплачивает, получает уведомление, отменяет операцию и оформляет возврат. Для сервиса вместо товара подставляем запись, подписку или бронирование.
На каждом шаге фиксируем владельца правила и источник данных. Кто определяет доступность? Откуда приходит цена? Какой банк принимает деньги? Где остаются персональные данные? Кто увидит ошибку и сможет её исправить?
Так быстро находятся места, где красивый макет молчит. Особенно полезен возврат. Успешную оплату умеют показывать почти все прототипы, а обратная дорога денег почему-то появляется ближе к релизу, уже с характером.
После такого прохода оценка становится честнее. Перевод и дизайн остаются видимой частью. Интеграции, данные и операционные правила получают собственные задачи, владельцев и сроки.
Слишком много общего тоже стоит денег
Универсальность легко превратить в отдельный продукт внутри продукта. Каждое поле получает условия показа, каждое правило — исключение, а тестирование начинает проверять комбинации, которыми никто не пользуется.
Поэтому мы выбираем минимальную достаточную изоляцию. Контент и рыночные параметры держим в настройках. Стабильную бизнес-логику оставляем в ядре. Данные, деньги и юридическую ответственность разделяем там, где ошибка становится дорогой или запрещённой.
Эта схема не обещает один релиз на весь мир. Она даёт более полезный результат: команда понимает, какая часть продукта действительно общая и за что придётся платить отдельно.
Кнопка осталась кнопкой
В новой стране пользователь всё равно нажмёт «Оплатить» и будет ждать обычного результата. До этого момента команда должна договориться о каталоге, цене, банке, данных и возврате.
Язык, валюта и ассортимент остаются в настройках. Смена получателя денег, места хранения данных или порядка операции требует отдельного контура.
Готовитесь выводить цифровой продукт или интернет-магазин на новый рынок? Приходите с одним реальным заказом. Мы пройдём его от карточки до возврата и соберём схему запуска до того, как одинаковые кнопки превратятся в три разные системы.
