At a glance: Send your app's rich in-app events from AppsFlyer to Meta ads.
Meta in-app events mapping
Advertisers map their in-app events, SDK or Servers-to-servers, to Meta predefined events. Advertisers can also send Meta postbacks about each app launch or any known app uninstall.
This enables advertisers to utilize Meta's advanced optimization capabilities, as well as build Custom and Lookalike Audience segments.
Predefined event mapping
Meta ads offers a wide range of events that are already predefined and can be mapped.
Find here the list of rich in-app events that can be sent to Meta with additional parameters providing extra information about the quality of events.
Learn more about mapping events on Meta.
Note that there's no predefined event for sending uninstalls to Meta ads. To send uninstalls, use a custom event.
Below is the list of other predefined Meta events that don't have additional parameters:
| Meta event identifier | Description | Recommended AppsFlyer SDK name |
|---|---|---|
| Donate | The donation of funds to your organization or cause. | af_donate |
| Schedule | The booking of an appointment to visit one of your locations. | af_schedule |
| SubmitApplication | The submission of an application for a product, service or program you offer, such as a credit card, educational program, or job. | af_submit_application |
| FindLocation | When a person finds one of your locations via web or app, with an intention to visit. For example, searching for a product and finding it at one of your local stores. | af_find_location |
| Contact | A telephone or SMS, email, chat or other type of contact between a customer and your business. | af_contact |
| CustomizeProduct | The customization of products through a configuration tool or other application your business owns. | af_customize_product |
Adimpression—for AndroidFb_mobile_purchase—for iOS |
Optimizes ad revenue on the Meta ads platform. See details below. | af_ad_revenue |
Mapping ad revenue data for campaign optimization
Meta ads can optimize your campaigns based on your ad revenue data. This is done by mapping the af_ad_revenue event to the following Meta ads event:
| Event name in AppsFlyer | Platform | Mapped to partner event | Meta ads optimization based on: |
|---|---|---|---|
|
af_ad_revenue |
Android | Adimpression | Specific ad revenue |
| iOS | fb_mobile_purchase | In-app purchases |
Availability limitations
- Currently, optimization via the Adimpression event is available only for:
- Android apps. iOS apps can continue sending ad revenue data using the fb_mobile_purchase event.
- Selected Meta ads accounts, as per Meta's criteria. When grayed out, eligibility criteria may not be met.
- The af_ad_revenue event is available for plans with an ROI360 advanced subscription only. Additionally, you need the impression-level via SDK ad revenue integration type.
- Non-ROI360 plans can send ad revenue data using other event names.
Custom in-app events mapping
AppsFlyer allows you to map any custom in-app event to send to Meta, by using the CUSTOM Meta Event Identifier option.
The event name and the event value (including the event parameters) configured in the SDK are forwarded to Meta, as is, and displayed under its original AppsFlyer SDK event name - not as "custom".
Note that you are able to use these events to optimize your campaigns.
Automatic parameter mapping with the custom event
Through the AppsFlyer deep integration with Meta, many of the AppsFlyer standard SDK event parameters are automatically mapped to Meta's predefined parameters. For example, the af_revenue parameter is converted to the _valueToSum parameter in Meta, which allows you to send a revenue per event that can be measured and optimized in Meta.
Note
Automatic parameter mapping can differ between CUSTOM and predefined events.
For predefined events, af_price is mapped to _valueToSum in some cases (for example, fb_mobile_add_to_cart). In other cases, af_revenue is mapped to _valueToSum (for example, in fb_mobile_purchase).
For events mapped to CUSTOM, af_price is always mapped to fb_price, and af_revenue to _valueToSum.
The following table details all the AppsFlyer event parameters, which when mapped through the CUSTOM event to Meta, are automatically mapped to Meta parameters.
| AppsFlyer Parameter | Meta Parameter |
|---|---|
| af_city | fb_city |
| af_class | fb_travel_class |
| af_content | fb_content |
| af_content_id | fb_content_id |
| af_content_list | fb_content_id |
| af_content_type | fb_content_type |
| af_country | fb_country |
| af_currency | fb_currency |
| af_date_a | fb_checkin_date |
| af_date_b | fb_checkout_date |
| af_departing_arrival_date | fb_departing_arrival_date |
| af_departing_departure_date | fb_departing_departure_date |
| af_description | fb_description |
| af_destination_a | fb_origin_airport |
| af_destination_b | fb_destination_airport |
| af_destination_list | fb_destination_ids |
| af_hotel_score | fb_hotel_score |
| af_level | fb_level |
| af_max_rating_value | fb_max_rating_value |
| af_num_adults | fb_num_adults |
| af_num_children | fb_num_children |
| af_num_infants | fb_num_infants |
| af_order_id | fb_order_id |
| af_payment_info_available | fb_payment_info_available |
| af_preferred_neighborhoods | fb_preferred_neighborhoods |
| af_preferred_num_stops | fb_preferred_num_stops |
| af_preferred_price_range | fb_preferred_price_range |
| af_preferred_star_ratings | fb_preferred_star_ratings |
| af_price | fb_price |
| af_quantity | fb_num_items |
| af_region | fb_region |
| af_registration_method | fb_registration_method |
| af_returning_arrival_date | fb_returning_arrival_date |
| af_returning_departure_date | fb_returning_departure_date |
| af_revenue | _valueToSum |
| af_search_string | fb_search_string |
| af_success | fb_success |
| af_suggested_destinations | fb_suggested_destinations |
| af_suggested_hotels | fb_suggested_hotels |
| af_travel_end | fb_travel_end |
| af_travel_start | fb_travel_start |
| af_user_score | fb_user_score |
Predefined events automatic mapping to the _valueToSum parameter
For predefined events, the Meta parameter _valueToSum is mapped either to the af_price or to the af_revenue parameters.
The following table details this mapping for all predefined Meta events with the _valueToSum parameter:
| Meta event | _valueToSum mapped to |
|---|---|
| fb_mobile_level_achieved | none |
| fb_mobile_add_payment_info | none |
| fb_mobile_add_to_cart | af_price |
| fb_mobile_add_to_wishlist | af_price |
| fb_mobile_complete_registration | none |
| fb_mobile_tutorial_completion | none |
| fb_mobile_initiated_checkout | af_price |
| fb_mobile_purchase | af_revenue |
| fb_mobile_rate | af_rating_value |
| fb_mobile_search | af_revenue |
| fb_mobile_spent_credits | af_price |
| fb_mobile_achievement_unlocked | none |
| fb_mobile_content_view | af_price |
| StartTrial | af_price |
| Subscribe | af_revenue |
Send complex in-app events to Meta ads
To send complex in-app events, meaning events with multiple items, to Meta, use a structured af_content array. Each object in the array must include id and quantity to ensure proper postback handling.
af_content_list is optional. When it is absent, Meta falls back to the fb_content field (mapped from af_content) to identify product IDs. As long as the af_content JSON includes an id field in each object, Meta can parse and extract content IDs from it.
If you do include af_content_list, do not also include af_content_id in the same event. Both parameters map to fb_content_id, and only one should be populated to prevent conflicts.
Note
fb_content_id is important for product-level use cases such as matching events to catalog items for Advantage+ Catalog Ads and Dynamic Ads, product-level performance reporting, and product-based optimization signals. For general conversion optimization based on event count and value, campaigns work without it.
Example, unified format compatible with Meta and TikTok
{
"af_revenue": 4.99,
"af_currency": "USD",
"af_order_id": "12345",
"af_content": "[{\"id\":\"ID1\",\"quantity\":\"1\"},{\"id\":\"ID2\",\"quantity\":\"1\"},{\"id\":\"ID3\",\"quantity\":\"2\"}]"
}This format works for both Meta and TikTok. TikTok also reads id values from the af_content field, so a single payload is sufficient when postbacking to both networks.
Important!
If the af_content parameter exceeds 1,000 characters, AppsFlyer may send the event to Meta without the fb_content parameter. If af_content_list is also absent in that scenario, Meta receives no product identification data. Keep af_content under 1,000 characters for events that include many items.
For more details about structuring complex in-app events, see the In-app events: Overview article.
Event and parameter limitations
The following limits apply to events you send to Meta ads:
- The following characters are not allowed:
- Colon (:)
- Period (.)
- Non-Latin (English) character sets: As of January 12, 2020, Meta rejects Chinese characters. AppsFlyer has not tested other character sets, and you should use them only after verifying with Meta if they support them in postbacks.
- Event names are case-sensitive. To avoid discrepancies, make sure you use the correct case in the event names for all media sources and app versions.
- Maximum number of parameters: 25.
- Length of event names and parameters: 2–40.
- Maximum parameter length: 100 characters.
- Maximum parameter length for the af_content parameter: 1000 characters.
- Characters permitted: Alphanumeric characters, underscores, hyphens, or spaces. Don't use non-Latin (English) characters. Using non-Latin letters results in inconsistent results.
Considerations regarding in-app event naming:
- Event names on AppsFlyer can be named the same as Meta event names (for example, fb_price), however, these should not be sent as CUSTOM events to Meta.
To keep on the safe side, refrain from naming events the same as Meta event names. - To perform in-app events postback mapping with Meta, get events data from all sources, including organic.
Important!
With the exception of the above parameters, AppsFlyer sends the CUSTOM events data as is to Meta. It is the responsibility of the app owner to verify the event data is according to Meta requirements, using valid Meta parameters (see the table above). Otherwise, these parameters aren't sent to Meta.