Events, types and serialization

What they are

event1 through event1000 (how many depends on your contract — 100 is standard, up to 1000 on Premium tiers). Plus out-of-the-box events for commerce.

Events are counters. Where an eVar says *what*, an event says *how many*.

Event types

Numeric events are underused. "Search results returned" as a numeric event lets you compute *average results per search* as a calculated metric, which immediately surfaces the searches returning too many or too few results.

Serialization — the deduplication mechanism

The problem: a member submits the complaint form, lands on the confirmation page, then refreshes it three times. Your form-submission event just fired four times. Your conversion rate is now wrong by 300%.

The fix: serialization. You pass a unique ID with the event, and Adobe discards repeats of the same ID.

AppMeasurement:  s.events = "event20:CMP-88213"
Web SDK (XDM):   _experience.analytics.event1to100.event20.id = "CMP-88213"
                 _experience.analytics.event1to100.event20.value = 1

The ID must be genuinely unique per real occurrence — a confirmation/reference number is ideal. A timestamp is acceptable. A session ID is not (blocks legitimate repeat conversions).

Rule: serialize every event that represents a completed business outcome. Form submissions, applications, appointment bookings, registrations. Do not bother serializing engagement events like "video started."

Success events vs instances

Every eVar automatically gets a companion metric called Instances — the count of hits where that eVar was *explicitly set*. This is free and enormously useful.

• Instances of Internal Search Term = how many searches happened
• Form Submissions (event20) attributed to Internal Search Term = how many searches led to a form

The gap between them is your funnel.

Event design principles

1. One event, one meaning. Never overload event20 to mean "form submitted" on one page and "PDF downloaded" on another. You will never untangle it.
2. Count the outcome, not the interaction, unless the interaction is the point. "Form started" and "form submitted" are both legitimate. "Form field 3 focused" probably is not.
3. Design events in pairs or funnels. event20 form start / event21 form submit / event22 form error. The relationships are what create insight.
4. Budget your events. Every event you invent is a permanent maintenance obligation. Before adding one, ask: *what decision changes based on this number?* If nobody can answer, do not build it.