How to Design Analytics Event Properties That Stay Useful

# How to Design Analytics Event Properties That Stay Useful

Event names tell you what happened. Event properties explain the context.

A useful analytics model therefore needs both:

Event
  +
Properties
  ↓
Meaningful analytics data

In a hotel booking application, the same concepts—hotel, room, booking, dates and search context—appear repeatedly. Their representation should remain deliberate and consistent.

1. Start With the Business Question

Do not begin by copying the entire application object into analytics.

Start with:

What question should this event answer?

For example:

view_item

may need a hotel identifier and name.

A purchase may need:

transaction_id
value
currency
items

The event contract should reflect the business purpose.

2. Use Stable Identifiers

If a hotel has one identifier in one event and a different property name in another, analysis becomes harder.

Avoid arbitrary variation:

hotelId
hotel_id
propertyId
property_id

when they all represent the same concept.

Define the analytics mapping deliberately.

3. Separate Application Models From Analytics Models

Prefer:

Application object
      ↓
AnalyticsService mapping
      ↓
Provider payload

rather than:

Application object
      ↓
Direct provider payload

This protects the analytics contract from changes in internal application models.

4. Keep Properties Purposeful

Useful property categories can include:

Identity
- hotel ID
- booking ID

Context
- destination
- dates
- guests

Ecommerce
- value
- currency
- items

Journey
- list
- position
- selected option

Not every event needs every category.

5. Avoid Entire Domain Objects

Avoid:

items: [hotelObject]

when the object contains internal structures unrelated to analytics.

Prefer explicit mapping:

items: [{
  item_id: hotel.id,
  item_name: hotel.name
}]

This makes the external contract easier to inspect and maintain.

6. Keep Cross-Provider Meaning Aligned

The application uses a centralized analytics layer for GTM/GA4 and Klaviyo.

That does not mean every provider needs identical payloads.

Instead:

Business action
      ↓
AnalyticsService
   ↙       ↘
 GA4     Klaviyo

Each provider can receive the properties appropriate to its event model while the business meaning remains consistent.

7. Think About Property Lifetimes

Some information exists only during one event.

Other information is useful throughout a journey.

For example:

Hotel ID
   ↓
view_item
   ↓
select_item
   ↓
purchase

A transaction identifier becomes especially important at purchase.

Marketing attribution can also need persistence because Angular route changes can remove the original URL parameters.

8. Validate the Contract

A practical review should ask:

9. Test the Event Contract

Test both the event and its properties.

For example:

Event: purchase
  ├── transaction_id
  ├── value
  ├── currency
  └── items

A successful event with incomplete properties may still produce weak analytics.

Common Mistakes

Conclusion

A durable analytics implementation is a contract, not a collection of ad-hoc push() calls.

Stable identifiers, purposeful properties and centralized mapping make the data easier to understand and safer to evolve.

Related Content