Приложение, адаптивный сайт или мобильная версия: что выбрать интернет-магазину

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

3 сентября 2026 Бизнес 15 мин чтения

---

Три канала, а не три технологии

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

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

Отдельная мобильная версия — второй сайт на поддомене (обычно вида m.magazin.ru) со своей вёрсткой и часто со своим, урезанным набором страниц. Покупатель этой разницы не видит: он открывает ссылку, а сервер решает, какую версию показать.

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

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

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

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

Сравнение по восьми параметрам

В таблице — параметры, по которым три канала расходятся на практике. Значения даны для интернет-магазина среднего размера, который собирается на модульной платформе из готовых модулей; для заказной разработки с нуля сроки другие и приведены отдельно в разделе о стоимости.

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

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

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

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

Второй аргумент — стоимость входа для покупателя. Между «увидел ссылку» и «увидел товар» на сайте нет ни одного шага. В приложении между ними стоит установка: переход в магазин, ожидание загрузки, разрешения. Часть аудитории на этом шаге теряется, и это нормальная плата за то, что оставшаяся часть возвращается в один тап.

Когда адаптивного сайта достаточно

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

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

Где адаптивный сайт упирается в потолок

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

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

Что входит в разработку такого сайта и по каким этапам он собирается, описано на странице сайтов для интернет-магазинов и в разборе этапов разработки сайта интернет-магазина. Если сайт уже есть и вопрос в том, где он теряет мобильного покупателя, ответ даёт аудит UX/UI или комплексный аудит интернет-магазина.

Отдельная мобильная версия: когда она ещё оправдана

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

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

Второй расход — соответствия адресов. У каждой страницы появляется два адреса, и поисковой системе нужно объяснить, что это одна и та же страница: канонические ссылки, взаимные указатели между версиями, корректная переадресация. Ошибка в этой настройке стоит позиций в выдаче, а обнаруживается через недели.

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

Случай, в котором отдельная версия объективно выигрывает

Есть ситуация, где отдельная мобильная версия остаётся разумным решением, и её стоит назвать прямо. Это большой унаследованный (legacy) сайт, вёрстку которого дешевле оставить как есть, чем переделывать целиком. Типичный пример — интернет-магазин на устаревшей системе управления, где десктопная витрина связана с внутренними сервисами, и переверстать её значит открыть отдельный проект на несколько месяцев. Лёгкая мобильная версия поверх той же серверной части даёт покупателю рабочий мобильный сайт за недели вместо кварталов, а решение о переделке десктопа откладывается до момента, когда для него найдётся бюджет.

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

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

Приложение: что оно даёт сверх сайта

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

Обратная сторона этого списка — требование магазинов приложений. Правила проверки App Store прямо описывают приложения с минимальной функциональностью, которые повторяют сайт и не дают ничего сверх него, как основание для отклонения: этому посвящён пункт 4.2 в правилах проверки App Store. Приложение, которое открывает мобильную версию сайта в отдельном окне и не добавляет к ней ничего своего, рискует не пройти проверку. Набор собственных функций мобильного канала стоит зафиксировать в техническом задании до дизайна экранов — переделка после отклонения обходится дороже.

Второе следствие — приложение публикуется не в одном магазине. Кроме App Store и Google Play, для российского покупателя работает RuStore и другие сторы, а требования к сборкам и оформлению карточки у каждого свои. Как устроена работа с карточкой и откуда берутся установки, разобрано в статье о продвижении мобильного приложения.

Что входит в состав приложения для интернет-магазина и какие модули собираются под бренд, описано на странице мобильных приложений для e-commerce; отдельно про уведомления — на странице push-уведомлений, а полный перечень возможностей — в разборе функций мобильного приложения интернет-магазина.

Сценарий выбора: четыре вопроса

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

Вопрос 1. Сколько раз покупатель возвращается за год?

Это главный вопрос, и он считается по данным заказов: доля клиентов с двумя и более покупками за год и средний интервал между покупками. Логика простая — приложение окупается на повторных покупках, потому что его главный актив в том, что человек уже установил его и получает уведомления.

Если повторных покупок мало и они редкие, приложение будет стоить как канал, а работать как визитка: установок немного, часть аудитории удалит его после первого заказа. Если покупатель возвращается раз в месяц или чаще — продукты, детские товары, косметика, зоотовары, товары для дома, аптека — приложение перестаёт быть дополнением к сайту и становится основным местом покупки. По данным страницы кейса Gulliver Family, 80% мобильного трафика ритейлера приходит через приложение, а не через мобильный сайт, и на приложение приходится половина общего дохода.

Вопрос 2. Откуда сейчас приходят покупатели?

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

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

Вопрос 3. Что покупателю нужно сделать в телефоне, чего нельзя сделать в браузере?

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

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

Вопрос 4. Сколько мест придётся править при каждой доработке витрины?

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

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

Оба канала на одной кодовой базе

Ответы на четыре вопроса чаще всего сходятся к одному: нужны и сайт, и приложение — вопрос в порядке и в деньгах. И здесь постановка задачи меняется. Вместо «сначала сайт, потом приложение отдельным проектом» оба канала собираются из одного исходного кода.

Технически это работает так: Flutter собирает из общего кода приложения для iOS и Android и веб-версию, а вместе с ними — сборки для RuStore, Aurora OS и мини-приложение в Telegram. Один и тот же код выпускается на разные платформы, а бизнес-логика — каталог, корзина, оформление, лояльность — пишется и проверяется один раз.

Что это меняет в ежедневной работе

Разница видна не в архитектурной схеме, а в работе контент-менеджера и в очереди задач на разработку:

• Товар заводится один раз и появляется в обоих каналах — без переноса и без сверки.
• Цена и остаток меняются в одном месте, поэтому рассинхрону между сайтом и приложением взяться неоткуда: расходиться нечему.
• Акция запускается синхронно — не «сначала на сайте, потом в приложении, когда выйдет обновление».
• Доработка делается один раз. Новое поле в карточке товара, другой порядок шагов в оформлении, дополнительный способ доставки — одна задача вместо двух.
• Дизайн-система одна на оба канала, поэтому бренд выглядит одинаково на телефоне и в браузере без отдельной синхронизации макетов.

Ограничения, о которых стоит знать заранее

У подхода есть две границы применимости, и обе стоит проговорить до старта.

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

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

Как устроен такой проект и что входит в состав работ, описано на странице приложения и сайта на одной базе и в разборе кроссплатформенной разработки на Flutter. Технический разбор общей основы — в статье о единой платформе для приложения и сайта, а разбор выбора между общим кодом и раздельной разработкой — в материале «Flutter или нативная разработка».

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

Сколько стоит каждый вариант

Цифры ниже — порядок расходов: сколько стоит запуск и во что обходится следующий год по каждому подходу.

Все цены указаны с учётом НДС; действующие значения по трём направлениям и трём пакетам опубликованы на странице тарифов. Отдельная строка в таблице заслуживает пояснения: сумма за два канала на общей базе меньше суммы двух отдельных проектов, потому что бизнес-логика собирается один раз, а не дважды.

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

Смету при выборе мобильного канала двигают шесть факторов:

1. Число каналов на старте. Один канал или сразу два — и собираются они отдельными проектами или из общего кода.
2. Состояние серверной части. Если сервер уже отдаёт данные для внешних систем, подготовка короткая; если каталог живёт внутри шаблонов сайта, его придётся выносить.
3. Число и глубина интеграций. Учётная система, CRM, служба доставки, эквайринг, маркетплейсы — каждая добавляет свою карту данных и свои проверки.
4. Уникальные сценарии. Подбор размера, конструктор образа, заказ на юридическое лицо, распил и колеровка — то, чего нет в типовом магазине.
5. Число целевых платформ. App Store, Google Play, RuStore, Aurora OS, мини-приложение Telegram — из одной кодовой базы это настройка сборок, а не отдельные проекты.
6. Кто делает интеграции. В пакете ПРО их подключает ваша команда или ваш подрядчик, в ПРО+ — команда исполнителя, без работы с вашей стороны.

Как считается стоимость владения на горизонте нескольких лет, а не только на старте, разобрано отдельно — в материале о стоимости владения готовым решением и модульной платформой. Сравнение подходов «собрать из модулей» и «написать с нуля» — на странице кастомной разработки против готового решения.

Кейсы: как выбор выглядел на практике

Четыре проекта, где вопрос стоял ровно так же: что делать с мобильным каналом при работающем сайте. Метрики приведены по данным страниц кейсов.

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

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

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

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

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

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

Чем адаптивный сайт отличается от отдельной мобильной версии?

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

Нужно ли приложение, если сайт уже адаптивный?

Зависит от того, как часто покупатель возвращается. Приложение окупается на повторных покупках: его актив в том, что оно уже установлено и может прислать уведомление. Если покупка совершается раз в год, приложение установят единицы, а сопровождать его придётся так же, как многолюдное. Приложение перестаёт быть дополнением, если покупатель возвращается чаще раза в квартал. Второй повод — сценарий, которого нет в браузере: сканер штрихкода, карта лояльности на кассе, оплата сохранённым способом. По данным страницы кейса Gulliver Family, через приложение идёт 80% мобильного трафика ритейлера при работающем сайте.

Заменит ли приложение сайт?

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

Что дешевле: приложение или мобильная версия сайта?

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

Что значит «приложение и сайт на одной кодовой базе»?

Это означает, что оба канала собираются из одного исходного кода: Flutter выпускает из общего кода приложения для iOS и Android, веб-версию, а также сборки для RuStore, Aurora OS и мини-приложение в Telegram. Практическая разница видна в ежедневной работе: товар заводится один раз и появляется везде, цена и остаток меняются в одном месте, акция запускается синхронно, доработка делается один раз вместо двух. Ограничения тоже есть: сайт при этом собирается заново на общей основе, а индексацию веб-сборки нужно проектировать отдельно — через серверную отрисовку страниц, и эта работа входит в состав проекта.

Сколько времени занимает запуск каждого варианта?

На модульной платформе интеграция под бренд занимает до 30 рабочих дней — и для сайта, и для приложения, и для двух каналов на общей кодовой базе: модули каталога, корзины, оплаты и лояльности уже написаны и не создаются под каждый проект заново. Отдельная мобильная версия делается внутри проекта по существующему сайту, отдельного срока у неё нет. Для полностью заказной разработки с нуля ориентир по рынку другой — 6–12 месяцев до первого выпуска, и это при отдельных командах на сайт и на приложения.

Отклонят ли приложение в App Store, если оно повторяет сайт?

Такой риск есть, и он описан в правилах проверки App Store — пункт 4.2 о минимальной функциональности. Проверка смотрит, даёт ли приложение пользователю что-то сверх сайта. Снимают вопрос собственные функции мобильного канала: уведомления, доступ к просмотренным товарам без сети, вход по отпечатку пальца или лицу, сохранённые способы оплаты, сканер штрихкода, карта магазинов с фильтрами. Набор таких функций стоит зафиксировать на этапе технического задания, до дизайна экранов, — переделка после отклонения обходится дороже.

С чего начать, если бюджет есть только на один канал?

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

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