Памятка новичку в разработке мобильных приложений24.06.2016 16:08

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

1. Как лучше разрабатывать — нативно или кроссплатформу?
2. Что выпустить первым — Android или iOS?
3. Можно ли как-то протестировать приложение перед релизом на живых пользователях?
4. Стоит ли открыть игру сразу на весь мир или только в одной стране?
5. Как привлечь в свое приложение пользователей, если бюджет на это ограничен или его вообще нет?
6. Как вообще узнать, хороши или плохи показатели моего приложения? Как узнать, если в нем есть проблемы и проблемные места?
7. Как часто стоит обновлять приложение?
8. Можно ли посмотреть, откуда приходят пользователи?
9. Стоит ли встроить в приложение рекламу или это отпугнет пользователей?
10. Что вообще встроить в приложение, чтобы не упустить чего-то важного?

Три года назад у меня тоже не было ответов на эти вопросы, зато они есть сейчас. Ещё три-четыре года назад мобильная индустрия вообще была в зачаточном состоянии, и половины важных и нужных инструментов просто не существовало. Зато сейчас у нас с вами есть почти всё, о чем можно мечтать. Главное — знать, куда смотреть и где искать. Меня удивляет, что в сети до сих пор нет ни одной грамотной и полезной информации для новичков. Хотя, возможно, я их просто не встречал.

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

Итак, вы разрабатываете мобильное приложение или даже только начинаете его проектировать. Первый и, наверное, самый спорный вопрос — на чем его делать? Должно ли это быть нативное приложение или имеет смысл посмотреть в сторону кроссплатформенных решений?

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

Для чего нам нужна кроссплатформенность? Она позволяет экономить на времени и ресурсах (иногда в два-три раза), свести разделенный на два отдельных процесса (и две команды) проект к одному. Это преимущество, которое нельзя переоценить. На мой взгляд, двойная экономия ресурсов — аргумент, перевесить который может только комбинация нескольких негативных факторов, и вы уверены, что вам их не избежать.

Кроссплатформенные движки сейчас вышли на очень хороший уровень, обзавелась массой облегчающих инструментов. Поэтому, что бы вы ни делали, что бы ни проектировали, изучите сначала вопрос кроссплатформенной разработки. Должны быть очень сильные аргументы, чтобы от неё отказаться. Я много общаюсь с разработчиками, которые делают приложения на заказ, и все они хором кричат «Не делайте кроссплатформу!». Но тут есть нюанс: нативная разработка (отдельно iOS и Android) в два раза увеличивает сроки и ресурсы.

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

«Сниженная производительность»

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

«Более отзывчивый интерфейс, высокая скорость работы»

Этот аргумент тоже не должен вас ввести в заблуждение. Уточняйте, докапывайтесь. Что значит «более отзывчивый»? Насколько выше скорость? Да, кроссплатформа подразумевает дополнительную программную прослойку, которая требует дополнительных ресурсов.

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

Да, в России огромный парк слабых устройств на Android (порядка 40% от всех смартфонов), и это, пожалуй, самый большой минус кроссплатформы. И тут вам нужно определиться: вы хотите охватить всех? Даже самых малообеспеченных со слабыми устройствами? Тогда это аргумент не в пользу кроссплатформенного решения. А вообще, идите на сайт движка, там всегда огромное количество примеров, ищите что-нибудь близкое, скачивайте, запускайте на слабом устройстве и смотрите сами. Тормозит? Сильно?

«Кроссплатформа будет очень дорога в обслуживании»

Это второй наиболее распространенный аргумент, и он меня всегда ставит в тупик. Каким образом сокращение ресурсов в два раза удорожает поддержку проекта? Задайте этот вопрос. Есть, конечно, нюанс: сложнее найти специалиста, иногда бывают сложности с плагинами и библиотеками, но неужели это плюс 70−100% ко времени? Задавайте конкретные вопросы: что конкретно удорожит обслуживание?

«Будут большие проблемы с плагинами, библиотеками и SDK»

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

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

Иногда приложение требует нативных интерфейсов, а они на iOS и Android разные. Если у вас именно такое приложение или вы влюблены в material design (как я), то да, кроссплатформа вам не подойдет.

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

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

Что выпустить первым — iOS или Android

Ещё год назад я бы сказал, что iOS. Просто в силу более понятной структуры и меньшего парка устройств, а это экономия на тестировании и времени. Но сейчас я точно отвечу, что Android. Google за последнее время добавила просто массу незаменимых инструментов в консоль разработчика, которых нет ни в iTunes Connect (консоль разработчика от Apple), ни где-либо ещё.

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

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

И таких сомнительных моментов там много. Есть ещё кто-нибудь, кого раздражает стоящая по-умолчанию галочка «для доступа ко всем функциям приложения нужен специальный аккаунт»?

Зато в Google Developer Console сейчас есть почти всё для того, чтобы тестировать, проводить эксперименты и повышать эффективность мобильного приложения.

Инструмент «Эксперименты»

Мой любимый инструмент. Позволяет проводить А/В-тесты маркетинговых материалов. То есть вы можете сделать несколько разных наборов скриншотов, баннеров, описаний, иконок и так далее и смотреть, какой набор работает эффективнее, а потом выбрать именно его. Инструмент не без вопросов, но это лучшее и единственное бесплатное для разработчика на решение на рынке.

Если вы всё-таки стартовали с iOS, то вам поможет Splitmetriсs. Один эксперимент вам дадут сделать бесплатно, потом — $250 в месяц. По-моему, нещадно.

Альфа-тестирование

Добавляете почтовый ящик в тестеров, консоль генерит тестовую ссылку, по которой можно скачать тестовую версию игры. Нетривиально, будьте осторожны. Работает, только если на устройстве вы используете браузер Chrome, а не старый Internet.

В iTunes Connect есть аналог — Testflight. Работает почти так же, только для завершения процесса регистрации использует исключительно Safari (будьте внимательны: если вы прямо из почтового приложения перейдете по ссылке, то увидите ошибку; вы должны открыть её на устройстве в Safari). Чтобы скачать тестовую версию на устройство, придется скачать одноименное приложение из App Store. В своё время я убил пару дней, пытаясь разобраться, как работает эта монструозная связка.

Бета-тестирование

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

Информация по конверсии из просмотра в скачивание

Это есть и у Apple. Позволит понять, всё ли хорошо со скриншотами, описанием, иконкой и так далее. Забегая вперёд, скажу, что средняя конверсия — 10%, для игр часто меньше. Известный мне максимум — 65%.

Если конверсия низкая, меняйте по очереди весь маркетинг, делайте А/В-тесты, упирайтесь до последнего. Это ключевой показатель для успешности вашего проекта. Ничего важнее просто нет (кроме показателя удержания пользователей или retention).

Быстрое одобрение

Занимает не более шести часов. В Apple недавно наконец-то сократили время рассмотрения приложения до двух дней. Аллилуйя! Есть непроверенное ощущение: если вы выйдете в пятницу или четверг, то есть шанс, что это время сократится до нескольких часов. У меня пару раз игра выходила через два часа после выливки. Раньше даже expedited review не давало такого результата.

Статистика по крашам и неожиданным закрытиям приложения (ANR)

Не работает на кроссплатформе, к сожалению, но в остальном бывает полезна. Только смотрите их не через «Сбои и ANR», а через следующий путь: «Статистика» > «Сбои за день» > «Подробности сбоев». Не знаю почему, но именно этот путь открывает нужные подробности, которые можно использовать. Кстати, в Google Analytics с полгода назад тоже добавили сбои. Они там подробные и работают даже на iOS.

Возможность отвечать на комментарии к приложению

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

Весь маркетинг проходит процесс одобрения только при выливке нового билда

Если вы меняете только маркетинг (описание, скрины и прочее), то новые появятся в Google Play уже через час-два и автоматически. Это иногда критично на первых стадиях, когда именно маркетинг будет основным объектом ваших экспериментов и изменений, а собирать новый билд каждые два дня у вас нет возможности.

У Apple вы можете без нового билда обновить только описание. Всё остальное — только с новой версией приложения. Единственный плюс — вы можете свободно менять маркетинг, пока приложение ждет ревью, но и тут есть подстава: после отправки новой версию на ревью вы уже не сможете добавить локализацию.

Тестирование уведомлений

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

Отчет о тестировании

Это тестирование на живых устройствах, добавлено недавно). Обалденная штука. Запускается автоматически, как только вы выпустите альфа- или бета-версию. Запускаются скрипты, которые проводят основные операции типа запуска, пролистывания, набора текста. Бесплатно. Даже скриншоты вам покажут с протестированных устройств. Если захотите более полных тестов — добро пожаловать в Firebase Test Lab там же, но это уже платно.

В iTunes Connect либо нет этих инструментов, либо аналоги неудобны. Ну, или у меня не хватило сил, терпения и времени, как с Testflight, чтобы разобраться, как оно работает. Например, я вижу, что у меня 100 сбоев — конечно, хочу тут же их пофиксить, кликаю на цифру, а мне показывают график. Зачем он мне? Мне нужен лог сбоя, чтобы его оперативно исправить, но найти его так и не удалось. Возможно, более сообразительные коллеги помогут? Буду очень благодарен.

Поэтому если вы новичок или просто здравомыслящий человек, полагающий, что любой проект на старте — это тестовый образец, требующий анализа, улучшений и повышения эффективности всеми возможными способами, то только Google Play Developer Console (GPDC) даст вам почти все инструменты, чтобы довести приложение до ума.

Что нужно встроить в приложение

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

Статистика

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

Обе платформы с недавнего времени внимательно следят за показателями вовлеченности пользователей, и этот показатель напрямую влияет на то, как ваше приложение будет отображаться в поисковой выдаче. Если показатель вовлеченности (retention) у вас ниже, чем у конкурентов, вы будете проигрывать гонку в поисковой выдаче Google Play. У меня такое ощущение, что и App Store уже экспериментирует с этим. Поэтому статистика — ваше всё.

На рынке есть много решений: Flurry, Google Analytics, Amplitude. В каждом из них есть свои плюсы и минусы: Flurry данные собирает два дня, в Google Analytics не очень удобно работать с сегментами и строить воронки, нет User Path. Amplitude, хоть и самое удобное и мощное решение из этих трех, имеет очень ограниченный бесплатный пакет событий.

Я использую одновременно Flurry и Google Analytics: они показывают картинку по-разному, и иногда её нужно дополнить второй статистикой, чтобы увидеть ее целиком. Ваша задача на первом этапе — видеть каждый шаг вашего пользователя. Особенно важна первая сессия: именно она либо приведет ко второй, либо не приведет. Заведите максимально подробные события, отслеживайте практически каждый клик, чтобы увидеть, где отваливаются ваши пользователи, на каком шаге, и что нужно исправить.

Атрибуция, она же трекинг

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

Не думайте, что вам это не пригодится. Если вы планируете успех, вам непременно нужно будет знать, откуда берутся самые качественные пользователи. И обязательно добавляйте в трекинг события (регистрация, достижение уровня, покупки) и целевые действия, чтобы видеть не только установки приложения, но и чуть больше. Это довольно обширная тема, для неё нужен отдельный материал.

Какие решения для трекинга у нас есть на рынке? Их много, я знаком с несколькими:

AppsFlyer — идеальное решение для новичка. Всё просто и понятно. Платите за установки приложения (5 центов), но, по моему личному опыту, счет вам не выставят, пока вы в месяц не натрекаете на $100. Миллион интеграций с разными рекламными источниками, даже есть Facebook, а он давно уже ни с кем не интегрируется.

Tune (раньше Mobile App Tracking и HasOffers) — сложное решение. Тормозной интерфейс (возможно, исправились, я уже год как не пробовал). Если вы не сталкивались, то вам будет очень сложно с этим работать. Зато очень подробная и детальная аналитика. На первых порах вам это не понадобится. К тому же дорого, берут деньги и за клики, и события.

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

Есть ещё Adjust (его очень любят западные коллеги), AdX (не знаком), а Mail.ru вот уже с полгода тянет с выпуском собственного трекера, ждем-с.

Обратная связь прямо из приложения

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

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

Поэтому сделайте большую кнопку «Обратная связь», запускайте почтовое приложение при нажатии или встройте SDK Zendesk — оно как раз для таких случаев. Не забудьте при этом в теме письма автоматически указывать название приложения, а в подписи тоже автоматом писать данные пользователя: операционную систему, устройство, страну, версию приложения, идентификатор пользователя (если таковой есть). Вам это точно потребуется для локализации проблемы. Zendesk это сделает для вас автоматически.

А/В-тесты

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

Если вы новичок, то просто послушайте моего совета: не ходите в Store без А/В-тестов гулять. Реализуется элементарно, польза неоценима. Я это делаю с помощью конфигурационных файлов.

Допустим, в вашем приложении используется регистрация. Вы хотите, чтобы пользователь создал профиль, —, но боитесь, что это отпугнет много народа. Как только у вас в голове появляются такие дилеммы, тут же вспоминайте про А/В-тесты. Зачем гадать, если можно узнать точно?

Итак, чтобы всё измерить, мы создаем два-три разных конфигурационных файла (конфига).

1. Вызывает окно регистрации на старте
2. Вызывает окно регистрации после того, как пользователь вовлечен (прошел второй уровень или прочел две-три статьи, например).
3. Вообще не вызывает окно регистрации.

Ставите случайное распределение и раздаете на старте пользователям конфиги в случайном порядке, при этом шлете в статистику соответствующее событие (получен конфиг 1).

Я в дополнение к каждому событию в игре (пользовательские действия) прицепляю метку с номером конфига, чтобы уже точно можно было делать любые срезы. В Google Analytics такие метки называются Labels, а во Flurry — Parameters. Потом мы сможете создать сегменты по признаку А/В-группы (по событию получения определенной группы во Flurry или по признаку Лейбла в Google Analytics) и смотреть любые события в игре в разрезе этих групп.

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

Возможность поставить оценку приложению

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

Будьте осторожны: нельзя мотивировать пользователей поставить именно пять звезд, такое приложение не пройдет модерацию. Многие активируют такую возможность удаленно уже после релиза, но я бы так не рисковал: в Google сомнительные обзоры могут просто стереть, а в Apple могут и позвонить вам с разбирательством (у меня такое было). Лучше устройте А/В-тест и оставьте наиболее эффективный сценарий.

Статистика по падениям приложения

Головная боль. Почему-то до сих пор ни одна из консолей не предоставляет полного доступа к крашам приложения. Краш-репорты в iTunes Connect вообще куда-то делись, а в Google Play зачастую тоже недостаточно информации, какой из процессов вызвал падение, особенно если у вас кроссплатформа.

Что у нас есть? Знаменитая Crashlitics (теперь Fabric) недавно стала бесплатной, пробуйте обязательно. Краши есть во Flurry в разделе Technical (странно отсортированы и в большинстве случаев бесполезны), есть они и в Google Analytics (почему-то в разделе «Поведение») — появились недавно и на удивление информативны. Ну и в самой Google Developer console, конечно. Как их найти, я написал выше.

На краши в iTunes Connect не надейтесь: их мало (пользователь должен дать согласие на отсылку, а ему это не нужно), там ничего не понять, и в результате последнего изменения я вообще не могу найти, куда их запрятали.

Уведомления

Безумно важная штука для возврата пользователей в приложение (то самое retention). Продумайте расписание для локальных уведомлений (инициализируемых самим приложением на устройстве) не менее, чем на месяц. Без уведомлений ваши показатели по активности пользователей будут плачевными.

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

Форс-апдейт

Это такая штука, которая позволит вам не бояться ошибиться. Очень простая система, которая каждый раз при старте приложения стучится на ваш сервер и проверяет номер актуальной версии. Если версия устарела, показывается окно «Обновитесь». Будьте внимательны, на Android такие окна иногда можно отменить физической кнопкой «Назад», не позволяйте этого.

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

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

Шифрование

Поставил последним: это не обязательно, но тоже может уберечь от разных просчетов. Особенно это касается приложений с платежами. По статистике 90% платежей в России — взломы.

Если у вас не серверное приложение с приоритетом сервера, то лучше зашифровать основные данные. Хитрецы просто открывают приложение в памяти, ищут поиском совпадения (например, у него 121 золотая монета, он ищет поиском цифру 121 и меняет её на 100 миллионов), меняют и сохраняют. Хотя бы от этого можно уберечься. По-хорошему, нужна ещё и валидация платежей и прочее, но это уже очень специфическая задача.

***

Хотел ещё пройтись по темам, как стартовать, на что обратить внимание и как работать с трафиком, но сделаю отдельно, если вам будет интересно. А пока будем считать, что у кого-то теперь есть памятка, как подготовиться к релизу. Я бы в свое время убил за нечто подобное.

Присылайте собственные кейсы, в результате которых вам удалось заметно улучшить (или, наоборот, ухудшить) показатели проекта, на what@growthhacks.ru. Интересные эксперименты обязательно попадут на страницы рубрики Growth Hacks.