Journey Analytics Previously known as Transact Insights. | Analytics User | Latest Version Latest version 21.05.0 cloud hosted.
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 Journey Platform.
Journey Analytics is built and hosted on the Google Cloud Platform (GCP) infrastructure. It is a fully managed service built using the GCP.
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.
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.
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 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:
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.
After a user is authenticated and authorized by Journey Manager, Journey Analytics' Data Visualizer provides access to Analytics data for only those Orgs and Applications for which the user has access to, on Journey Manager.
Journey Analytics also supports Journey Manager's multi-tenancy architecture. This means that separate business units (Orgs) can manage their own applications separately and control access to their own Journey Analytics analytics data.
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.
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:
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.
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.
There are two types of custom events customers can send from either an application (designed in Maestro, Composer or Open UX) or from Journey Manager.
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.
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 an application (designed in Maestro, Composer or Open UX) or from a service running on Journey Manager. 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.
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:
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:
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.
Journey Analytics stores the following data:
Transaction and Session data
Milestone events: Opened, Started, Bounced, Abandoned, Saved, Completed (Submitted)
Section name and sequence ID for Saved and Abandoned milestones
Field events: Field navigation, Field completion, Field validation
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.
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.