Pages

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from this space and version 7.0

This guide describes the data collected by the Frosmo Platform from customer websites, and where that data is stored in the visitor's browser and in the Frosmo back end.

Table of Contents

For information about how Frosmo collects and stores data from its own websites and user interfaces, see Frosmo Privacy Policy.

Collecting data

The Frosmo JavaScript library collects usage data in the visitor's browser and sends the data to the Frosmo back end over an HTTPS connection. The library sends the data in the background so as not to interfere with the visitor's user experience. The Frosmo JavaScript library also stores selected data locally in the browser.

The data can be categorized into:

Table of Contents
maxLevel2
minLevel2
includeModification|Product|Server|Visitor

By default, the Frosmo Platform collects and processes only anonymous and pseudonymous information about visitors and their behavior on a website. The platform does not collect data that in itself enables the identification of an individual data subject.

The Frosmo Platform can collect additional information about visitors, including account data, such as email addresses and phone numbers. However, the processing of such data must always be determined by the customer and explicitly documented. Frosmo only collects account data for the purpose of transferring the data to the customer's back end systems or third-party systems controlled by the customer, such as customer relationship management (CRM) systems or marketing automation systems.

Modification performance data

The Frosmo Platform automatically tracks (counts) the following basic events for a modification:

  • Click: The visitor has clicked a part of the modification for which clicks are tracked, such as a button, link, or any element with the class frosmo-click. If the modification has no clickable parts, it cannot get a click.
  • Display: Frosmo Core has rendered the modification to the page. The display event does not require that the modification has been in the browser viewport and therefore visible to the visitor.
  • True display: The modification has remained visible and stationary in the browser viewport for at least 3 seconds. In addition, if the modification's width and height are both less than or equal to 300 pixels, the modification must have been fully in the viewport. If the modification's width or height is greater than 300 pixels, at least 75% of the modification must have been in the viewport.

The platform only counts one basic event of each type per modification per page load. That is, a modification can only get a single click, a single display, and a single true display per page load, regardless of how many times the visitor actually clicks or views the modification before reloading the page or navigating to another page.

In addition to the basic events, the Frosmo Platform also tracks (counts) the following performance-related events for a modification:

  • Conversion: The modification is attributed a conversion through a click, display, or true display that the modification got. For more information about conversion attribution, see Introduction to conversion tracking.
  • Custom event: The modification gets a special event you are specifically tracking for the modification.

The Frosmo Platform does not automatically track conversions and custom events, so you need to implement their tracking separately. Your Frosmo team usually does this for you, based on your requirements and specifications.

The Frosmo Platform tracks basic events, conversions, and custom events separately for each variation of a modification.

Based on the basic event and conversion counts, the Frosmo Platform automatically calculates the following basic performance metrics for a modification:

  • Click-through rate (CTR): The ratio of clicks to displays or true displays that the modification gets. The platform tracks CTR separately for displays and true displays.
  • Conversion rate (CR): The percentage of all visitors that completed a conversion after clicking or seeing the modification. The platform tracks CR separately for clicks, displays, and true displays.
  • Total revenue: Total revenue attributed to the modification after the modification was clicked or displayed. The platform tracks total revenue separately for clicks, displays, and true displays.

For more information about modifications in general and modification statistics in particular, see Modifications and Modification statistics.

Product data

Product tracking is the process of automatically collecting product data from a website. Product tracking has to be manually set up for each site either by Frosmo in the custom code or by the customer through the data layer in the site code. The collected data is mainly used in product recommendations.

Product data can include several attributes, such as:

  • ID
  • Name
  • Category
  • Image
  • Price
  • URL
  • Custom data (such as author name, product color, or availability)

The Frosmo Platform can track product views and purchases separately for each visitor. Product data as such does not contain personal data.

Server logs

Server logs are files for recording events on a web server, namely information about incoming page requests. Website visitors do not have access to logs; the logs are normally only accessible to the webmaster. The data in the logs is only used for the technical monitoring of the platform, not for profiling, targeting visitors, or any commercial purposes.

The logs can be divided into the following types:

  • Access logs

    The access logs contain:

    • Browser data
    • IP addresses
    • Requests to the server
    • Metadata, such as server request dates and times
    • Page referrer information
    • Resources requested from the server, including HTML and image files
  • Error logs

    The error logs contain the same information as access logs but with some additional data about the server status and errors.

If a third-party cookie is used on a site, its content is also logged. For more information about cookies, see Data collection and storage.

In addition, the server may store logs from applications handling requests for the web server. These logs may contain data stored in the Frosmo back end, but they do document describes where and how the Frosmo Platform stores its operational data: data collected from websites, data generated based on the collected data, configuration data managed in the Frosmo Control Panel, and any other data required to operate the platform.

Table of Contents

Tip

If you're looking for:

Data stored in the Frosmo back end

The Frosmo Platform stores its operational data in different databases in the Frosmo back end. In addition to main databases that are used across the platform, the platform also uses dedicated Redis databases (one per customer) for storing data related to custom features.

The Frosmo back end contains the following main databases:

  • Master

    The Master database stores all the operational data that is displayed or managed in the Frosmo Control Panel. The data can be broadly grouped into:

    • Company settings (including target groups)
    • Site-specific data
    • User account settings

    The site-specific data includes:

    • Analytics data (reports)
    • Configuration data, for example:

      • Conversion definitions
      • Modifications
      • Placements
      • Recommendation configurations and recommendation data
      • Segments and segment groups
      • Triggers
    • Usage data collected from sites:

      • Modification performance data (events and metrics)
      • Product data
      • Visitor data

    The data in the Master database is stored for the duration of the customer's subscription agreement. The data is removed manually.

  • Elasticsearch

    The Elasticsearch database stores error data from across the Frosmo Platform, from both the front end and the back end. The error data is used for monitoring and debugging purposes. The database uses the server access logs as its source, so it can contain the same data as the access logs. In addition, for sites that use the data layer, the database can contain personal data retrieved from the data layer.

    The data in the Elasticsearch database is stored for 31 days, after which it is automatically removed.

  • Reporting

    The Reporting database stores aggregate data required to generate analytics reports, such as conversion reports, modification reports, and segment reports, and to display advanced tracking statistics. The data is parsed from other sources, so the database does not contain any data that is not stored elsewhere in the Frosmo Platform.

...

The log data is used to create usage statistics. Before refining the data for statistics, any personal data, such as IP addresses, is removed.

By default, the logs are stored for six months, after which they are automatically removed.

Visitor data

The Frosmo Platform tracks the following data about a visitor on a website:

  • Background data

    Information about the visitor that is not related to a specific website. For example:

    • Visitor's browser
    • Visitor's device (mobile, desktop, tablet)
    • Visitor's geolocation (on country/region/city level)
    • Visitor's IP address
  • Behavior data

    Information about the visitor's actions on the website. For example:

    • Amount of time the visitor has spent on the site or on a specific page
    • Content modifications the visitor has seen or clicked
    • How many times the visitor has visited the site
    • Pages the visitor has viewed
    • Products the visitor has viewed
    • When the visitor has last visited the site
    • Whether this is the visitor's first visit on the site
  • Conversion and transaction data

    Information about the visitor's actions on the website in connection with purchases and other conversions. For example:

    • Conversions the visitor has completed on the site (for example, purchases, subscriptions, reservations)
    • Products the visitor has added to their shopping cart
    • Products the visitor has purchased
    • Whether the visitor is a paying user
    • Whether the visitor is logged in
  • Account data

    Personal data collected and stored temporarily for the purpose of transferring it to customer's back end systems or third-party systems controlled by the customer. This information is collected only when explicitly agreed with the customer. For example:

    • Username
    • Email address
    • Postal address
    • Subscription type
    • Wallet balance (on gaming sites)

Storing data

For more information about what data is stored and where, see:

Table of Contents
maxLevel3
minLevel2
excludeModification|Product|Server|Visitor

...

  • If not combined with other data, the data in the Reporting database cannot be used to identify a data subject.

    The data in the Reporting database is stored for the duration of the customer's subscription agreement. The data is removed manually.

  • Requests

    The Requests database stores information about Message API calls that return modification content for display. The purpose of the database is to keep a record of what content has been returned to which visitor on which site. However, the database does not track whether the content is actually displayed. The Message API also uses this data to decide what content to return to a particular visitor, or whether to return any content.

    The data retention period depends on the modification. If the modification hasn't been updated or displayed for 90 days, its request data is automatically removed.

Data stored in the visitor's browser

In addition to sending data to the Frosmo back end, the Frosmo JavaScript library stores data in the browser's local storage and cookies.

None of the library's core features require the use of cookies, so storing data in cookies can be disabled, if necessary. Local storage, in turn, is a safe way to manage data, since web servers do not have access to it.

Local storage

Using local storage means that the data is stored in the visitor's browser.

...

Data itemLocal storage keyDescriptionRetention period
Local Frosmo ID__frosmoeasy__uid

Used to identify the visitor (browser) on the Frosmo Platform in order to retrieve visitor-related data from the Frosmo back end. The ID is unique within a site.

The ID is generated from the browser's user agent string and does not contain any personal data that can be used as such to identify the visitor.

Indefinitely unless manually removed
Context__frosmoeasy__contextUsed by the Frosmo Platform for personalization. The context holds data for segments, page visit history, location, and other data gathered from visitor activity on the site. By default, the context does not contain any personal data that can be used as such to identify the visitor.Indefinitely unless manually removed

Cookies

A cookie is a small piece of data sent from a website and stored in the visitor's browser while the visitor is browsing. Cookies are used, for example, to store temporary information or to track the visitor's browsing behavior.

...

Data itemCookie nameDescriptionRetention period
First-party cookies
Keywordsfrosmo_keywords

Used by the Frosmo Platform to store the IDs of the target groups to which the visitor (browser) currently belongs.

This cookie is set only when the visitor belongs to one or more target groups. If the visitor is removed from all target groups, the cookie is deleted.

30 days
Quick contextfrosmo_quickContext

Data needed for modifications whose content is preloaded. The data includes, for example:

  • Local Frosmo ID
  • Segment data

This cookie is set only when the site uses modifications whose content is preloaded.

365 days
Frosmo offfrosmo-offUsed when the Frosmo Platform is disabled for the site on the visitor's browser.Session
Local Frosmo IDfrosmo_uid

Used to identify the visitor (browser) on the Frosmo Platform in order to retrieve visitor-related data from the Frosmo back end. The ID is unique within a site.

The ID is generated from the browser's user agent string and does not contain any personal data that can be used as such to identify the visitor.

Note

This cookie is only used on Apple devices when the additional configuration option easy.config.contextApi is enabled.


1 year
Frosmo Previewfrosmo_preview_tool

Used by Frosmo Preview to check whether the visitor has the application open. If the visitor had the application open on the previous page or before a page reload, the application opens automatically after the current page loads.

This cookie is set only when the visitor, who is also a logged-in user of the Frosmo Control Panel, has Frosmo Preview open on the site.

Session
Third-party cookies
Global Frosmo IDid

Used to identify the visitor (browser) across different domains and websites.

The ID does not contain any personal data that can be used as such to identify the visitor.

31 years and 1 month

Data stored in the Frosmo back end

The Frosmo Platform stores its operational data – both the data that it collects from sites and the data that it generates from the collected data – in different databases in the Frosmo back end. In addition to main databases that are used across the platform, the platform also uses dedicated Redis databases (one per customer) for storing data related to custom features.

The Frosmo back end contains the following main databases:

  • Master

    This database stores all the operational data that is displayed or managed in the Frosmo Control Panel. The data can be broadly grouped into:

    • Company settings
    • User account settings
    • Site-specific data

    The site-specific data includes:

    • Analytics data (reports)
    • Configuration data, for example
      • Conversion definitions
      • Modifications
      • Placements
      • Segments and segment groups
      • Triggers
    • Usage data:
      • Modification performance data
      • Product data
      • Visitor data
    • Error tracking data (services and service alerts)

    The data in the Master database is stored for the duration of the customer's subscription agreement. The data is removed manually.

  • Elasticsearch

    This database stores data about errors that occur in the Frosmo scripts during runtime. The error data is used for monitoring and debugging purposes. The database uses the server access logs as its source, so it can contain the same data as the access logs. In addition, for sites that use the data layer, the database can contain personal data retrieved from the data layer.

    The data in the Elasticsearch database is stored for 31 days, after which it is automatically removed.

  • Reporting

    This database stores aggregate data required to generate reports, such as conversion reports, modification reports, and segment reports. The data is parsed from other sources, so the database does not contain any data that is not stored elsewhere in the Frosmo Platform. If not combined with other data, the data in the Reporting database cannot be used to identify a data subject.

    The data in the Reporting database is stored for the duration of the customer's subscription agreement. The data is removed manually.

  • Requests

    This database stores information about Message API calls that return modification content for display. The purpose of the database is to keep a record of what content has been returned to which visitor on which site. The Message API also uses this data to decide what content to return to a particular visitor, or whether to return any content.

    The data retention period depends on the modification. If the modification hasn't been updated or displayed for 90 days, its request data is automatically removed.

...

Additional data stored through APIs

The Frosmo Platform can collect and store data through the following APIs:

  • Custom APIs

    A custom API is a customer-specific API created for a specialized purpose that cannot be realized using standard Frosmo Platform features. A custom API can in principle collect and store any data from a site.

  • Context API

    The Context API stores and retrieves visitor context data to and from Frosmo servers. The API uses a Redis database on the regional platform server that services a site.

    Info

    The Context API is mainly used for storing context data on Apple devices. By default, the Frosmo JavaScript library stores a visitor's context in the browser's local storage. However, if you need to support shared context in the Safari browser on Apple devices, the library must access the context from a Frosmo server instead, which is where the API comes in. (Safari does not accept cookies or local storage data from websites the visitor has not visited, which is what the shared context basically is.)