Opt-out scenarios

  • Advertisers
  • Developers

AppsFlyer enables app owners to comply with opt-out regulations, like GDPR, and user requests not to record attribution data. 

opt_out.jpg

Where app owners are prohibited or choose not to fully record user actions and attribution data, these users need to be opted-out in AppsFlyer. AppsFlyer enables a range of opt-out options from the total cessation (stopping) of attribution recording to the partial recording of events on a session by session basis. The opt-out scenarios described here enable app owners to select whom and what to opt-out. This enables app owners to comply with different regulatory requirements, like GDPR.

Opting-out can take place at a number of different levels depending on the regulatory and user requirement. 

 Note

  • Follow the appropriate flow using an opt-out scenario as detailed. This so as to ensure compliance with opt-out requests and in order to continue to collect attribution data where appropriate
  • In scenarios where opt-out is activated, the AppsFlyer ID is hashed

Scenarios

Opt-out on installation

coppa_compliant_appsflyer.png

When: Upon the first launch (Example, COPPA compliance)

What: The app requires the user's agreement to perform event recording during all sessions. If the user consents to recording (example, user above a certain age) the app calls the SDK startTracking method. Otherwise, the startTracking method should simply not be called

 Caution

Don't use stopTracking if startTracking was never called.

How: The startTracking method should always be called at the session start of opted-in users, but shouldn't be called for opted-out users. In addition, in-app events cannot be sent for users who have never opted-in, as they are regarded as coming from unknown users and go to organic.

Therefore, for apps, we recommend that enable Installation opt-out, has a permanent flag parameter that shows if startTracking was called beforehand or not. This flag should ALWAYS be checked before calling startTracking or sendEvent methods are called.

Data sent to AppsFlyer: No data is sent. If the user subsequently opts-in attribution and session data are sent from the time startTracking is called. 

 Example

com.carefulapp requires users to register upon installing. The form includes a check-box: "I'm over age 13". Dev the developer added a flag called is_tracking, which becomes true only for registrations that have this box checked, and then activates startTracking.

Code sample example here.

Session opt-out

When: Upon every app launch

What: All app sessions require the user's agreement to perform event and data recording during a session

How: For the Session opt-out scenario the first SDK call comes after the user agrees or refuses that data be sent from their device.

If the user agrees to send data then startTracking method should be called.
If the user refuses that data be sent then stopTracking method should be called.

Data sent to AppsFlyer will depend on the opt-out status of each session as follows: 

  • Opt-out session: No data is sent. 
  • Opt-in session: All session data is sent. Note: The first time the user opts-in install attribution data is sent. 

 Example

com.adultsplay is a casual gaming app for adults over 18 years old. It doesn't require users to register, but it does require their confirmation of age with every new launch. Sessions where the users confirm they're over 18 get the full gaming experience and are recorded, while otherwise no recording is carried out.

Dev the developer added a flag called is_tracking, which becomes true only for sessions that confirm age 18. ONLY if this flag is true AND the new session is NOT confirmed for age, the stopTracking method is called.

One time opt-out

OpenGDPR-logo-BLK.png

When: Anytime (GDPR)

What: The app owner collects attribution and post-install data. The user requests to stop further collection of data, Example In compliance with a GDP request GDPR.

How: Don't call startTracking and then directly call stopTracking!

Instead, on the first launch use the startTracking method with the requestListener. Upon successful completion, in the callback function call stopTracking.

On all the following sessions don't call startTracking.

Data sent to AppsFlyer: Install and session data is sent to AppsFlyer. No data is sent to AppsFlyer after the stopTracking method is called. 

 Example

com.watchmegrow is a plant growth viewing app, where users watch growing plants and mobile ads. The app owner wants to keep all in-app activities data secret.

On the first launch, Dev the developer calls startTracking method with the requestListener. When receiving a successful completion, calls stopTracking from the callback function and sets a persistent parameter is_first_launch to false. On the following launches Dev checks if is_first_launch is false, and then skips startTracking.

 

Code sample example here

 Record install and anonymize

When: Upon the first launch

What: The app owner collects all attribution data, but wants to collect all further information, such as in-app events or sessions data, as unattributed organic data. Post-installation, all device IDs are anonymized when sent to AppsFlyer from the SDK.

How: Don't call startTracking and then directly call stopTracking!

Instead, on the first launch use the startTracking method with the requestListener. Upon successful completion, in the callback function call setDeviceTrackingDisabled(true).

Data sent to AppsFlyer:

  • On install: Complete attribution data is sent to AppsFlyer
  • After install: Session data including in-app events are sent to AppsFLyer. User identification information is anonymized or hashed on receipt by AppsFlyer. 

 Example

The app owner of the com.munistic app believes all users are born equal and prefers to see all their post-install actions as organic only.

On the first launch, Dev the developer calls startTracking method with the requestListener. When receiving a successful completion, calls setDeviceTrackingDisabled(true) from the callback function.

Code sample example here.

Opting out of retargeting campaigns

Consider excluding opted-out users from retargeting campaigns. These users are likely to complain about being retargeted having opting out.

When manually running retargeting campaigns, targeted at active users, make sure to remove the opted- out users from the lists sent to media sources lists.

Alternately, if you're using AppsFlyer Audiences (to automatically build your audience lists and send them to selected media sources), then opted-out users are excluded from the media device lists sent to media sources by AppsFlyer.

stopTracking API and deep linking

Using the stopTracking API stops all external communication by the AppsFlyer SDK embedded in the app.

Therefore, after calling stopTracking, shortened links are no longer decoded by the AppsFlyer SDK. This means that any shortened link does not generate the call to onAppOpenAttribution, and deep linking isn't performed correctly.

If your app has a relatively high percentage of opted-out users and you plan some retargeting campaigns for your users, use regular links and avoid using shortened links.

Restart the SDK function

When an opted-out user agrees to opt-in call the startTracking method to restart the SDK and begin recording attribution data.

Was this article helpful?
0 out of 0 found this helpful

Page Contents: