Connect with us

Статьи

Пятый набор Акселератора ФРИИ: самое интересное

Фонд Развития Интернет Инициатив в следующий вторник, 28 апреля, организует DEMOday, выпускной вечер, на котором будут представлены стартапы из пятого выпуска акселератора — 28 проектов из сфер логистики, рекламы, СМИ, гаджетов и других направлений.

Наталья Маркова

Опубликовано

/

     
     

Фонд Развития Интернет Инициатив в следующий вторник, 28 апреля, организует DEMOday, выпускной вечер, на котором будут представлены стартапы из пятого выпуска акселератора — 28 проектов из сфер логистики, рекламы, СМИ, гаджетов и других направлений.

Участники получили 800 тысяч рублей инвестиций и услуги акселерации, эквивалентные сумме в 600 тысяч рублей за 7% долю в проекте. За три месяца участники должны были сформировать и проверить бизнес-модель своего проекта — успешно закончившие программу акселератора могут претендовать на получение инвестиций в размере до 14.5 млн рублей.

Мы отобрали самые интересные проекты пятого выпуска акселератора ФРИИ и предлагаем их вашему вниманию.

Appfollow

1-d4TG9WrqR87me_2pnU8Suw

Сервис для мониторинга отзывов в App Store, Google Play, Windows Store. Сервис так же предлагает конкурентный анализ приложений — и он интегрирован со Slack и Trello.

DriverPack Solution

Менеджер установки драйверов, предназначенный для автоматизации работы с драйверами на платформе Windows ОС. База данных представляет собой набор пакетов драйверов, которые организованы по категориям. Ключевой особенностью программы является возможность работы без подключения к Интернету, что обеспечивается наличием собственной offline-базы драйверов.

HappyCart

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

1024x500-ShoppingCart

Promarket

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

Robolanding

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

TESLAWATCH T-Band

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

TESLAWATCH (устаревшее)
TESLAWATCH (устаревшее)
Разработчик: TESLAWATCH
Цена: Free
Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
3 комментария

3 Comments

  1. Vitaliy Ampilogov

    23.04.2015 at 00:16

    Драйвер пак это конечно сильно) Туда можно добавить работу по подписке – не продлил подписку и устройство отключается

  2. Антон Злобин

    07.05.2015 at 15:23

    Хлам.

You must be logged in to post a comment Login

Leave a Reply

Разработка

Интересные материалы для разработчика мобильных приложений #234 (5-11 ноября)

В нашей новой подборке новости с Android Dev Summit, Continuous integration в Яндексе, тотальная интеграция в Google и интересное руководство по жизненному циклу пользователей. Заходите!

AppTractor

Опубликовано

/

Автор:

Гнущиеся смартфоны и другая информация с Android Dev Summit

Сейчас Google проводит Android Dev Summit, и уже состоялся открывающий кейноут. В основном рассказанное там предназначается Android-разработчикам, но есть и новость, способная заинтересовать более широкие массы: «сгибающиеся смартфоны». Внимательно посмотрев онлайн-трансляцию, мы написали и о поддержке таких устройств, и о другой информации из кейноута.

Руководство по разработке Web-приложений на React Native

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

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 AI, Устройства, IoT

 Вакансии

Комментарии
Продолжить чтение

Маркетинг и монетизация

«Мои игры никто не покупает»: пара простых советов

Компания Inlingo перевела для нас интересный пост Reddit, объясняющий успех тех или иных игр.

AppTractor

Опубликовано

/

Автор:

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

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

Собственно, вот эти игры:

Pillar

The Path of Motus

Я испытываю смешанные чувства, когда выставляю кого-то на всеобщее обозрение, но! Во-первых, без контекста было бы непонятно. Во-вторых, это намного более сильные работы чем то, что мне присылают обычно, так что подробным разбором полетов я никого не опозорю.

Всю суть авторского вопроса передает следующая цитата:

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

А вот мой ответ:

Прежде всего — я посмотрел трейлер к Pillar и это полный крышеснос.   Очень тягучая, жуткая атмосфера, немного похоже на «I Have No Mouth and I Must Scream».

Далее: вот мой пост на Reddit, очень рекомендую с ним ознакомиться – “Я не зарабатывал деньги до 14 игры“.

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

Если честно — я понимаю, почему ваши игры плохо продаются. Не то чтобы я мог конкретно сказать, что не так… Подача будто бы любительщиной отдает.  Может, вы просто переоцениваете свои навыки как аниматора — игры будто бы изо всех сил кричат, что их делал профи, что они выглядит как Braid. Это не так. А вот та же Castle Doctrine со своим лоу-фай исполнением даже не пытается конкурировать с Braid, так что никому и в голову не придет их сравнивать.

One Hour One Life еще слишком свежа в моей памяти, я необъективен (и да, она выглядит ОФИГЕННО), но люди обычно описывают визуалку в ней как «милую». Почему-то всем нравятся простая мультяшная визуалка, она обезоруживает. Это даже не пиксельная графика, это что-то типа… что-то типа каракулей. Каракулей от руки. Это была моя первая пиксельная игра за добрых десять лет, но я все равно умудрился попасть в яблочко.

Все, с визуальной частью вроде закончили. The Pillar мне нравится больше, на самом деле. Анимации движения странные, но к ним можно привыкнуть.

Далее: что за фигня в игре творится?

Инновации в играх должны быть МАКСИМАЛЬНО ОЧЕВИДНЫ. Человек смотрит трейлер и сразу понимает: так, а в такое я еще ни разу не играл.

Давайте посмотрим на трейлер The Castle Doctrine или One Hour One Life. Человек смотрит и видит, что это, как в это играть (почти как обучение!) и насколько это непохоже на все остальные игры.

Это еще один звоночек, на который нужно обратить внимание: достаточно ли сам игровой процесс цепляет? Стоит ли его вообще включать в трейлер?

Тут надо будет придумывать охранную систему и пытаться пробраться через охранные системы других игроков.

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

Эти концепты сразу заинтриговывали всех, кому бы я их ни рассказывал. Даже не-геймеров.

Иногда я просто сижу и жду, пока меня не осенит. Чтобы так «Ох ты!». Что-то настолько очевидное, что я срываюсь гуглить: а вдруг такую игру уже делали? Концепт, до которого мог бы додуматься абсолютно любой.

Я навскидку могу назвать 5 своих друзей, которые работали над играми, похожими на The Castle Doctrine. Я нервничал, это была почти что гонка. А потом я увидел кино «Судная ночь» (The Purge), она тоже примерно про это же.

В общем: хороший концепт легко ложится в трейлер и легко цепляет игрока.

И последнее: ценность.

Люди обычно решают потратить деньги на игру по одной из двух причин.

  1. Они в таком восторге, что покупают игру сразу, не раздумывая. Это часто связано с нереально крутым визуальным исполнением, как в The Last Night. Люди просто сделают ЗАТКНИСЬ И БЕРИ ДЕНЬГИ, так что игра окупится в любом случае. Сюда же относится Hyper Light Drifter. Такие проекты выстреливают сразу же. Это как левитроны — все хотят, чтобы у них над столом парила какая-нибудь ерунда.
  2. Они долго и вдумчиво взвешивают все pro et contra, их надо завлекать холодными цифрами. Их надо завлекать тем, что игра глубокая, что в нее можно играть неделю, месяц, год. Они обойдут ее, покивают себе, помнут игру между пальцами — да, это стоит двадцать баксов. Для них игра — она как рюкзак. Возьмешь что попало и обязательно прогадаешь, тут надо посмотреть, повыбирать, чтобы одну — и на всю жизнь (да, прямо как жену).

Однопользовательские игры обычно полагаются на вау-эффект, исключений немного и обычно мы говорим либо о бесконечных тайкунах (Stardew Valley, Factorio, Subnautica), либо о зубодробительных рогаликах (Spelunky, Nuclear Throne). В любом случае, мы говорим о глубоком погружении и хорошей реиграбельности.

И именно поэтому, к сожалению, однопользовательские игры понемногу вымирают, успех Braid или Fez повторяют единицы, да и те играют на эмоциях (см. п. 1). Зато провалившихся игр с внушительным бюджетом — пруд пруди, хотя лет пять назад все они прекрасно окупились бы. И это я даже не говорю о том, что успех Braid или Gone Home нельзя сравнить с успехом Stardew Valley или Factorio, это принципиально разные уровни.

Я не считаю, что инди-игры обречены, я просто считаю, что люди стали играть в разные жанры инди-игр. Старички в шоке от того, что короткие однопользовательские игры стали плохо продаваться, новички в шоке от того же (потому что почти любая первая игра короткая и однопользовательская), но это не означает, что инди в принципе не продаются. Наоборот!

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

И именно поэтому лучше полагаться на второй тип игроков.

Уже 11 месяцев множество людей каждый день играет в The Castle Doctrine. За семь месяцев много кто наиграл в One Hour One Life по 900 часов. Если игра сможет удерживать внимание долгое время — на это и нужно полагаться.

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

Проще всего реализовать это через мультиплеер. Да, конечно, есть варианты и для однопользовательских проектов. Просто моя первая хитовая игра (15-я по счету, Sleep is Death) была многопользовательской…

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

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

Комментарии
Продолжить чтение

Статьи

Тестирование не (только) поиск багов

О тестировщиках и обезьянах рассуждает руководитель QA компании Redmadrobot Марина Куликова.

Redmadrobot

Опубликовано

/

Автор:

Почему-то принято считать, что тестирование — самая простая точка входа в мир IT. За годы работы в разных компаниях, странах и ролях — от тестировщика до Head of QA Redmadrobot — я успела на себе испытать разные подходы и наступить на разнообразные грабли. В этой статье постараюсь ответить на самые популярные вопросы и помочь начинающим QA-инженерам сориентироваться в том, что их ждет.

Открыть и потыкать

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

В итоге у менеджеров, дизайнеров и разработчиков возникают вопросы: почему это тестирование лезет в продукт, код и дизайн? их задача проверять все возможные комбинации кнопок! Конечно, и это тоже. Но с тыканьем на кнопки справляются и приложения, например, MonkeyRunner для Android.

А кто будет тестировать зашитую логику, бекенд, краевые сценарии и остальное?

В теории в обязанности тестировщика входит

  • составление тест-дизайна, тест-кейсов, стратегии тестирования
  • репорт и проверка багов
  • проверка и создание документов (артефактов) тестирования
  • проверка безопасности
  • рекомендации о выпуске сборки (продукта) — да-да, во всех утопичных постулатах прописано, что только QA/QC может дать добро на выпуск продукта.

О том, что разработка тест-дизайна и тест-кейсов не так проста, в большинстве компаний хотя бы догадываются, привлекая к этому и написанию кейсов для тест-дизайна QA Team Lead’ов или Senior QA. Или даже создают для этого отдельную роль — TC Designer (writer). Разнообразные стратегии проверки краевых значений, тестирование интерфейсов, нагрузочное и другие кейсы пишут Senior инженеры.

Само тестирование выполняют рядовые тестировщики — люди, в лучшем случае обладающие навыками пользователя компьютером и каким-то продуктом. Хотя некоторые сценарии и запуск SQL-скриптов, работа со сторонними tools доступны не каждому опытному пользователю. И бизнес считает нормальным содержать 20-30 таких специалистов-обезьянок, называя их тестировщиками.

Как можно догадаться (на самом деле можно!), это неправильно. Как с точки зрения бизнеса, так и по отношению к специалистам. Инженеры QA/QC могут принести куда больше пользы, если им доверять и вкладываться в их развитие.

Как минимум, всей команде не придется тратить время на изначально нежизнеспособные дизайн и бизнес-концепции — хороший QA/QC может выявить подобные кейсы еще на этапе разработки.

Чтение кода

Чтобы быть по-настоящему полезным специалистом, тестировщик должен уметь читать код хотя бы на интуитивном уровне, понимать логику разработчиков и мыслить не только алгоритмами, но и процессами. В идеале еще и быстро адаптироваться к новым языкам и программам/средам.

Да, в идеальном мире процесс должен исполняться по модели чёрного ящика, но если сервис работает медленно, хоть и верно — может, стоит оптимизировать код? Или, к примеру, нужно спроектировать негативный сценарий — для подготовки такого теста может понадобиться что-то дописать в коде или подложить программе нужные данные. И да, это задача QA/QC-специалистов — вы же хотите, чтобы после прохождения тестирования у вас был качественный продукт?

Тестировщик должен не бояться заглядывать в код и помогать разработчику разбираться с проблемами. Ревью кода, дебаггинг и юнит-тестирование — не прерогатива разработчиков. Мы не ставим под сомнение их компетенции, но обеспечение качества — ответственность всей команды. Тестировщики же должны напоминать об этом и нести бремя контроля. QA — Quality Assurance — обеспечение качества, QC — quality control — контроль качества. Об этом полезно напоминать тем, кто не чувствует разницы.

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

Безудержная автоматизация

Знать код не значит безудержно все подряд автоматизировать.

Почему-то считается, что тестировщики делятся на автоматизаторов и ручных (мануальных). И большинство ручных мечтает стать автоматерами.

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

Целесообразность автоматизации сильно зависит от специфики проекта: сроков, поддержки, повторяемости, стабильности и других параметров.

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

Если нужно проверить, что продукт точно взлетит, к обязательному набору можно добавить бета-тестирование. И, конечно, нужно грамотно проводить приемочное тестирование (acceptance).

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

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

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

Цели тестировщика в отношении продукта наиболее близки к целям бизнеса и стратегической цели компании. В то же время внутри компании это роль исследователя.

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

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

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

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

В идеале управление качеством (QA) и тестирование это две разные сущности. Ну, а о процессах и разнице между QA и QC уже в другом тексте!

Комментарии
Продолжить чтение

Аналитика пользователей

Жизненный цикл пользователя: руководство профессионалов

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

AppTractor

Опубликовано

/

Автор:

В среднем по рынку, единожды пользуется приложением 80% установивших его  пользователей. А на седьмой день сохраняется лишь 12% аудитории, которую вы смогли привлечь. Но значит ли это, что все ушедшие потеряны навсегда? Совсем нет — многие ушедшие могут вернуться в ваше приложение через месяц или даже через год.

Ушедшие… и вернувшиеся

Мы привыкли, что возвраты считаются на горизонте одного месяца, однако, если посмотреть на действиях пользователей за год, то можно узнать много нового и интересного. Так, по подсчетам Adjust, в среднем 11% ушедших пользователей возвращается в приложение после трехмесячной паузы, а после двух месяцев — 17%. Даже отсутствующие шесть месяцев могут вернуться — их доля достигает 4%.

Количество “вернувшихся ушедших”, конечно, зависит от категории. Так, в “Играх”, “Утилитах” и eCommerce приложениях их, обычно, больше среднего. А в категориях “Социальные сети”, “Стиль жизни”, “Путешествия”, “Развлечения” и “Бизнес” — меньше.

Например, если в eCommerce-приложения после трехмесячного отсутствия возвращается 18% пользователей, то для “Бизнеса” это всего около 2%.

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

Например, ваше приложение получает 2,000 новых установок каждый день и в среднем 26% это платные рекламные кампании. На четвертый месяц около 60 “платных” пользователей будут как раз те, кто отвалился в начале, но через три месяца снова открыл приложение. Но вместо того, чтобы учесть таких людей как вернувшихся, их припишут к новым установкам и потребуют за них оплату. Если взять среднюю цену установки в $2.26, то вы потеряете на неправильной атрибуции 150 долларов. В день. За месяц это уже 4,500 долларов.

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

Удаление приложений

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

Adjust Lifecycle Tracking определяет средний “срок жизни” приложения на устройстве в 6 дней для органической установки и в 5 с половиной дней для платной.

Как и в случае с возвратами, все также сильно зависит от категории. Тут на разных концах спектра развлекательные приложения с менее чем одним днем и eCommerce приложения, которые, в среднем, удаляют через 11 дней:

А что с повторными установками? По данным Adjust, в среднем 40% пользователей, удаливших приложение, установят его заново!

Повторные установки в реальной жизни

В руководстве Adjust рассматривается несколько кейсов, один из которых касается приложения для путешествий.

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

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

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

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

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

Отслеживание жизненного цикла на практике: пример Viber

Моши Блюм, глава приобретения пользователей в Viber:

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

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

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

Мы также используем показатель удалений в качестве обратной связи для наших CRM-кампаний. Учет отрицательной обратной связи, связанной с uninstall-ами, позволяет нам точно и правильно рассчитать влияние наших коммуникаций на  существующую базу пользователей. Это касается тонкой настройки количества отправленных обновлений, качество маркетинговых сообщений, а также навязчивости различных вариантов связи.

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

Жизненный цикл — это процесс

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

Подробнее обо всех тонкостях жизненного цикла – в новом руководстве Adjust.

Комментарии
Продолжить чтение

Реклама

Наша рассылка

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

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.