Adobe Experience Platform Mobile SDKs – Privacy & Visitor IDs

This article is part of the Adobe Experience Platform Mobile SDKs mini-series. It is about privacy, opt-in, opt-out, and how you can have sensible visitor IDs in a hybrid app.

You can find the overview here.

This article is not going to tell you whether anything is GDPR-compliant, or legally ok, or anything like that. I am not a lawyer, and only a (your) lawyer can tell you.

Privacy

There are a lot of aspects of privacy, and so we’ll concentrate on one, and call it out specifically: can I make it so tracking of my app users can be switched on or off, depending on their wishes?

The common terms here are “opt-in” and “opt-out”, and the interesting questions usually are

• do I ask my users to tell me when they want to be tracked? Or
• do I ask my users to tell me when they don’t want to be tracked? And
• what happens before they had their say?

The Experience Platform Mobile SDKs come with a mechanism that implements those three questions. The good news: it is really easy to use. The bad news: it won’t help you through all the discussions with legal on which way you should go.

When you set up your Mobile Property in Launch, you have three options:

These options, in turn, mean the following:

Within your app, you can then prompt users, ask them for their preference, and handle changes, using the MobileCore.setPrivacyStatus() (documentation) method.

So, the setting on the Mobile Property influences what the AEP Mobile SDKs do by default, and MobileCore.setPrivacyStatus() allows you to change the default, i.e. do what the user tells you to do.

Simple as can be, so no reason not to use it!

On the actual states: I think “Opted in” and “Opted out” are pretty easy to understand: we either send data, or we don’t.

Setting the default to “unknown”, though, means that the AEP Mobile SDKs queue everything.

This means that if you manage to get an opt-in from your users at some later stage, you can send everything that has been queued. It means that if you select “unknown” as your default, you must absolutely enable timestamps on your report suite, because that queued data will arrive timestamped.

If your report suite does not accept timestamps, the AEP Mobile SDKs will not queue any Analytics data, not even with the default set to “unknown”. There would be no point.

Passing IDs into WebViews

A lot of apps out there are hybrid apps, i.e. part of the app is simply pages from a web site being loaded into WebViews into the app.

In cases like that, and if you want to track “both parts” of your app, you run into an issue with visitor IDs: while the app manages a visitor ID for each user (stable from install, through updates, until uninstall), the WebView is ultimately a normal browser, and so tracking inside a WebView relies on Javascript, and cookies.

Consequence: you’ll have two visitor IDs per user, and you won’t be able to see how people move around all of your app. Visits are going to be cut off at the hand-over from app to WebView.

Ouch

But there is a built-in method that passes the visitor ID into the WebView, and Javascript code (since Visitor API 1.7, released in August 2016, I believe) picks it up automatically, meaning your users will have the same ID in both parts of your app.

The Identity.appendVisitorInfoForURL() (documentation) method is what you need, and the documentation has good examples on how to use it.

In our sample app, we could use it like so:

    final String urlForWebViewAsText = targetJSONResponse.getString("url");
    URL url = new URL(urlForWebViewAsText); // I like to check my URLs
    final WebView webView = findViewById(R.id.webView);
    if (urlForWebViewAsText.length() > 0) {
        Identity.appendVisitorInfoForURL(urlForWebViewAsText, new AdobeCallback<String>() {
            @Override
            public void call(final String urlWithVisitorID) {
                runOnUiThread(new Runnable() {
                    @Override
                    public void run() {
                        textView1.setText(textForTextView);
                        webView.loadUrl(urlWithVisitorID);
                        Snackbar.make(view, "Content replaced", Snackbar.LENGTH_LONG)
                                .setAction("Action", null).show();
                    }
                });
            }
        });
    }

I did not do that before, because I currently do not have any Adobe applications deployed on webanalyticsfordevelopers.com. Yeah, I know. One day, I’ll migrate the blog to my own server, but that is currently not priority.

The other interesting conundrum: if you track your web site into one report suite, and your app into another one, but then your app loads pages from your site, what do you do?

I have seen some people build code into their site that switches report suites, accordingly. You will have to load pages into your app with further parameters, so that switcher knows what to do.

Check out the Identity.getURLVariables() (documentation) method, which will allow you to build your own URLs, and still attach everything that is needed for passing visitor IDs into WebViews.

By the way: if you are interested in any of the visitor IDs in your app — maybe you want to track it, or store it somewhere — you can retrieve the Experience Cloud ID using the Identity.getExperienceCloudId() (documentation) method, or other IDs using the MobileCore.getSdkIdentities() (documentation) method.

If you want to track the Experience Cloud ID into Analytics, it might be easier to just use the built-in Data Element, though.

Easy.

Privacy and IDs are, overall, surprisingly straight-forward in apps, at least when you’re using the AEP Mobile SDKs.