An event dictionary for each kind of business

Ready-made event and property lists for online retail, super-apps, fintech, travel, education and subscription media. Copy and start.

This page is written to be copied. Six kinds of business, and for each one a list of events with their properties that you can take as it stands and start with. The reasoning behind the choices is in designing events; if you have not read it, read at least revenue, because that is the one place where a property name changes a number on a person's profile. And to get this list actually running on your own site or app, see placing events. And if you want to recommend products in your messages, the id you put in product_id here has to match the product catalogue.

#How to read this

The "status" column in every table has two values and the difference matters:

• Standard means the platform declares this name and the panel gives it a Persian label. That is the whole of it.
• Proposed means the name is our convention. The platform does not know it and treats it like any other name. You may change it; just change it before the first send.

One common misreading, closed here: "standard" does not mean "in the event picker". Until the tenant's real schema loads, the segment builder shows ten fixed names (order_completed, product_viewed, product_added_to_cart, checkout_started, order_refunded, searched, app_opened, signed_up, message_opened, message_clicked) and after that it builds the list from your own events. The journey builder labels only eight. A standard name you have never sent appears in no list at all.

Three things to keep separate about the standard list:

Only three names actually have behaviour. order_completed adds the amount to the profile's total_revenue, increments order_count and moves last_order_at. order_refunded and order_cancelled subtract the absolute amount and decrement the order count, both floored at zero. The rest of the standard names have no behaviour at all.

Standard means recognised, not automatic. No event is sent by itself. The names app_installed, app_opened, app_updated, app_removed, session_started and session_ended are declared in the code as "lifecycle events the SDKs emit automatically", and no SDK emits them. If you want them, send them.

**Do not send the message_* names yourself.** Segmentic's own workers write them, and they are listed under what Segmentic writes.

#The names the platform knows

#The properties you put on every event

Before the tables, five rules that are the same across all six businesses.

Do not resend the context. context already carries device, OS, app version, page, campaign and timezone, and the collector puts each in its own column. A platform property on every event is a worse copy of device_type.

Send identifiers as strings. "order_id": "A-100294", not "order_id": 100294. A number is stored as text too, but a string joins against your own system from the start.

Send numbers as numbers and booleans as booleans. "quantity": 3, not "quantity": "3". A numeric-looking string never reaches the numeric map, and a "greater than" filter on it never answers.

Pick one language for property values and stay with it. Values are stored as sent, with Persian normalisation only. gold and طلایی are two values and do not land in the same segment.

Use revenue, total, value, and the pair price with quantity, only on an event where money moved. Revenue is extracted from any event carrying those keys and added to that person's lifetime value. For an amount that is not real money, use another name. The tables below deliberately use unit_price, cart_total and amount, none of which is reserved.

#Online retail

The default funnel this list supports: product_viewed, then product_added_to_cart, then checkout_started, then order_completed. The abandoned-basket segment is the same list: anyone with a product_added_to_cart in the last seven days and no order_completed.

curl -X POST https://in.segmentic.net/v1/track \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wk_seg_..." \
  -d '{
    "message_id": "b3d51f28-4c6a-4b1e-9d70-2f8a3c5e7d10",
    "user_id": "u_88123",
    "event": "order_completed",
    "timestamp": "2026-08-07T10:02:41.000Z",
    "properties": {
      "order_id": "A-100294",
      "revenue": 2450000,
      "currency": "IRR",
      "item_count": 3,
      "shipping_cost": 49000,
      "discount": 150000,
      "coupon_code": "NOWRUZ",
      "payment_method": "gateway"
    }
  }'

{"status":"ok","accepted":1}

#Super-app and ride hailing

Using revenue on wallet_topped_up and ride_completed is deliberate. The code explicitly allows for this: revenue accrues from any event, not only orders, because a customer may model a subscription or a top-up as its own event. Note though that only order_completed increments order_count, so the profile's order count does not count rides.

Put service on every super-app event. Without it you cannot ask for "took a taxi but never ordered food".

#Fintech and payments

amount appears here instead of revenue on purpose. The value of a transfer is not your money: call it revenue and every user's total_revenue becomes their account turnover, so the "high-value customer" segment becomes "moves a lot of money around". On payment_completed both appear, because you want both figures: revenue is the fee that is yours and amount is what the user paid.

#Travel and booking

days_to_departure is stored on the event rather than computed at query time. The difference is that months later you can still ask "how many people booked within three days of the flight", whereas with only depart_date you would have to subtract two strings at report time, and a date string in the property map is text.

#Education

course_abandoned has to be decided by your own system and sent from your server; the platform does not manufacture an event out of the absence of one. If you would rather not build it, do the same thing with a journey that waits after lesson_completed.

Do not put course progress on the profile as a trait unless a user only ever has one course. A trait is one value per person, so with two courses the second erases the first.

#Subscription media

The thing that always surprises people in subscriptions: subscription_cancelled returns no money. Only order_refunded and order_cancelled subtract from total_revenue. A cancellation means the next renewal does not happen, not that previous months are refunded, and the profile says exactly that.

#The traits you send with identify

These are the keys the code gives meaning to, and which become real profile columns:

A new profile starts with all three consents on. An existing customer base has already consented through your own flow, and defaulting to off would make your first campaign reach nobody.

name and created_at are also declared as reserved keys, but they are not promoted to columns and stay ordinary traits. If you want a full name, send first_name and last_name.

Every other key is a free-form trait and lands in the traits and traits_num maps. A shop usually also sends: loyalty_tier string, loyalty_points number, is_wholesale boolean, preferred_category string.

curl -X POST https://in.segmentic.net/v1/identify \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wk_seg_..." \
  -d '{
    "message_id": "c74a9e01-5f22-4a8b-8c31-7ee2d9b40a55",
    "user_id": "u_88123",
    "traits": {
      "phone": "09123456789",
      "email": "Hamid@Example.com",
      "first_name": "حمید",
      "city": "تهران",
      "birthday": "1993-04-11",
      "sms_opt_in": true,
      "loyalty_tier": "gold",
      "loyalty_points": 1840
    }
  }'

{"status":"ok","accepted":1}

What that does to the profile: phone becomes +989123456789 and phone_operator is written as mci, email becomes hamid@example.com, loyalty_points lands in both the text and the numeric map so that a "greater than" filter works, and loyalty_tier stays text only.

#What Segmentic writes

These four names are written into your event stream by the platform's own workers. Do not send them yourself, but do build segments and funnels on them like any other event.

The message_id of these events combines the request id and the event name, so that a send and a failure for the same message do not de-duplicate against each other.

message_delivered, message_bounced and unsubscribed are declared as constants and nothing else in the backend uses them: no worker writes them and nothing reads them, so a report built on message_delivered comes back empty. The panel asks for a delivery event anyway. Its messaging dashboard template and the starter metrics for delivery rate, open rate and click rate each need one mapped to a name from your own event schema, and activation does not proceed until you name one, so unless you send a delivery event yourself, that dashboard and those three metrics are never built.

What is missing is the event, not the data. A campaign report counts its own delivered messages from the receipts a transport sends back, the deliverability service reads bounces off the SMTP return path and writes them to the suppression list, and an unsubscribe lands on the person's record in the preference centre and comes back as the suppression reason on the next send. None of that arrives as a row in your event stream.

The attribution worker recognises exactly four names, message_sent, message_withheld, message_opened and message_clicked, and skips every other event it is handed. message_clicked is not written by a worker either: the web SDK raises it when a visitor lands on a link carrying sg_mid, once, until a different message id replaces it. The comparison is against the one id in storage, not against a history of them, so a visitor who lands on one message, then a second, then the first one again reports the first click twice.

Next: identity explains how these events attach to one person, and designing events lists the decisions that cannot be undone.