▪️Extended integration
Last updated
Last updated
You can set a property "Last login entry point" and segment users by it or react when they are logging in from a specific entry point.
This is useful, in case the integrated website has different entry points, for example - there is a lobby, landing page, user profile, etc. Or there are different device types that can be used to log in, like mobile, desktop, app, TV, etc.
The entry point can be reported in the following way:
You can pass any string value as the entry point, but the number of different entry points per label is limited to 50.
You can report a specific action done by the end-user, for example when the user is clicking on the submit button on the cashier page, you can report the action 'CashierSubmitClicked'.
Example:
As soon as the action is defined, and triggered at least once, you can build a real-time journey to react to such action
In case you need to provide additional attributes together with action, please follow the 'Reporting client-side events' approach described below.
In some cases, you will want to start a campaign when the user is getting to a specific page.
One of the options is to pass a special parameter in the URL of any of your pages.
For example, you can build a URL like
When a user comes on this page you can catch him with the campaign waiting for the "Core: client action" and action DEPOSIT_OPENED
Note: the passed parameter in our example is "dp:action&action=TEST5" which is "URL Encoded". You can also pass any other deep links that will be triggered automatically after the user is logged in
There is a possibility to put markers on the user from the campaign flow or with automation rules and use these markers on the front end.
When the marker is set to the user, you are able to use it in the front end using the following code.
You can also update JS markers from the client side with JavaScript, e.g.
You can report events in the context of identified end users via Smartico JS SDK.
Public channels are considered as not trusted, those should be used only for non-sensitive events like - the user navigating to a specific screen, clicking on some elements, etc.
Example:
The payload of the event is passed as JSON object with any structure and data types.
Before reporting any custom events, please contact the Smartico Customer Success Manager to align the data that will be reported and how it should be processed by the Smartico system.
Smartico team will need to register such events and define rules for processing and storing payload
As soon as the user is logged in, you can get user profile details, such as avatar, current level, and points balance, and present this information on your site
You can expose gamification tools to a limited percentage of the users using the Gamification control group.
For example, you can set it to 10%; in this case, gamification will be enabled randomly for 10% of newly registered users.
You can use a user property "ach_gamification_in_control_group" to segment users to whom gamification is disabled and use it on the front end to hide an entry point to the Gamification widget.
Example of the JavaScript code to expose the gamification widget only for users not in the control group.
You can set the custom avatar as a PNG image with a 1x1 proportion for logged-in users.
You can set the custom nickname for the user, the way he will be visible in the leaderboards and tournaments
There is a way to set the Gamification widget skin using JavaScript API
There are two possible cases we have got from clients.
If you have Day and Night visual schemes for your website, you may want to use two different Gamification skins depending on the UI of the main site.
Another case is when you want to give some users special skins, for example, based on the achieved level.
There are different ways to load the Gamification widget, MatchX game, Spin The Wheel, Scratch card, and other components.
You can see examples of embedding MatchX and other gamification components on this demo page: https://expo.smartico.ai/widgets/api_widgets
Also, check these articles in the documentation for the details of the integration:
The inbox widget (or notifications widget) is an interface where the user can see the history of all notifications sent from Smartico CRM.
To open the inbox widget, use the following javascript code
You can also get a count of unread messages in order to show it in your own interface. The count is available as a callback and will be updated whenever the user gets a new message or marks some messages are read.
The Inbox widget is an additional feature that needs to be enabled on your setup.
There are also limits regarding the total inbox messages that can be sent monthly on one setup.
Please get in touch with your Customer Success Manager for details.
You can design a "bell" or "envelope" icon with a count of unread notifications, as shown in the example below.
Popups and inbox messages can be suspended in some cases. Usually, it's done on the screens where the user shouldn't be interrupted from the main process, e.g., on the Deposit page or while completing a KYC form.
After disabling suspension, the first popup that was missed will be shown to the end-user if the client session remains active (the user didn't refresh the page or didn't navigate between pages).
If the integrated platform is loaded in the iframe and not the owner of the main window, the setup should be done in a different way.
The site that owns the main window should load only the smartico.js script without doing initialization of the label/brand and identifying the user. HTML code to past as is:
The iframe should load smartico_inframe.js script and makes the same calls as described above, but using _smartico_inframe object instead of _smartico.
Example of the script
Please contact your Customer Success Manager to evaluate if your setup needs this type of integration.
The gamification widget can be opened in read-only mode from 3rd party sites.
The most common reason for this is to provide the Support team the possibility to see the current status of the gamification setup as the end-user sees it.
The widget can be opened using the URL:
Parameters to be passed:
label_key & brand_key - the same set of public keys for the label & brand as used in the front-end integration for the end user
user_ext_id - identification of the user in the integrated product
user_hash - md5 hash and the validity timestamp separated with the ":" symbol
The user_hash should be calculated in the following way
Label salt key can be retrieved from label configuration in Smartico BackOffice. Hash validity timestamp is defining the time in epoch with milliseconds till which the hash will be valid.
Example of calculation:
Example of JavaScript code opening a widget in the iframe and closing it when the widget is closed from inside:
Smartico BackOffice is using the same approach to show the gamification widget of any user in the CRM section
The simple user identification is based on the unique ID of the user set in the _smartico_user_id
In case the user ID can easily be guessed (e.g. it's a sequential number or just a sting that corresponds to the username), there are additional mechanics to protect identification.
You will need to calculate a hash string from the user ID, secret salt key, and validity timestamp. The calculation formula is the same as described here. The hash should be calculated on the server(!) and passed in the front end in the following way.
The salt key should be requested from Smartico Customer Success Manager and should be kept in secret.
You can directly call the Smartico script to trigger the browsers' native dialog for push permissions.
This can be done for the already identified user or an anonymous (visitor).
The push permissions token will be registered automatically on the Smartico side when the user is identified.
It's also possible to build marketing (acquisition) campaigns., gamification, and communication for anonymous users (visitors), please get in touch with your Smartico Customer Success Manager to make the needed setup and provide training.
By default, the Smartico script is not allowed to be used on the localhost.
This is done to prevent the creation of "phantom" users when the script running on localhost is usually connected to the DEV/QA environment, and the user that reported from this environment will be sent to smartest, which will lead to the creation of the users that shouldn't be on production.
If you want to run on localhost and you are going to use a real/production user, you can enable debugging on the localhost
Smartico has two fields to hold UTM parameters - core_utm_source and core_utm_campaign.
These fields can be set via server REST API or can be also set from the front-end
You can check if the user belongs to the segment.
You can use this functionality to change the front-end of your web-site based on the segmentation that is managed by smartico.
You can also use checkSegmentListMatch to verify multiple segments in one request, you can find more details here - https://github.com/smarticoai/public-api/blob/main/docs/classes/WSAPI.md