# From JavaScript Tags to Native SDKs: Understanding Mobile vs Web CMP Architecture

![](https://cdn.hashnode.com/uploads/covers/6a69b6ac546b5ad90f2dd280/fd472176-2130-411c-a7b1-7ca4f5d675a2.jpg align="center")

A website and a mobile app can belong to the same business, but they do not handle tracking in the same way.

That is one reason a **web CMP and mobile CMP are not simply interchangeable**.

On a website, consent management works within the browser. On a mobile app, it has to work within the app itself and with the tools installed in it.

## How does a Web CMP work?

A web CMP is added to your website. It can display a consent notice, let visitors choose their preferences, and communicate those choices to the tags and services running on the site.

For example, if your website uses Google Analytics or advertising tags, your consent setup needs to tell those tools what the visitor has allowed.

Google supports consent mode for websites and explains that the setup can control when Google tags load and how they respond to a user's consent choice.

This is mainly a **browser-based setup**.

## What changes in a mobile app?

A mobile app has a different environment.

There are no website pages where you can simply add a JavaScript tag. Instead, apps often use SDKs for analytics, advertising, attribution, and other services.

That means your consent solution needs to communicate with those SDKs.

Google's documentation, for example, explains that an app consent banner can communicate consent information to SDKs, which then adjust their behaviour based on that information.

This is where a **mobile app CMP** becomes different from a web CMP.

## Why does this matter for tracking?

Imagine your company has:

*   A website with Google Analytics
    
*   An iOS app with analytics and advertising SDKs
    
*   An Android app with similar tools
    

You cannot assume that the consent setup on your website automatically covers what happens inside both apps.

The implementation has to match the platform.

Apple has its own **App Tracking Transparency** framework for certain types of tracking across companies' apps and websites. On iOS 14.5 and later, apps need the user's permission through this framework to track them in the way Apple defines or access the device's advertising identifier.

So there may be more than one privacy control involved in a mobile app.

## Web CMP vs Mobile CMP: the simple difference

The easiest way to think about it is:

**Web CMP → website + browser + web tags**

**Mobile CMP → app + SDKs + mobile tracking tools**

The goal is similar: give users control over how their data is used.

The way you implement that control is different.

If you want to see the differences side by side, this [mobile CMP vs web CMP comparison](https://seers.ai/blogs/mobile-cmp-vs-web-cmp-complete-comparison/) covers the main differences in setup, tracking, and consent handling.

## What if you have both a website and an app?

You need to think about both environments instead of trying to force one setup everywhere.

For the app side, [Seers Mobile App CMP](https://seers.ai/mobile-app-cmp/) is built for mobile apps and supports consent management through app-based integration.

For the website side, [Seers](https://seers.ai/) provides consent management for web environments.

The important thing is not simply adding a consent banner.

Your consent choices need to reach the tools that collect or use data, in the environment where those tools are running.

That is what makes the difference between having a CMP and having a consent setup that actually works.