Event vs property in analytics: what's the difference?

Event vs property: the difference

Pageviews tell you where people went. Events tell you what they did: started a trial, played a video, used a filter, paid. Each event has a name, a time, the person or device that did it, and a set of properties:

track('purchase', { order_id: 'A1042', value: 129, currency: 'USD', items: 3, coupon: 'SPRING' })

There are two kinds of properties. Event properties describe this one occurrence (the order value). User properties describe the person and persist across events (their plan, their signup date, their country).

One event with properties, not many events

The most common mistake in tracking is creating an event per variation: click_buy_red, click_buy_blue, click_buy_footer. Reports then need every variant added by hand, and new variants are missed.

Instead, name the action once and put the variation in properties: click_buy with color and position. A useful test: if two events would always be analysed together, they should be one event. Keep events in the dozens, not the hundreds, and let properties carry the detail.

Naming rules

• Object + action, one style. order_paid, trial_started — or Order Paid, but not both.
• Past events, not UI. Name what happened (signup_completed), not the button (blue_cta_click); buttons change, the business event does not.
• Typed properties. A value is always a number, a currency always a three-letter code. Mixed types break sums and filters.
• No personal data in names or free-text properties. Emails and phone numbers do not belong in event properties.

Events and properties in TapCub

Events reach TapCub from the web script (tapcub.track()), from autocapture, from the mobile and mini-program SDKs, and from server SDKs. All of them land in one event store, so a signup sent from your back end and a click sent from the browser can sit in the same funnel.

Each event name can be registered as a definition with a display name, category and declared properties, and the tracking plan checks live data against those declarations. Property governance lets you block a property, whitelist the ones you allow, isolate values with too many distinct entries, or quarantine events that fail validation instead of storing bad data. Properties that look like personal data are stripped and reported as a data quality warning.

Common mistakes

• Tracking everything. Hundreds of unused events make the important ones hard to find.
• Different names per platform. signup on web, sign_up in the app and SignUp on the server are three events.
• High-cardinality properties. A full URL with query string, or a timestamp, as a property makes breakdowns useless.
• Firing events on load. An event every page sends automatically records nothing about behaviour.

Related guides: Event Tracking and Form Analytics.