Отложенная глубокая привязка в iOS

Мы пытаемся реализовать отложенное глубокое связывание в одном из наших приложений для iOS, чтобы поощрять пользователей приглашать своих друзей использовать приложение и вознаграждать пользователей в зависимости от того, сколько установок произошло по их реферальной ссылке. В основном похож на продукт TapStream.

Рассмотрим этот пример:

Таким образом, UserA делится своей ссылкой "ourappURL.com/refer?id=userA" в любой сети, которую они хотят. Пользователь B щелкает по этой ссылке, после чего они переходят в Safari, а затем возвращаются на страницу App Store, где UserB загружает приложение.

Когда UserB открывает приложение, приложение проверяет, с какого идентификатора реферала они вошли (если есть). В этом примере идентификатором реферала будет "userA", поскольку это идентификатор, который был в реферальной ссылке. Затем приложение отправляет это на наши серверы, и мы награждаем UserA реферальным кредитом.

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

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

Ответ 1

Мы также попытались сделать это сами, и я попытаюсь сломать здесь различные шаги.

Возвращаясь к вашему примеру, вы правильно говорите о "запоминании" идентификации устройства и всех соответствующих данных "id = userA". Вы также правильно относитесь к "изолированной природе iOS", которая, как я полагаю, означает, что веб-странице не разрешено хранить информацию за пределами браузера (Safari), а приложения (ваше приложение) не могут получить доступ к информации, хранящейся в других приложениях (например, Сафари).

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

Следующая задача, которая остается самой большой проблемой, заключается в том, как однозначно идентифицировать это устройство из информации, собираемой из браузера? Javascripts в браузерах, в отличие от родных приложений, не имеют доступа к IDFA, которые могут использоваться для уникальной идентификации устройства iOS. Чтобы преодолеть это, можно предположить, что вы используете комбинацию общей информации, доступной как для браузера, так и для вашего родного приложения, то есть типа ОС, общедоступного IP-адреса, размера экрана и т.д. И т.д. Обратите внимание, что составной ключ из эти поля данных не гарантируют уникальность (представьте себе, что два iPhone 6 посещают эту веб-страницу через один и тот же маршрутизатор). Поэтому ваш сервер backend (при условии, что вы используете его для хранения этой пары ключ-значение), захочет иметь стратегию управления обработкой коллизий на ключах, то есть второй ключ удаляет первый ключ, или вы разрешаете коллизию существовать, имея очередь значений для одного ключа. Это действительно зависит от того, как вы на самом деле планируете использовать эту технологию.

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

Ниже приведено краткое описание шагов:

Пользователь 1 приглашает пользователя 2, отправив следующую ссылку на 2: example.com?inviter=1
Пользователь 2 посещает веб-страницу P
P создает и отправляет на ваш сервер следующую пару ключ-значение. S iOS | 55.55.55.55 | 750 × 1334 → inviter_id = 1
Пользователь 2 отправляется в магазин приложений и загружает ваше приложение A
Через 2 первых запуска A, A контакты S с одним и тем же ключом (при условии, что IP-адрес не изменился).
S находит значение inviter_id = 1, используя этот ключ, переданный и, допустим, вознаграждает пользователя 1 пять баллов за приглашение 2.

Надеюсь на эту помощь!

Изменить 04/24:

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

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

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

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

В ходе этих процессов мы работали с несколькими поставщиками: Appsflyer, Adjust, TapStream, и в итоге мы закончили работу с метками Branch https://branch.io.

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

Ответ 2

Здесь есть хорошее решение: http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/

Основной рабочий процесс:

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

Ответ 3

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

UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;

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

Ответ 4

Мой ответ ЗДЕСЬ

Apple больше не поддерживает Deep Links. Теперь он называется Universal Links и работает немного по-другому.

Источник

Теперь, когда Apple больше не поддерживает схемы URI для глубокой компоновки, разработчики должны внедрять Universal Links, чтобы правильно привязываться к iOS. Если вы уже используете схемы URI, ознакомьтесь с нашим блогом при переходе на Universal Links.

От: ЗДЕСЬ

И ЗДЕСЬ - это еще одна статья об универсальных ссылках и о том, что они собой представляют.