Journey Analytics The behavioural analytics tool. | Analytics User | All versions This feature is related to all versions.
Milestones are significant events that occur in a transaction. There are two types of milestones in Journey Analytics:
Custom milestones can be used for several purposes based on the needs of the business and/or the application. Custom milestones allow 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 Journey Analytics and cannot be revoked.
To send a custom milestone from a Maestro application, use the following Maestro Milestone API:
Insights.milestone("Custom milestone name");
Presently, there are two ways Journey Analytics uses custom milestone data:
In the context of User Journeys, custom milestones are markers that represent the path the users take within a transaction. A common example of where a milestone can be used in a Maestro application is when an applicant prefills data using the LinkedIn prefill exchange component. In this example, the moment the applicant clicks Use This Profile, a click rule will initiate, and the milestone will be recorded by Insights. 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.
Note that some of the Exchange components like LinkedIn prefill, Mitek ID scan etc, come with pre-built custom milestones. However, you may modify the pre-built logic to meet your business requirements.
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 sample logic to identify and send applicant and reviewer milestones. For this use case, an appropriate place to send this milestone would be in the form load rule.
In the above example, when an application is loaded in the browser, a milestone is sent to Insights. This milestone sent will vary depending on the collaboration job step from where the transaction is created. If the application is at the “Application Review” step, the “Review Transaction” milestone is sent to Insights. If the application loads on any other step, the “Applicant Transaction” milestone is sent to Insights. With these milestones in place, you can now filter the transactions for a specific milestone in Insights and hence see the data for either applicant transactions or review transactions.