Testing & Debugging Google Consent Mode v2 Signals on Apps

Proper testing ensures that Google Consent Mode (GCM) signals are set correctly and that downstream SDKs (Firebase, Branch, Airbridge, Kochava) behave as expected.

✅ What to Verify

  1. GCM signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) are applied according to user consent.

  2. Signals propagate to integrated SDKs:

    • Firebase picks up changes immediately.

    • AAP SDKs (Branch, Airbridge, Kochava) receive updated consent values.

  3. Behavior changes dynamically if the user updates consent.

  4. Correct defaults are applied before user interaction.

🔍 Tools for Debugging

  • Didomi SDK Logs

  • Firebase DebugView

  • ADB (Android) or Xcode Console (iOS) for runtime logs

  • Network sniffers (e.g., Charles Proxy) for verifying event payloads

🛠 Step-by-Step Testing Guide

1. Enable Debug Logs

Activate verbose logging in Didomi SDK:

// Android
Didomi.getInstance().setLogLevel(LogLevel.DEBUG)
// iOS
Didomi.shared.setLogLevel(.debug)

Check in your app logs for successful consent update:

FirebaseAnalytics: Consent updated successfully

You can refer to steps 4 and 5 below for more detailed validation depending on your integration (Firebase, Kochava, Branch or Airbridge).

2. Validate Initial Defaults

Before any user action, ensure the default status you configured in the Didomi Console is applied.

Expected output matches your SDK config.

3. Simulate User Consent

Perform the following scenarios:

  • Full consent given

  • Only analytics consent given

  • Consent refused

  • Consent updated after initial choice

Monitor logs to confirm updated status.

4. Test Firebase Integration

  • Enable Firebase DebugView:

    • Android: adb shell setprop debug.firebase.analytics.app <your.package.name>

    • iOS: Launch with -FIRDebugEnabled argument

  • Open DebugView in Firebase Console:

    • Verify events stop sending analytics data if analytics_storage = denied.

    • Check if personalization is disabled when ad_personalization = denied.

5. Validate AAP SDK Signals

Branch

  • Check console logs for:

Branch set EEA = 1 and adPersonalization = false

  • Confirm correct behavior for GDPR vs non-GDPR.

Airbridge

  • Validate eeaRegion value in SDK logs.

  • Confirm updated status for personalization and user data.

Kochava

  • Monitor install/event payload for consent string.

  • Confirm it includes TCF or GPP fields.

6. Network Verification

Use Charles Proxy or similar:

  • Inspect Firebase or AAP SDK payloads.

  • Ensure consent-related parameters match Didomi-calculated values.

✅ Best Practices

  • Test on multiple regions (GDPR vs non-GDPR).

  • Verify behavior on first app launch and after consent changes.

  • Always use real SDK builds, not mocks, for final validation.

⚠️ Common Issues

  • Missing or incorrect default values → Signals may be set to a specific state depending on the integration you use (Firebase, Airbridge..).

  • Integration not enabled in Didomi Console → No GCM updates are propagated.

  • Firebase Analytics still sending events when consent denied → Debug Firebase config.

Next Steps

PreviousGoogle Consent Mode - implementation stepsNextDeprecated: Manual setup

Last updated