Для любого бизнеса важно время, которое проходит от момента получения предложения (в нашем случае ссылка для пользователя) до момента, когда пользователь сможет полноценно пользоваться продуктом (что-то купить, продать, посмотреть).
Сейчас чтобы начать пользоваться хауспати надо пройти несколько шагов. Есть демо-видео https://streamlayer.myjetbrains.com/youtrack/api/files/7-1874?sign=MTU5MjUyNDgwMDAwMHwxLTEyfDctMTg3NHxqZ0JwenU4WDJWRm9IQ3hNZHUwNk1nZ0k0U2RfbXVZ%0D%0AMnZaeG41VkNHc25FDQo%0D%0A&updated=1584726865257
Оно ускорено в 2 раза примерно и длится полторы минуты. То есть можно считать, что пользователю в среднем надо больше трех минут, с момента получения ссылки. Притом мы проходим через 22 действия (возможно, что-то я еще упустил, т.к. считал по видео).
Требуется не больше 30 секунд для начала использования всех функций. Регистрация из шести шагов (два из которых - обыкновенные экраны онбординга с одной кнопкой)
Нам надо сделать так, чтобы один пользователь мог пригласить другого и как-то ему об этом сообщить.
Пользователь получает ссылку через смс, мессенджер или email. Он точно знает кто ему прислал ссылку и переходит по ней. Далее пользователь регистрируется, потом он видит, что его кто-то пригласил. Но для чего это, когда пользователь уже и так знает откуда он прошел по ссылке и кто именно его пригласил?
Для достижения такого функционала они используют install attribution через третий сервис. Потом ищет друзей через связь своего номера телефона и контактной книги (а еще там есть фейсбук)
Пользователь получает ссылку. Регистрируется и в конце регистрации он видит экран, что его кто-то пригласил. Туда можно еще добавить кнопку "Say Hi" и далее он может пользоваться приложением полноценно.
Для достижения такого функционала нам не нужна аттрибуция, а серверное апи на 90% уже есть.
- зависимость от внешнего сервиса
- дополнительная сложность
- дополнительная поддержка
- дополнительная абстракция (надо сразу сделать решение независимым от конкретного сервиса аттрибуции)
- дополнительное тестирование (как это сделать в сервисе мы пока не знаем точно)
- допзатраты денег
- в branch.io я не нашел апи, которое позволит приложению определить, кто именно сделал приглашение. Возможно, эту информацию можно "зашить" в свойства диплинка.
- возможность в будущем, что сервис депрекейтнут
- возможность в будущем, что аттрибуцию запретят производители
- я не нашел, что дают гарантию 100% аттрибуции (ее и в принципе невозможно дать).
- что если хостапп уже использует другой сервис аттрибуции?
- куда нам вшивать библиотеку сервиса: просить сделать это хостапп или к нам в StreamLayerVendor. Потом ее надо будет поддерживать.
- я не нашел, что дают гарантию 100% аттрибуции (ее и в принципе невозможно дать).
- все "крутится" у нас
- все менеджерим мы
- сервер на 90% готов
- мобилкам интегрироваться легко (реализовать 2 метода, поддержку диплинков и 1 доп. экран с приветствием)
- все достаточно просто тестировать
- Пользователь1 видит ссылку от Пользователя2
- Проходит по ней
- Инсталлит приложение, либо открывает уже установленное на экране онбординга авторизации. Он еще помнит, зачем вообще открыл приложение (см. п. 1)
- Проходит простейшую регистрацию
- Видит приветственный экран, что у него получилось сконнектиться с Пользователь 2.
- Пользуется приложением.
Если Пользователь1 увидит экран всего лишь один раз на 10 (даже меньше) секунд, то стоит ли тратить силы, чтобы его показать сразу после шага 3? Когда у пользователя еще свежО воспоминание, от какого пользователя он прошел по ссылке.
- Нам надо показать всего лишь один дополнительный экран в нашем флоу авторизации (из шести).
- Для показа этого экрана До авторизации нам надо затратить много сил и времени (посчитайте в деньгах и нереализованных других фичах и исправленных багах)
- Для показа этого экрана После авторизации у нас уже все есть, надо только все это использовать.
А так же при использовании 3rd party решения
При использовании чистого решения StreamLayer