Product events describe meaningful actions in your application, such as completing onboarding or sending an invitation. Give each event a clear definition so reports count the behavior you intended.

Choose the action and key

Use a readable title in past tense, such as Invite Sent, and a stable code key, such as invite_sent. Keep changing values out of event keys. Use one key for the same action across all applicable screens.

Define what success means. For an invitation, decide whether the event represents creating an invitation, successfully submitting an email for delivery, or the recipient accepting it. These are different actions and should not silently share one definition.

Register the event first

Create the event under Events → Add Events, select Code, and save its Key before adding the call to your application. The SDK rejects unknown keys.

See How to set up event tracking for the complete setup procedure.

Call track at the right point

Initialize the SDK once in the browser. For a configured key invite_sent, call:

await userorbit.track("invite_sent");
JavaScript

Place the call after your application's invitation action succeeds. Avoid adding the same call to both a button handler and a component effect that observes the result. Re-renders and repeated handlers can create separate events for one action.

Analytics records the code key. In-app experiences can also react to the configured event, subject to their own targeting and delivery rules. Disabling in-app functionality does not mean every analytics path is disabled.

Understand identity and properties

Identify signed-in people with a stable ID when your analysis needs to follow their activity. Without an explicit identity, the SDK can use a generated or stored browser ID. Verify sign-out and shared-browser behavior using the User identity API reference.

The current public browser method does not forward an arbitrary properties object to Analytics. Although the method's options type includes hiddenFields, those fields are not forwarded as custom Analytics event properties by the current code-event path. Do not pass a second argument such as { plan: "business" } and assume it creates a reportable event property.

Use profile attributes for information that describes the person, and verify how it appears in Analytics before building a report around it. If your use case requires values specific to each individual event, confirm a supported collection approach with Userorbit.

Validate before release

Open Analytics → Live Events in the correct project and perform one known action. Confirm its key, identity, and timestamp, then test a cancelled action and repeated navigation.

For a release, record the event owner, exact trigger, key, intended identity, data allowed, and expected count. After deployment, repeat the test and check for a sudden increase or decrease in volume.

If a report looks wrong, first verify the underlying events. A report cannot distinguish an intentional repeated action from a duplicate call without a correct tracking implementation.

Was this helpful?