Using Adobe Date Segments in Alarmduck Anomalies
If you have been reading my recent posts related to Alarmduck, you have seen that I use this tool to monitor data anomalies in my Adobe Analytics implementation. In the past, I have explained how I use Alarmduck to identify new client opportunities, look for “hot” internal search phrases and identify product-related anomalies. In this post, however, I am going to share a different trick I use with Alarmduck related to date ranges.
By default, Alarmduck identifies data anomalies based upon the last 90 days of [Adobe Analytics] data. It also focuses on the most relevant data points (if using an eVar or sProp) to avoid producing anomalies for items that have very little data. Both of these safeguards help Alarmduck to avoid triggering too many data anomalies. However, there may be some specific instances in which you purposely want to be notified more often about changes in your data. For example, in my case, I may want to know if an identified company has spiked in reading my blog within the last week or two, or if a specific post has had a recent spike or dip.
In these cases, the trick that I use is to apply a date component to the Adobe Analytics segments that I use to look for data anomalies. To illustrate this, let’s go through an example. One of the Alarmduck reports that I use is one that looks for anomalies in any of my blog posts as shown in red here:
This report is configured to determine if any known company viewing my blog (using a segment to limit it to just “Adam Blog Posts”) has a data anomaly related to Blog Post Views as shown here:
Once this is live, I will receive data anomaly alerts in Slack like this:
As you can see, Adobe hits my blog pretty regularly, but at one point, it was so much so, Alarmduck triggered a data anomaly.
But, what if some new, random company started hitting my blog in the last few weeks? Let’s say that a company had only 10 blog post views in the last few weeks. This gets tricky, because some companies would want to see this as a data anomaly (because it is a huge development relatively speaking), while others would argue that 10 blog post views is simply too few to care about when looked at with all of the data being reviewed.
Therefore, if I decide that I want to err on the side of getting more data anomaly alerts in Slack and include the 10 blog post scenario above, I can apply/modify the segment I used for the preceding Alarmduck report to add a date component. By limiting the number of days using a date segment, the overall dataset that Alarmduck reviews is reduced, which means that items that previously were not in the Top 50 or 100 items, now very well could be. For example, if I limit the segment to the “Last 14 Days,” that will make any spikes/dips occurring in the last two weeks stand out and be more likely to trigger an Alarmduck data anomaly. So where previously 10 blog post views for one company might have been ignored, in the last 14 days, 10 blog post views might suddenly be noteworthy (from a data perspective).
So if I want to try this out, all I need to do is to tweak the “Adam Blog Post Views” segment mentioned above to include a date range using the newly added date components in the Adobe Analytics segment builder. In this case, I decided to make a few additional changes. I am going to include “Adam Blog Posts” and restrict the country the US, and make sure I know that a company name exists and exclude any companies I have flagged as competitors, while also adding the Last 14 Days. Here is what the segment looks like when it is done:
Once this is saved, I would update my previous Alarmduck report to use my new segment or I could simply create another report that uses this new segment and retain the old report as well. Having both reports is nice because one serves as my normal data anomaly alert and the new one is my “recent activity” data alert. Both are useful for different purpose.
Here is an example of a data anomaly that I later received as a result of the new report looking at data for the last 14 days:
This is an example of a data anomaly that my original report didn’t pick up because it wasn’t significant to flag, but over the last two weeks, it did register as a data anomaly.
As you can see, leveraging what you already know in Adobe Analytics and using Alarmduck provides an incredible amount of data anomaly granularity. The best part is that much of this leverages your existing knowledge of Adobe Analytics and avoids having to re-learn a new tool to build segments. I would suggest that you consider adding date ranges to some of your Adobe Segments and Alarmduck reports for cases where you’d like to see more recent spikes/dips in eVar/sProp values for your desired metrics.
