▪️Pages & Widgets Analytics

Smartico automatically measures how visitors interact with the landing pages, promo pages, custom games, and widgets you build in Web Studio. Every meaningful action — a page opening, a screen change, a button click, a form submit — is recorded as an event. This guide explains, in plain language, what each event means, how to track your own buttons and links, and how to get the raw data for your own analysis.

What gets measured

There are two families of events:

• Page events happen on a full Smartico page (a landing page, promo page, or custom game the visitor opens in the browser).

• Widget events happen inside a widget — a Gamification Block or Custom Game you embed on your own website.

The two families measure the same kinds of actions; they are just separated, so you can tell "activity on a Smartico page" apart from "activity inside a widget on my site".

Page events

Event	What it means
Page view	A visitor opened the page. It also fires when someone returns to the page using the browser's Back button — those returns are flagged separately, so you can tell fresh visits apart from back-button returns.
Page hidden	The visitor switched away from the page — moved to another browser tab, minimised the window, or locked their phone.
Page visible	The visitor came back to the page after it had been hidden.
Page unload	The visitor left or closed the page. This is the last event we record for that visit.
Page route change	The visitor moved to a different screen inside the same page (for pages that have several screens — for example, from the home screen to a "Missions" screen).
Page CTA click	The visitor clicked a button or link that you chose to track. This one is not automatic — see Tracking your own buttons and links.
Page form submit	The visitor submitted a form on the page (for example a sign-up or contact form).
Page error	The page's code hit an unexpected error. Handy for spotting a page that has broken for real visitors.

Widget events

Event	What it means
Widget mounted	The widget finished loading and appeared on your host page.
Widget unmounted	The widget was removed from the page.
Widget hidden	The page hosting the widget was hidden (tab switch, minimise, phone locked).
Widget visible	The host page became visible again.
Widget route change	The visitor moved to a different screen inside the widget.
Widget CTA click	The visitor clicked a button or link you chose to track inside the widget. Not automatic — see below.
Widget form submit	The visitor submitted a form inside the widget.

Which events happen on their own, and which you set up

Almost everything is automatic. Page opens, screen changes, hide/show, leaving the page, form submits, and errors all record themselves with no work on your side.

The only events you decide on are the CTA click events. A "CTA" (call to action) is any button or link whose clicks you want to measure — "Sign up", "Deposit", "Play now", "Claim bonus", and so on. You can set these up in one step with the Web Studio assistant, or add them by hand — see Tracking your own buttons and links.

Tracking your own buttons and links

There are two ways to add click tracking — let the Web Studio assistant do it for you, or add it by hand.

The quick way: the /analytics-track-clicks command

In the Web Studio editor, open the AI assistant chat, type /analytics-track-clicks and send it:

/analytics-track-clicks

The assistant reviews your page and automatically tags the buttons and links worth measuring — primary calls to action such as Sign up, Log in, Deposit, Play now, Spin and Claim bonus, offer/card buttons, and prominent navigation — giving each one a clear, readable tracking name (for example signup-cta, deposit-button, claim-bonus). It:

• only adds the tracking attribute — it never changes how anything looks, reads, or behaves;

• never overwrites a name you already set, so it is safe to run again after you add new buttons (it only tags what isn't tagged yet);

• skips forms — form submits are already tracked automatically (see below), so there's nothing to add for them;

• works the same for full pages and for widgets (Gamification Blocks / Custom Games).

Because it edits your page, the assistant first shows a short summary of what it will do and asks you to Proceed or Cancel. When it finishes, it lists everything it tagged, so you can see the names that will appear in your reports. It's on-demand — run it whenever you like, and publish your page afterward for the new tracking to go live.

The manual way: add data-track-id yourself

To track a specific element (or rename what the assistant chose), add a data-track-id attribute with a short name of your choice:

<button data-track-id="signup-cta">Sign up</button>

<a href="/deposit" data-track-id="deposit-link">Deposit now</a>

To adjust any name the assistant picked, just edit its data-track-id value.

What are the tracked click records

From then on, every time a visitor clicks a tagged element we record a CTA click event that carries:

• the id it was given (signup-cta, deposit-link, …) — for a link without a data-track-id, we fall back to the link's URL;

• the visible text of the element that was clicked ("Sign up", "Deposit now").

This lets you compare which buttons get clicked most, measure the click-through of a specific offer, or build a funnel from "page view" to "clicked the deposit button".

Pick clear, stable names and reuse them across your pages so your reports stay consistent. Forms need no tagging — a form submit is captured automatically whenever a visitor submits a <form>, whether or not the command ever touched it.

What information does each event carry.

Alongside the event type, every record includes useful context so you can slice the data:

• Which page or widget it happened on (so you can report per page).

• When it happened.

• The visit it belongs to (a session id that resets when the visitor closes the tab), so you can reconstruct a visitor's journey and measure time between steps.

• Who the visitor is — the known user id and external user id once the visitor is identified, or an anonymous visitor id for visitors who haven't been identified yet. Anonymous activity is still recorded.

• Where they came from — the utm_source, utm_medium, utm_campaign, utm_term and utm_content from the page URL (captured on the first event of the visit), plus the referring website. This is what lets you attribute activity to a specific campaign.

• Device, operating system and browser, and the visitor's country/brand context.

• The screen (route) they were on, and, for CTA clicks, the id and text of the element clicked.

Using the raw data for your own analysis

You are not limited to the reports in the Smartico back office. All of this landing-page and widget activity is available as raw data in the Smartico Data Warehouse (DWH), so you can build your own reports, dashboards and models in your own BI tools.

• The events described above live in the DWH table g_lp_analytics (one row per event).

• Page details — the page's name, its type, and whether it is published — live in a companion table, dm_lp_template, which you can join to g_lp_analytics to show friendly page names instead of ids.

• History is retained for roughly 3 years (the most recent 1080 days).

With direct access, you can, for example:

• Build funnels — page view → screen change → CTA click → form submit — and see where visitors drop off;

• Measure CTA performance — clicks and click-through rate per button, per page, per campaign;

• Attribute activity to campaigns using the captured UTM values;

• Compare device / browser / country breakdowns;

• Combine landing-page activity with your other Smartico data for deeper analysis.

If you don't yet have Data Warehouse access, or you'd like help getting started with queries, contact your Smartico Success Manager.