Мобильный трекинг после iOS 14.5: Еще один способ

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

Также, я не буду рассказывать о решениях, которые уже предложены такими компаниями как AppsFlyer, Adjust и другими трекерами а также про SKAd Network.

А расскажу я о способе трекинга, который я придумал (на самом деле я, конечно, ничего не придумал, просто сложил в голове несколько давно существующих и простых решений). Если вы продвигаете мобильное приложение и хотите протестировать у себя описанное мной решение, напишите мне телеграм: @V_ikonnikov

Содержание статьи:

- Как трекать разные источники при продвижении iOS приложения после iOS 14.5

- Как трекать Facebook Ads при продвижении iOS приложения после iOS 14.5

UPD: Описанный ниже способ давно известен как fingerprinting. Это запрещено по гайдлайнам Apple и приложение может быть отклонено

Мобильный трекинг после iOS 14.5: Еще один способ

Как трекать разные источники при продвижении iOS приложения после iOS 14.5

Мобильный трекинг после iOS 14.5: Еще один способ

1. Приложение (или сайт) рекламирует iOS приложение

2. Клик по рекламному объявлению ведет на трекер, содержит информацию о рекламе (utm-метки например, для идентификации источника, рекламной кампании, креатива и т.д.)

3. Трекер забирает и записывает для клика: IP адрес, iOS version, device model, carrier

4. Открывается рекламируемое приложение, шлет в трекер IP адрес, iOS version, device model, carrier и user_id

User id генерируется при первом запуске приложения, уникальный на уровне приложения, по user_id невозможно идентифицировать одного и того же пользователя в разных приложения

5. Трекер ищет есть ли клик с такими параметрами в последние 60 секунд / 30 минут

6. Трекер связывает клик с user_id

7. Клиент совершает целевое действие в приложении (например In App Purchase) Трекер из приложения шлет ивент In App Purchase (с user_id)

8. Трекер связывает по user_id In App Purchase с кликом

9. Видим в трекере какое объявление, какой источник привели In App Purchase и доход

Как трекать Facebook Ads при продвижении iOS приложения после iOS 14.5

По сути все то же самое, что в разделе выше, только еще трекер при переходе с объявления прогружает facebook pixel и забирает click_id из кук, а при совершении целевого действия facebook шлет по Server-to-server Facebook API ивент в котором передает click_id и данные по конверсии

1. Facebook/Instagram показывает рекламное объявление

2. Клик из объявления ведет на трекер (который потом редиректит в App Store) Трекер прогружает Facebook Pixel, получает куки фейсбука, записывает Facebook Click ID и другую информацию для большей точности (IP, iOS version, device model и т.д.)

3. По схеме из предыдущей части, трекер сопоставляет user_id, click_id, facebook_click_id

4. Когда пользователь совершает целевое действие, трекер шлет в Facebook по Server-to-server API событие, передает в параметрах click_id

5. Facebook по click_id связывает ивент и клик у себя в БД

6. Конверсия появляется в рекламном кабинете у объявления и кампании которые к ней привели

Эпилог

На мой взгляд такой способ трекинга даст большую точность (но не 100%-ную, конечно) чем трекинг с использованием SKAd и IDFA учитывая что, кажется, не менее 50% пользователей не будут давать согласие на трекинг.

При предложенном мной трекинге для “расхождения” необходимо чтобы в одну и ту же минуту два или более пользователей пришли в одно конкретное приложение с одним IP адресом и одинаковой моделью iPhone - это первое что приводит к неточности. Второе - если, например, в момент между кликом по объявлению и первым запуском приложения пользователь поменяет сеть, прыгнет с 4G на WiFi или наоборот (это случается, особенно если у пользователя включена настройка "Скачивать приложения только по WiFi").

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

Какую проблему не решает такой способ, так это идентификации пользователя сквозь несколько приложений, если только приложение которое показывает рекламу не является само рекламной платформой (как Facebook/Instagram например), но над этим тоже еще стоит подумать.

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

33
7 комментариев

Это хороший фильтр в 21 веке. Если маркетолог тебе аффектит и трекит, то можно с ним не работать, пока не вырастет

1

Все нормально, это стадия отрицания у индустрии

1

Просто спрашиваю - а как реализуется у сеток переход на указанную вами трек ссылку? Они же вроде сами ссылки генерят?

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

1

при размещении в сетке указывается ссылка на апп. Ссылку предоставляет трекер, то есть это не сразу прямая ссылка на стор

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

Отличное решение, спасибо.