Data Privacy and Security

   Journey Analytics The behavioural analytics tool.  |   Analytics User |   Latest Version Latest version 23.04.0 cloud hosted.

Journey Analytics Architecture

To support detailed statistical analysis of user behavior with applications, Journey Analytics collects events from two sources – Journey Manager and the browser where the application is rendered. Journey Manager 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 Journey Analytics DOES NOT collect any Personally Identifiable DataPersonally identifiable information (PII) is any data that could potentially identify a specific individual. Any information that can be used to distinguish one person from another and can be used for de-anonymizing anonymous data can be considered PII. (PII). The Journey Analytics service has been explicitly designed to NOT record or store user input data and PII. You may verify this by using the browser’s F12 tool to monitor the network traffic of an Journey Analytics enabled application.

The figure below describes the high-level architecture of how Journey Analytics fits into the Temenos Journey Manager.

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

Data in Transit

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

Authorization of incoming Events

When a user opens an application (that has Journey Analytics enabled), Journey Manager embeds a JWT (JSON Web Token) in the header of the network response. The JWT is signed by Journey Manager with a secret key only known to Journey Manager and the Journey Analytics backend. The application further embeds this JWT in all interaction events sent to Journey Analytics. The JWT contains the required information for the Journey Analytics 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 Journey Manager Instance that has Journey Analytics 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 Journey Analytics Analytics UI

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

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

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

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

Organizations Data Privacy

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

Journey Analytics is designed to support single and multi-tenancy usage by leveraging Journey Manager 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, Journey Analytics 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.

Journey Analytics collects three types of events:

Transact Status events

These events include an ID to uniquely identify a transaction in Journey Analytics so that all interaction events can be linked to that transaction. Journey Analytics receives Transaction status events primarily from Journey Manager. 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 Journey Analytics 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 Journey Manager. 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 Journey Analytics backend to be stored in the Journey Analytics database. If the Journey Analytics backend receives a Segment Name or Value that is not listed in the Segment Whitelist, the Segment event will NOT be stored in the Journey Analytics database.

Network Rules

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

• https://eventconsumer-dot-transact-insights.appspot.com
• https://dataprovider-dot-transact-insights.appspot.com
• https://apiserver-dot-transact-insights.appspot.com
• https://dashboard-dot-transact-insights.appspot.com
• https://accounts.google.com

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

• The on-premises Journey Manager URL.
• https://dashboard-dot-transact-insights.appspot.com

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:

• https://eventconsumer-dot-transact-insights.appspot.com
• https://accounts.google.com

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

Data Stored in Journey Analytics

Journey Analytics stores the following data:

Transaction and Session data

• Manager information.
• Transaction ID.
• Form Organization information.
• Form Space information.
• Form and version information.
• Browser session information (Time when the session was established, user_agent, device location, device info, time-zone).

Milestone events: Opened, Started, Bounced, Abandoned, Saved, Completed (Submitted)

• Transaction identification.
• Timestamp of the event.

Section name and sequence ID for Saved and Abandoned milestones

• Section (page/dialog) events: Section navigation, Section completion.
• Transaction identification.
• Timestamp of the event.
• Section name.

Field events: Field navigation, Field completion, Field validation

• Transaction identification.
• Timestamp of the event.
• Section name.
• Field name.
• Field sequence.
• Field path, for example ContactDetails/PrimaryContact/AddressLine1.
• Key Strokes (Count of key-ups in the field. Sent as part of field completion event).
• Data Length (Length of data in the field. Sent as part of field completion event).
• Time in field (Time spent in the field. Sent as part of field completion event).

Custom Milestone events: These could be sent through milestone APIs from a Maestro form, by adding an Insights business rule in a Composer form, or from a service running on Manager using TxnUpdater API.

• Transaction identification.
• Timestamp of the event.
• Milestone name.

Segment events: These could be sent through segment APIs from a Maestro form, by adding an Insights business rule in a Composer form, or from a service running on Manager using TxnUpdater API.

• Transaction identification.
• Timestamp of the event.
• Segmentation name.
• Segmentation value.