Карты и геолокация в приложении: Яндекс.Карты, 2ГИС или Google Maps

Вопрос «какую карту подключить» выглядит как выбор одного компонента, но за ним стоят четыре разные задачи: показать точки продаж, понять, где находится покупатель, разобрать введённый адрес и посчитать маршрут. Провайдеры сильны в разном, поэтому выбор начинается не со сравнения возможностей, а со списка сценариев, которые магазин собирается закрыть. В разборе — сравнение трёх карт по девяти параметрам, разрешения на геопозицию в iOS и Android и правила магазинов приложений, устройство карты магазинов и адреса доставки, состав работ и порядок расходов, а также четыре проекта, где карта решала конкретную задачу бизнеса.

5 сентября 2026 Технологии 16 мин чтения

---

Не одна карта, а четыре задачи

Короткий ответ звучит так: если магазин работает по России и главное для него — адреса и сроки доставки, разумная точка старта это Яндекс.Карты; если сеть стоит в торговых центрах и покупателю с курьером важно найти конкретный вход, точнее будет 2ГИС; если аудитория живёт за пределами России, выбор смещается к Google Maps. Дальше — о том, откуда берётся этот ответ и в каких случаях он меняется.

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

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

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

Разобрать адрес. Перевести строку, которую человек набрал руками, в координаты и обратно. За это отвечает геокодер, а за подсказки при вводе — геосаджест. Именно эта часть чаще всего определяет, дойдёт ли заказ до курьера в пригодном виде, и именно по ней провайдеры различаются сильнее всего.

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

Термины дальше по тексту: SDK — набор готовых компонентов провайдера, который встраивается в приложение; тайлы — фрагменты изображения карты, которые приложение подгружает при перемещении; MAU — число уникальных пользователей за месяц, по которому провайдеры часто считают объём использования; полигон — область на карте, заданная контуром, обычно зона доставки.

Сравнение трёх карт по девяти параметрам

В таблице — параметры, по которым три провайдера расходятся на практике проектов для розницы. Тарифные условия сознательно описаны через модель, а не через цифры: у всех трёх они пересматриваются, и любое конкретное число в статье устареет быстрее, чем статья. Действующие условия смотрите в документации провайдера по ссылкам в разделах ниже.

Таблица намеренно не сводится к одному победителю, потому что его нет. Google Maps выигрывает две строки, которые для части проектов решают всё: мировое покрытие и самый готовый набор инструментов для Flutter — плагин поддерживает команда Flutter, и он обновляется вместе с самим фреймворком. 2ГИС выигрывает строку про здания: входы, подъезды и схемы торговых центров — это данные, которых у двух других провайдеров в таком объёме нет. Яндекс.Карты выигрывают на сочетании подробной адресной базы по России, пробок и привычности интерфейса покупателю.

Три строки читаются против Google Maps в российском проекте: зависимость от сервисов Google на устройстве, зарубежные расчёты и тарификация по числу обращений, которую нужно прогнозировать заранее. Строка про Flutter, наоборот, читается против двух отечественных провайдеров: их SDK написаны под iOS и Android, и в кроссплатформенном проекте между приложением и SDK стоит плагин-обёртка. Это рабочая, но дополнительная деталь: она добавляет работы при обновлении версий SDK, и её стоит учитывать в смете сопровождения.

Яндекс.Карты: адресная база и пробки по России

Для интернет-магазина, который работает по России, Яндекс.Карты закрывают самую частую пару задач: разобрать адрес и посчитать срок доставки. В наборе — MapKit для iOS и Android, JavaScript API для сайта, геокодер, подсказки при вводе адреса, маршрутизация и матрица расстояний между точками. Отдельно стоит слой пробок: он влияет не на картинку, а на обещанный покупателю срок.

Второй практический аргумент — договорной. Лицензия оформляется с российским юридическим лицом, оплата идёт в рублях, закрывающие документы приходят в привычном виде. Для сети, у которой карта — часть коммерческого продукта, а не эксперимент, это снимает отдельную задачу у бухгалтерии и юристов.

Третий — привычность. Покупатель в России видел этот интерфейс тысячу раз: жесты, метки, кнопка построения маршрута работают так, как он ожидает. Обучать его не нужно, а любое отклонение от ожиданий на экране выбора адреса стоит конверсии.

Где придётся считать заранее

Бесплатный вариант MapKit ограничен и по набору возможностей, и по объёму использования, поэтому для коммерческого приложения нужна лицензия. Объём считают по обращениям к сервисам и по числу пользователей, а значит смету надо строить не от факта «карта есть», а от прогноза: сколько раз в месяц открывается экран с картой, сколько раз вызывается геокодер, сколько раз считается маршрут. Эти цифры получаются из аналитики уже работающего сайта — как её читать, разобрано в материале про аналитику мобильного приложения.

Вторая деталь — Flutter. MapKit поставляется нативными библиотеками для iOS и Android, поэтому в кроссплатформенном приложении между кодом на Dart и картой стоит плагин-обёртка. Она работает, но добавляет слой, который нужно обновлять вместе с версиями SDK. Как это устроено на уровне языка и почему кроссплатформенный код при этом остаётся одним, разобрано в статье про Dart для Flutter.

Когда это правильный выбор: сеть работает по России, ключевые сценарии — ввод адреса доставки, срок доставки, магазины на карте; бюджет и договор нужно вести в рублях.

2ГИС: здания, входы и справочник организаций

2ГИС решает задачу, которую два других провайдера решают хуже: он знает не только, где стоит здание, но и как в него попасть. Входы и подъезды, этажность, схемы этажей торговых центров, справочник организаций с часами работы и телефонами — исторически это основной продукт компании, и он остаётся её сильной стороной. Состав продуктов — мобильные SDK, веб-карта MapGL, поиск по справочнику, маршрутизация — описан в документации 2ГИС.

Для розницы это превращается в два конкретных сценария. Первый — точка в торговом центре. Метка «где-то в здании» заставляет покупателя обходить центр кругом; метка на конкретном входе с указанием этажа снимает эту проблему целиком. Второй — курьер и самовывоз. Разница между «дом 12» и «дом 12, третий подъезд» на доставке измеряется минутами на каждый заказ, а на объёме сети — часами работы курьерской службы.

Где придётся считать заранее

Подробность 2ГИС распределена неравномерно: в городах присутствия она выше, чем у конкурентов, за их пределами данных заметно меньше. Для сети, у которой магазины стоят в областных центрах, это не проблема; для магазина с доставкой в малые населённые пункты по всей стране покрытие придётся проверять по своему списку адресов до выбора, а не после.

Вторая деталь — состав возможностей в тарифах. Часть функций мобильного SDK, включая работу без сети, доступна не во всех вариантах лицензии. Это стоит уточнять у провайдера списком: какие именно сценарии из вашего технического задания входят в выбранный тариф. Формализовать этот список удобно на этапе разработки технического задания — там же, где фиксируется остальной состав первой версии.

Когда это правильный выбор: магазины стоят в торговых центрах, важны самовывоз и курьерская доставка «до двери», а бизнес работает в городах, где у 2ГИС подробные данные.

Google Maps: мировое покрытие и готовый набор инструментов

Google Maps Platform остаётся самым полным набором для проектов, которые выходят за пределы России. Единое качество подложки по всему миру, карточки мест с отзывами и фотографиями, маршрутизация, готовые компоненты автодополнения адреса — документация платформы покрывает практически любой сценарий, который может понадобиться рознице.

Для кроссплатформенной команды есть ещё один аргумент, который редко называют в первых рядах, а он экономит недели. Плагин карты для Flutter ведёт сама команда Flutter, он входит в набор поддерживаемых ими пакетов и обновляется вместе с фреймворком. Это меньше кода-прослойки в проекте и меньше работы при обновлении версий — на длинной дистанции сопровождения разница заметная.

Где придётся считать заранее

Первое ограничение техническое и жёсткое: SDK Google Maps на Android опирается на сервисы Google. Российское приложение публикуется не только в Google Play — четыре магазина приложений это норма, а на части устройств сервисов Google нет. Значит, для сборок в RuStore и AppGallery нужен второй провайдер карт — и тогда в проекте появляются две карты вместо одной, с двумя наборами экранов и двумя лицензиями. Что делать, если основной магазин приложений становится недоступен, разобрано отдельно в материале про блокировку в App Store и Google Play.

Второе — расчёты. Платформа тарифицируется по числу обращений к каждому продукту, оплата идёт через аккаунт в облаке Google. Для российского юридического лица это отдельный вопрос к финансовой службе, а не строка в смете разработки. Условия тарификации пересматривались, поэтому расчёт стоит делать по действующему прайсу платформы, а не по цифрам из статей.

Когда это правильный выбор: у бизнеса есть аудитория за пределами России, приложение выходит на несколько рынков, а вопрос расчётов с зарубежным поставщиком решён.

Геолокация: разрешения, точность и правила магазинов приложений

Карта — это подрядчик и лицензия. Геолокация — это разрешение пользователя, и здесь провайдер не при чём: доступ к местоположению выдаёт операционная система, а правила выдачи диктуют Apple и Google. По нашему опыту на этой части теряется больше конверсии, чем на выборе провайдера карты, и вернуть отказ гораздо труднее, чем получить согласие с первого раза.

В iOS приложение запрашивает доступ либо на время использования, либо постоянно, и тексты объяснений обязательно прописываются в настройках сборки — как именно, описано в документации Core Location. С iOS 14 у пользователя появился отдельный переключатель точности: он может разрешить доступ, но отдать только приблизительное местоположение. Приложение обязано остаться работоспособным и в этом случае.

В Android разрешения разделены на приблизительное и точное местоположение, и начиная с Android 12 пользователь сам выбирает, какое из них выдать; правила и порядок запроса описаны в руководстве по разрешениям на местоположение. Доступ в фоновом режиме — отдельная история: он запрашивается отдельно, а Google Play требует объяснить, зачем он нужен, и проверяет это объяснение при публикации. Для магазина фоновое местоположение почти никогда не оправдано: оно нужно курьерскому приложению, а не покупательскому, и попытка запросить его «на всякий случай» превращается в риск отклонения сборки.

Из таблицы следуют два правила продукта, которые стоит зафиксировать до дизайна экранов. Первое: не запрашивать геопозицию на первом экране. Запрос при запуске приходит раньше, чем человек понял, зачем приложению его местоположение, и отказ на этом шаге закрывает сценарий надолго — повторно система спрашивать не будет, пользователю придётся идти в настройки. Правильный момент — рядом с выгодой: кнопка «показать ближайший магазин», шаг ввода адреса доставки, экран проверки зоны.

Второе: запасной путь обязателен для каждого сценария. Магазин, который без геопозиции не показывает каталог, теряет не долю аудитории, а всю ту её часть, что не выдаёт разрешения по привычке. Выбор города списком, ручной ввод адреса, полный список магазинов текстом — это не запасной вариант «на всякий случай», а основной путь для заметной доли покупателей. Как эти шаги влияют на дальнейшую воронку, разобрано в разборе конверсии корзины интернет-магазина.

Отдельный вопрос — правовой. Координаты, привязанные к учётной записи покупателя, обрабатываются вместе с остальными его данными, поэтому геолокация попадает в тот же контур согласий и хранения, что и телефон с адресом. Формулировки согласия и порядок хранения — предмет для юриста компании, а не для технического задания; в проекте это отражается на составе экранов и на том, где физически лежат данные. Смежные требования к защите платёжных данных разобраны в материале про безопасность платежей в мобильном приложении.

Карта магазинов: что делает её рабочей

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

Карточка точки, а не метка. На метку нажимают ради содержимого: адрес, часы работы сегодня, телефон, ориентир для входа, кнопка построения маршрута в карте телефона. Часы работы важно показывать как «сегодня до 22:00», а не таблицей на неделю: покупатель смотрит на экран, чтобы решить, ехать ли прямо сейчас.

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

Связь с каталогом. Вопрос покупателя редко звучит как «где ваши магазины». Он звучит как «где посмотреть вот эту куртку». Карта, на которой можно отфильтровать точки по наличию конкретного товара или по услуге, отвечает на настоящий вопрос — но для этого ей нужны остатки по магазинам из учётной системы, а это уже задача обмена данными, а не карты. Как устроен такой обмен, разобрано в материале про автоматизацию учёта товара в рознице и интеграцию с 1С.

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

Один источник адресов. Самая частая поломка карты магазинов — не техническая. Адреса заводятся руками отдельно на сайте и отдельно в приложении, потом одна точка переезжает, и полгода покупатели ездят по старому адресу. Источник должен быть один — учётная система или административная панель, а карта только показывает то, что в ней лежит. Когда сайт и приложение собираются из одного кода, эта проблема снимается конструктивно: список адресов один на оба канала. Как это устроено, описано в разборе приложения и сайта на одной платформе Flutter.

Доставка: адрес, зона и правильный склад

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

Шаг 1. Адрес

Ввод адреса — самое узкое место всего оформления заказа. Работающий вариант состоит из трёх частей: подсказки при вводе, чтобы человек не набирал строку целиком; уточнение метки на карте, потому что геокодер ставит точку по номеру дома, а вход бывает с другой стороны; и отдельные поля для квартиры, подъезда, этажа и домофона — этих данных в карте нет и быть не может, они приходят только от покупателя.

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

Шаг 2. Зона

Зоны доставки задаются полигонами: у каждой свои срок и стоимость. Здесь важно одно правило: проверка попадания адреса в зону делается на сервере, а не в приложении. Приложение — это то, что стоит на устройстве покупателя, и его ответ нельзя считать окончательным ни для расчёта стоимости, ни для приёма заказа. Экран показывает результат, решение принимает сервер.

Шаг 3. Город и склад

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

Шаг 4. Статус и курьер на карте

Показ курьера на карте — не функция карты, а отдельный продукт: нужен источник координат, то есть приложение курьера с фоновым доступом к местоположению и своим согласием. Для большинства магазинов достаточно более простого шага: статусы заказа с уведомлениями и ориентировочное время прибытия. Как устроены сами уведомления, разобрано в материале про push-уведомления в приложении, а состав работ по курьерской части — на странице приложения для службы доставки. Отдельный разбор для общепита — в статье про собственное приложение доставки еды или агрегатор.

Сколько стоит карта в проекте

Расходы на карту делятся на три статьи, и их полезно держать раздельно, потому что платятся они разным адресатам.

Первая — лицензия провайдера карт. Она платится Яндексу, 2ГИС или Google напрямую и не входит ни в стоимость разработки, ни в лицензию платформы. Это регулярный платёж, который зависит от объёма обращений, поэтому его считают по прогнозу нагрузки, а не по расходу прошлого месяца.

Вторая — работы по подключению. Экраны, состояния разрешений, обработка отказа, связь с каталогом и с оформлением заказа. Это разработка, и её объём определяется списком сценариев, а не тем, какой провайдер выбран: подключение самого SDK — небольшая часть работ.

Третья — сопровождение. Версии SDK обновляются, правила разрешений в iOS и Android меняются, зоны доставки перерисовываются вместе с ростом сети. Это регулярная работа, а не разовая.

Модель оплаты в FITTIN состоит из трёх частей. Первое — единоразовая интеграция под бренд, до 30 рабочих дней: разворачивание платформы, настройка модулей, интеграции с 1С, эквайрингом и службами доставки, публикация в магазинах приложений. Второе — ежемесячные лицензионные платежи, в которые уже включены все затраты на техническую поддержку команды: мониторинг работы, обновления модулей и обновления безопасности, поэтому своя команда разработки для сопровождения не нужна. Третье — новый функционал и доработки, они считаются отдельно по модели Time & Materials с оценкой по часам до старта задачи.

Карта и работа с адресом — как раз третья часть. Каталог, корзина, оплата и программа лояльности собираются из готовых модулей платформы, а экраны карты, зоны доставки и обработка разрешений дописываются на исходном коде под сценарии конкретной сети. Для ориентира по остальным двум частям: тариф ПРО для мобильного приложения — от 525 000 ₽ единоразово и от 150 000 ₽ в месяц; приложение и сайт на одной кодовой базе — от 735 000 ₽ и от 250 000 ₽ в месяц. Все цены указаны с учётом НДС, действующие значения опубликованы на странице тарифов. Разница между моделями оплаты работ разобрана в материале про Time & Materials и фиксированную цену.

Кейсы: как карта решала задачу бизнеса

Четыре проекта, где карта и геолокация закрывали разные задачи. Метрики приведены по данным страниц кейсов.

Итог: выбор карты на одной странице

Выбор между Яндекс.Картами, 2ГИС и Google Maps решается не сравнением возможностей, а списком сценариев, которые магазин собирается закрыть, и географией его покупателей.

Команда — федеральная команда FITTIN с центром разработки в Воронеже: распределённая модель даёт эффективные ставки без потери качества. Платформа входит в реестр российского программного обеспечения Минцифры под номером 2487103.

Что делать дальше:

• Собрать список сценариев с картой и оценить бюджет — калькулятор стоимости или сравнение тарифов.
• Зафиксировать состав первой версии, включая зоны доставки и работу с адресом, — разработка технического задания.
• Найти, где покупатель теряется на экранах адреса и магазина, — аудит UX/UI или комплексный аудит интернет-магазина.
• Понять, что переиспользуется из текущего приложения, — аудит кода.
• Обсудить конкретный сценарий — приложение для интернет-магазина, приложение и сайт на одной базе, приложение для службы доставки или разговор с командой.

Часто задаваемые вопросы

Какую карту выбрать для приложения интернет-магазина в России?

Отталкивайтесь от сценариев, а не от возможностей. Если основное — ввод адреса доставки, расчёт срока и магазины на карте по России, разумная точка старта это Яндекс.Карты: подробная адресная база, данные о пробках, договор с российским юридическим лицом и оплата в рублях. Если сеть стоит в торговых центрах и важно, чтобы покупатель и курьер нашли конкретный вход, точнее будет 2ГИС с его данными о входах, подъездах и этажах. Если у бизнеса есть аудитория за пределами России, к сравнению добавляется Google Maps. Проверить выбор можно за один шаг: возьмите двадцать реальных адресов из своих заказов и посмотрите, как каждый провайдер их разбирает.

Можно ли использовать Google Maps в приложении для российского рынка?

Технически да, но есть два ограничения, которые стоит проверить до начала работ. Первое: SDK Google Maps на Android опирается на сервисы Google, а российское приложение публикуется не только в Google Play — на части устройств этих сервисов нет, и для сборок в RuStore и AppGallery понадобится второй провайдер карт. Второе: платформа тарифицируется по числу обращений и оплачивается через аккаунт в облаке Google, что для российского юридического лица становится отдельным вопросом к финансовой службе. Если оба вопроса решены и аудитория международная, Google Maps остаётся полным и удобным набором инструментов.

Нужны ли две карты в одном приложении?

Две карты нужны в одном конкретном случае: когда основной провайдер не работает на части устройств, где приложение должно быть опубликовано. Практический пример — Google Maps на Android-устройствах без сервисов Google. Тогда в проекте появляются два набора экранов, две лицензии и двойная работа при каждом изменении. По нашему опыту это оправдано только при действительно международной аудитории; в проекте для российского рынка проще выбрать одного провайдера, который работает во всех целевых магазинах приложений. Во всех остальных случаях вторая карта — это удвоенные расходы на сопровождение без выгоды для покупателя.

Что будет, если покупатель не даст доступ к геолокации?

Приложение должно работать полностью — это требование, а не пожелание. Значительная часть аудитории отказывает в доступе по привычке, а повторно система разрешение не запрашивает: человеку придётся идти в настройки телефона, и почти никто этого не делает. Поэтому каждый сценарий с геопозицией нужен в двух вариантах: город определяется автоматически или выбирается списком, ближайший магазин показывается по геопозиции или ищется по названию улицы, адрес доставки подставляется или вводится руками с подсказками. Отдельно стоит учесть, что с iOS 14 и Android 12 пользователь может дать доступ, но отдать только приблизительное местоположение — этого хватит для выбора города, но не для подстановки адреса.

В какой момент запрашивать разрешение на местоположение?

Не при запуске приложения. Запрос на первом экране приходит раньше, чем человек понял, зачем приложению его местоположение, и доля отказов на этом шаге заметно выше. Правильный момент — рядом с очевидной выгодой: нажатие на «показать ближайший магазин», переход к вводу адреса доставки, проверка зоны. Перед системным окном полезно показать свой экран с объяснением в одну строку — что именно приложение сделает с местоположением. Тексты объяснений для iOS прописываются в настройках сборки, и они видны пользователю в системном окне, поэтому формулировка «для улучшения работы приложения» здесь не подходит.

Сколько стоит подключить карту к приложению?

Расходы делятся на три статьи, и платятся они разным адресатам. Лицензия карт платится провайдеру напрямую, ежемесячно, по объёму обращений — она не входит ни в стоимость разработки, ни в лицензию платформы. Работы по подключению платятся подрядчику один раз, и их объём зависит от списка сценариев, а не от выбранного провайдера: само подключение SDK — небольшая часть, основное это экраны, адрес, зоны и обработка отказа в доступе. Сопровождение — обновления SDK и изменения правил iOS и Android — в модели FITTIN включено в ежемесячные лицензионные платежи. Сами экраны карты считаются как доработка по Time & Materials с оценкой по часам до старта задачи, поверх готовых модулей каталога, корзины и оплаты.

Как показать зону доставки на карте?

Зона задаётся полигоном — контуром на карте, у которого есть свои срок и стоимость доставки. Все три провайдера умеют рисовать полигоны, поэтому вопрос не в карте. Важно другое: проверка попадания адреса в зону должна выполняться на сервере, а не в приложении, потому что приложение стоит на устройстве покупателя и его ответ нельзя считать окончательным для расчёта стоимости и приёма заказа. Экран показывает результат — «доставим сегодня до 20:00, 300 ₽» или «в этот адрес доставки нет, доступен самовывоз», — а решение принимает сервер. Отдельно закладывайте инструмент для перерисовки зон: они меняются вместе с ростом сети, и делать это через выпуск новой версии приложения неудобно.

Работает ли карта во Flutter-приложении так же, как в нативном?

Для покупателя разницы нет: на экране это та же карта того же провайдера с теми же жестами и метками. Разница есть для команды. У Google Maps плагин для Flutter ведёт сама команда Flutter, он обновляется вместе с фреймворком. У Яндекс.Карт и 2ГИС SDK написаны под iOS и Android, поэтому в кроссплатформенном проекте между кодом и картой стоит плагин-обёртка — она работает, но добавляет слой, который нужно обновлять при смене версий SDK. На практике это влияет не на возможности карты, а на трудоёмкость сопровождения, и это стоит учесть в смете заранее.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.