Track screens
Contentsquare aggregates user behavior and engagement at the screen level. To do so, it is required to track screen transitions by calling a dedicated API. When the API is called, the SDK logs a screen_view
event that identifies the new screen with the screen name provided.
Screen name handling
Section titled Screen name handlingThe screen name is limited to 2083 characters. However, this limit is not enforced by the SDK, but rather by the Contentsquare servers.
Screenview after app in background
Section titled Screenview after app in backgroundThe 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.
Implementation recommendations
Section titled Implementation recommendationsFrom a functional standpoint, we expect a screenview to be sent:
- Right after the SDK has started
- 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)
We advise you to take a look at our reference implementations of screenviews in our sample app. Learning from them is the best way to make sure your implementations are correct. Regardless, here is some general advice.
When to send your first screenview
Section titled When to send your first screenviewMost events collected by the SDK require a screenview event to be sent first so they can be associated with that screen; otherwise, they will be discarded. If you need to collect events from the moment the app launches, you should trigger a screenview event immediately after the SDK has started.
Automatic start
Section titled Automatic startIf the SDK is started automatically, you should send your first screenview when your app’s life cycle begins. For instance, you can send it in application:didFinishLaunchingWithOptions:
of your UIApplicationDelegate
if you are using UIKit, or in the init()
of your App
struct if you are using SwiftUI:
Manual start
Section titled Manual startIf the SDK is started manually, you should send your first screenview right after calling start()
:
General rules
Section titled General rulesFrom 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 of thumb, you should send your screenviews in viewWillAppear(_ animate: Bool)
. Be aware that only doing this might not cover all your cases though, and you might need to send screenview events in other parts of your code.
If you are using SwiftUI to build your application, you should send your screenview in .onAppear()
. Be aware that only doing this might not cover all your cases though, and you might need to send screenview events in other parts of your code.
ScrollViews with paging
Section titled ScrollViews with pagingBe careful when tagging screens with paged ScrollViews: if you want to create a screenview event whenever the user changes the page, do so in UIScrollViewDelegate’s scrollViewDidEndDecelerating(_ scrollView: UIScrollView)
function. Make sure that you do not trigger a double tag when the screen appears, or when you come back to the screen after the app being hidden. Also make sure not to send a screenview when the user slightly interacts with a page, but without really changing pages.
Popups and modals
Section titled Popups and modalsWhen dealing with popups and modals, if you are having issues triggering a screenview event for the underlying view when the modal closes we have the following advice. You could overcome this issue by using a delegate pattern, and setting the underlying screen as the modal’s delegate. The modal would call some delegate method when it is dismissed. The underlying screen would implement that method, where it would make the screenview.
Back navigation and navigation between screens
Section titled Back navigation and navigation between screensMake sure that screenview events will be triggered when a user will go to the previous screen. i.e. Home > Profile > Home, it is expected to have a screenview event for the Home screen that might be reached with the back navigation button. Normally, if you send your screenviews in viewWillAppear
, this should work fine.
Redirecting the user to another screen (authentication, home) when closing the app/re-opening the app
Section titled Redirecting the user to another screen (authentication, home) when closing the app/re-opening the appFor some apps, you might want to redirect users whenever they hide your app, for example for security purposes (bank apps, password managers, etc…). If that is the case, pay specific attention to the way screenview events are sent, in order not to track a screen which is not actually shown users.
Application life cycle
Section titled Application life cycleWhen your application returns from the background to the foreground, the SDK automatically logs a screenview with the title of the last logged screenview, so you don’t have to handle this transition yourself.
How to name screens
Section titled How to name screensAs 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.
Separate words with spaces, dashes or underscores
Section titled Separate words with spaces, dashes or underscoresWhen generating screen names with multiple words, separate them using spaces, dashes, or underscores.
For instance, use Home & Living - Home Furnishings
instead of for a sub-category in a retail app.homeLivingHomeFurnishings
Use screen template/layout names
Section titled Use screen template/layout namesAs 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…
Multiple layouts/states for one screen
Section titled Multiple layouts/states for one screenIn 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