Lets explore some usual and unusual ways to use dimensions in tealeaf reports. I’ll assume you know the basics of what dimensions are, and the standard way of using them. To review quickly, and event’s value can be stored in a dimension. When you look at a report for that event, in a hour’s period, you can see how many times the event fired (the event’s count) for that hour, or, you can look at how many times each value occurred in that hour. Of course, you can look at more than an hour – but lets keep the verbiage and phrasing simple. When you setup the dimension, you can tell the dimension to record every value the event ever has, or, you can create a whitelist – a list of values that you want to see counted. There are blacklists too, but even after 14 years, I’ve very seldom found a use for those.
Now lets digress just a bit, and explore what dimensions and whitelists do not do. A value in a whitelist is not an event condition. You cannot say “trigger this event only if a whitelist value is present”. Nope. If you have three values in the whitelist, and the event fire 1000 times, but none of the event’s values are in the whitelist, then the report will show the event occurred 1000 times, and the report will list ‘other’ as the sole dimension value. So you see, the whitelist does not prevent the event from firing – it just identifies the specific values you want to see details about.
Another thing dimensions cannot do (at least, as of release 8.7x) is trigger an alert. Often we want to trigger an alert if a specific value of an event occurs, or if an event’s value matches one of a list of such values. Alas, it just doesn’t work that way. An Alert gets triggered based on the event’s count, not it’s whitelist’s value’s count. So,you cannot use a whitelist to trigger an alert. Hope this tidbit saves somebody a wasted day trying to make that work.
As an aside – if you need to create an alert for specific event values; 1) create a building-block event, setting this event’s value to whatever you are looking for. 2) Create a second event that triggers only when the first event fires. Put your list here, and compare the list to the first event’s value. If the first event’s value matches the list, the second event will fire. Use the second event to drive the alert. Therefore, the alert is based on the second event, and the second event only fires if the value of whatever you are looking for matches the list. If your conditions are complex (an IP in the range of blah to bal; OR a userid of ‘johnDoe’; OR a useragent string containing ‘Snap!’) this technique makes it pretty easy. Individual Building Block events whose values are IP, LoginId, and useragent, then a single event that looks at each Building Block event, has the specific list of interesting values for each, and combines results of the list comparasion according to your needs to determine if the event fires. We do this for ‘Session of Interest’ Alert, which goes to security teams (in real time) whenever a specific set of conditions occur. Then they can go watch that session. If enough folks leave a comment expressing an interest, I’ll post example code for the list matching.
Back to the main thread <grin>
Dimension value counts have to be recorded, hence events with dimensions contribute to the size of the database aggregation tables. Looking at the Tealeaf DB statistics page in the Tealeaf portal’s administration view, lots of tables end in _AGG. If any get over about 40M rows, you are going to see performance degradation in the Data Collector’s speed, in report generation, and surprisingly, in the time it takes the event editor to commit new event definitions. Get too many events with large numbers of unique dimension values, and you’ll be unpleasantly surprised to find it takes fifteen minutes to “save” a new event.
But dimensions can be put to great use with a little care. Anything with a small number of unique values are perfect candidates. If you are interested in the viewing choices your customers make for a particular product, and want to see their choices broken down by product size or color, use a dimension for size, and another for color. Fire the event on a specific product SKU, record the customer’s size and color choice in a report group associated with the event, and you can see a report of how often the product was viewed in each size and color combination. Have a number of similar products? Create the event to fire on any of a list of product SKUs, and, add the product SKU as a dimension in the report group. Now your report will show multiple SKUs, sizes and colors. Just don’t go overboard – recording too many different SKUs in this one event will lead to aggregation table bloat, again.
Another fun thing I like to do with with Dimension Groups is to create histogram reports.You know dimensions and whitelists let you record unique values and dimension groups let you group these values. One good example is to use the Session Duration session variable. On each hit, the system updates this session variable with the the current duration of the session. You can create an event that records this. Lets say you create an event on the “purchase complete” page, and record the value of the Session Attribute “Session Length Running Time (sec)”. Now you have, for each purchaser, how long it took for them to get from start to purchase. Now lets group these counts into buckets. Create a Dimension Group, and each element is 0-1799;1800-3599;3600-5399,… etc. Populate this Dimension group with the Session Attribute “Session Length Running Time (sec)”. The internal name of this attribute is S_TOTAL_TIME. Assign this Dimension group to a Report group and the Report Group to the event. The resulting report shows 1) how many purchases in the hour; 2) how many customer made their purchase in 0-3 minutes; 3-5.9 minutes; 5-8.9 minutes; I find this technique to be interesting – it helps the business visualize how long it takes most customers to make a purchase. You can extend it so the purchase event triggers for a specific product – and then compare the two reports to see if different products take differing time to purchase. I wish there was some way to put the comparison up on a single report, but I haven’t found a way to do that.
One more I have not tried personally, but would be interesting… The Report Group above defines how long it takes to reach a purchase from the start of the session. What if you want to know how long it takes to get from Event A to Event B, and report that as a histogram? For example – start of checkout to purchase complete? Go create Events A and B for Start of Checkout-BB and End of Checkout-BB, and record the Session Length Running Time (sec) as their values. Create an Event C “Time in Funnel (sec)”, that fires when both events have fired. Edit it in Advanced mode, and record the value of this event as the difference between the value of Event B – the value of Event A. Note that you may need to account for multiple event A’s occurring before the Event B, so make sure you use the latest (highest numbered) event A in the event A collection. Now use the value of Event C to populate a Dimension Group along the lines of the last example, and use the Dimension Group to populate a Report Group assigned to Event C. Report on Event C, and the report showing how many users spent how many seconds in the checkout funnel is available. I have not tried this one yet – please let me know if you encounter any difficulties with this one.
I hope these work for you, and spark some more interesting ideas on using dimensions!
