Why do consent rates differ so significantly between desktop and mobile?

Consent rates differ between desktop and mobile mainly because the banner looks and behaves differently on a small screen, and because mobile visitors more often arrive through in-app browsers or browsers that delete stored choices sooner. Sometimes the gap is a technical fault: the banner or the consent update loads too late on mobile, so choices are not passed to Google tags at all.

First separate two questions. Do mobile visitors actually decline more often, or are their choices simply not being recorded? The first is a design and behaviour question. The second is a tagging bug that you can find and fix.

Why is consent on mobile different?

• Banner layout. On a phone, the banner often covers most of the screen, buttons are stacked, and one option may only be visible after scrolling or on a second layer. Small changes in layout change what people click.
• No interaction at all. Many mobile visitors leave before touching the banner. “No choice” is not the same as “declined”, but in most reports both end up outside the consented group.
• In-app browsers. Links opened from social or messaging apps run in the app’s own browser. A choice made there is often not available in the next session, so the banner appears again and the same person is counted several times.
• Browser privacy features. Some mobile browsers limit how long cookies set by scripts are kept. If the consent cookie expires, returning visitors see the banner again.
• Different traffic mix. Mobile traffic often comes from other channels and campaigns than desktop traffic. Visitors with low intent decline or ignore banners more often, independent of the device.

Is it a technical error?

Check this before changing the banner design:

1. Same banner configuration. In your consent management platform (CMP), check whether mobile uses a different template, a different default or a different script-blocking setting.
2. Default before any tag. Open Tag Assistant with a mobile user agent and select the earliest Consent event. The default for ad_storage, ad_user_data, ad_personalization and analytics_storage must be set before any tag fires.
3. Update after the click. Accept the banner and check that a consent update follows on the same page, before the visitor navigates. If the update only arrives on the next page, or not at all, choices are lost.
4. Asynchronous CMP. If the banner loads asynchronously and slowly on mobile networks, Google recommends the wait_for_update setting so tags wait a short time for the update.
5. Persistence. Reload the page. If the banner appears again although you already chose, the consent cookie is not stored or not read correctly.

What can I improve without pressuring users?

• Compact, readable banner. Show the key information and both options on the first screen, without hiding content more than needed.
• Equal options. Accept and decline should be equally easy to reach. Which design is permitted in your market is a legal question; clarify it with your data protection officer.
• Fast loading. Load the CMP early and keep it light, so the banner is ready before visitors scroll or leave.
• Measure per device. Compare consent rates by device in your CMP’s statistics before and after each change, and change only one thing at a time.

Rule out the technical causes first: same configuration on all devices, default before every tag, update on the same page. Only then optimise the mobile banner layout, and measure every change per device.

Sources

• Google Ads Help: About consent mode
• Google for Developers: Set up consent mode on websites
• Google for Developers: Troubleshoot consent mode with Tag Assistant

Want to know whether your mobile consent gap is a design issue or a tagging error? We check your banner, CMP and consent mode on every device and show you where choices get lost. Book a free intro call or read more about our tracking agency.