Skip to main content
Question

SKAdNetwork - Listen to Trial conversion events app side


Forum|alt.badge.img+7

Hi, 

We are trying to use SKAdNetwork to track trial starts and trial conversions via Branch. While working with Branch customer support, they suggested we track these natively via BranchEvents so that the events would be captured by SKAN. This is easy for trial starts since we get a callback on device when the trial starts. However, for trial conversions, we need to do this client side as well to have them registered via SKAN. Is there an easy way to do this? One way I thought about doing this would be to set up `addPurchaserInfoUpdateListener` in the app and an async storage valuue to set this listener until if fires and then check if the user info changes to subscribed or cancelled. This seems a little convoluted though so I wanted to see if there was an easier way. 

As an aside, the Branch docs should probably be updated with a note around SKAdNetwork as we spent a lot of time trying to debug why we were getting no attribution data and it was because the events were coming server side not client side and therefore could not be attributed. 

12 replies

Forum|alt.badge.img+1

Hello @jake lynch ,

We are also using RevenueCat and Branch in our app.

currently we receive our START_TRIALS in our branch dashboard coming from RevenueCat.
but we are also facing the issue of the START_TRIAL events not being attributed on our SKAdNetwork.

Are you guys manually sending the START_TRIAL Branch events from the fe/client to branch?

 


Forum|alt.badge.img+7
  • Author
  • Active Member
  • 11 replies
  • July 12, 2023

Hi @MateoParodi

This is eventually what we started doing. Server-side events cannot be aggregated by the SKAdnetwork, so you need to manually attribute events on the FE. We have not been able to do this for purchases yet, since we have 7-day trial that autoconverts, but the trial starts have been sufficient.


Forum|alt.badge.img+1

Nice, 

can you please help me a little bit on how you send the START_TRIAL event manually?
which RevenueCat SDK are you using? native ones for Android/iOS or the react-native one?


Forum|alt.badge.img+7
  • Author
  • Active Member
  • 11 replies
  • July 12, 2023

You can do something like:

```

const event = new BranchEvent(BranchEvent.StartTrial);

await event.logEvent();
```

And call that in the case of successful trial start from revenue-cat


Forum|alt.badge.img+1

But you don’t need to send also some parameters, like the transaction, campaign, etc. to be attributed to a specific ad or campaign?

like this example in the branch documentation:
 

 


Forum|alt.badge.img+7
  • Author
  • Active Member
  • 11 replies
  • July 12, 2023

You can if you want to, but branch should handle a lot of that on its own if you have set up branch correctly in your ads


Forum|alt.badge.img+4

@jake lynch @MateoParodi having the same problem.  Wouldn’t adding the Start trial event client side + Branch integration lead to double reporting for the trial?


jeffrey_bunn
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • 162 replies
  • May 30, 2024

Just wanted to add some context here. SKAdNetwork doesn’t have any server-side APIs, so the conversion values need to be collected and set client-side. Collecting those values directly from the device using Branch’s SDK makes sense. While this would definitely be made easier if the RevenueCat SDK interfaced with SKAN directly, this isn’t on our roadmap as it would require a significant investment into building that system and wouldn’t add anything beyond what you get from Branch as we would have to do everything client-side as well. This has been passed on as a feature request to our product team though. I hope this helps clarify things!


Forum|alt.badge.img+3

@achraf-62a7dc Did you ever figure that out? It sounds logical to me that we should turn off the START_TRIAL event forwarding from the RC Branch integration if we track it client side. 


  • New Member
  • 2 replies
  • January 8, 2025

Hi ​@jeffrey_bunn,

Our subscription-based app is also facing the same issues mentioned here.

 

Specifically, the “purchase” event (trial conversion) is sent to Branch from RevenueCat via the integration, and then to Meta from Branch using the event mappings in the Branch dashboard. We hoped this setup would populate ROAS values in Ads Manager, but no luck so far (we’ve been running Meta ads since December).

 

While reviewing Branch's documentation today, I came across something interesting (related to ​@jake lynch's point about SKAN limitations for server-side events):

If you are sending any event to Branch via a server to server call and you are running Facebook campaigns on iOS, it is required that you send the OS version to Branch for proper attribution on Facebook ads. 

 

I checked the payload that RevenueCat sends to Branch via the integration, and it seems the OS version is missing. The “user_data” field in the request body includes attributes like “app_id,” “developer_identity,” “idfa,” “idfv,” “ip,” and “os.” However, the “os” value is just a string (e.g., “iOS”) and doesn’t include the OS version.
 

Is this OS version something that can be appended by RevenueCat, or should we add it as user attributes on our end? If the latter, it’d be helpful if this were clarified in the documentation to save others from running into the same issue.

 

We also configured SKAN postback windows on the Branch dashboard (aka SKAN Conversion Center) in late 2024 (screenshot below), but we still don’t see any SKAN data on Branch. Consequently, ROAS values still aren’t showing up in Meta Ads. If Branch’s note about the missing OS version is accurate, this might be the missing piece of the puzzle. Pls note that “PURCHASE” event in the screenshot is what RevenueCat sends to Branch. 

 

Let me know your thoughts!

Updated:
- We use iOS14+ campaigns on Meta ads. 


wes_clark
RevenueCat Staff
Forum|alt.badge.img+6
  • RevenueCat Staff
  • 235 replies
  • January 15, 2025

Hi! We do not currently append the OS version, but I can raise the suggestion internally. 


  • New Member
  • 2 replies
  • January 15, 2025

@wes_clark Thanks for the reply. Yes, that would be great. I’d love to see if it fixes the issue. Pls note that your AppsFlyer integration is already sending the os version. 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings