App conversions
App conversions sends in-app events from your iOS or Android app to your advertising platforms as server side app conversions. Installs, purchases, product views and any custom event your app already tracks can all be delivered.
A mobile measurement partner is not required, and the two can run alongside each other. Where an MMP or another SDK already tracks the same action, the event name has to match exactly on both, because that is what lets the destination recognize them as the same conversion.
Sources and destinations
Section titled “Sources and destinations”Supported sources
| Category | Supported |
|---|---|
| App |
Supported destinations
| Category | Supported |
|---|---|
| App Conversions |
Two ways to implement
Section titled “Two ways to implement”The choice is about what your app already has in place rather than about what Signals can receive. Either way, events post to a subdomain issued to you, at the /apptrack path, and that address is what identifies your account.
| Path | When to use it |
|---|---|
| Datahash API | Your events already exist in code. Your developers add a POST alongside the calls they make today. |
| Firebase and GTM | Your app already sends events to Firebase. Those events are forwarded from there through Google Tag Manager rather than written again. |
Prerequisites
Section titled “Prerequisites”- An iOS or Android app, and a development team who can add the event calls.
- For the Firebase path, the Google Tag Manager SDK with the correct container for Android and for iOS, and Firebase already set up in the app.
- Agreement on which events matter and what each one is called, since the name has to stay identical everywhere it is sent.
- At least one device identifier available on the event: GAID on Android, or IDFA and IDFV on iOS.
The Datahash API path
Section titled “The Datahash API path”Send a POST to https://{subdomain}/apptrack with the event as JSON. The body carries the event name, the timestamps, the consent flags, the device and app context, the hashed user parameters and the event properties.
Implement the call in parallel with the existing MMP or SDK event rather than in place of it. The event name you send has to equal the name that MMP or SDK emits for the same action, with no synonyms, no difference in casing, and no swapping spaces for underscores.
The Firebase and GTM path
Section titled “The Firebase and GTM path”-
Add the required parameters to your existing Firebase events, logging them with
Analytics.logEventin Swift on iOS and the Java equivalent on Android. Firebase’s own getting started guides cover other languages. -
Configure tags in Google Tag Manager to forward those events server side to the destinations you have connected in Studio.
The GTM request goes to the same subdomain and /apptrack path, with the event name and parameters as query parameters rather than a JSON body.
Parameters
Section titled “Parameters”The full reference is in the implementation guide for the path you are using. The shape is the same either way.
| Group | Parameters |
|---|---|
| Required on every event | channel, type, messageId, originalTimestamp, anonymousId, advertiserTrackingEnabled, applicationTrackingEnabled, event, sentAt, integrations.All |
| Required per the implementation guide | event_time in Unix seconds, event_id, and the consent parameters application_tracking_enabled and advertiser_tracking_enabled. Purchase events also need value and currency. |
| Recommended, for match quality | Under context.userparams: h_email, h_phone, h_first_name, h_last_name, h_gender, h_dob, mobile_ad_id, idfv, external_id, plus ip_address and ua on the context itself. |
| Optional, describing the event | Under properties: currency, value, transaction_id, level, search_string, status, delivery_type, subscription_id, plus a products array carrying category, sku, name, sku_type, quantity, price and brand. |
Identifiers
Section titled “Identifiers”Hash personal data before you send it. Email address, phone number, first and last name, gender and date of birth all go as SHA-256 hashes in the h_ parameters, and each has a normalization rule to apply first, such as lowercasing an email address. Apply SHA-256 hashing to PII has the code for that step.
Do not hash device identifiers. GAID, IDFA and IDFV are sent as they are, and hashing them makes them unusable at the destination.
The consent flags travel with every event. advertiserTrackingEnabled and applicationTrackingEnabled record what the user permitted, so a destination that requires consent can honor it.
Managing the instance
Section titled “Managing the instance”One subdomain serves the app. To change the destinations the events feed, open the instance from the Manage existing instance table, click the edit option in the menu at the top right, update the fields and click Finish.
Best practices
Section titled “Best practices”- Use the same event names in the API or Firebase call as in your MMP. A name that differs by a capital letter or an underscore is a different event to the destination.
- Send a unique
event_id, and keep it identical across every source reporting the same action. That is what deduplicates the event rather than counting it twice. - Send timestamps in Unix seconds.
- Include at least one device identifier on every event.
- Agree the event list before development starts. Each event has to be implemented and mapped, so adding one later means another app release on the Firebase path.
Troubleshooting
Section titled “Troubleshooting”Events arrive but are counted twice. The event_id differs between the sources sending the same action. Make it identical across all of them.
The destination reports the event under a different name. The event name does not match what the MMP or SDK emits. Compare the two character for character.
Match rates are low. Usually no hashed identifier on the event, or a normalization step missed before hashing.
Device identifiers are not matching. Check they are being sent unhashed. Personal data is hashed, device identifiers are not.