For Frosmo to deploy the iGaming setup to your site, the site must be ready to be integrated with the Frosmo Platform. This guide walks you through the steps of making sure your site is ready.

Process overview

The following table summarizes the preparation process and shows you who's responsible for which task (either you or Frosmo, or both). The table also shows which tasks are required.

If you are at any point unsure how to proceed, contact Frosmo support, and we'll help you forward.

Table: Tasks for preparing your iGaming site for the Frosmo Platform

Preparing your site

The following tasks are your responsibility in the preparation process:

Adding the Frosmo scripts to the site

To integrate the Frosmo Platform with your site, add the two <script> elements provided by Frosmo to every page of your site. The following code snippet shows an example where the <script> elements have been added at the end of the <head> element in the page source code.

    <!-- Load the Frosmo Platform -->
    <script type="text/javascript" charset="utf-8" src="//" async></script>
    <script type="text/javascript" charset="utf-8" src="//" async></script>


The first element loads the Frosmo Core library (frosmo.easy.js). The second element loads the Frosmo custom script (<site_origin>.js).

For instructions on how to add the elements to your site, see Adding the Frosmo scripts to your site.

If your site has content inside <iframe> elements whose origin differs from that of the containing page, and if you want the Frosmo Platform to track and personalize that content, add the Frosmo scripts also inside the <iframe> elements.

For more information about the Frosmo scripts, see Technical overview.

Setting up events and metadata for game and visitor tracking

The iGaming setup relies on specific data layer events for game and visitor tracking on a site. The setup also supports the Open Graph protocol for tracking additional data.

You need to ensure that your site sends at least the required events from the appropriate pages. For example, any page where visitors can launch a game must send a gamePlay event for the game when it's launched. In addition, it is recommended that you always define at least the page type with Open Graph metadata.

For more information about data tracking in the Frosmo Platform, see Data tracking solutions.

Supported iGaming events

You must use the data layer to send iGaming events.

The iGaming events are conceptually similar to Google's Enhanced Ecommerce events.

The following table describes the iGaming events supported by the Frosmo Platform and shows you which events are required by the iGaming setup. The table also provides data layer push templates for sending the events.

Table: iGaming events

EventDescriptionData layer pushRequired

The visitor saw one or more games, but did not launch any.

Example: The visitor opened a game category page, or the visitor searched for games and viewed the search results, which listed a number of games from different categories.

This event tells the platform which games a visitor sees on a game category or search page.

    event: 'gameImpressions',
    products: [{
        gameId: 'Game ID',
        name: 'Game Name',
        category: 'Category/Subcategory',
        vendor: 'Vendor',
        image: 'https://vendor.gameimage.url',
        launchUrl: 'https://vendor.gamelaunch.url'

The visitor launched a game.

Example: The visitor selected a game from a category page or from search results, launching the game.

This event allows the platform to track which games visitors play the most. This, in turn, allows the platform to recommend (a) most popular games and (b) similar or otherwise related games, where visitors who played game A also played games B, C, and so on.

This event also allows the platform to collect game data, which is a prerequisite for generating game recommendations.

The platform treats this event as a product view event. Recommendations based on product views use this event.

    event: 'gamePlay',
    products: [{
        gameId: 'Game ID',
        name: 'Game Name',
        category: 'Category/Subcategory',
        vendor: 'Vendor',
        image: 'https://vendor.gameimage.url',
        launchUrl: 'https://vendor.gamelaunch.url'

The visitor completed a deposit.

Example: The visitor transferred money from their bank account to their digital wallet on your site.

This event allows the platform to track when and how much money registered visitors reserve for gaming on the site. This, in turn, allows the platform to drive those visitors to spend that money accordingly.

If you cannot or prefer not to provide the amount of money deposited, send the event with amount set to an empty value. The event provides the platform with valuable information even without the amount.

While optional, it is recommended that you send this event.

    event: 'deposit',
    amount: '123.45',
    option: 'Payment Method'


The visitor placed a wager or otherwise made a purchase in a game.

Example: The visitor placed a bet and spun the wheel in a roulette game.

This event allows the platform to track which games visitors spend money on. This provides a stronger scent of visitor interest than, for example, tracking gameImpressions, and allows the platform to recommend popular games with greater confidence.

The platform treats this event as a transaction event. Recommendations based on product purchases use this event.

While optional, it is recommended that you send this event.

    event: 'gameSpin',
    products: [{
        amount: '123.45',
        gameId: 'Game ID'


The visitor completed the registration process and created a new user account.

Example: The visitor signed up as a new user to your site.

This event allows the platform to track the conversion of anonymous visitors to registered ones, which is both a user journey milestone and often a key performance indicator (KPI). In terms of the user journey, this event allows the platform to target unregistered and registered visitors with different recommendations.

    event: 'registrationSuccess'

The following tables describe the supported data for iGaming events. The tables also show for which event types each data property is valid.

To get the most out of the Frosmo Platform and ensure optimal recommendation performance, include all the data listed for each event type.

Table: iGaming event data

PropertyDescriptionEvent types

Event type.

The possible values are:

  • deposit
  • gameImpressions
  • gamePlay
  • gameSpin
  • registrationSuccess

List of games included in the event.

The list is an array of game data objects. For more information about the object, see the following table.





Amount of money deposited.

If you cannot or prefer not to provide the amount, set this property to an empty value.

optionPayment method the visitor used to make the deposit.deposit

Table: Game data object

PropertyDescriptionEvent types

Game ID.

The ID of a given game must be consistent across all events. For example, the game impression and purchase events for the same game must use the same game ID.




nameGame name.




Game category.

Define a hierarchy of parent and child categories as a breadcrumb using / as the separator. For example: Jackpots/Slot Jackpots



vendorBrand or company that develops or provides the game.



imageGame image URL.



launchUrlGame launch URL.



amountAmount of money the visitor wagered.gameSpin

The Frosmo Platform also supports additional game data. As a rule, if you want to send additional data to the platform, use a game data feed. If you cannot use a feed, consult with Frosmo about a custom solution for sending the data directly from the site.

Supported Open Graph metadata

Using Open Graph metadata is optional. However, it is recommended that you always define at least the page type with Open Graph. Otherwise, Frosmo needs to implement custom tracking for page type. In addition, if you cannot provide game image and launch URLs in data layer events or in a game data feed, define the URLs with Open Graph.

The following table describes the supported Open Graph metadata and where to define it on the site.

Table: Supported Open Graph metadata


Game image URL.

The URL must be an absolute URL.

Game page
<meta property="og:image" content="" />

Page type.

The possible values are:

  • page.category: Game category page
  • page.front: Site home page
  • page.product: Game page

Game category page

Game page

Home page

<!-- Site home page -->
<meta property="og:type" content="page.front" />

Game launch URL.

The URL must be an absolute URL.

Game page
<meta property="og:url" content="" />

Setting up recommendation placement on the site

The Frosmo Platform uses placements to position content – modifications – on a web page. Placements, in turn, use CSS selectors to define the target web page element or elements in relation to which modifications are placed. The recommendation modifications included in the iGaming setup all use predefined placements (which are also included in the setup). However, for the platform to correctly place the recommendations on a page, the CSS selectors of the placements must be customized for your site.

You and Frosmo together plan where to place the recommendations on your site. Once there's a plan, Frosmo needs to know the specific selectors to use in the recommendation placements. You have two options for defining the selectors:

  • If possible, add empty elements for the recommendations to the designated places in your site's source code. Use the following ID attributes for the elements:
    • Home page:
      • Recommendation 1: frosmo-home-reco-1
      • Recommendation 2: frosmo-home-reco-2
      • Recommendation 3: frosmo-home-reco-3
    • Game category page:
      • Recommendation 1: frosmo-category-reco-1
      • Recommendation 2: frosmo-category-reco-2
  • If it's not possible to add the web page elements, Frosmo uses existing elements to determine the correct selectors.

Frosmo applies the selectors to the placements during deployment.

Updating a Content Security Policy to allow Frosmo content and scripts

The Frosmo Platform uses scripts to both inject content to your site and collect data from the site. If the site uses a Content Security Policy (CSP) to control where resources can be loaded, you must update the policy to allow Frosmo content sources. Otherwise, the platform will not function on your site.

Frosmo content sources

The exact content sources you need to allow depend on the platform region where your site is hosted. The following table lists the sources by region.

Table: Frosmo content sources to allow in a CSP

RegionContent sources * * * * *

Affected policy directives

You must update the following policy directives, if used on the site, to include the Frosmo content sources for your platform region:

  • connect-src
  • default-src
  • frame-src
  • img-src
  • script-src
  • style-src

The exact set of directives that you need to update depends on what's defined in the site's CSP configuration. For example, if the CSP only defines the default-src directive, update only that directive to include the Frosmo content sources. Do not define additional directives just for Frosmo content. By comparison, if the CSP defines all six directives listed above, update all of them to include the Frosmo sources.

Example policy

You can define a CSP either with the Content-Security-Policy HTTP response header, which you set in your web server configuration, or with the HTML <meta> element, which you define directly on a web page. The HTTP response header is the recommended approach.

The following CSP configuration examples show you how to allow Frosmo content on a site hosted in the EU region. The examples include both the original configuration without Frosmo content sources and the updated configuration with Frosmo sources.

Example: CSP for EU site using HTTP response header
# Original CSP
Content-Security-Policy: default-src 'self';
                         script-src 'self';

# CSP updated for Frosmo content
Content-Security-Policy: default-src 'self' *;
                         script-src 'self' *;
Example: CSP for EU site using <meta> element
<!-- Original CSP -->
    content="default-src 'self'; script-src 'self';"

<!-- CSP updated for Frosmo content -->
    content="default-src 'self' *; script-src 'self' *;"

Setting up a game data feed for the site

You can use a game data feed to:

  • Provide Frosmo with additional, relevant game information that is not available through game tracking on the site.
  • Ensure that the game data stored in the Frosmo database is always up to date.

While not required, a game data feed is a useful complement to game tracking. Since game tracking relies on visitors viewing pages that contain and send game data, and since the game data on the site may be incomplete or out of date, a game data feed is an excellent way to ensure that the Frosmo Platform always has the latest and complete game data available for analytics and web content.

If you have distinct sets of games for different sites or environments, provide separate feeds for them.

To read your game data feed, Frosmo needs:

  • URL of the feed
  • If used, authentication credentials for reading the feed (the platform currently supports the "Basic" and "Bearer" schemes for HTTP authentication)
  • Description of the feed data structure if the structure is not self-explanatory

Once you've provided this information, Frosmo will set up and schedule a feed reader to retrieve and save the game data at regular time intervals. The available update intervals are: 1 day, 2 hours, 1 hour, 15 minutes. The feed reader will handle any conversions between your game data structure and the Frosmo product data structure.

Game data feed setup

The game data feed must be in either the JSON or XML format. Optionally, the feed can be gzip-compressed.

It is recommended that the feed contain at least the following attributes for each game:

  • ID (must match the one in the iGaming events)
  • Brand
  • Category
  • Features
  • Image URL
  • Launch URL
  • Theme
  • Type
  • Volatility

The following code is an example of the contents of a game data feed in the JSON format.

Example: Game data feed contents in JSON
    "id": 1,
    "name": "Agent Jane Blonde Returns",
    "type": "Slot Machine",
    "brand": "EntNet",
    "category": "Slots",
    "subcategory": "Themed",
    "themes": [
    "badges": [
    "images": [
    "launch": "",
    "features": [
    "reels": 5,
    "paylines": 15,
    "rtp": 96.5,
    "volatility": "medium",
    "rating": 4,
    "reviews": 12
    "id": 2,
    "name": "Arabian Nights",
    "type": "Slot Machine",
    "brand": "EntNet",
    "category": "Jackpots",
    "subcategory": "Slot Jackpots",

// ...

Sending customer information to Frosmo

The Frosmo Platform can use customer information for visitor segmentation and content personalization. If you have relevant customer information stored in, for example, a customer relationship management (CRM) system, and if you want to make the information available to Frosmo, let us know, and we'll figure out together the best way to send the information to the platform.

An easy way to send the information is through the data layer. The following example shows a data layer push for a login event with associated customer information.

    event: 'login',
    user_id: '9876ad45ef9',
    promotions: [1234, 5678, 9012],
    segments: [1212, 3434, 5656, 7878],
    balance: 1234.56,
    age: 56,
    country: 'GB',
    language: 'en'

Sending Frosmo events to Google Analytics

If you're using Google Analytics (GA4) on your site, you can have the Frosmo Platform track basic modification events (clicks, displays, true displays) also as GA4 events. This means that, for every basic event, the platform also triggers a corresponding GA4 event, allowing you to consolidate reporting and analytics in GA4.

Frosmo will set up the integration for your site. This requires access to your GA4.

Where to go next