Appsflyer android sdk integration

Персонализация инвайтов в приложении с использованием AppsFlyer

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

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

Интеграция SDK и получение атрибуции

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

Первым делом интегрируем SDK в проект — в документации есть подробная инструкция.

После интеграции можно проверить, как приходит атрибуция после установки. Для этого добавим в метод onConversionDataSuccess простой лог.

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

Скорее всего после установки и запуска будет выведено «Attribution – empty». Для этого может быть несколько причин:

Неправильно настроен проект в AppsFlyer.

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

Ваше устройство не добавлено в тестовые.

Если всё сделано правильно, то от AppsFlyer придёт атрибуция, она выглядит примерно так (для наглядности я отфильтровал пустые значения через debbuger):

Пример атирибуции после установки

Примерно такие данные лежат внутри map. Тут много всего интересного, например, поле http_referrer показывает, откуда был переход по ссылке, а is_first_launch можно использовать для отслеживания первого запуска.

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

Кажется, что всё хорошо, но есть подводные камни.

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

Время, которое пройдёт от запуска приложения до вызова метода, может быть разным, особенно при первом запуске. На тестовых прогонах оно менялось от 2 до 15 секунд. Если код в методе не влияет на UI, то это не проблема, но если на основе атрибуции нужно собрать экран — всё становится хуже. Здесь нет хорошего решения, потому что каждое из них будет блокировать пользователя на некоторое время после запуска приложения, или оно сложно для реализации.

Итак, теперь мы умеем получать информацию об установке, отлично! Не забудьте порадовать аналитиков этими данными.

Сервис коротких ссылок

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

У AppsFlyer уже есть API для генерации таких ссылок, но не бесплатное. Не стоит опускать руки, если вы не готовы платить, в SDK для клиентов есть аналог. Его имя — LinkGenerator.

Теперь при переходе по короткой ссылке будет происходить редирект на сайт, потом в Google Play и, наконец, в приложение.

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

Во-первых, нужно добавить в манифест приложения соответствующий intent-filter.

Во-вторых, обработку ссылки в методе onAppOpenAttribution. Сюда придут все данные, которые были закрыты короткой ссылкой.

Так как требуется участие сервера, при получении данных тоже есть задержка, но в отличие от метода onConversionDataSuccess она не такая существенная.

Фича с приглашением новых пользователей

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

Проведя декомпозицию, получаем две подзадачи:

Создание и шаринг ссылок-приглашений.

Обработка ссылок-приглашений после установки.

Пойдём по порядку. Фактически всё, что нужно для создания ссылки-приглашения, у нас уже есть. Добавляем данные о пользователе, который шарит ссылку: его id, имя и аватар.

Готовая ссылка с текстом для шаринга выглядит так: Click this link to add Rick_Rick as friend in ABPV https://abpv.onelink.me/nWMv/344e6258, остаётся только передать её в шаринг.

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

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

Добавим в метод onConversionDataSuccess обработку ссылок-приглашений. От обычных ссылок их можно отличить по полю media_source, внутри него должно быть значение af_app_invites.

Дальше данные передаются в onInstallationAttributionSubject, стейт экрана приглашения меняется в зависимости от значения этого subject.

Итоговый экран приглашения

Заключение

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

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

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

Источник

Appsflyer android sdk integration

React Native AppsFlyer plugin for Android and iOS.

🛠 In order for us to provide optimal support, we would kindly ask you to submit any issues to support@appsflyer.com

When submitting an issue please specify your AppsFlyer sign-up (account) email , your app ID , production steps, logs, code snippets and any additional relevant information.

Table of content

From version 6.3.0 , we use xcframework for iOS platform, then you need to use cocoapods version >= 1.10

From version 6.2.30 , logCrossPromotionAndOpenStore api will register as af_cross_promotion instead of af_app_invites in your dashboard.
Click on a link that was generated using generateInviteLink api will be register as af_app_invites .

We have renamed the following APIs:

Old API	New API
trackEvent	logEvent
trackLocation	logLocation
stopTracking	stop
trackCrossPromotionImpression	logCrossPromotionImpression
trackAndOpenStore	logCrossPromotionAndOpenStore
setDeviceTrackingDisabled	anonymizeUser
AppsFlyerTracker	AppsFlyerLib

And removed the following ones:

• trackAppLaunch -> no longer needed. See new init guide
• sendDeepLinkData -> no longer needed. See new init guide
• enableUninstallTracking -> no longer needed. See new uninstall measurement guide

If you have used 1 of the removed APIs, please check the integration guide for the updated instructions

Production version from npm:

Источник

Android Manifest merge conflict (backup rules) #9

Comments

ljwan12 commented Jan 14, 2020

tools:replace specified at line:20 for attribute android:fullBackupContent, but no new value specified

The text was updated successfully, but these errors were encountered:

ljwan12 commented Jan 14, 2020

What went wrong: Execution failed for task ‘:android:processReleaseManifest’.

Manifest merger failed : Attribute application@fullBackupContent value=(@xml/vungle_backup_rule) from [com.vungle:publisher-sdk-android:6.4.11] AndroidManifest.xml:19:9-60
is also present at [com.appsflyer:af-android-sdk:4.11.0] AndroidManifest.xml:14:18-73 value=(@xml/appsflyer_backup_rules).
Suggestion: add ‘tools:replace=»android:fullBackupContent»‘ to element at AndroidManifest.xml:19:5-95:19 to override.

elitvynov commented Apr 23, 2020

• What went wrong:
  Execution failed for task ‘:android:processReleaseManifest’.

Manifest merger failed : Attribute application@fullBackupContent value=(@xml/vungle_backup_rule) from [com.vungle:publisher-sdk-android:6.4.11] AndroidManifest.xml:19:9-60
is also present at [com.appsflyer:af-android-sdk:4.11.0] AndroidManifest.xml:14:18-73 value=(@xml/appsflyer_backup_rules).
Suggestion: add ‘tools:replace=»android:fullBackupContent»‘ to element at AndroidManifest.xml:19:5-95:19 to override.

Did you find any solution? I have this problem too

elitvynov commented Apr 28, 2020

This is working, thank you

syrakozz commented May 3, 2020

but it takes forever while building

Cotel commented May 8, 2020

I’m having a similar issue 😢

In the main manifest allowBackup is set to false. The task is failing for a dynamic module.

ManakaMichihito commented May 14, 2020

I have the same problem.

fullBackupContent is not only used by AppsFlyer.
There is also a library that dynamically sets fullBackupContent just like AppsFlyer.
We cannot always do a manual merge.

lfg-ryan commented May 14, 2020

I have the same problem. Vungle is also using this and I can’t tell how to merge them in Unity when all of this is auto-generated stuff.

ManakaMichihito commented May 21, 2020

AppsFlyer support only answers manual merges, no matter how many times we explain it, it doesn’t fix the issue.

ManakaMichihito commented May 22, 2020 •

They don’t seem to present anything other than manually merging AndroidManifext.xml.
The answer was an inquiry to Unity technologies.

tools: replace = «android: fullBackupContent»
If there is a person to go and solve

Is required:
android:fullBackupContent=»true»
&
AppsFlyer’s FullBackup rules
(XML : full-backup-content tag)

They said:
«We have to do this in order to do the attribution and tracking accurately, if not, the reinstall will always retrieve the old install data which should be deleted.»

VladimirKuzmin-azur commented Jul 14, 2020 •

android:fullBackupContent=»@xml/appsflyer_backup_rules» tools:replace=»android:fullBackupContent
This works just fine for me. Mediation Debugger also shows that Vungle if fine. But I am little worried for Vungle backup-ing.
Could some android sensei tell if this is fine solution or not?
p.s. doing this from Unity’s main manifest

m-kul commented Jan 8, 2021

This is working, thank you

Can anybody clarify, in which manifest file we need to add this? I cannot find appsflyer’s manifest file.

af-vs commented Jan 14, 2021

We see that this issue is indeed confusing and would like to elaborate a bit extra on this matter.

TL;DR

• If you don’t wantAuto Backup — just set android:allowBackup=»false» in AndroidManifest and you are good to go
• If you wantAuto Backup — you have to:

1. Manually merge backup rules from conflicting SDKs such as Vungle and AppsFlyer (there could be more) into your own XML file (e.g. @xml/merged_backup_rules ).
2. Specify this file by setting 2 attributes in AndroidManifest:
   • android:fullBackupContent=»@xml/merged_backup_rules» (to use your own rules)
   • tools:replace=»android:fullBackupContent» (to give your rules higher priority than rules from any SDK) in AndroidManifest

Some background:
Since Android 6.0 (API level 23) Android has an Auto Backup feature that will back up the app’s data into Google Drive every now and then automatically. This is enabled by default but may cause problems to some service providers like AppsFlyer and Vungle. The reason is that we save some data into SharedPreferences which are being backed up by Android, but we don’t expect this data to retain between installs. If this data is restored after the user reinstalls the app, we may report attribution for this app incorrectly. I assume, Vungle SDK has some similar challenges.

Since AppsFlyer uses AAR to distribute the library, together with the library jar we package AndroidManifest in which we specify backup rules that are important for our SDK to function properly. Unfortunately, Android as of today doesn’t have a solid merge mechanism so in case you have 2 libraries with conflicting values for the same attribute in AndroidManifest you get different kinds of merging conflict errors.

The only solution we can see for now without harming other SDKs is to merge such conflicts manually

As a result you should have this file with merged rules:

Источник