-> Appsflyer -> Meta
Указывали ли вы Customer User ID для AF такой же как в сервисе по подпискам?
Если я правильно понял вопрос, то да, это нужно, чтобы матчить юзеров между сервисом подписок и AF
Может из за этого не допоказывать ивенты в скане? Такое ощущение что показывает только тех кто разрешил доступ к idfa
В работе со сканом лучше использовать клиентские события, бОльшая часть серверных событий в скан может быть не отправлена. Скан события следует искать в скан-дашборде, в обычном дашборде AF будут события от тех юзеров, кто дал двойной консент - вам и рекламной сети, если сеть самоаттрибуцируемая)
Клиентские события это в самом аф что? В ручную трекать?
Да, те, что отправляете сразу в AF из приложения (клиента)
В обчным дашборде видны все события, в скане часть
То есть получается скан нужно настравать на события затреканые через аф, то есть в ручную. Это получается будет только одно событие start trial/purchase. На остальнольные события, которые придут с сервера, расчитытьвать нельзя?
Нет проблем с s2s событиями, если вы их присылаете без задержек, так, чтобы пользователь был активным в приложении и значение конверсии успело обновиться. Если вы присылаете события с задержкой, то есть вероятность, что они просто не успеют записаться.
Понял. Я думал что когда, тот же apphud, отправит событие, когда юзер уже давно не а впе, в аф с Customer User ID и уже аф свяжет его у себя с «юзером»
Это противоречит концепции SKAN. Но для целей атрибуции AF нет таких ограничений, событие запишется
А подскажите еще про 48 часов postback skan? Это задержка на стороне Apple или Appsflyer?
Если у вас ретеншен юзеров которые оформили триал приближается к 100% к моменту когда триал конвертируется (если вы хотите отправлять тех, кто сконвертировался), то можно отправлять и s2s. В противном случае события будут теряться. При отправке s2s в скан у вас появляется 2 дополнительных узла которое должно пройти событие и приложение должно быть запущено на клиенте. Когда вы отправляете событие с клиента у вас нет дополнительных задержек, а следовательно потерь событий.
Ну юзеры которые взяли триал и удалили апу стремятся к 0 так что это можно не рассматривать. А что за 2 дополнительных узла? Отправлять события с клиента хорошо конечно, но если юрез не заходит а впу к примеру, или заходит но редко. Лучше отправлять сразу с сервера в аф, и как я понял нужно указывать у аф Customer User ID и он будет по этому айди связывать ивент с сервера со своими данными. А start trial по сути моментально приходит в аф с сервера, когда юзер еще в апе, это другие события в 99% случая приходят когда он не в апе
>>А что за 2 дополнительных узла? в случае s2s: сервер нотификаций apple -> сервис по работе с подписками -> AF -> ваше приложение (приложение должно быть активно) -> skad network в случае клиентского события: ваше приложение -> skad network Это схема в общих чертах, без учета таймеров и версии skan >>А start trial по сути моментально приходит в аф с сервера, когда юзер еще в апе, это другие события в 99% случая приходят когда он не в апе ну если уверены, что все точно прилетает моментально, нигде не будет задержек и событие улетит пока приложение активно, то, конечно, можно отправлять и s2s >>и как я понял нужно указывать у аф Customer User ID и он будет по этому айди связывать ивент с сервера со своими данными. верно, чтобы AF мог сматчить событие с пользователем нужно указывать appsflyer ID при отправке события, его должен знать сервис который работает с подписками (уверен, что эта информация есть в хелпе сервиса которым пользуетесь)
Обсуждают сегодня