Types of Transactional Service Implementation Scenarios¶

We understand that many agencies have different ways of designing their Transactional Services within their sites, therefore this article will serve as a guide on where you should implement the event trigger codes on your transactional service(s).

What are the Types of Transactional Service Implementation Scenarios¶

Typically, there should be logical 'Start' and 'End' pages for all digital services such that each step in your service has a unique URL that can be easily identified in your analytics tool.

The diagrams below aim to guide and illustrate some of the different scenarios of how agencies designed their Transactional Service(s) and where they should place the event trigger codes.

For Standard Flows¶

• Unique Start and End Pages
• Start & End on Same Page

For Non-Standard Flows¶

• Common Start but different End Pages
• Different Starts but Common End Page
• Different Starts but Overlapping Pages

For Standard Flows¶

Unique Start and End Pages¶

This scenario describes the flow where a user finishes a task that your transactional service provides through a Multi-Page Transaction.

What should you do:

1. Implement the startTransactionalService() on the individual start pages (depicted by the green square(s)) along with the Tracking ID.
2. Also, add in the completeTransactionalService() only on the appropriate end pages (depicted by the red square(s)). Note that: Since the service(trackingid-a) has multiple endpoints, the completeTransactionalService() should be added in each of the end pages.

Start & End on Same Page¶

This scenario describes the flow where a user finishes a task that your transactional service provides through a Single-Page Transaction.

What should you do:

As such, implement both the startTransactionalService() and completeTransactionalService() on the same page.

However, we have come across certain digital service transactions that do not fall within the 'typical' scenario.

For Non-Standard Flows¶

Common Start but different End Pages¶

This scenario describes the flow where both your transactional services (e.g. trackingid-a, trackingid-b) have the same start page (e.g. the only service access point) but the individual transaction completes/finishes on a different end page.

What should you do:

1. Implement the startTransactionalService() for each Tracking ID (e.g. trackingid-a, trackingid-b) and add them on the same service's start page (depicted by the green square).
2. Then, add the completeTransactionalService() only on the appropriate end pages (depicted by the red square(s)) with the associated Tracking ID.

Different Starts but Common End Page¶

This scenario describes the flow where the two transactional services have a different start page but completes their individual services on the same ending page/point. For example, a common end page that is used across multiple transactional services of your site - an acknowledgment or "thank you" message page.

What should you do:

Given such case, our recommendation to agencies would be to implement a control flow logic (e.g. use of conditional statements) inside your own codebase (front-end or back-end), to determine which service has completed and to trigger the completeTransactionalService() with the associated Tracking ID.

Different Starts but Overlapping Pages¶

This scenario describes the flow where multiple transactional services (TS) within your site have different start pages but one or more of the TS (e.g. trackingid-c) resides between or within the other TS flows.

What should you do:

Since the start pages and end pages are different across the various transactional services, the implementation of the event trigger codes should be the same as per the standard flow.

Why is My Service Getting a Low Completion Rate?¶

If you are getting a low completion rate on your service(s) shown in WOGAA's dashboard, the few reasons why this could happen:

• Inserting the event trigger code in the Wrong End Page¶

  

  Agencies have implemented the event trigger code - completeTransactionalService() only on the "Logout" page.

  As such, this is an error-prone implementation as it will result in an inaccurate way of measuring completion rate (e.g. low completion rate ) of their service(s).

  Since there is a possibility that a user can choose not to logout from the site/application after "completing" the transaction(s), technically the service will still be considered as "incomplete" on our end given that the user did not arrive on the "end page"(Logout page).

  What you should do:

  The completeTransactionalService() should be placed on an appropriate end page/last step that you would consider the "Transaction to have finished" instead of the "Logout" page.

• Counting completion rate on transactions with ‘save and return’ state¶

  If your service allows users to save a transaction and finish it later (e.g. "Save as draft"), this is how WOGAA is currently tracking the "Start" and "Complete" figures:

  1. Given a transaction (e.g. some form filling) is started, the startTransactionalService() is triggered.
  2. Next, the user performs a "Save as draft" action of the transaction and leave the site.
  3. Then, the user comes back to the site and open up the "draft".
  4. At this stage, a new startTransactionalService() is fired.
  5. Once the transaction is completed, the completeTransactionalService() is executed.

  This should result in Two Starts and One Complete events sent to WOGAA's server based on this type of transactional behaviour.

Lastly, if you have any questions about this or any of our WOGAA's features, feel free to reach out to our GovTech WOGAA team at support@wogaa.gov.sg