Custom events

The tracker records the visit for you: pageviews, outbound clicks, downloads, scroll depth, engaged time. Anything that happens inside your product is yours to name, with mrkr.track() or its declarative counterpart. Neither costs you anything: custom events do not count toward your plan's quota.

#mrkr.track()

Call it from your own code, anywhere after the script tag has loaded:

mrkr.track("signup_completed", { plan: "pro", source: "landing_page" });

The first argument is the event name (truncated to 64 characters). The second is an optional flat object of properties. There's no need to declare an event before you send it: the first time an event name arrives, it registers itself and immediately shows up in your Events list.

#The declarative attribute: data-mrkr-event

For clicks specifically, you can skip writing JavaScript entirely and annotate the element instead:

<button data-mrkr-event="cta_click"
        data-mrkr-prop-variant="hero"
        data-mrkr-prop-plan="pro">
  Start free
</button>

This fires the same as calling mrkr.track("cta_click", { variant: "hero", plan: "pro" }) on click. Each data-mrkr-prop-* attribute becomes one property; multi-word attribute names (data-mrkr-prop-plan-tier) come through as plan_tier, matching what you wrote in the HTML.

#Property limits

Properties are bounded on both the client and the server, so a stray payload can't blow up storage or the bytes your visitors upload:

• Booleans and finite numbers are stored as-is; NaN and Infinity are dropped.
• Strings longer than 256 characters are truncated, not rejected.
• Objects and arrays are JSON-stringified, then truncated the same way as a string: nested structures survive as a stringified blob, but they can't be broken down by key in the dashboard.
• null and undefined values are dropped entirely rather than stored as empty.
• If you send more than 8 properties, the ones that get dropped are chosen deterministically (by sorting keys alphabetically and keeping the first 8), so the same payload always keeps the same subset instead of a random one.

#Naming conventions

Event names and property keys become labels in your dashboard's breakdown UI, so treat them like you would a database column: lowercase, snake_case, and consistent across call sites (signup_completed, not signup_completed in one place and SignupComplete in another; those are two different events to Mrkr). Avoid putting anything personally identifying in an event name or a property value; properties are for categories to group by (a plan tier, a variant, a step number), not free text.