Best Way to Send Subscription Value to Meta for ROAS Campaigns (7-Day Free Trial)

Put On Your Mask
R

Rehan Naveen Perera

Active Member
Hey everyone, I’m planning to run ROAS campaigns on Meta for a subscription app that has a 7-day free trial. We’re currently using Adapty for subscriptions and AppsFlyer as our MMP. What’s the best way to send subscription value back to Meta for optimization, through Adapty directly or via AppsFlyer?
 
you shouldnt have issues with any of them.

If you are using adapty events in Appsflyer, then it doesn't make sense to do adapty-appsflyer-meta as you will lose some event signal quantity when adding that extra step - it is better to go directly with adapty-meta.

If you are using AF sdk events, then you can go with any of them! either appsflyer-meta or adapty-meta although in my experience, you will have less tech issues when integrating Appsflyer!
 
davamosk said:
you shouldnt have issues with any of them.

If you are using adapty events in Appsflyer, then it doesn't make sense to do adapty-appsflyer-meta as you will lose some event signal quantity when adding that extra step - it is better to go directly with adapty-meta.

If you are using AF sdk events, then you can go with any of them! either appsflyer-meta or adapty-meta although in my experience, you will have less tech issues when integrating Appsflyer!
Click to expand...
are you able to start a AEM campaign with server side events?
 
now that you mention that, I think I had issues the last time because Adapty is NOT attaching the IP and IDFV parameters that are mandatory to unlock AEM so you will actually need the extra step :(
 
We've found no major differences between sending direct via SDK vs Adapty/RevenueCat->Meta vs Adapty/RC->AppsFlyer->Meta after significant testing. In fact (as noted above) we often find that the S2S events from Adapt/RC/other tools are missing important attributes which result in Meta rejecting the event, and AppsFlyer take care of avoiding that, so always better to go via MMP.

Practically though - are you talking about purchase events after the 7d trial? If so, 2 call-outs:

1 - I find client side (SDK) firing purchase events (trial convert events) can have very low data volume. Practical example - in 1 app we only see 30% of users open the client within 48hrs of the trial converting to paid. A shit load never come back at all of course, and there's a long tail of users coming back to the client slowly over multiple days/weeks. End result - sending trial conversion events from the client could end up sending only a slice of the total events.

2 - I don't believe Meta are doing much/anything with these data points. Even if they are, it's data that's 7d late - the campaign already spent/optimised before this signal even arrives. We have much better success by using either an "uncanceled trial" event (e.g. 1hr after the trial started fire for users who didn't cancel yet), or some kind of predicted LTV (can be as simple as sending 50% of the possible revenue for anyone who didn't cancel).
 
You must log in or register to reply here.
Back
Top