Event tracking

If you can install a Feature Experimentation SDK and identify a user, you can use Optimizely Feature Experimentation to track any event, from users interacting with specific elements of a web page or mobile app to more complex metrics like lifetime value that are calculated in backend systems.

Tracking and measuring user behavior is a prerequisite for understanding how your customers use your product and why they use it that way. Without that information, it is much more difficult to judge the performance of a new feature flag rule, such as an A/B test, or apply any lessons learned to future rules. You do not know which specific components of your product your customers are interacting with, and you do not have the information you need to build a user-centric roadmap for future development.

To track events effectively, you must strategically plan for metrics important to your organization and implement the appropriate infrastructure. This is a two-step process.

This topic provides an overview of some best practices for the process steps.

See also Choose metricsChoose metrics.

You should use a customer data platform like Optimizely Data Platform (ODP) or Segment when configuring event tracking. Doing so can help bypass a common challenge when getting started, which is configuring and validating API calls throughout your stack.

Without a customer data platform, you may run into a double-tagging problem. Double-tagging can occur when your stack includes multiple technologies with overlapping functions, such as tracking conversions. Unless you are diligent and organized from the beginning, it is easy to tag the same events in more than one tool inadvertently.

When the feature flags and functions of your own site are double-tagged like this, your engineering team often inherits a level of technical debt that can require substantial effort to resolve.

Avoid this by incorporating a product like SegmentSegment into your implementation from the beginning and carefully planning your strategy for defining and tagging events early on. In particular, consider the following factors:

After identifying the events you want to track, the next issue is how best to implement the SDK on your site. This involves adapting the SDK to meet your organization's needs.

Typical use cases that require adapting the SDK include the following:

Specific approaches to implementation vary depending on how many of these conditions apply to your application.

In many cases, SDK instrumentation can and should be done in the code itself rather than further down the stack. Because all products tie into one service in a multi-system or service-oriented architecture, you can instrument in one place. This simplifies the initial deployment and updates and maintenance.

This approach can work if you need results in real-time, but it is not always the best way to handle it. If you need real-time results, consider encapsulating information in an API instead.

For example, consider an event ticketing application. The application includes a module called buy_tickets that is driven by Java on the backend. In a queue-based model, all information about a user interaction is captured in a slot in the queue. The application will process the sign-in in real-time, but it will not necessarily do the same for all the actions related to that sign-in. Event processing speed in the queue depends on the volume of events and the backend's ability to handle the traffic. As a result, there may be some lag in delivering A/B test results.

Now imagine one million people using this application at the same time. If the app tries to record the success or failure of an A/B test somewhere on the site, those results will likely not be delivered in real-time under a queueing model. If, however, these events are tracked through an Optimizely Experimentation API, the results would be available immediately, with no noticeable lag.

If real-time results are important to you, instrument your events at the place where they actually happen.