At a glance: Advanced-Matching Data Sharing enables hashed user identifiers, such as email and phone number, to be forwarded from AppsFlyer to selected ad networks, allowing partners to attribute events to ad engagements without a device ID.
About Advanced-Matching Data Sharing
As device identifiers become less available, ad networks increasingly rely on first-party data to match ad engagements. Advanced-Matching Data Sharing addresses this gap by forwarding hashed identifiers to supported partners in a privacy-compliant format.
The feature is optional and configured per partner. When enabled on a supported network, AppsFlyer forwards hashed identifiers alongside event data for installs, re-engagements, and in-app events.
Important!
All identifiers must be hashed with SHA-256 before reaching AppsFlyer, either on-device via the SDK or server-side via the S2S API. Plain-text data is never received, stored, or forwarded, and any value that fails validation is dropped at ingestion.
Supported partners
The scope of Advanced-Matching Data Sharing varies by partner. Snapchat and TikTok support installs, re-engagements, and in-app events, while Google and Meta are limited to in-app event matching. The feature is currently available with the following networks:
| Partner | Integration type | Supported events |
|---|---|---|
| Google (googleads_int) | OCI | In-app events |
| Meta (facebook_int, metaweb_int) | SRN + CAPI | In-app events |
| OpenAI (openai_int) | CAPI | Installs, re-engagements, in-app events |
| TikTok (tiktokglobal_int, tiktokweb_int) | SRN + CAPI | Installs, re-engagements, in-app events |
| Snapchat (snapchat_int, snapweb_int) | SRN + CAPI | Installs, re-engagements, in-app events |
| Pinterest (pinterest_int) | CAPI | Installs, re-engagements, in-app events |
| Reddit (reddit_int) | CAPI | Installs, re-engagements, in-app events |
| Roku (rokuads_int) | SRN + CAPI | In-app events |
The end-to-end flow
Here's what happens from the moment an identifier is retrieved to the moment it reaches a partner:
- An identifier (email address, phone number, or other supported type) is retrieved in the app or on the backend.
- The identifier is normalized and hashed using SHA-256: automatically by the AppsFlyer SDK, or on the server before sending via the S2S API.
- The hashed identifier is sent to AppsFlyer alongside the event (install, reinstall, re-engagement, or in-app event).
- If Advanced-Matching Data Sharing is enabled for the partner, AppsFlyer forwards the hash alongside the event payload.
- The partner uses the hash to match the event to a known user, improving attribution accuracy and match quality.
Note
Hashed identifiers are only forwarded to partners where Advanced-Matching Data Sharing is enabled. When the turn on/turn off is off, no hashed data is shared with that partner, even if identifiers are present on the event.
How hashed user identifiers reach AppsFlyer
Hashed identifiers reach AppsFlyer via two methods: the SDK or the server-to-server (S2S) API. In both cases, only properly hashed values are accepted. The tabs below describe each method.
SDK V7.0.1 introduces a method for passing raw identifiers to the AppsFlyer Android and iOS SDKs. The SDK normalizes and hashes the input before sending it to AppsFlyer:
The SDK performs the following steps in sequence:
- Normalizes the input according to each partner's requirements.
- Hashes the normalized value using SHA-256.
- Sends only the hashed value to AppsFlyer. The raw input never leaves the device.
Invalid values are rejected by the SDK with an error and not sent to AppsFlyer.
Note
Android and iOS support is available starting with SDK V7.0.1.
For implementation details, see the Android SDK integration guide and iOS SDK integration guide.
When sending events via the S2S in-app events API, identifiers must be normalized and hashed server-side before submission. The API accepts the following fields:
| Field | Description |
|---|---|
email_hashed |
Hashed email address |
phone_number_hashed |
Hashed phone number, digits only |
phone_number_e164_hashed |
Hashed phone number in E.164 format |
first_name_hashed |
Hashed first name |
last_name_hashed |
Hashed last name |
fb_login_id |
Facebook login ID (not hashed; passed as-is) |
Important!
Every field in this table (except fb_login_id) is validated against the SHA-256 format. Values that don't match are dropped silently and not forwarded to any partner. Other fields in the event are processed normally.
Why are there two phone number fields? Networks match events by comparing the hash that AppsFlyer forwards to their own stored hash of the user's phone number. Because the same number normalized in a different format produces a different hash, both sides must hash from the same format to get a match. Since networks normalize phone numbers differently and AppsFlyer receives values already hashed, both versions must be sent to cover all supported partners.
-
phone_number_hashed: for Meta and Snapchat. Normalization format before hashing:16501234567 -
phone_number_e164_hashed: for Google and TikTok. Normalization format before hashing:+16501234567
Normalize and hash identifiers
Normalize the raw value exactly as described below, then hash using SHA-256 and send the lowercase hex digest.
Email (email_hashed)
- Remove all whitespace.
- Convert to lowercase.
- Hash with SHA-256.
Example:
User@Example.COM → user@example.com → SHA-256 hash
Phone number, digits only (phone_number_hashed)
Use this for Meta and Snapchat.
- Prepend the country code.
- Remove all symbols, letters, and leading zeros.
- Hash with SHA-256.
Example:
+1 (650) 123-4567 → 16501234567 → SHA-256 hash
Phone number, E.164 (phone_number_e164_hashed)
Use this for Google and TikTok.
- Prepend the country code.
- Remove all symbols, letters, and leading zeros.
- Prepend a
+sign. - Hash with SHA-256.
Example:
+1 (650) 123-4567 → +16501234567 → SHA-256 hash
First name (first_name_hashed) and last name (last_name_hashed)
- Remove all whitespace.
- Convert to lowercase.
- Hash with SHA-256.
Facebook login ID (fb_login_id)
Send the raw Facebook login ID as provided by the Facebook Login SDK. This field is not hashed.
Turn on Advanced-Matching Data Sharing
Advanced-Matching Data Sharing is controlled per partner and per app, and must be enabled explicitly for each network.
To enable Advanced-Matching Data Sharing:
- In AppsFlyer, from the side menu, select Collaborate > Active Integrations.
- Search for the partner and select it.
- Turn on Advanced-Matching Data Sharing.
- Click Save integration.
When Advanced-Matching Data Sharing is turned on, any event that includes one or more supported identifier fields will have those fields forwarded to the partner.
Note
Turning off Advanced-Matching Data Sharing immediately stops hashed data sharing with that partner. Other integration settings, including postbacks and event data, are not affected.
Privacy and data handling
When Advanced-Matching Data Sharing is enabled for a partner, AppsFlyer begins forwarding hashed user identifiers to that network along with event data. Before turning it on, confirm the following:
- A lawful basis exists (under applicable privacy laws, such as the General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA)) to share this data with the partner.
- Your privacy policy has been updated and, where required, user consent has been obtained.
- Your data-sharing practices align with the partner's terms.
Important!
AppsFlyer does not process or store plain-text Personally Identifiable Information (PII). All identifier fields are validated at ingestion: values that don't conform to the SHA-256 format are dropped and never forwarded to any partner.
FAQ
Is Advanced-Matching Data Sharing the same as the Audiences' hashed email and phone feature?
No. These are separate mechanisms. Audiences build user lists for ad targeting. Advanced-Matching Data Sharing forwards hashed identifiers with individual events to improve match rates at the partner level. AppsFlyer plans to consolidate both methods, using the new data retrieval method for both Advanced-Matching Data Sharing and Audiences.
What happens if I send an invalid hash value?
The field is dropped at ingestion and not forwarded to any partner. Other fields in the event are processed normally.
Do I need to send all supported fields?
No. Only the identifiers available and relevant to the configured partners need to be included. Missing fields are not forwarded.
Will Advanced-Matching Data Sharing improve install attribution?
For Snapchat and TikTok, yes. These partners support install and re-engagement claims based on hashed email and phone. For Google and Meta, it currently improves match rates for in-app events only.
Does AppsFlyer ever receive plain-text user identifiers?
No. When using the SDK, hashing happens on-device before anything is sent to AppsFlyer. When using the S2S API, hashing happens on the server before submission. AppsFlyer only accepts hashed values.