One big problem with events in the Tealeaf model has been that an event on page N of a user session cannot know about user choices made on previous pages in the session. This post will explore a way around this problem, using Tealeaf session attributes to store state information about the user’s interaction with web application.
Lets start with a hypothetical application, explore the problem, and walk through a solution. The application allows three different ways for a user to search for a group of products: Quick, Guided, and Advanced. At the end of the three search processes, the last page of each process all use the same URL and provide the same response page. Nothing in the final page URL, formfields, or response identifies if the user came down the Quick, Guided, or Advanced search path. So how should we create the “last page” event for the three search processes? Making just one “last page” event will not work well for calculating independent conversion rates for the three processes. We need separate events for AT:S:Q:CompleteV:CP,AT:S:GU:CompleteV:CP,AT:S:A:CompleteV:CP [1] For these, we need some way of knowing what choice the user made when they selected the type of search to perform.
Session Attributes store data. If we can store a unique pattern into a session attribute for each search path, then we can test the attribute for each pattern and trigger an event when the attribute contains a recognized pattern.
Caveats first: This solution uses events with the category “Session Attribute Event – Per Page”. Events built from this category are evaluated on every single hit. On sites with large traffic, having a lot of these events can put a strain on the CPU. If the Event Processor process cannot keep up with the demand put on it, the Canisters will start to spool during the busy hours of the day, and the message in the application event logs will be similar to “Number of unprocessed events is greater than 20,000…” (where 20,000 is a limit set in the DecoupleEX session agent of the TealeafCaptureSocket.cfg file).
If it is possible to get the development group to add tags to the response, so that there is a specific pattern in the Response page that identifies both the page and the process, then this Session Attribute events solution will not be necessary - simply create events that recognize the tags found in the Response. Unfortunately, it is sometimes not possible to get tags added, due to time or staff resource constraints, in which case, we need an “all-Tealeaf” solution.
1) Create a Session Attribute, call it AT:Current Search Method:Rsp
2) Identify a unique pattern in each of the three Requests that start each of the search processes. If the application implements the Client UI events, then the ID or Name of the control clicked are likely candidates. Another possibility may be the URL-path, or a URLField, may be unique and sufficient to identify each path.
3) Create three events that trigger when a user REQUESTS the first page of each process. In each event, place the unique pattern identifying each process in the AT:Current Search Method:Rsp attribute. You may use the pattern defined in the event, or you may want to use the Start Tag and End Tag. If the Start/End tag method is used, the string between the two tags will be moved to the session attribute. If you don’t use the Start/End tag method, the Pattern data will be moved to the session attribute. Use the Pattern if the pattern that triggers each event is unique. Start/End tags let you use one pattern that recognizes the kind of search started, but use different part of the same buffer to extract a shorter, uniquely identifying string for the session attribute
4) Create the event AT:S:G:CompleteV:B that recognizes the View of the final search request/result . Make this a building block event – it will fire regardless of the process taken.
5) Create three events AT:S:Q:CompleteV:SAEP:B, ,AT:S:GU:CompleteV:SAEP:B,AT:S:A:CompleteV:SAEP:B using the “Session Attribute Per Page” event type, specifying the AT:Current Search Method:Rsp attribute. Each of the three events specify one of the three unique patterns. Therefore, only one (or none) of the three events will fire on every hit.
6) Create the three final events AT:S:Q:CompleteV:CP,AT:S:GU:CompleteV:CP,AT:S:A:CompleteV:CP. These are compound events that combine the search global event AT:S:G:CompleteV:B with each of the three events in AT:S:Q:CompleteV:SAEP:B, ,AT:S:GU:CompleteV:SAEP:B,AT:S:A:CompleteV:SAEP:B
That’s it! You have the three events that clearly identify that the search results were delivered to the client, and which kind of Search process generated the final result view. Now that the “Current Search Process” events exist for each kind of search, you can use them anyplace in the search processes where there is ambiguity in the URL, URLField, or Response, to clearly identify what kind of search process is being used.
Related Posts:
A Naming Convention for Events
