Event tracking examples for seven kinds of business

Good event tracking starts small: the handful of events that describe how your business creates value. The event tracking examples below give a starting set for seven kinds of business, with the properties worth attaching and the questions each set answers. After them, we cover the naming rules and mistakes that most often spoil event data.

If you're new to the idea, an event is a record that something happened: a name, a time, the person who did it and a few properties. How events work in LogZuno shows the exact shape.

How to read these examples

Each list is a starting point of eight to twelve events, not a complete plan. Track these first, build the reports they enable, and add more only when a question needs them. Every event is named as a past-tense action and sent, where possible, from your backend after the action succeeds. Real-time event tracking explains why the backend matters.

1. SaaS product

With these you can build the activation funnel (sign-up → project → invite), weekly retention, feature adoption and trial-to-paid conversion. Add a group ID for the customer's company so you can count active accounts. More on the numbers in SaaS KPIs and LogZuno for SaaS.

2. Ecommerce store

The funnel from Viewed product to Placed order shows exactly where shoppers drop out, and averaging amount on Placed order gives average order value. Use order_id as the event's idempotency key so a retried webhook never counts an order twice. See the ecommerce metrics guide and cart abandonment.

3. Marketplace

Marketplaces have two sides, so track both:

• Supply: Listed item, Updated listing, Responded to enquiry, Accepted booking.
• Demand: Searched (with query and results_count), Viewed listing, Sent enquiry, Booked.
• Transaction: Payment captured, Payout sent, Left review (with rating).

Searches with results_count: 0 are gold: they tell you what buyers want that sellers don't yet offer. Track liquidity as the share of listings that receive an enquiry within seven days.

4. Fintech app

Fintech events carry more regulation, so track actions and outcomes without sensitive values:

• Started onboarding, Submitted KYC, KYC approved / KYC rejected (with reason code, never document data)
• Linked bank account, Funded account (with amount_band, not the exact balance)
• Sent payment, Payment failed (with error_code), Card frozen

The onboarding funnel is usually the biggest lever: every extra verification step loses people, and the funnel shows which step. Never put personal identifiers or account numbers in properties. The fintech metrics guide covers the numbers to watch.

5. Mobile app

• Installed app (sent by your backend on first launch), Completed onboarding
• Enabled notifications, Opened from notification
• Started session is optional; daily activity can be derived from any event
• Your app's core action, for example Logged workout or Saved recipe
• Purchased subscription, Restored purchase

Because mobile users often update slowly, add app_version to every event so you can compare behaviour across releases. The Swift and Dart examples show how to send events from iOS and Flutter apps. See also mobile app metrics.

6. Content or media site

• Viewed article (with section, author, word_count)
• Read 75% (a scroll milestone, not every scroll)
• Shared article (with network)
• Started free trial, Subscribed, Hit paywall

The ratio of Hit paywall to Subscribed by section tells editors which content converts. On content sites, separating real readers from bots matters more than anywhere else; see bot traffic in GA4.

7. Developer tool or API

• Created API key, Made first API call (sent by your API, not the dashboard)
• Hit rate limit, Received error (with status, endpoint)
• Installed SDK (with language, version)
• Upgraded plan

Made first API call is the activation event for almost every API product. Measure the time from Created API key to it, and alert when Received error spikes. LogZuno's own alerts can post those spikes to Slack. Building with AI coding agents? See the starter set for vibe coded apps.

From events to reports: a worked example

Take the SaaS set above and a team of three. In their first week they send Signed up, Created project, Invited teammate and Payment received from the backend. By the end of week two they have four reports:

1. Weekly sign-ups by source, a trend broken down by the source property. It shows that most sign-ups come from comparison pages, not the blog.
2. Activation funnel: Signed up → Created project → Invited teammate, per user, within 7 days. It shows 74% create a project but only 31% of those invite anyone.
3. Weekly retention from Signed up to any later event. It shows week-4 retention of about a third.
4. Revenue by plan, the sum of amount on Payment received, broken down by plan.

The funnel points straight at the invite step, which becomes the next quarter's work. Four events were enough to find it; forty would only have hidden it. These numbers are illustrative, but the shape is typical.

How many events should you track?

Fewer than you think. Most products are well described by ten to twenty events in the first year. A good test: for each event, can you name a chart or alert that uses it? If not, leave it out until a question needs it.

Volume is a separate matter. A busy product sends millions of events a month from a small number of event types. Keep the types few and well named, and the volume will take care of itself. LogZuno plans are priced by monthly event volume, from 50,000 to 500,000 events, with every feature on every plan.

Naming rules that keep data clean

1. Past tense, user's point of view. Created project, not create_project or projectBtnClick.
2. One event, many properties. Feature used with feature: "export" beats Export used, Share used and thirty siblings.
3. Consistent property names. Always amount and currency, never price in one place and total in another.
4. No personal data in names or properties. Use IDs and bands, not emails or exact balances.
5. Write it down. Keep the list in a tracking plan, as described in product analytics best practices.

Mistakes that spoil event data

• Tracking clicks instead of outcomes. A click on "Pay" isn't a payment. Track the confirmed result.
• Firing on page load. An event that fires every time a page renders inflates counts and means nothing.
• Duplicates from retries. Use an idempotency key, such as an order ID, so a retried request is stored once.
• Changing meaning silently. If Signed up starts firing before email verification, last month's numbers no longer compare.
• Never checking. Watch events arrive in a live feed as you add them, then audit counts against your database monthly.

Sending these events with LogZuno

Every example above is one HTTP request to /v1/log, or up to 100 at once with /v1/batch. Events appear in a live feed within seconds, so you can confirm tracking works the moment you deploy it, then build funnels, retention and dashboards from the same data. Start with the quickstart, or read more about event tracking in LogZuno.