In-app conversion tracking: How to track conversions without violating GDPR and store policies?

2026-08-14 | devqube
In short: The discrepancy between the report in the ad panel and actual sales usually has three causes: some events do not arrive because the SDK operates on the client side; some users have not given consent, so they disappear from attribution; and some of the data you see comes from a model, not from measurement. All three can be fixed without breaking the law, and this usually improves results. Below: what you are allowed to measure, how to move measurement to the server, how conversion modeling works, and how to build your own database instead of relying on provider SDKs.

 

Where we are in 2026: what replaced old tracking methods

In-app conversion tracking has become one of the toughest challenges for marketing and development teams in recent years. The Meta panel shows 340 campaign installs, Google Ads adds its own, and you have 210 new accounts in your database. Someone in a meeting asks which number is true, and there is no good answer. Sound familiar?

The instinct is to blame the creatives or seasonality. But the fault usually lies elsewhere. Since 2021, mobile app measurement stopped being a technical task and became a series of decisions about what can be collected, from whom, and through which channel. The truth is that a large portion of teams never made these decisions consciously. Because they were made for them… by the default settings of the libraries.

Let’s start by clarifying a fact that still circulates in an outdated version across various public sources.

Third-party cookies have not disappeared. On April 22, 2025, Google announced that it is keeping the current model in Chrome. On October 17, 2025, it withdrew most of the Privacy Sandbox program that was supposed to replace them, including Topics, Protected Audience, Attribution Reporting API, and two Android proposals: SDK Runtime and Protected App Signals. The reason was low adoption. What remained are CHIPS, FedCM, and Private State Tokens.

That was six years of preparation for a change that… did not happen.

For you, from the perspective of campaign measurement, this has one consequence: there is no single technology that will solve this problem (and observing market trends, it doesn’t look like it will change anytime soon). In other words, no new standard will arrive to restore the old level of visibility. What works today are four separate data sources that (unfortunately) you have to piece together yourself:

In-app conversion tracking: How to track conversions without violating GDPR and store policies?

Besides, there were never any cookies in the mobile app. The whole discussion was about websites. In an app, something else matters: the device’s advertising identifier, ATT consent, and exactly when your libraries are triggered.

What is actually allowed to be measured: GDPR, Apple, and Google

 

Disclaimer: This is not legal advice. Before making changes, it’s worth showing this to a lawyer, preferably along with the EDPB 2/2023 guidelines, which explain why the cookie provision applies to apps.

I point out in advance that this is a highly simplified legal layer, which you need for correct data measurement.

You are bound by three independent sets of rules.

  • The Law (GDPR and the ePrivacy Directive, implemented in Poland as Art. 399 of the Electronic Communications Law) requires consent before reading or writing anything on the user’s device, including the advertising identifier.
  • Apple requires ATT consent before you access the IDFA or combine your data with data from other companies.
  • Google Play requires a declaration in the Data Safety form and the use of AAID instead of other persistent identifiers for advertising purposes.

Key thing to remember: the ATT prompt is not a consent in the sense of the GDPR, but an Apple policy requirement. You must collect legal consent separately and document it separately.

What you collect or do Does it require legal consent Does it require ATT What about Google Play
Advertising identifier (IDFA, GAID) Yes, before reading Yes, on iOS Use AAID, declare in Data Safety
Own installation identifier Yes, unless it is strictly necessary for the service to function No, as long as you do not combine it with other companies’ data Declare as “Device or other IDs”
Device fingerprinting Yes, although it is risky in itself Prohibited by policy regardless of consent Non-compliant with policy
Email address provided during registration Yes, separately for marketing purposes No, as long as it stays with you Declare data category
The same email sent to Meta or Google Yes, and a separate legal basis is needed Yes, Apple lists this as an example of tracking Subject to advertising policy
Product events without an advertising identifier Yes, if you save anything on the device No Declare category
Data combined exclusively on the device, without external transmission Yes, but this is the mildest case No. Apple explicitly excludes this from the definition of tracking Depends on the category

The last row is more important than it seems at first glance (and we’ll return to it in the section on attribution modeling).

One more rule that (as a rule) few people know about, and can be surprising during an App Review audit: Apple treats the mere placement of a third-party SDK in your app as tracking if it combines your data with data from other developers’ apps for advertising purposes, even if you do not use this feature. So in practice… there is a good chance you are responsible for what someone else’s code does in your product.

 

Moving measurement to the server: what you gain and how it works

This is the most underestimated change you can make, and at the same time the one that pays off the fastest in results.

What is the problem

By default, your events fly to Meta and Google straight from the device, through the SDK built into the app. This route has three weak points. The event is lost when the user closes the app at the wrong moment or loses coverage. You have no control over what exactly the SDK sends, because it is someone else’s code. And you have no way to check the consent status before sending, because the decision is made inside the library.

What is the solution

You send events from your server, via API. Meta calls this Conversions API and has a separate version for app events, with the action_source parameter set to app. Events go to a so-called dataset, which is what used to be called Pixel ID.

In-app conversion tracking: How to track conversions without violating GDPR and store policies?

What exactly do you gain:

  • Control over consent. The server checks your database to see if the user has given consent before sending anything. This is the only place where you can do this truly reliably.
  • Event completeness. A conversion saved in your database will reach Meta regardless of what the user’s phone is doing at that moment.
  • Data enrichment. You add to the event what you have in the database, which the SDK does not see: order value after returns, subscription status, segment affiliation.
  • A single integration point. Meta allows sending web, app, offline, and messenger events through a single endpoint.

 

What to watch out for

 

Deduplication is mandatory. If you leave the SDK and add CAPI, Meta will count every conversion twice, and you will make budget decisions on inflated numbers. Deduplication is done through a shared event_id passed in both paths. Meta uses the same mechanism for apps as for websites, and requires it for all existing app event integrations, including SDK and MMP.

Personal data must be hashed. Email addresses and phone numbers must be normalized and hashed using the SHA-256 algorithm before sending. Beware of a common misunderstanding: hashing does not change the legal status of this data. A hashed email is still personal data, and you still need a basis to transfer it.

Hashing protects data in transit, it does not relieve you of your obligations.

In April 2026, Meta made available a simplified CAPI configuration without developer involvement. This is a basic version: if you need to decide which events fly and with what parameters, direct integration remains the choice.

This is where it’s easiest to make a mistake, so let’s break it down into two different mechanisms.

Consent Mode v2 is the way you tell Google what the user has consented to. Four parameters: analytics_storage, ad_storage, ad_user_data, ad_personalization. It applies to advertisers targeting the European Economic Area since March 6, 2024. In the app, they are set through Firebase, in versions at least 21.5.0 on Android and 10.17.0 on iOS.

The idea is this: a user without consent does not disappear from the system; instead of identified data, signals without identifiers are sent. So Google knows the number of events without consent and knows the full data of events with consent. Based on this, it estimates how many conversions are hiding in the group without consent, and adds them to the report.

Three things you need to know about this. This is an estimation, not a measurement; in the report, you see conversions that nobody counted. The model needs data to learn, so with low traffic, it might not work at all. And most importantly: if you don’t implement Consent Mode, you get nothing. In the EEA, conversion reporting for optimization, building and targeting remarketing lists, and demographic reporting then stop working. No one will reconstruct data from the period without signals retroactively.

Mechanism two: on-device measurement and ICM

This is newer and much less known. Integrated Conversion Measurement (ICM) is Google’s protocol for app campaigns, rolled out since May 2025 together with measurement providers. It works on on-device measurement: conversion signals are processed locally on the phone and aggregated before anything goes outside.

And here the last row of the table from the previous section comes back. Apple explicitly excludes from the definition of tracking the situation where data is combined exclusively on the device and does not leave it in an identifying form. The entire on-device measurement is designed around this sentence, which is why it works for a user who refused ATT consent.

ICM covers three groups previously considered lost: iOS users without ATT consent, Android users from the EEA, and everyone who turned off system-level tracking. At Google Marketing Live in May 2026, Google announced the expansion of reach to the EEA, the UK, and Switzerland, as well as covering web-to-app paths and view-through conversions.

Practical note: ICM is enabled on the MMP and SDK side, not in the Google Ads panel. If your measurement provider doesn’t support this or no one has turned on on-device measurement, you simply don’t have it.

 

First-party data: five places in the app where you collect data naturally

Everything above is about how to better transmit the data you have. This section is about how to have more of it without violating anyone’s trust.

There is one rule and it’s worth remembering: Collect data where the user is already doing something anyway, and where they see what’s in it for them. Everything else is a form that ruins conversion and generates junk records.

 

  • Registration and login. The most obvious and most often wasted. You collect an email, but you don’t collect marketing consent as a separate, voluntary option, so later you can’t use this address. Separate account consent from marketing consent and save both with a date.
  • Onboarding with a question about purpose. A screen like “what are you looking for in the app” with three tiles. The user gets a personalized start, you get a segment on the first session. This is the best value-to-friction ratio in the entire app.
  • Notification settings. Instead of a single switch, provide a choice of categories. You get a preference map, and by the way, a higher opt-in for notifications, because the user doesn’t have to agree to everything at once.
  • First transaction or first key action. The moment of highest trust in the entire relationship. Here you ask for data expanding the profile, for example about the industry or company size in a B2B product.
  • Behavior in the product. You don’t ask about anything, you just observe: which features are used, what the return frequency is, where people drop off. This is data that no advertising network will give you, and it best predicts customer value.

The ethical minimum for each of these five points: tell them why you are asking, allow them to skip, do not block features behind marketing consent. The latter is not just a matter of decency; forced consent does not meet the condition of being voluntary and legally does not exist.

How to combine your own data with Meta and Google campaigns

Collected data must be put to work, otherwise it is just a storage cost.

Customer Match in Google Ads

You upload a list of hashed email addresses or phone numbers, Google matches them to user accounts and creates an audience from it. You can target ads to it, exclude it, or use it as a signal to find similar people.

Practical parameters from Google’s policy: the list has a maximum membership duration of 540 days, and to remain active, it must have at least 100 members added or updated within this period. Data must be hashed using the SHA-256 algorithm. The account must meet requirements regarding the history of policy compliance. In the case of lists based on mobile identifiers, only users active on Google networks in the last 30 days are included.

One technical change to pass on to the IT department: since April 1, 2026, the old API services for uploading lists do not work for new integrations, and Google directs you to the Data Manager API.

Conversions API in Meta

The same logic, but instead of audience lists you send events, described in the previous section. App events go to the dataset and are processed in the same way as those from the SDK or from an MMP, with mandatory deduplication.

The condition that invalidates everything above

For both, you need a legal basis to transfer data specifically to these companies. Consent for “data processing for marketing purposes” written vaguely into terms and conditions from three years ago will most likely not suffice. Google explicitly requires this in its own EU user consent policy for partners uploading lists.

This is a place where talking to a lawyer really pays off, because it concerns a single paragraph on your consent screen, and determines whether you can use Customer Match at all.

The order in which all this must run

There is one thing left, without which the previous sections won’t work, and this is the most common implementation error in apps.

Analytics libraries start when the app launches, because that’s what the default installation instruction looks like. The consent screen is an interface element and appears a few screens later. The order turns out to be the reverse of what was intended, and nothing indicates this, because nothing breaks.

The correct order:

In-app conversion tracking steps

Step 2 is skipped most often and requires one thing from your developer. Google provides four keys for the info.plist file, starting with GOOGLE_ANALYTICS_DEFAULT_ALLOW_, and writes directly in the documentation that by default no consent values are set. There is no default refusal. Without these keys, the entire consent mechanism is merely a “decoration.”

How does it look in the case of Android?

On the Android system, the equivalent of the iOS settings is the AndroidManifest.xml file. Inside the <application> tag, analogous <meta-data> tags should be added, assigning them a value of false. Only after calling the setConsent() method in the code with the values selected by the user, the SDK on both platforms will safely switch the consent status from DENIED to GRANTED.

Step 3 before step 4 is not a marketing gimmick, but a condition for informed consent. A person who does not yet know what the app is for has no way of evaluating whether they want to agree. By the way, this order increases the consent rate, because the question is asked when the user already sees value.

When a user withdraws consent for analytics or advertising data, Google Analytics removes all user properties, including the saved consent for ad personalization. It must then be restored with a separate call.

Connect a test device to a network traffic capture tool, install a fresh copy of the app, and run it. Do not touch anything.

If in the first few seconds, before the consent screen appears, you see connections to the domains of the analytics provider, MMP, or advertising network, you know where to start.

Do you want to be sure that your app collects data legally and efficiently? Order an audit of your app. We check the initialization order, consent configuration, server-side event completeness, conversion value schema, and declarations in both stores. You get a list divided into what fixes compliance, and what will realistically improve campaign results.

 

In-app conversion measurement – summary

What is the most important thing from this article? Legal compliance and data quality are equal goals. A team that orders the startup sequence, moves events to the server, and collects proper consents, simultaneously gets lower legal risk and more complete reports.

The sequence of actions, if you had to do it from scratch:

  • Check when your SDKs start. If before the consent screen, this is priority number one, and the fix takes hours, not weeks.
  • Implement Consent Mode v2 if you advertise in the EEA. Without it, you lose optimization and remarketing, and no one will inform you about it.
  • Ask your MMP about ICM. It’s the cheapest way to regain visibility of users without consent.
  • Move key events to the server via Conversions API, keeping deduplication in mind.
  • Organize the five places for collecting first-party data and separate account consent from marketing consent.
  • Only then launch Customer Match and similar tools, because without a legal basis and without data, they have nothing to work with.

 

Frequently asked questions

Is the ATT prompt enough as consent under the GDPR? No. ATT is an Apple policy requirement. The consent required by GDPR and ePrivacy must be collected separately, documented, and it must be possible to withdraw it.

Does hashing the email exempt me from the consent obligation? No. A hashed address remains personal data. Hashing secures data in transit and is technically required by Google and Meta, but it does not replace a legal basis.

Does Conversions API allow bypassing privacy restrictions? No, and that is not its purpose. It improves completeness and control over the data you have consent for. Sending from the server without user consent is a violation just like sending from the device.

Will I lose data if the user does not give consent? Partially. Conversion modeling through Consent Mode, on-device measurement through ICM, and aggregating Apple frameworks remain. You will not get data at the individual user level.

Have third-party cookies been phased out? No. Google backed away from this on April 22, 2025, and on October 17, 2025, it withdrew most of the Privacy Sandbox. There are no cookies in mobile apps anyway.

Where to start if I have limited developer time? With the initialization order of SDKs and the default values of Consent Mode. It’s the smallest workload with the biggest impact on both compliance and data quality.

Sources

Google / Google Ads documentation and help

 

Privacy Sandbox initiative

 

Meta / Facebook documentation

 

Apple documentation

 

Legal regulations and authority guidelines (EU / PL)

 

Analytics platforms and MMPs (Mobile Measurement Partners)

This text does not constitute legal advice. Documentation state as of August 6, 2026. Platform documentation changes frequently, so verify the currency of sources before implementation.