- Optimizely X Full Stack
THIS ARTICLE WILL HELP YOU:
- Identify and avoid common stumbling blocks for tracking events in Full Stack
- Identify metrics that will have the most impact within the context of your experimentation program
- Streamline and speed up your entire Full Stack implementation experience
In Full Stack, you can use event tracking to measure the full range of behaviors required to evaluate experiment performance, 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. If you can install an Optimizely SDK and identify a user, you can use Full Stack to track any event.
Why would you want to do this? Tracking and measuring user behavior is a prerequisite for understanding how your customers use your product, and why they use it that way. For example, without that information, it is much more difficult to judge the performance of a new feature rollout and to apply any lessons learned to future rollouts. You won't know which specific components of your product your customers are interacting with—and you won't have the information you need to build a user-centric roadmap for future development.
To track events in Full Stack effectively, you must engage in strategic planning for instrumenting metrics important to your organization, and make sure you implement the appropriate infrastructure. This is a two-step process:
Identify where to track those metrics in your technology stack
Instrument the SDK to actively track the events
This article will give you an overview of some recommended best practices for both stages of the process.
The events you decide to track will always depend on the knowledge you want to uncover. And in most cases, that knowledge will serve your organization's goals by delivering impact in one of two ways: boosting revenue or lowering costs. Before you define any events, decide where your focus should be.
Revenue vs. cost
Revenue-focused: Think of how your site helps generate revenue for your organization. It can be hard to visualize, so one way to fully explore it is to use a revenue tree.
Start at the top with revenue and identify where that revenue comes from. For example, the number of paying customers has a direct impact on revenue. So does the lifetime value of each customer.
Now repeat the process and explore how each of these metrics evolves in turn. What factors directly contribute to the number of paying customers? What factors contribute to lifetime value? Keep going until your answers identify specific areas of your website, or activities of your sales team. Often, these are the events you should be tracking.
Cost-focused: You could also look at factors that contribute to costs. One common place to start is with support costs. Does your site enable customers to resolve more of their own issues without contacting support? If not, you may want to consider support deflection techniques to help drive down the number of support tickets coming in.
Ultimately, your choices will come down to trade-offs between what matters most for your organization on the one hand, and what’s possible and practical on the other. Just as you’d do with experimentation use cases, you will have to go through an event prioritization process before moving forward with implementation. This will usually involve determining the utility of tracking an event or behavior (ideal candidates are usually high-impact and low-effort), as well as the actual feasibility of instrumenting it with Full Stack.
Read more about focusing on metrics that really matter.
Use a customer data platform
We recommend using a customer data platform like Segment when setting up event tracking in Full Stack. Doing so can help bypass a common friction point in getting up and running on Full Stack, which is configuring and validating API calls throughout your entire stack.
Without a customer data platform, you may run into the double-tagging problem. Double-tagging can occur when your stack includes multiple technologies with overlapping functions—for example, tracking conversions. Unless you are diligent and organized from the beginning, it's easy to inadvertently tag the same events in more than one tool.
When the features and functions of your own site are double-tagged like this, your engineering team often inherits a level of tech debt that can take a significant amount of effort to resolve.
You can avoid this by incorporating a product like Segment into your Full Stack implementation from the beginning, and then carefully planning your strategy for defining and tagging events early on. In particular, take care to consider these questions:
The specific use cases you wish to address
The feasibility of addressing these use cases
The metrics that will best enable you to do this
The most efficient and effective means to embed these metrics into your existing infrastructure
Once you’ve identified the events you want to track, the next issue is how best to implement Full Stack on your site. This involves adapting the Full Stack SDK to meet your organization’s needs.
Typical Full Stack use cases that require adapting the SDK include:
Your application will handle a high volume of events
You will be routing through a proxy server
You will need results in real time
Specific approaches to implementation will vary depending on how many of these conditions apply to your application.
In many cases, instrumentation of the SDK can and should be done in the code itself, instead of further down the stack. Because all products tie into one service in a multi-system or service-oriented architecture, you have the opportunity to instrument in one place. This has the advantage of simplifying both the initial deployment as well as updates and maintenance.
However, while this approach can still work if you need results in real time, it's not always the best way to handle it. You can also consider encapsulating information in an API instead.
As an example, consider an event ticketing application. The application includes a module called
buy_tickets that's driven by Java on the back end. In a queue-based model, all information about a user interaction is captured in a slot in that 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 both the volume of events, and the ability of the back end to handle the traffic. As a result, there may be some lag in delivering experiment results.
Now imagine a situation where one million people use this application at the same time. If it tries to record the success or failure of an experiment somewhere on the site, those results will likely not be delivered in real time under a queue model. If, however, these events were tracked through an Optimizely API, those results would be available immediately, with no noticeable lag.
If real-time results are important to you, then you should instrument your events at the place where they actually happen.
Many Full Stack users work with implementations that include a lot of integrations and external requests, and are concerned that adding Full Stack tracking may contribute to a network bottleneck.
Some Full Stack SDKs implement an asynchronous dispatcher to prevent requests from blocking each other or forming a bottleneck. It is also possible to use an events pipeline, along which you would send events at a later date to avoid slowing down your site for visitors.
The diagram above shows how an Optimizely customer working with a service like Amplitude might use a backend event pipeline to serve as unified event propagation mechanism. Activate / track http requests are deferred on the server and then dispatched in the browser, using a cookie to transmit the required information.