Implementing Conversion Events in Adobe Analytics

A conversion event is a specific moment on your website where a meaningful action is completed. Adobe Analytics calls these Success Events: the discrete counts that tell you how many times something significant happened. How many product pages were viewed? How many items were added to a cart? How many lead forms were submitted? Those numbers all come from conversion events, and they flow through a single JavaScript property: s.events.

The s.events Property

Setting a conversion event means assigning a value to s.events on the page or interaction where that event occurs. The value is a string containing one or more event names, comma-separated when multiple events need to fire at the same time.

s.events = "prodView";                            // single predefined event
s.events = "scOpen,scAdd";                       // two events firing simultaneously
s.events = "purchase";                           // purchase event
s.events = "event3";                             // custom event
s.events = "event1,event2";                      // two custom events at once
s.events = "event17=5";                          // custom event incrementing by 5
s.events = "event2,event1:1234abcd,purchase";    // plain, serialized, and purchase together

Only valid Adobe Analytics event names will register. You can use the seven predefined retail events, or custom events named event1 through event1000. Any other string is silently ignored, which means implementation errors produce no error messages, only missing data.

Predefined Events for E-commerce

Adobe provides seven predefined events built for standard retail tracking. They have fixed names, require no admin configuration, and map directly to e-commerce reports.

Implementation follows a straightforward mapping: identify which of these events applies to each key moment in your purchase flow, then configure your tag manager to fire the correct event at each point.

// Product detail page
s.events = "prodView";
// First add-to-cart action (cart opens and an item is added in one step)
s.events = "scOpen,scAdd";
// Order confirmation page
s.events = "purchase";

Revenue and units associated with a purchase come from s.products, not from s.events alone. The purchase event signals that an order occurred. The product string carries the financial data.

Custom Events

The predefined set covers retail scenarios. For any other business goal, you define your own events. The range runs from event1 to event1000, and common uses include newsletter subscriptions, form initiations and completions, registrations, file downloads, video completions, chat initiations, and any other action your site should be measuring.

s.events = "event3";      // Registration
s.events = "event7";      // Newsletter sign-up
s.events = "event15";     // Form completion
s.events = "event17=5";   // Five items in a bulk order

The =value syntax on the last line is useful when one interaction should count as multiple units. Firing event17=5 increments the event by five rather than one, which is appropriate for quantities like seats booked or items in a batch transaction.

On their own, custom event numbers are meaningless. event14 tells an analyst nothing six months after implementation without documentation and a friendly name assigned in Admin.

Naming and Configuring Events in Admin

Before implementing any custom event, give it a human-readable name. The path is Admin > Report Suite > Edit Settings > Conversion > Success Events. Without this step, reports display bare event numbers that nobody can interpret. Once named, the friendly label appears throughout Analysis Workspace.

You can also rename predefined events to fit your industry. A travel site might rename “Orders” to “Bookings” and “Units” to “Nights Booked.” The Admin interface is also where you set each event’s type and deduplication behavior, both covered below.

Event Types

Every conversion event has one of three types, configured in Admin, which controls how its value increments.

A Counter event increments by one integer at a time and is the default. Use it for discrete occurrences: a registration happened, a form was submitted, a newsletter was signed up for. The count represents how many times that action occurred.

A Currency event accepts any decimal amount and applies currency conversion if the value is sent in a currency other than the report suite default. Use this for monetary values: revenue, cost, margin. Adobe handles the exchange rate conversion automatically.

A Numeric event also accepts decimal amounts but does not apply currency conversion. Use it for non-monetary quantities: engagement scores, session durations, or item counts in a multi-unit transaction.

One important detail in the Admin dropdown: avoid the variants labelled “Counter (No Subrelations)” and equivalents for other types. The restricted version prevents the event from being broken down by dimensions in Analysis Workspace, which removes most of its analytical value. The restriction is almost never intentional and easy to select by accident.

Event Deduplication

Some events risk being counted more than once for what is genuinely a single conversion. A visitor who refreshes the order confirmation page registers as a second purchase. A visitor who clicks Submit twice generates two form completions. Adobe provides three deduplication settings per event, configured in Admin.

The default, “Always Record Event,” counts every execution. This is correct for interactions that legitimately recur, like product views or content engagements.

“Record Once Per Visit” allows the event to fire only once per visit regardless of how many times the code executes. Use this carefully. Some events can legitimately occur multiple times in a single visit: a visitor who adds three different products to their cart in one session should generate three scAdd events. Setting that event to “Record Once Per Visit” collapses all three into one and distorts the data.

“Use Event ID” is the most reliable approach for transactions with unique identifiers. You attach a serial number to each event instance, and Adobe counts only the first occurrence of any given ID. This is event serialization.

s.events = "event1:tx-9821";                            // event1 serialized with order ID
s.events = "event2,event1:tx-9821,purchase";            // event2 and purchase fire normally; event1 is serialized

The serial ID is typically a transaction ID or order number generated by your backend: a value that is unique per conversion and stable on page refresh. When the same ID appears again because a user refreshed or bookmarked the confirmation page, Adobe recognizes it and does not increment the count a second time.

Serialization should be standard practice on the purchase event and on any form submission where a confirmation page exists. Enable “Use Event ID” in Admin for those events before the implementation goes live.

Building Conversion Funnels

Every website has a conversion funnel regardless of whether it sells products. The process of identifying and implementing events is consistent across industries.

The first step is identifying the conversion actions: the specific points in the user journey that represent meaningful progress toward your business goal. The second is assigning a custom event to each of those actions. The third is tagging each relevant page or interaction in your tag manager to fire the correct event at the correct moment.

The three examples below show how this applies to different site types.

Lead Generation Site

A content site where users submit a contact form or register for access has a two-step funnel. The form page is the first conversion point; the confirmation page is the second.

// Form page (user reaches and begins the form)
s.events = "event1";
// Thank-you / confirmation page (submitted successfully)
s.events = "event2";

With these two events in place, you can measure the drop-off rate between form initiation and completion. Users who reach the form but do not submit it are visible in the data.

Subscription Service Site

A media site where users sign up for topic-specific newsletters has a richer funnel. The options page is where you capture which newsletter the user is interested in, so an eVar is set there alongside the initial event. Form start and completion follow on subsequent pages.

// Newsletter options page (capture which newsletter was viewed)
s.eVar12 = "technology";
s.events = "event1";
// Subscription form start
s.events = "event2";
// Subscription form completion
s.events = "event3";

The eVar on the options page allows you to later break down form completions by newsletter topic: which subscription drove the most completed sign-ups, and which had the highest drop-off between start and completion.

Automotive Configurator Site

A car manufacturer site where users build a vehicle configuration and request a dealer quote has a four-step funnel. The model detail page captures which vehicle the user is viewing as a dimension; the subsequent steps each fire a custom event.

// Model detail page (capture which model was viewed)
s.eVar12 = "Sedan GT";
// Configuration complete (user has finished specifying options)
s.events = "event1";
// Dealer request form start (user is entering their details)
s.events = "event2";
// Dealer request confirmation (form submitted successfully)
s.events = "event3";

These four data points give you a full picture of funnel health: how many people view a given model, how many complete the configuration, how many initiate a dealer request, and how many follow through to submission.

Common Pitfalls

The most expensive implementation mistake is firing a conversion event on every page rather than on the specific page where the conversion occurs. If s.events = "event2" is included in the global page code, every single page load inflates the metric. Events must fire exactly once, at the moment the conversion is completed, which is almost always the confirmation or thank-you page.

Not serializing the purchase event is a close second. Without serialization, every load of the order confirmation page records a new order. A customer who refreshes once produces two purchase records. Always attach the order ID as a serial identifier and enable “Use Event ID” in Admin for that event before go-live.

A subtler version of the same problem is applying “Record Once Per Visit” to events that can legitimately recur. A visitor who adds three different items to their cart in one session should produce three scAdd events. Deduplication at the visit level collapses them into one, producing an inaccurate picture of cart behaviour.

Custom events should be named in Admin before the implementation is live, not after. Reports that fill up with event3, event7, and event14 during a testing period are confusing to clean up retroactively, and analysts who encounter those numbers without context have no way to interpret them.

Every event also needs a row in the Solution Design Reference specifying the event number, its friendly name, what it measures, which pages it fires on, and the trigger condition. Without that document, institutional knowledge lives only in whoever built the implementation, and it does not survive team changes.

Finally, verify that no event type was accidentally set to “No Subrelations” in Admin. The restricted variant prevents the event from being used in dimension breakdowns in Analysis Workspace. It is easy to select from the dropdown without noticing, and the consequence is that an entire metric becomes analytically inert.

See you soon.