Skip to main content
Question

How Meta ads\Firebase integrations handle web purchase via Stripe

  • January 21, 2026
  • 2 replies
  • 19 views
L
Forum|alt.badge.img

Hello! 

Apart from mobile app purchase flow we also have webapp purchase. In case of mobile app we collect all the necessary identifiers within the app. But what about the webapp? We do create RC customer before the purchase and provide `client_id` from gtag.js as `$firebaseAppInstanceId` and `$fbAnonId` from `_fbp` cookie. Is this correct? 

Will the meta conversions api specifically correctly send the purchase considering that there is no mobile platform yet and only `$fbAnonId` which as I understand works for iOS only in app terms as said here - 

 

2 replies

hussain
RevenueCat Staff
Forum|alt.badge.img+6
  • hussain
  • RevenueCat Staff
  • January 23, 2026

Hi ​@Lo4D,

Thanks for reaching out. I’m happy to help.

The key thing here is that RevenueCat’s Meta Ads integration is built around mobile app identifiers, so a web-only Stripe checkout won’t have the required data unless that same customer has already generated those identifiers from within your app.

In RevenueCat, $fbAnonId means the “Facebook anonymous identifier” collected from the Meta SDK in your mobile app (iOS). It’s one of the device identifiers used for dispatching events to Meta.

So mapping _fbp (web Pixel cookie) into $fbAnonId isn’t expected to work as they’re different identifiers.

For an event to be delivered to Meta through RevenueCat, the customer must have $fbAnonId or a mobile advertising ID set at the time the event is processed (for both App Events API and Conversions API).

That means:

  • If the customer has never opened the mobile app (so you don’t have $fbAnonId/$idfa/$gpsAdId), RevenueCat won’t be able to dispatch Meta events for that Stripe purchase through the Meta Ads integration.

  • If the user does open the app later and those identifiers are set, that can help for future lifecycle events (e.g., renewals) after the identifiers exist, but it won’t retroactively “fix” an already-processed purchase event.

If your goal is web purchase conversion tracking, you’ll generally want to implement Meta Pixel + (web) Conversions API directly in your web checkout/server (using web identifiers), rather than relying on the mobile-focused RevenueCat Meta integration.

Best,

Hussain

Hussain, Developer Support Engineer (RevenueCat)
L
Forum|alt.badge.img
  • Lo4D
  • Author
  • New Member
  • January 23, 2026

Hi ​@Lo4D,

Thanks for reaching out. I’m happy to help.

The key thing here is that RevenueCat’s Meta Ads integration is built around mobile app identifiers, so a web-only Stripe checkout won’t have the required data unless that same customer has already generated those identifiers from within your app.

In RevenueCat, $fbAnonId means the “Facebook anonymous identifier” collected from the Meta SDK in your mobile app (iOS). It’s one of the device identifiers used for dispatching events to Meta.

So mapping _fbp (web Pixel cookie) into $fbAnonId isn’t expected to work as they’re different identifiers.

For an event to be delivered to Meta through RevenueCat, the customer must have $fbAnonId or a mobile advertising ID set at the time the event is processed (for both App Events API and Conversions API).

That means:

  • If the customer has never opened the mobile app (so you don’t have $fbAnonId/$idfa/$gpsAdId), RevenueCat won’t be able to dispatch Meta events for that Stripe purchase through the Meta Ads integration.

  • If the user does open the app later and those identifiers are set, that can help for future lifecycle events (e.g., renewals) after the identifiers exist, but it won’t retroactively “fix” an already-processed purchase event.

If your goal is web purchase conversion tracking, you’ll generally want to implement Meta Pixel + (web) Conversions API directly in your web checkout/server (using web identifiers), rather than relying on the mobile-focused RevenueCat Meta integration.

Best,

Hussain

Interesting. We’ve already tested it out and RC does send these events to both Meta and GA. Maybe these identifiers of course won’t connect the event with the ad campaign though.

Terms & ConditionsCookie settingsAccessibility statement