Data and statistics

What are users doing?

All parts of Mybring should have a basic level of usage logging. What basic level includes might vary in the different areas of Mybring, but this general list works as a starting guide.

Siteimprove is available in all parts of Mybring through Tagmanager in Mybring Layout. Out of the box, this collects standard web statistics like page views, viewport resolution, operating system, etc.

If you are building applications without Mybring Layout or the Tagmanager script, the Siteimprove script must be included manually – contact Mybring Experience for more directions.

Logging usage

Siteimprove

In addition to the automatically collected web statistics, it is recommended that all parts of Mybring collect useful information about usage. Generally, this should be done through event logging, as opposed to the automatic navigation logging, in Siteimprove.

Basic event logging

It is recommended to log the following user actions:

• Main user tasks, like order shipment, view invoice and send request to customer service.
• UI manipulation by the user, like filtering, expanding/collapsing, sorting, grid vs. list view and pagination.
• For multi-step flows, consider logging any interaction from the user that you wish to include in a funnel in Siteimprove. For instance start of flow, first interaction and so on.
• Conditional views, for instance how often a specific button is shown if its appearance is conditional.
• Error messages that are displayed.

Detailed event logging

Basic logging is not always enough to answer all questions required to make good decisions. More detailed logging can be continuous or temporary, based on what we want to find out and the nature of the planned changes. The information needed will be specific to the task at hand, but can still follow the recommendations and categories for basic logging.

Parameters and category values

Event logging requires three parameters, or properties: Category, action and label. Values for action and label are not predefined, but for the category parameter, you should use one of the following predefined values.

Action and label values

For the action property, try to describe what happened from the user’s perspective. “Ordered shipment” or “Downloaded report” are examples of good values.

The “Label” property identifies which element on the page has been interacted with. It is often better to make a specific logging value than to use the actual label on the element. “Next” or “34” do not provide good information about what has happened for anyone trying to read the statistics.

• Use clear, unique and identifying names for your logging values, and avoid technical or internal domain expressions.
• Check if someone else understands the names of your logging values. Preferably someone not working close to you. Consider if something that makes sense to you right now will also make sense to anyone at a later time.
• Think about consistency for the category, action and label values. This consistency should be across teams and applications.
• Don’t log user or customer information.
• Always log with English values.
• Don’t log the location of the event. Siteimprove automatically logs the page on which the event happened and the rest of the values should be enough to identify the element within a page.
• Action and label values are automatically prefixed with SU- for superusers.

Set up logging

In addition to the Siteimprove script, Mybring Layout also has a script that simplifies event logging. The script is served from the design system, so it can also be used in applications that don’t use Mybring Layout. The script is a function SiteImprove.registerEvent() that takes an object with the three values, it’s placed in the function related to the triggered event. Keep in mind the logical order of this against validation, so that events aren’t logged if their validation fails.

You can place event categories and the SiteImprove function in its own file like this:

// analytics.ts

export enum SICategory {
  TASK = "Task",
  SETTING = "Setting",
  FLOW_STEP = "Flow step",
  UI_CHANGE = "UI change",
  CONDITIONAL_VIEW = "Conditional view",
  ERROR_MESSAGE = "Error message",
  ADMINISTRATION = "Administration"
}

export const logToSiteImprove = (
  category: SICategory,
  action: string,
  label: string
) => {
  if (typeof SiteImprove !== "undefined") {
    SiteImprove.registerEvent({
      category: category,
      action: action,
      label: label
    })
  }
}

That way you only have to check if it’s undefined in one place, and you have the categories ready to use.

You can then log events where needed:

import { logToSiteImprove, SICategory } from '../analytics.ts'

onClick={() => {
  logToSiteImprove(
    SICategory.TASK,
    "Edit address book contact",
    "Confirm edit contact",
  )
}}

TypeScript

Add the following to conf.d.ts

interface RegisterEvent {
  category: string
  action: string
  label: string
  event?: string
}

declare namespace SiteImprove {
  function registerEvent(RegisterEvent: RegisterEvent): void
}

Testing

To test locally you can console log the values you want to log. Check if the values are correct, that they are logged when they should and the correct amount of times. You can also console log the SiteImprove function itself to make sure it is found on the site. It should return a function.

After pushing to QA, you can check if the data is correct in SiteImprove, before pushing to production.

When logging in production

Check the numbers a few days after putting your logging into production. It’s not easy to get it all correct the first time. You might not be able to verify the numbers completely, but here are some tips to see if the logging needs adjustments:

• Compare to number of visits or page views. Some numbers, like logins, should be comparable to visits.
• Compare to related data, like orders. Ideally, they should match.
• An event dependent on another must be lower than the one it is dependent on. Do the numbers make sense?
• If the numbers are unnaturally high, check if the event is logged on page load.

Logging performance and state

We use Grafana to log data to measure performance, API-speeds, number of request from one API to another, which pod has the greatest load, etc. Generally a live view of the condition of the applications.

Consider which values are relevant to log for your application.