Journey Analytics The behavioural analytics tool. | Analytics User | v4.4 & Higher This feature is related to v4.4 and higher.
Milestones are significant events that occur in a transaction. There are two types of milestones in Journey Analytics:
Custom milestones can be used for a number of purposes based on the needs of the business and/or the application. It allows customers to build Analytics reports that answer specific questions to enable data-driven decisions that improve the onboarding experience and conversion. It is important to note that once a milestone is sent, it will forever be recorded against this transaction in Insights and cannot be revoked.
Presently, there are two ways Journey Analytics uses custom milestone data.
To send a custom milestone from a Composer application, follow these steps:
In the context of User Journeys, custom milestones are markers that represent the path the users take within the transaction. A common example of where a milestone can be used in a Composer application is when an applicant prefills data using the LinkedIn prefill exchange component. In this example, the moment the applicant clicks the Use This Profile button, a Transact Insights milestone rule can be triggered to send the LinkedIn Prefill milestone to Journey Analytics. This milestone records that the applicant has used the LinkedIn prefill component to prefill data in the form. Another example could be when Applicants validates their identity using a Green ID or Mitek Tiden ID verification.
In this example, the script returns something like "Linkedin Prefill" which will be treated as a LinkedIn Prefill Milestone. Also, it is important to make sure that any dynamic variable used in the script are listed under Parameter Changes triggering condition. For instance, the screenshot below displays the triggering conditions tab with "LinkedIn prefill" as a variable which triggers this rule when its value changes.
Custom milestones are a good way to distinguish between transactions made by applicants and transactions made by reviewers. A common use-case is once an applicant has completed an application, the submitted transaction will be reviewed by a review team which creates a second transaction. In Insights, the events from review transactions will skew all metrics for applicant transactions. For example, for one end-user completed application, Insights will show the completed count as 2. In most cases, you will only want to consider and analyze transactions made by applicants. To address this issue, you can implement custom milestones to identify when a transaction is an “Applicant Transaction” (transactions initiated by applicants) and when a transaction is a “Review Transaction” (transactions initiated by reviewers/someone other than the applicant).
The screenshot below displays a sample logic to identify and send applicant and reviewer milestones from a Composer application.
For this use case, an appropriate triggering condition is Trigger rule at initialization as shown below.