Analytics (Construct 3)

Analytics in Construct 3 is all event‑sheet actions — no JS, no SDK identifiers in your code. Wire it once into your layout transitions and custom events flow through the same pipe as every other FRVR game.

Level funnel

On start of layout "Level_1":
  Action: FRVR SDK → Level Start ("level_1")

On end of layout "Level_1":
  Action: FRVR SDK → Level End ("level_1")

Always pair a Level Start with exactly one Level End using the same id. Incomplete pairs throw off completion‑rate dashboards.

FTUE (first‑time user experience)

Sequential onboarding steps — re‑reporting an earlier step is ignored. That means you don’t need to guard against “did the player already see step 2?” — fire the step whenever it happens, and the backend dedupes.

On TutorialStep1 complete:
  Action: FRVR SDK → Log FTUE (1, "learn_to_jump")

On TutorialStep2 complete:
  Action: FRVR SDK → Log FTUE (2, "learn_to_doublejump")

Custom events

On button "OpenShop" clicked:
  Action: FRVR SDK → Log Event ("shop_open")

On purchase success:
  Action: FRVR SDK → Log Event ("bought_skin", "skin=red_hat,slot=head")

The second argument is a free‑form properties string; the exact format (JSON vs. key=value) depends on your plugin version — hover the field in Construct’s picker to see the expected shape.

Naming conventions

Event names: snake_case, past‑tense for completed actions (bought_skin, opened_shop).
Level ids: snake_case, scoped (world1_level3, not just level3). Game‑mode qualifiers fold into the id (endless_hard, daily_2026_04_24).

What you don’t have to do

Don’t batch events yourself — the SDK queues them.
Don’t gate on consent — events queue until the CMP resolves, then dispatch or drop based on the result.
Built‑in events (page_loading, game_loaded, device_info) fire automatically.

Full event taxonomy, custom events with numeric values, consent queueing: Web SDK analytics.