Data Privacy and Security

Architecture

To support detailed statistical analysis of user behavior with applications, Journey Analytics collects events from two sources – [%=TransactVariables.TransactManager%] and the browser where the application is rendered. sends transaction status events and applications rendered in the browser send user interaction events. The user interaction events include information such as - field visit, field completion, validation error, section navigation etc.

These analytical events are directly comparable to the Google Analytics or Adobe Analytics events recorded by these analytics services. These events DO NOT include any user input data itself and therefore DOES NOT collect any Personally Identifiable Data (PII). The service has been explicitly designed to NOT record or store user input data and PII. You may verify this by using the browser’s developer tools to monitor the network traffic of an enabled application.

The figure below describes the high-level architecture of how fits into the .

is built and hosted on the Google Cloud Platform (GCP) infrastructure. It is a fully managed service built using the GCP.

Data in Transit

code runs on GCP’s App-Engine servers. This includes both the code that processes events coming from an application and and the code that delivers analytics views on . All communication between an application (rendered on the browser), and occur over secured network protocols (using Transport Layer Security). does not support non-secure communication protocols.

Authorization of incoming Events

When a user opens an application (that has enabled), embeds a JWT (JSON Web Token) in the header of the network response. The JWT is signed by with a secret key only known to and the backend. The application further embeds this JWT in all interaction events sent to . The JWT contains the required information for the backend to; first, Authenticate and Authorise the interaction events (behavioral data) from the applications; second, map the events to the corresponding customer’s GCP project and the associated BigQuery dataset.

Data at Rest

Each customer’s data is isolated and stored in a separate GCP project, and each Instance that has provisioned is allocated a dedicated Dataset on BigQuery within the customer’s GCP project. GCP BigQuery is the same massively paralleled query service that powers Google Analytics. Refer to https://cloud.google.com/resource-manager/ to understand how GCP projects are managed. We adhere to best practices advised by GCP documentation. When at rest, all events data is encrypted using AES-256 encryption and stored securely in BigQuery. Google encrypts all data by default with Google-managed keys. It is possible for us to manage the encryption keys ourselves, but we don't currently do this. Please refer to the following links for more details:

https://cloud.google.com/security/encryption-at-rest/
https://cloud.google.com/security/encryption-at-rest/default-encryption

Authentication and Authorization to access Analytics UI

Customer’s business teams can access their analytics data through their server deployed on the Cloud or on-premise.

A customer’s business user must have an appropriate ’s user account with roles to access analytics data. Access to is managed by ’s security protocols. All access controls are also managed by , such as access to Organizations, Spaces, and Applications.

The ’s security architecture supports 2FA user authentication and temporary role assignments. After authenticates the user, it redirects all analytics through iFrames. Communication between the user’s browser and the data visualizer happens via using HTTPS protocol (i.e. with TLS) which delivers all analytics data securely.

After a user is authenticated and authorized by , provides access to Analytics data for only those Orgs and Applications for which the user has access to.

Organizations Data Privacy

Users of can only view data from the Organizations they are assigned.

is designed to support single and multi-tenancy usage by leveraging Organizations. Single tenant environments can be self-managed to use Organizations to group Individual business units so they can access specific applications and the resulting Journey Analytics data from the specified applications. In a multi-tenant environment, application and analytics access is centrally managed on behalf of all tenants.

Strict No PII policy

As described in the above section, employs all possible mechanisms and strategies to NOT store data relating to PII.

Personal data is effectively anything related to an individual that can be used or combined to identify that person. Examples include Names, addresses, phone numbers, credit card, bank and other account numbers, IP and email addresses, license plate numbers, VAT codes, passports, driver’s licenses, national identification numbers, biometric identifiers.

collects three types of events:

Transact Status events

These events include an ID to uniquely identify a transaction in so that all interaction events can be linked to that transaction. receives Transaction status events primarily from . However, Started and Submitted transact status events are received from an application rendered in the users’ browser.

Standard user Interaction events (Behavioural data)

These events include a wide variety of user interaction data arising from user engagement with the application. A detailed list of these events is provided in the Data stored in section below. In short, it only includes information pertaining to user interaction and guaranteed to exclude PII.

Custom events

There are two types of custom events customers can send from a supported application or host system: Milestones and Segments.

Event Description

Custom Milestones

These are custom events that customers can implement to capture key events specific to their business, context of the application and the application workflow. These can be implemented in an application using APIs provided in Maestro or a business rule in Composer. These events can also be sent from a service running on .

These events only include the name of the Milestone itself and nothing more. The Customer’s implementation team must make sure that no PII is sent in the API’s Milestone name parameter. It is strongly recommended to not use programming variables in the API parameter. Instead, the best practice is to explicitly hardcode the name of the custom Milestone in the API parameter at implementation time and use conditional logic where needed.

Custom Segments

These are events that assist customers to capture user Segments to analyze transactional data specific to a set of transactions having similar characteristics. Like custom milestones, these can be sent from a supported application or host system. These events include a Segmentation Name and a Segmentation Value.

The Customer’s implementation team must make sure that no PII is sent in the API’s Segmentation Name and Segmentation Value parameters. It is strongly recommended to not use programming variables in the segment API parameters. Instead, the best practice is to explicitly hardcode Segmentation Name and Segmentation Value in the API parameter at implementation time and use conditional logic where needed.

As an added PII deterrence measure, for Segment events, a Segment Whitelist feature has been implemented in Insights. Customers have to explicitly whitelist all Segment Names and Values that should be allowed by the backend to be stored in the database. If the backend receives a Segment Name or Value that is not listed in the Segment Whitelist, the Segment event will NOT be stored in the database.

Network Rules

To support , servers deployed on-premises must have firewall rules which support outbound access to the following Google Cloud Platform endpoints:

In addition, for all internal users who need access to UI, their machine should be able to make outbound calls to the following URLs:

In addition, for all internal users who test applications (rendering forms in the browser to generate transactional data), their machine should be able to make outbound calls to the following URLs:

All traffic is REST JSON service calls over HTTPS, typically message payloads are very small measuring a few KB at most.

Data Stored in

stores the following data:

Data Retention

Applicant behavioral data is warehoused indefinitely, but focuses on recent trends to offer actionable insights. As a result, users can access applicant behavioral data from the past 4 years.