Overview

This document provides comprehensive guidelines for implementing consent management in mobile applications, ensuring compliance with data protection regulations including GDPR, LGPD, and IAB Transparency & Consent Framework (TCF) requirements. It addresses proper handling of user consent for third-party services including advertising networks, analytics platforms, and other tracking services.

Implementation Requirements

1. Don’t initialize Third-Party Services Without Consent Verification

Implementation Steps:

1. Check if user has made a consent decision
2. Verify consent for the specific vendor/service
3. Only initialize the service if both conditions are met
4. If no consent was granted for a given vendor or purpose, you’ll need to:

2. Two-Phase Consent Checking

Always implement both checks as required by GDPR Article 7(1) and IAB TCF specifications:

Phase 1: Has user made a decision?

• Check if the user has interacted with the consent layer
• If no decision has been made, do not process personal data

Phase 2: Does user consent to specific purpose?

• Check if consent was granted for the specific third-party service
• Each vendor/service requires individual consent verification

User Workflow Scenarios

Scenario 1: Normal User Workflow

Flow: User opens app → SDK shows consent layer (if needed) → User makes choice → App continues with appropriate services

Implementation Steps:

1. App Startup: Initialize consent management platform. You’ll use the method checkAndOpen() for that. Check the examples on our help docs (iOS, Android)
2. Consent Check: the previous step will determine whether consent is needed or not automatically, so the user can inform consent decision. 
3. Service Initialization: Initialize services based on user consent choices

Implementation example:

// This hypothetical example assumes you have implemented: 
//   - OneSignal (s1448)
//   - Google Ads/AdMob (s1)
//   - Google Analytics (s26)

class yourGreatApp {

    void function onAppLaunch() {
        if shouldInitializeService("s148") {
            OneSignal.initialize("your-token")
        }
    
        if shouldInitializeService("s1") {
            AdMobService.initialize()
        }
    
        if shouldInitializeService("s26") {
            FirebaseAnalytics.initializeApp("your-token")
        }   
    }
    
    
    boolean private function shouldInitializeService(string: purposeId):
        // Phase 1: Check if user has made any decision
        consentStatus = CMPManager.getUserStatus()
        if consentStatus.status = "choiceDoesntExist"
            return false  // Consent Layer was not yet displayed to this client
        
        return CMPManager.shared.getStatusForPurpose(id: purposeId) == "granted"
    }
}

Scenario 2: No Internet Connection

Flow: User opens app without internet → CMP cannot load consent layer → App must handle gracefully

Critical Observations:

• Our mobile SDK cannot retrieve configuration from servers
• Previous consent decisions may still be valid (as per GDPR Article 7(3) on consent withdrawal)
• App must function in degraded mode without processing personal data in case no consent was given yet

Implementation Strategy:

1. Check for possible persisted consent data from previous sessions (you’ll use getUserStatus() as in the preivous example for that)
2. If a previous consent exists, proceed normally
3. If no persisted consent and no internet:

• • Block all non-essential third-party services
  • Show user-friendly message explaining the situation
  • Set up connectivity listener to retry when connection restored, and display the consent layer when this happens
  • Allow basic app functionality that doesn’t require personal data processing

User Experience Considerations:

• Display clear message about limited functionality
• Implement retry option when connection available
• Explain that no personal data will be shared until privacy choices are made
• Provide option to continue in limited mode

Scenario 3: No Consent Necessary

Situation: User is outside EU and CMP is configured to only display in EU → No consent layer shown

Implementation Strategy:

1. Initialize CMP configuration as normal
2. Allow CMP to determine if consent layer should be shown using checkAndOpen()
3. If consent is not required, user status will return “choiceExists” and vendors and purposes will be set to “granted”
4. Initialize all services normally

React to Consent Changes

Consent changes can happen in several scenarios:

• User opens consent settings and changes preferences
• Consent expires and needs renewal (this setting can be found under Legal on your CMP dashboard)
• Legal requirements changes that force recollection of consent
• User requests data deletion

The checkAndOpen() method will react to all of those situations. Implement a listener that will tracks consent changes. You can use the didReceiveConsent callback for that (iOS and Android). If at any time a given vendor or purpose is rejected, take action immediately and block the services accordingly.

Testing Checklist

Functional Testing

Normal Flow Testing:

• App starts correctly and shows consent layer when needed
• User consent choices are properly recorded and respected
• Services initialize only with appropriate consent
• App functions correctly after consent decisions

Rejection Flow Testing:

• User rejection properly blocks third-party services
• App remains functional or enters degraded mode depending on your revenue strategy

Offline Testing:

• App handles no internet connection gracefully
• Cached consent data is used appropriately
• Privacy-friendly mode activates when needed
• Connection restoration triggers proper retry logic

Timeout Testing:

• Consent layer timeout triggers appropriate fallback
• App doesn’t freeze or crash during timeout
• Fallback mode properly blocks data processing
• User receives clear communication about status

Compliance Testing

Data Processing Verification:

• No tracking data sent before user makes consent decision
• Vendor IDs correctly mapped to actual services
• Individual service blocking works as intended
• Consent granularity properly implemented

Legal Requirement Verification:

• Consent withdrawal stops data processing immediately
• Data subject rights can be exercised through app
• Proper audit trail maintained for consent decisions
• Legal basis documented for all data processing

Troubleshooting

Common Issues and Solutions

Issue: Services initialize even when consent is denied

Root Causes:

• Missing consent check before service initialization
• Incorrect vendor ID mapping

Solutions:

• Add explicit consent check before ALL third-party service initialization
• Verify vendor IDs match those in Global Vendor List
• Implement proper synchronization between consent and service initialization
• Clear service instances when consent is revoked

Issue: Consent layer never appears
Possible Causes:

• Incorrect CMP configuration (wrong ID, domain, etc.)
• Network connectivity issues
• User is outside target geographic region
• App integration problems

Debugging Steps:

• Verify CMP configuration matches account settings
• Test network connectivity and CMP server accessibility
• Check console logs for error messages
• Test with force-open consent layer to verify integration
• Confirm geographic targeting settings in CMP dashboard

Implementation Priority Checklist

High Priority (Must Complete Before Launch):

• Consent verification implemented before ALL third-party service initialization
• Proper error handling for timeout, network, and configuration issues
• Basic app functionality preserved when consent cannot be determined
• All vendor IDs verified and correctly mapped to actual services

Ongoing Improvements:

• Follow up analytics on your CMP dashboard for consent success rates
• A/B testing for consent layer optimization
• Integration with additional compliance frameworks
• Enhanced user education about privacy choices