Record your own events

Call lt('track', name, properties) to record activity beyond automatic page views, such as a completed sign-up or a selected plan. A new name appears in the catalog when its first event arrives; you do not register it in advance.

Before you start: deploy the tracking snippet. The examples describe an Acme sign-up and checkout; replace the event names and property values with your own.

Record an event

1. Add a track call after the snippet, where your application completes the action you want to record:

lt('track', 'signup_completed');
lt('track', 'signup_completed', { plan: 'pro', seats: 5 });

The event name is required; a call without it is ignored. Properties are an optional JSON object. Sending a new name needs no separate configuration.

2. Perform the action on your deployed site.
3. Verify it works: find the event in Live, then check its name in Events. Live refreshes every 5 seconds.

The loaded tracking function handles invalid arguments and internal errors without throwing into your page; the affected event can still be lost. The loader snippet queues calls made before the script loads. The minimal variant does not provide that queue, so early calls can throw.

Use lt('flush') to send the buffer immediately. Normally the script handles this itself when the page is hidden or left.

Name events so they stay readable

Event names are case-sensitive, free-form text: Signup and signup produce separate entries. Catalog rows and reports group by that exact name, so use a consistent convention:

• One style for everything, for example lower case with underscores — signup_completed, checkout_started, plan_upgraded.
• The thing that happened, not where the button was.
• A stable name. Renaming an event splits its history into two entries.

Attach properties

Properties describe the action, such as a plan, currency, or seat count. Pass a JSON object; full-mode events retain its keys and values as sent.

lt('track', 'checkout_started', { plan: 'pro', seats: 5, coupon: 'SPRING' });

Use a few short property values per event. The script flushes near 60 KB, and batches over 64 KB are refused. Never include passwords, card numbers, or other data you do not intend to store.

In full mode, events already include URL, referrer, and page title. Tracking reads these values from the URL:

• utm_source, utm_medium, utm_campaign, utm_term and utm_content;
• the advertising click id, when one is present — gclid, fbclid, msclkid, ttclid, twclid, li_fat_id, dclid, gbraid or wbraid. Only the first one found is kept, in that order.

Tracking adds the visitor’s country when the event arrives.

Cookieless events still record the action but drop its properties. They contribute to event totals, the catalog, and Live, without creating or joining a person. They therefore cannot supply the person history used by funnels and attribution. Backend events have a separate identity path. See Tracking and consent.

Check what you are actually sending

The catalog. Events lists names as they first arrive. Each row shows count, last seen time, up to 50 sampled property keys, status, and Workflow trigger. Search by name; sort either way by count, last seen, first seen, or name; or use the All, Active, and Archived tabs.

Look for a low-count row with a near-identical name when an expected count is short; a typo creates its own catalog entry.

MCP. tracking_event-names_list returns the same catalog to an agent.

The live feed. Live lists arriving events newest first, with name, arrival time, page, source, and visitor when known. Filter by domain to isolate a site. It refreshes every 5 seconds, pauses in a background tab, and resumes when you return. Agents can read the stream with tracking_live-events_list.

Use Live to verify individual calls, the catalog to inspect names, and reports for counts over time.

Start a workflow from a name

Select Workflow trigger on an event’s catalog row to publish each recorded occurrence to Lepsto Workflows. Clear it to stop publication. Every name starts with this setting off, and the setting belongs to that name in that product.

Changing the checkbox does not change event storage, counts, or reports.

Set this option on Events; a workflow step cannot change the conditions that trigger its own runs. Archiving and unarchiving names are also catalog actions rather than workflow steps.

Account for these effects before testing:

• It takes up to about a minute for a tick or an untick to reach every part of the system. A test event sent straight after ticking may produce no run — wait a minute and send another before concluding anything is wrong.
• The trigger carries the person’s email and phone when Tracking knows them, whatever the visitor chose about consent, because a workflow step that sends a message needs a recipient. The properties you sent with the event are never published.

Trigger a workflow from a tracked event covers this in full.

Hide a name you no longer want to see

Choose Archive to hide an obsolete or mistaken name from dashboards. Its events and counts remain, and new events continue to arrive. Unarchive makes the name visible again.

MCP. tracking_event-names_archive and tracking_event-names_unarchive.

Send events from your backend instead

Use your backend for payments confirmed by a billing provider, subscription endings, or operator-started trials. Authenticate the HTTP request with a public access key.

Send up to 500 events in an events array. Names remain free-form. Tracking recognizes six lifecycle names: signup, trial_started, subscription_started, payment, refund, and churn. Only payment and refund require an amount; ordinary named events require event_id and name.

Any name can include amount_minor with currency. For names outside the six lifecycle events, the amount is stored but does not contribute to revenue reports or lifetime value.

Choose an event_id for each backend event. The response separates accepted events, duplicates, and validation rejections. Reuse the same ids after a timeout so a retry cannot store them twice. A 402 refuses the whole batch; resolve its plan or billing reason before resending. See Revenue fields and HTTP responses.

What does not arrive

A sent event is not necessarily stored. These checks can remove it:

Next steps

• Identify a visitor: turn an anonymous browser into a named person.
• Send revenue from your backend: the six lifecycle names that carry money and the fields they take.
• Read the attribution reports: what the events you send add up to.
• Trigger a workflow from a tracked event: make one of these names run a workflow.
• Fix events that never arrive: symptom by symptom.