A few more SiteCatalyst-Twitter tips
I know I promised that my next post would discuss using the SAINT API in connection with capturing Twitter data—and that article is coming soon—but since Adam Greco’s post two days ago, he and I have been fortunate enough to discuss with many of you how you’re planning to capture and use Twitter data. I wrote about one way to capture this data here. The great thing about solutions like the one Adam and Omniture Consulting devised to pump Twitter data into SiteCatalyst is that they’re constantly evolving and growing to serve more and more client needs. In this short post, I’d like to discuss briefly two additional points to consider as you and your colleagues help to develop your own strategy for merging Twitter and web analytics.
Twitter campaign tracking
First, a common practice on Twitter is to try to drive customers (and potential customers) to your site by linking to press releases, product info pages, user forums, and pages that may address specific questions/concerns about your brand that are raised by users on Twitter. This is typically done using a service such as tinyurl.com or is.gd to “shorten” the destination URL; since tweets are limited to 140 characters, some URLs would be too long even if they were their own tweet, without any additional explanation.
If you are doing this, or are thinking about doing it, consider adding campaign tracking codes to these destination URLs before shortening them using your preferred service. While tying tweets to specific visitors on your site is tricky, determining which tweets by representatives from your organization directly led to conversion isn’t hard at all. Add a tracking code to the destination URL and let SiteCatalyst do the rest.
Twitter data in your production report suite without inflation
Second, in my post yesterday I suggested putting all of your Twitter (and other social media) data in a report suite separate from the one that you use to track user interactions with your web site. The reason for this is that tweets do not represent page views, visits, or visitors to your site; mixing Twitter data with site data would lead to inflation in each of these metrics. I am here today to tell you that there is actually a fairly nifty way of getting Twitter data into the same report suite as your site data practically without inflation.
As mentioned in Adam’s post as well as in my own, we recommend pumping Twitter data into SiteCatalyst using the Data Insertion API. Typically, this involves populating the
<visitorid> element with a visitor ID that your server assigns in any manner that works well for you. Passing the visitor ID allows SiteCatalyst to organize requests into visits. But you don’t want Twitter to inflate your visit count. So simply leave out the
<visitorid> element. Instead, pass the
<userAgent> elements; this causes a visit not to be counted for the given XML post.
One metric down; two to go. As you may already be aware, SiteCatalyst is able to track a user as a unique visitor based on a combination of IP address and user-agent string when the visitor ID is not available. Typically this is a good fallback method because most end users on your site at any one time have unique IP addresses and/or user-agent strings, so SiteCatalyst tracks them as distinct visitors. But if, in your Data Insertion API implementation, the IP address and user-agent string are always the same, then all of the posts will appear to have come from one visitor. The visitor data in your production report suite will be inflated, but only by one (1) daily unique visitor, one monthly unique visitor, etc.
Finally, you will want to ensure that page views are not counted for each tweet. This is fairly straightforward as well. You can cause any Data Insertion API post not to be counted as a page view by counting it as something else—in this case, a “custom link,” which passes data into SiteCatalyst but is not a page view. (I will cover custom links in depth in a post in the near future.) This is done by adding two additional elements to your XML post:
The linkName element is used to give a friendly name to the action that is being reported in this post, and can be anything that you want. The linkType element should have a value of “o” in this case, but can also be “d” to count a file download and “e” to count an exit link click.
Using this method, if you sent data for 10,000 tweets in a single day into your production web site’s report suite in SiteCatalyst, you would end up with all of your Twitter data in eVars, zero extra page views, zero extra visits, and one extra daily unique visitor.