Smartlook

Android

iOS

React Native

Flutter

Ionic

Cordova

Unity

Unreal Engine

Cocos

Xamarin

Web
SDK Installation
SDK Conceptual
Setup & Start RecordingWhen The Recordings Appear in Dashboard?Life Cycle, Session, UserWhat is recorded and howHandling Sensitive DataScreen Recording QualityEvent TrackingRecording NavigationIntegrating with Other Tools
SDK API reference
SDK Cookbooks
SDK Integrations
REST API (beta)

Handling Sensitive Data

The goal of analytic is to understand the user journey in the application and their interaction with it to improve the user experience. To gather the necessary data, Smartlook follows user actions and records what users see on the screen. This indeed represents a challenge for protecting user privacy - out of decency, the law requirements, and also because the data itself is rarely needed for analytical purposes.

What analytics uses is the metadata.

There are several ways how Smartlook protects user privacy when gathering the information it needs for its purposes. Smartlook obfuscates out of the box the native visual elements that typically contain private information. The data are replaced by neutral colour boxes during the recording process, they never make it to our systems. Moreover, Smartlook offers a set of methods that enable application developers to avoid recording unnecessary information.

Also, Smartlook provides an open-source Consent SDK for iOS and Consent SDK for Android, that allows application authors to get user consent to gather the data for analytical purposes.

Handling UI with Sensitive Data

Potentially any UI element may contain sensitive information that should not be recorded. On the other hand, some elements that are not recorded by default may contain harmless data vital for analytics. Smartlook offers a comprehensive set of methods to handle various scenarios.

Terminology: in Smartlook, disabling UI element recording is done by blacklisting it. Enabling UI element recording is done by whitelisting it. Blacklisted UI elements are also called sensitive.

Most UI elements are whitelisted by default. Some types of UI elements (text edits, web views) are blacklisted by default.

There are three levels of granularity established for handling the sensitive data recording:

  • individual UI elements recording
  • UI element types recording
  • the whole screen recording

In order to provide robust user privacy protection by default, some UI elements, namely text inputs and web views (that typically contain sensitive user data) are not recorded in the default Smartlook setup. The application author must take active steps to whitelist these elements in order to record their content.

Handling Sensitivity of Individual UI Elements

In order not to record a particular view, like here in an example with an image view that shows a portrait image of the user, use a variable that holds a reference to the view with one of the following approaches to black list it, e.g.,

When, on the other hand, an otherwise blacklisted view (in our example a web view) should be recorded, follow this example code:

More on the topic in API reference.

Handling Sensitivity of Classes

This functionality is available only on some platforms. Please consult the API reference if it is available for a particular development toolchain.

In some use cases, whitelisting or blacklisting individual views is not practical, e.g., in an application that heavily uses web views for presenting some insensitive content, or if the application defines its own subclasses of visual components that present sensitive user data.

To cover this use-case, Smartlook offers on some platforms a convenient way to blacklist or whitelist all descendants of some class or visual elements that conform to a protocol.

Handling Content Presented in WebViews

Native WebView classes are blacklisted by default. Its instances, or the whole class, must be whitelisted in order to record its content. However, a whitelisted web view can still contain HTML elements with sensitive content, and Smartlook thus does not record the HTML elements where the user enters data.

In order to change the default behaviour, HTML elements that are not recorded by default can be whitelisted by assigning smartlook-show CSS class to them. Any HTML element that should not be recorded can be blacklisted by assigning smartlook-hide CSS class to it: ,[object Object],.

Rendering Modes: Handling Sensitive Data at the Whole Screen Level

There can be scenarios when direct recording of the screen is not appropriate or necessary to understand the user behaviour. In such cases, Smartlook can be instructed to use (permanently or just temporarily) one of its wireframe rendering modes.

When a wireframe mode is on, Smartlook draws a sketch of the screens instead of copying its content literally into the video. The principal UI elements and user interaction with them are still clearly distinguishable, but their actual look and content (texts, images) are replaced by an abstract representation.

Setting Rendering Mode

The default rendering mode for an application is set in the dashboard.

When debugging or experimenting to find the most suitable one for a particular application, the default rendering mode can be also set within the setup options. In production releases, this option should not be used.

The application can change the rendering mode at any time, e.g., to temporarily hide the sensitive user content on some screens. It is also possible to obtain the currently used values.

More about rendering modes could be found in the API reference.

Handling Sensitive Events

It is not just the visual elements that can contain sensitive information. Sometimes, a clue to sensitive user data can be found in user interaction events. Consider that, e.g. location of click events on a keyboard area could be used to guess user password even when the keyboard itself is obfuscated.

Click events in the area of the system keyboard are never recorded by Smartlook. User interaction with custom input elements, e.g., custom PIN-Pad, must be filtered out programatically by the application developer.

The default setting is to track all events (with the exception of events on the keyboard, for obvious user privacy reasons). When this is not desired, the application may fine-tune the level of tracked events.

Typically, the default Full Tracking mode is desired, as it gives a detailed picture of user activities.

OOn the other hand, on some screens the event location of touches on an otherwise blacklisted view can reveal sensitive private information (e.g., custom input view for PIN). In such a case, touches should not be recorded, and the application should switch to the Ignore User Interaction Events mode temporarily.

In specific cases, some apps that handle complex private information on particular screens may prefer stopping event recording altogether, by switching to the No Tracking mode for the screens.

Event tracking mode cannot be set on per-UI-element basis, only for the whole application.

More about rendering modes could be found in the API reference.