Трибуна Денис Гордиенко
3 912

Как мы снизили стоимость разработки приложения в два раза

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

В закладки
Аудио
Денис Гордиенко, генеральный директор Brigt Mobile

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

Мы затронем тему о том, как:

  • сэкономить на разработке мобильных приложений;

  • выстроить разработку, сэкономив на неважных для клиента процессах

Как обычно происходит

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

  • Этап прототипирования.
  • Этап дизайна – (сюда входит отрисовка всех макетов, согласование с клиентом, внедрение правок).
  • Этап верстки / фронтенда
  • Этап сборки – один из основных этапов (включает в себя серверную часть, программирование приложений на базе HTML-вёрстки, создание архитектуры БД и разработка админки).
  • Этап тестирования и исправления багов.

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

Раньше весь этот процесс у нас стоил 35 тыс за один экран, т.е. если у вас приложение на 10 экранов, вышло бы 350 тыс. Это, конечно, не огромная сумма, но для многих клиентов на MVP-версию ценник неподъемный. Отсюда родилась идея о том, что нужно изменить технологии так, чтобы это было выгодно и клиентам, и нам. Мы пришли к тому, что необходимо выбросить все ненужное для быстрого запуска стартапа.

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

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

К чему я пришел

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

То есть на страте есть некая структура, например, на 10 экранов, в которой прописано, что конкретно в каком экране должно быть (регистрация, авторизация, редактирование и т.д.). Получается такое микро-ТЗ. На этапе согласования с клиентом, ещё до получения денег,, мы погружаемся в идею и прописываем какие поля должны быть на каждом из экранов. По идее это не более 1-2 часов для адекватного сейлза.

Первый этап - разворачиваем сервер и БД

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

Второй этап - запуск каркасных приложений

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

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

В такой схеме мы исключаем этап дизайна и используем шаблоны дизайна конкретных элементов управления, которые программист расставляет уже индивидуально под каждый проект. То есть используется не шаблон всего экрана, а некие заготовки инструментов управления (отдельно шаблон кнопки, текста, заголовка, блока и т.д.). Из этого, ориентируясь на структуру, мы формируем каждый из экранов. Благодаря такому подходу этап верстки сокращается по нашим замерам в 8 раз. То есть время с восьми часов на один экран сокращается до одного часа.

Третий этап - натив и интеграции

Третий этап - это интеграция и реализация нативных функций. Ранее я уже писал, что мы специализируемся на гибридной, а точнее, webview-технологии разработки приложений. Это сделано, опять же, с точки зрения экономии стоимости и сроков запуска проекта.

Так вот, в третьем этапе к каркасу мобильных приложений мы дописываем нативные функции, которые обусловлены идеей приложения. Если клиенту нужен сканер QR-кода или распознавание VIN-номера автомобиля, то, конечно же, это делать нужно нативно.

То же самое и с интеграциями - подключение к 1С, Битрикс24, amo.crm, соцсетям делается на этом этапе.

Четвертый этап - багфикс и причесон

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

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

Развитие стартапа

После появления идеи, я рекомендую своим клиентам придерживаться следующих этапов развития:

  • Запуск MVP-версии
  • Сбор обратной связи, тестирование идеи на живых пользователях
  • Принятие решение по дальнейшим изменениям

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

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

Пишите мне в личку или по контактам на сайте свои идеи для стартапа, а я помогу оценить их по вот такой схеме. Жду ваши мнения в комментариях.

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 50, "likes": 23, "favorites": 115, "is_advertisement": false, "subsite_label": "tribuna", "id": 49748, "is_wide": false, "is_ugc": true, "date": "Thu, 01 Nov 2018 10:03:44 +0300" }
{ "id": 49748, "author_id": 127886, "diff_limit": 1000, "urls": {"diff":"\/comments\/49748\/get","add":"\/comments\/49748\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/49748"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199116, "possessions": [] }

50 комментариев 50 комм.

Популярные

По порядку

Написать комментарий...
2

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

Так вот, где этот сайт для вебвью располагается у вас обычно: на локалхосте или на внешнем ресурсе? Какие трудности и ограничения есть у приложений на вебвью?

Ответить
0

Анатолий, Вы всё верно понимаете. Это мобильный сайт, который отображается в приложении-обёртке. Кроме того, в нативной части могут быть дополнительные функции, кроме простого отображения. Например, GPS, push, работа с камерой и т.д. В этом случае, данные из натива передаются на сервер с webbiew через JS-методы

Сервер, как и в стандартной модели размещается у хостинг-провайдера, обычно мы рекомендуем VPS с серверным пространством BitrixVM, т.к. для администрирования сервера используем админку от 1С-Битрикс.

Ответить
3

Сам до недавнего времени писал на Cordova-based решениях. Я так понимаю,что вы их и используете(поправьте если не прав). ИМХО уже сейчас лучше использовать flutter. Для любого уважающего себя веб-разработчика порох входа во flutter минимальный.

Из своего опыта могу сказать,что на кордове очень намучился работать с камерой и не только. Например, записывать видео. Настолько все медленно и ужасно...

Во flutter'e очень удобный "канал" для работы с нативным кодом(по сравнению с вариантом кордовы). Нативные компоненты, компиляция в arm64 код(весь, а не только компоненты, как делает React Native).

Ответить
0

Александр, не совсем верно. Мы пишем чистый webview на Bitrix.Framework (пространство разработки от Битрикса). К нему написали собственные обёртки (пробовали Bitrix.Mobile, но оно ужасно неповоротливое). Кордову, ионик и подобные компилируемые фреймворки забрили из-за двух факторов:
1. При обновлении приложения его нужно переопубликовывать
2. Более высокий порог входа для программистов.
Второй пункт не про то, что мы говнокодеров привлекаем, а обусловлен тем, что программистов воспитываем почти с нуля и нам критично насколько быстро он сможет выполнять боевые задачи

Ответить
1

Почему при обновлении надо переопубликовывать?
Один раз генерируете .jks или .keystore файлик (я про андроид) и подписываете с помощью jarsigner каждый новый билд одним и тем же файлом. Или я не так понял?

Ответить
0

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

В случае webview такого нет. Вы изменяете html на сервере и при очередном обращении к этому экрану пользователь видит свежую версию экрана

Ответить
1

Почему решили использовать отвратительный Битрикс?

Ответить
0

Мы его используем в качестве админки и фреймворка. А в чём, на Ваш взгляд его отвратительность?

Ответить
0

В целом мое негодование направлено на инфраструктуру Битрикса и его серверные части. И думаю что в фронтовой они не сильно иначе делали.
Основные претензии к попыткам угодить всем через модульность, которая выливается в совершенно чудные танцы с бубном при конфигурации. Шаг влево шаг вправо от этой модульности и ты уже пишешь вкрапления на php.

Ответить
0

Я думаю, что здесь поможет наследование. Например, наш техдир принципиально запрещает лезть в ядро и разбирать архитектуру Битрикса, чтобы, как раз, не было желания накостылить там, где это не нужно. Всё общение с ядром только через понимание входных и выходных данных. Если есть излишек - забиваешь, если чего-то не хватает, то наследуешь и дописываешь то, чего не хватает. Со своей стороны могу сказать, что 90% претензий к Битриксу основано либо на желании что-то закостылить по быстренькому, либо на непонимании принципов ООП. Это не камень лично в Ваш огород, просто в защиту Битрикса.

Ответить
2

"После появления идеи, я рекомендую своим клиентам придерживаться следующих этапов развития:
Запуск MVP-версии
Сбор обратной связи, тестирование идеи на живых пользователях
Принятие решение по дальнейшим изменениям"

Сразу запуск MVP-версии после появления идеи? А как же аналитика, опросы и др. перед запуском MVP-версии? Уже на этих этапах можно понять, что идея так себе и не стоит вкладываться даже в MVP.

Ответить
0

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

Ответить
1

Я общее направление действий и имею в виду, клиент и слов таких может не знать Customer Development, Roadmap, Customer journey Map и др. А аналитика и опросы перед запуском MVP для большинства проектов обязательный этап.

Я вот только эту статью оцениваю, а не весь ваш блог. Я, например, клиент. У меня появилась идея. Читаю статью и понимаю, что первый этап развития "Запуск MVP-версии". Ок, запускаем MVP, тратим деньги, получаем продукт, который никому не нужен.

Ответить

1

Это понятно. Бывают проекты, которые можно на этапе аналитики понять, что скорее всего не прокатит и продукт никому не нужен. Вливать в такой в такой проект деньги и поддерживать какое-то время смысла нет.
Кто-то рассказывал историю из серий Саус Парка. Там гномы воровали у жителей грязные трусы. У гномов был план на этом зарабатывать. План состоял из трёх пунктов:
1. Воруем грязные трусы
2. Второй пункт плана они забыли.
3. Получаем прибыль.

Ответить
0

Иногда не нужную никому идею можно модифицировать и сделать нужную. В принципе, кастдев примерно об этом

Ответить
0

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

Ответить
1

можно ли на webview написать приложение для курьера которое стабильно в фоновом режиме будет передавать на сервер его GPS-трекинг, при этом чтобы оно работало на iphone,android и windows mobile?

Ответить
2

Да, если сделать нативную функцию фонового GPS-трекинга, который передаёт данные на сервер. Мы как раз недавно такую фишку сделали в нашем готовом решении для запуска маркетплейсов услуг - http://servicepi.ru

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

Ответить
1

если оценить приложение в экранах = 3шт (авторизация + просмотр списка заказов + просмотр заказа с возможностью смены статуса) = 16*3 = 48 тыс руб ? вы готовы сделать его за эту сумму?

Ответить
0

Если это только экраны (без дополнительных нативных функций и интеграций с внешними сервисами и базами), то да. Получается, что заказы будет создавать админ из своей панели. Напишите мне в ВК https://vk.com/truewuch или на мыло d@brightmobile.ru обсудим детали.

Ответить
0

Круто! А можете код показать? Реализовано на swift?

Ответить
0

Серверная часть и экраны на Bitrix.Framework, а натив на Java/Objective-C

Код натива в ближайшее время зальём на гитхаб в формате опенсорса и напишу отдельную статью с интервью нашего техдира. Как говорится coming soon :)

Ответить
0

Ждем ждем

Ответить
0

Кстати, что скажете про сравнение Swift и ObjC?

Ответить
0

Если делать webview или подобное простое, с точки зрения нативной части, приложение, то по барабану

Ответить
0

Нет, я имею в виду в целом языки если сравнивать, что думаете?

Ответить
0

Думаю, что я не iOS-программист, чтобы брать на себя ответственность за сравнение :) Если сильно интересно, то завтра уточню у нашего техдиректора.

Ответить
0

Да не )), просто интересовался

Ответить

1

было 35 тыс за экран, а теперь в 2 раза = 17,5 тыс?

Ответить
1

16 тыс экран. Спасибо, что обратили внимание, почему-то пропустил точную цифру в статье

Ответить
1

Я описывал аналогичный подход к запуску с точки зрения дизайнера стартапов. Мы у себя в стартап-инкубаторе как-то сами по себе пришли к этому, когда поняли, что время это очень важно, если ты хочешь получить финансирование. Конечно, написано совсем просто и без всяких тонкостей, ибо аудитория фейсбуковская была.
----
... Теперь мы стараемся как можно быстрее запуститься. И пофиг на внешний вид, на иконочки-кнопочки, на фотографии и прочие няшности. Наш процесс уже выглядит так: концепция — разработка — ЗАПУСК — работа над ошибками — дизайн — верстка — версия 2.0 —развитие.

Другими словами, после того, как мы что-то придумали, мы изучаем технологию, составляем план разработки и отдаем все разработчикам. В качестве дизайна тупо покупаем первый попавшийся html-шаблон за 20 баксов, пичкаем его контентом и фотографиями со стоков. На это уходит 1 день.

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

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

Не знаю, подойдет ли вам такой метод, но от себя скажу, что время экономится существенно. И результат получается лучше, чем если бы это делалось линейно. Также пропадает такой фактор как усталость от проекта.

Ответить
1

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

Ответить
0

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

Ответить

0

Чтобы собирать по конвейеру быстрые качественные проекты. Bootstrap родом от разработчиков твиттера. Они тоже говнецо делают? Да и по дизайну никто не мешает клиенту продолжать работу с нами, если есть такая необходимость.

Ответить
1

1. Стали в 2 раза меньше платить сотрудникам
или
2. Стали в 2 раза меньше работать

Профит)

Ответить
0

Михаил, вы так пишите, как-будто это срыв покровов. Я в статье и написал о том, что стали в 2 раза меньше работать заменив дизайн и долгую вёрстку на быструю вёрстку на бутстрапе.

Ответить
0

То, что я написал - называется юмор) Я даже статью не читал. Увидел очередное банально-рекламное название - и решил написать.

А раньше Вы как верстали без бутстрапа?

Ответить
0

Банально-рекламное название как раз и нужно чтобы привлечь максимум просмотров :)

Верстали на голом HTML+SCSS

Ответить

1

MVP = тяп ляп и в продакшн
Есть и другие нелитературные определения. Увы но Индия это теперь мы.

Ответить
0

У Вас есть более подходящие решения для проверки той или иной гипотезы без траты кучи денег на разработку? Тогда поделитесь ими с нами.

Ответить
0

Почему у вас стоимость работы зависит от количества экранов? Что если будет сложная логика работы приложения? Например, логика работы страницы приложения стоит в 3 раза больше верстки? Выходит что вы написали про MVP каких-то типовых проектов?

Как себя поведет webview если нужно загрузить и проскролить список из 10 000+ элементов? Что будет с плавностью и отзывчивостью?

Почему вы считаете что html верстка быстрее нативной и/или других кроссплатформенных технологий? Может быть html верстальщики просто дешевле или в команде не было нативщиков?

В одном из комментариев вы написали: "Кордову, ионик и подобные компилируемые фреймворки забрили из-за двух факторов: 1. При обновлении приложения его нужно переопубликовывать".

Работает ли такой подход на iOS? Если да, то что вы будете делать, когда apple прикроет такую возможность?

Ответить
0

Вячеслав, попробую ответить на всю массу Ваших вопросов:

1. Стоимость привязана к количеству экранов по принципу среднего арифметического. Практически в любом проекте примерно 20% сложных экранов, 40% средних и 40% простых. Конечно, есть риск просчитаться, но он сопоставим с ошибкой в сроках при почасовой оценке, а для сейлзов так проще и для клиентов понятнее.

2. Нет, мы не делали типовых MVP. Это как-то даже звучит абсурдно, т.к. MVP - это как раз ключевая бизнес-функция, которой проект будет отличаться от конкурентов.

3. Если есть огромная куча элементов, которую нужно проскроллить, то используется либо lazy load, либо, в крайнем случае, пагинация. Если уж совсем беда из-за плохой скорости передачи данных, то можно воспользоваться

4. По поводу скорости html-вёрстки. Возможно, в статье не совсем корректно выразился. Речь не о скорости загрузки, а о скорости разработки. То есть сделав 1 webview-экран мы его по факту реализовали и в iOS, и в Android и в веб-версии. По скорости загрузки передавать сгенерированный экран, либо данные, например, в JSON, при текущих реалиях 3-4G разницы нет. Можете скачать из сторов нашу демку для запуска маркетплейсов "Сервис поиска исполнителей", посмотрите как всё грузится.

5. Да, подход работает и в iOS. Для сторов, формально, это передача контента (свайп-меню, верхняя плашка, GPS и т.д. у нас нативные). То есть, если выражаться Вашими словами, то Apple должен прикрыть передачу данных между приложением и сервером в принципе, а этого никогда не будет. В год мы публикуем 40-50 приложений в сторы, при модерации подобных вопросов с саппортом не возникает, хотя, саппорт Apple на порядок суровее, чем Гугловский.

Ответить
0

В 3 пункт не вставилось название - можно воспользоваться Crosswalk

Ответить
0

Стартапам не нужен дизайн... Странное, на мой взгляд, утверждение.
Ни слова про UX-тестирование, только утверждение у клиента. Очень странно.
Я примерно представляю, что именно получается в итоге - если это какие-то очень прикладные приложения под конкретного человека, то здорово 😃

Ответить
0

Стартапу как раз вредит UX-тестирование и прочие заморочки на этапе MVP. MVP - это как раз о том, что делаешь ключевую бизнес-функцию как получилось, главное супер быстро, а затем итеративно её улучшаешь в формате agile и lean startup. Не вопрос, когда-то продукт придёт и к UX-тестированию. Но это не первичная и даже не вторичная задача на старте. В принципе, моя позиция совпадает вот с этой притчей - https://bash.im/quote/420672

Ответить
0

Ясно, спасибо! :) А я вот сторонник теории, что первое впечатление два раза не создашь ;)

Ответить
0

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

Ответить
0

Ясно, спасибо ;)
Единственное - MVP применяется во многих случаях, и абсолютно не обязательно на малой аудитории.
🤓

Ответить
0

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

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Хакеры смогли обойти двухфакторную
авторизацию с помощью уговоров
Подписаться на push-уведомления
{ "page_type": "default" }