Track screens

Contentsquare aggregates user behavior and engagement at the screen level. To achieve this, it is necessary to provide a name for each screen by calling a dedicated screenview API.

import { ContentsquareCDVPlugin } from '@contentsquare/cordova-plugin-types';

declare var ContentsquarePlugin: ContentsquareCDVPlugin;

ContentsquarePlugin.sendScreenName("ScreenName", (result)=>{
    // Success
}, (err)=>{
    // Handle error
});

The screen name is limited to 2083 characters. However, this limit is not enforced by the SDK, but rather by the Contentsquare servers.

The SDK triggers a screenview automatically after the app is put in background and foreground, as long as a screenview with a screen name has been triggered previously. It will use the last screen name set.

From a functional standpoint, we expect a screenview to be sent:

• When the screen appears
• When a modal/pop-up is closed and the user is back on the screen
• When the app is put in the foreground (after an app hide)

As a general rule, keep the number of distinct screen names under 100. Since these names are used to map your app in Contentsquare, choose names that are clear and comprehensive.

If you want to generate screen names including more than one word, it is best to separate them and to do so using space, dash or underscore characters. Contentsquare handles automatically the formatting for them.

Example: For a sub-category list of a retail app, use Home & Living - Home Furnishings instead of homeLivingHomeFurnishings.

As a general recommendation, use names referring to the screen template/layout rather than referring to the specific content (data). This will help:

• To keep the number of distinct screen names low and therefore make Contentsquare easier to use
• Remove the risk of sending Personal Data to Contentsquare

List of screen types falling into that category: Product detail, Event detail, Conversation/Chat, User profile…

In some cases, there will be screen that can have different layouts/states depending on the user context. In this situation, it would be interesting to append the layout/state value to the screen name. Examples:

• Home screen of a travel app adapting its layout on the user context:

  State	Screen name
  No trip planned	Home - no trip
  Trip planned	Home - trip planned
  Trip about to start	Home - upcoming trip
  Trip in progress	Home - trip in progress

• Product detail screen of an e-commerce app with different layouts depending on the type of product:

  State	Screen name
  Default template	Product detail
  Template with suggested products	Product detail - Suggestions
  Template with bundled products	Product detail - Bundle