> For the complete documentation index, see [llms.txt](https://help.smartico.ai/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.smartico.ai/welcome/products/vibe-studio-beta/pages-and-widgets-analytics.md).

# 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

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

#### Widget events

<table data-search="false"><thead><tr><th width="202.140625">Event</th><th>What it means</th></tr></thead><tbody><tr><td><strong>Widget mounted</strong></td><td>The widget finished loading and appeared on your host page.</td></tr><tr><td><strong>Widget unmounted</strong></td><td>The widget was removed from the page.</td></tr><tr><td><strong>Widget hidden</strong></td><td>The page hosting the widget was hidden (tab switch, minimise, phone locked).</td></tr><tr><td><strong>Widget visible</strong></td><td>The host page became visible again.</td></tr><tr><td><strong>Widget route change</strong></td><td>The visitor moved to a different screen inside the widget.</td></tr><tr><td><strong>Widget CTA click</strong></td><td>The visitor clicked a button or link <strong>you chose to track</strong> inside the widget. Not automatic — see below.</td></tr><tr><td><strong>Widget form submit</strong></td><td>The visitor submitted a form inside the widget.</td></tr></tbody></table>

### 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:

```html
<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)**](/welcome/technical-guides/smartico-data-warehouse.md), 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.smartico.ai/welcome/products/vibe-studio-beta/pages-and-widgets-analytics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.