▪️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.
If you want to add or remove tags, you will need to modify original set on the client side and send it back, 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 account 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 live avatar, current level, and points balance, and present this information on your site
You can expose gamification tools to a limited percentage of the user 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 also to 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 who are not in the control group.
You are able to set the custom avatar as a png image with a 1x1 proportion for logged-in user.
You are able to set the custom nickname for user, the way he will be visible in the leaderboards and tournaments
There are different ways to load the Gamification widget, MatchX game, Spin The Wheel and 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 every time when 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 number of total inbox messages that can be sent per month on one setup.
Please contact your account manager for details.
You can design a "bell" or "envelope" icon together 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 Smartico account 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 formula of the calculation 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 Account Managers 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 account 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