> For the complete documentation index, see [llms.txt](https://docs.adpage.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adpage.io/app-tracking/identifiers-and-consent-in-apps.md).

# Identifiers and consent in apps

App events carry no cookies. This page covers which identifier to send, what each platform accepts, and how consent affects it.

A web event carries cookies that let a platform recognise the visitor. An app event carries none. Without a deliberate choice, the only thing you send is an IP address, and the platform accepts the event but can barely attribute it.

## The options

| Identifier                                 | Where it comes from                                 | Notes                                                              |
| ------------------------------------------ | --------------------------------------------------- | ------------------------------------------------------------------ |
| Hashed email address                       | The app, as an event parameter, hashed with SHA-256 | Strongest option for signups and purchases, works across platforms |
| `madid` (IDFA / GAID)                      | The device, only after tracking permission          | Strong for app campaigns, availability on iOS is limited           |
| `anon_id`                                  | The Meta SDK, when the app has it installed         | Meta only                                                          |
| `external_id`                              | The app's own user id, or `app_instance_id`         | Always available, useful for repeat recognition                    |
| Hashed phone number, first name, last name | The app, as event parameters                        | Extra matching signal alongside the email address                  |

{% hint style="info" %}
Send the email address hashed from the app, and hash it correctly: lower case, trimmed, SHA-256. A platform silently ignores a value it cannot match, so a wrongly hashed field looks exactly like a working one.
{% endhint %}

## What this means per platform

* **Meta** expects identifiers in `user_data`, and device information in `app_data`. It also expects the tracking flags described on the Meta page.
* **TikTok** expects identifiers in the user object of the app event.
* **GA4** does not need any of this. It identifies the app install by itself.
* **Google Ads** does not receive these from the container at all, see the Google Ads page.

## Consent

An app needs its own consent mechanism. The website's cookie banner does not cover it, and the consent signals your container already handles do not arrive from the app unless the app sends them.

Two things to settle with the client:

* who builds the in-app consent screen, usually the app developer,
* what the app sends when the user refuses, so the container can suppress the tags that need consent.

On iOS, the tracking permission prompt (ATT) is a separate question from analytics consent. Only with that permission is the advertising id available, and Meta expects to be told whether it was granted. Never report permission as granted when it was not, also not to make an error message disappear.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.adpage.io/app-tracking/identifiers-and-consent-in-apps.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.