First, I'm at summit in SLC next week, and am looking forward to seeing folks there. If you want to chat informally about tag management systems in general or satellite specifically, let me know!
I've posted at the Satellite blog in their Satellite Implementation Series. My overall goal is to see how far I can implement without even touching my s_code or adding any plugins. The first and easiest thing was to get around needing the getQueryParam plugin. Come take a look:
SiteCatalyst Implementation Series: Breaking up with SiteCatalyst plugins
We’ve all had a love/hate relationship with our SiteCatalyst plugins. I mean, where would we be today without good ol’ s.getQueryParam or s.getTimeParting? And when you have a new tracking parameter from your marketers, who doesn’t love to get your developers and implementation consultants to change and test those fateful lines in the doplugins section? But it’s time to move on. Technology has finally caught up to our needs. Plugins you previously couldn’t have lived without are now obsolete, since their functionality is built right into the Satellite interface....
I'm very excited to announce I'm joining the Satellite TMS team at Search Discovery, here in Atlanta. While leaving the decision to leave Keystone was not easy to arrive at, I am very happy to working with such a great team and product here at SD. Keystone was a really amazing opportunity for me and I learned and grew more in the last two years than I would have thought possible, and I view everyone there like family, but it was time for something new. I've been strictly on the consulting side of the industry for the last 6 years and look forward to helping build a product that will help both consultants and clients alike do meaningful work in less time, with less headaches.
Anyways, I hope to be able to dedicate more time to blogging- both for Satellite and for my own blog here (which is in quite a sad state and needs a massive update). I'll also be at summit next month and would love to chat with anyone interested.
Sorry for the lack of blogging, lately, but it's been a very busy few months. I have a lot of posts in the works, though, on topics like "the ins and outs of SiteCatalyst Merchandising eVars" and "Can a web analytics vendor evolve too quickly?"
In the meantime, I'm in beautiful, sunny San Francisco for the eMetrics digital optimization summit. It's off to a great start. If you're here and want to meet up, let me know! I'm here through Thursday morning.
I posted over at the Keystone Community about how to properly identify content in GA:
This year, I’ve been involved in many Google Analytics implementations and audits, and there has been a recurring theme around misunderstood GA Configuration Settings, mostly regarding how a page is identified. For instance, one recent client of mine had a 350-page site. But because of missed configuration settings, those 350 pages were showing up as literally 28000 URIs! Can you imagine pulling a report on any given page of that site? So to clear the air and hopefully save some GA users out there from future headaches, I identify and have instructions on 3 quick ways to use GA Configuration to properly identify your pages:
- Use the right Default Page setting (Default Page does NOT mean “my defaultiest page”)
- Use a filter to standardize trailing slashes.
- Exclude Query String Parameters.
Head on over to read the full post!
Head on over to the Keystone Community Blog for my latest post, with Tips and Tricks for Campaign Tracking in Omniture:
The standard Omniture Campaign reporting offering, based solely on a query string/tracking code pair, is pretty solid: campaign reports and all the possible classifications, paid/natural search detection and reporting, and marketing channel reporting, managed from right there in the SiteCatalyst admin console. But over time we’ve found some tips and tricks that can maximize the value of your campaign tracking efforts.
- Custom Campaign Click-throughs
- Granular, Classified Tracking Codes with a Marketing Channel prefix
- Campaign Landing Page Pathing
- Campaign Cross-Visit Participation
Head over and take a look!
I'm still here, but not on this blog quite as much. I happily started working for Keystone Solutions about a month ago and they've kept me quite busy, hence the lack of posts. I did manage to finally get one a new post out on the Community blog:
In other words: Why all internet users should hope they are being tracked.
...It’s like voting by secret ballot: every time you click (or don’t click) on an item, you are submitting an anonymous vote for how the website could be better...
...All internet users want online marketers to succeed, whether they are aware of it or not. The existence of (and free access to) the sites we know and love relies on successful marketing. I know no one loves an internet cluttered with ads, but I'm pretty sure we'd hate it even more if it were ad-free with the caveat of having to pay for each site we visited. The more relevant the ads can be to the users, the more successful they are- meaning less ads are needed to keep the internet afloat. Targeting not only helps keeps the internet free it makes the internet more relevant to users...
...Regardless of current legislation, the Web Analytics Industry must put effort into educating the public about what is being tracked, why, and how it benefits the average user. Where do you stand?
Read more at the Keystone Solutions Community Blog. I suspect the majority of my future posts will be over there (I hope to get moving on a bi-weekly column soon), so you can just transfer your RSS subscription right over:).
This short-and-sweet post will answer the following questions, all of which have come up to me in the last month:
- Why are my Product Views in SiteCatalyst inflated?
- How do I see Product Views in a conversion funnel?
- Why did our Solution Design Document have both the "prodView" event AND a custom "Product View" event?
There's one answer to all three questions: prodView does not behave like other events. prodView acts for the product variable almost like "instances" does for eVars. This can confuse people who don't know what they are looking at:
For one, it will not show up in non-product reports. If you want to see it in a conversion funnel, maybe broken down by campaigns, you won't be able to.
Second, s.events="prodView" doesn't have to appear anywhere in your code for the prodView event to be set. Anytime that s.products is set without a corresponding event, prodView will be set automatically. Which means the number of product views could potentially be inflated without ever being set. If you are using the products variable on your site, it's possible you have data in your prodviews report without you ever even setting it. This also makes debugging it a bit tricky.
My recommendation? Use a custom event for product views. If you want to still take advantage of some of the out-of-the-box reports in SiteCatalyst that come from the prodView event, then you can set it along with your custom event (s.events="prodView,event5") and get the best of both worlds- just be aware that you will then have two reports that may not match each other perfectly and may confuse some of your SiteCatalyst users (documentation is your friend; take advantage of the SiteCatalyst feature of writing notes for reports that need clarification).
Mistake #1: Hoarding data
You've heard of report monkeys—I'm going to tell you about data squirrels. Data squirrels spend lots of energy collecting data; then they hoard it. They carry it around in their cheeks, feeling well-prepared for the winter, but their mouths are so full they can't process and swallow their hoarded goods.
I'm thinking of one former client who was using nearly every single variable available at the time- virtually every available report in Sitecatalyst was filled with data. According to "Best Practices", they had a weekly meeting to discuss their implementation and keep it up-to-date- the data was tested, current, and abundant. Their dashboards were vibrant and plentiful. But they were so busy collecting and hoarding data that they had no time to process and analyze it. The idea of taking action on the data was never part of the process.
For all of their effort, how much value do you think they were getting out of their analytics tool?
Sidenote: Data Squirrels and Report Monkeys make great friends. The Squirrel hands data to the Monkey and the Monkey hands "reporting requirements" back to the squirrel. This cycle can go on indefinitely without any real value.
Mistake #2: Believing the work is done when the implementation is complete
You know what makes the web analyst in me want to go cry in a corner? This all-too-common situation:
A major company spends thousands of dollars and dozens of man-hours on an implementation project to grab and report on some new data. The implementation consultant gets the data, shows them the working reports, signs off on the project, then walks away. Six months later, the company calls the consultant and says "this report doesn't work anymore, someone disabled the variable five months ago and it took us until now to notice. Can we bring you back on to fix the problem?" (Presumably, so the data can go another 5 months without being used).
If you can go 5 months without looking at a report, why-oh-why did you throw money at someone to make the report available? Sadly I know the answer: it's easier to throw money at something and feel that sense of accomplishment than it is to spend time analyzing and making potentially risky decisions based on the data.
It's a lovely feeling to wrap up an implementation and feel like the hard part is done. But if you really want value out of your tool, the work is far from done. Fortunately, the post-implementation work is the fun stuff: the stuff that doesn't count on your IT department to roll out new code; the stuff that has the potential to realize actual, provable value for your company.
If you must, on the day your implementation project is completed, mark a few hours of time two weeks or one month out to play with the data until you get an action out of it. Schedule a meeting with the analyst-minded folks of your organization and go over the data- NOT to discuss how complete your implementation is, but to discuss what insight the data has given you and what the next steps are. Don't let USING your data fall down the priority list just because it doesn't have a project and a budget attached to it.
Mistake #3: Repeating this phrase frequently during the implementation process: "I want to track..."
•I want to HYPOTHESIZE...
•I want to TEST...
•I want to COMPARE...
•I want to BRAINSTORM...
•I want to OPTIMIZE...
•I want to DECIDE...
•I want to ACT UPON...
"Tracking" or merely collecting data should never be the goal or even a main focus. ALWAYS implement with this question in mind: "How am I going to USE this data to optimize my site?"
Mistake #4: Failing to evolve
A major healthcare website recently hired an agency with which I am familiar. The client has used Omniture for years and noticed a few things that were a little off in their reports (have I mentioned how much I hate the Form Analysis plugin?), so they hired this agency to do an implementation audit. As they sign the contract for the implementation audit contract, they say, "You'll notice we don't use conversion variables or events, and that's fine. We're really content with just the traffic data, just help us make sure the traffic data is coming through properly". In other words, "This solution worked for us four years ago, please just keep it working as is."
Oh, how this breaks my heart! Because I know a year from now they might say, "Gee, we're spending a chunk of money on our web analytics, but we've never done a thing with the data. Let's bring on an expert to help us analyze". And that expert will say "analyze? analyze what?" Then they'll need to re-implement, then wait even more time before they have real, actionable data.
If you're using the same set of reports that you were 18 months ago, you are very likely losing value on your implementation. That is, unless your website hasn't changed, in which case there may be bigger problems. The web is constantly evolving: so should your site, and so should your implementation.
The problem, of course, is finding a balance between "We don't need any newfangled reports" and "Let's track everything in case someday we might need it". The best way around this? Any time you are changing your implementation, don't think of what data you want to track now (again: never think "I want to track"). Think of which reports you've actively used in the last 3 months. Think of what reports you will use in the next 3 months. If current reports don't fall in that list, scrap them or at least hide them from your menu so they don't distract you.
See what analytics trends are on the rise. Check out some of the top blogs in the industry- particularly your vendor's blog, like Omniture's Industry Insights- to see what's up-and-coming in analytics. If you're hiring an implementation consultant- either from a vendor or an agency- don't just tell them what reports you'd like. Ask them which cool reports others having been using. Use their experience. They may be content to take orders or fulfill the requirements of the contract (which are usually made by salespeople, not analysts), but it's very likely that they have great ideas if you'll give them a couple hours to incorporate them.
I write this post as a step in the direction of repentance. I have been a Data Squirrel enabler, and I know it. Learn from my past and don't allow these mistakes to diminish the value of your implementation.
Because right now my role is mostly in implementation, it sometimes feels like the world of analytics is nothing but figuring out how to report- either how to get the data in there or how to present it. I want to see some action!
I challenge you all to spend a mere 30 minutes in your tool of choice to find one- just ONE- actionable piece of data, and *here's the kicker*: actually take steps towards that action (even if it's just making a plan). I don't expect the action to only take 30 minutes, but you should definitely be able to find your piece of data and start a plan in that time.
Here are a few ideas that range from simple to ambitious to help you get started:
- Look at your Error Pages report and fix the most-clicked broken link. If needed, use a pathing report to find the page sending people to your error page. This is practically a freebie.
- Look at your top internal search keyword. Figure out a way to make content on that topic more easily findable from your homepage. Ask yourself: would this make a good internal promotion?
- Look at your top 5 highest-traffic landing pages, then see which is converting the least. Make a hypothesis about what could improve (compare to highest-converting page if you need ideas), then make a game plan to A/B test it.
- See which paid search keyword has the highest bounce rate. Hypothesize on how to make your landing page appeal to users clicking on that keyword more, or reword your keyword so it brings in more qualified traffic. Make an A/B test out of it.
- Think of the one thing on your site you wish users were doing more of. Now put it in a fall-out report. Find the point of highest abandonment. Hypothesize about why users are falling out. Test it.
- Find a low-performing call-to-action. Figure out a different way to present it: perhaps a different graphic or reworded text. Test it. (Are you noticing a "test it" theme, here?)
- Take your highest-performing campaign. Play with segments until you see who the campaign appeals to the most. Earmark that segment for more marketing efforts.
- Find a video with a high conversion rate. Feature it in an area with higher visibility.
- Look at your top Organic Search Terms. Do you see a lot of your brand name in there? Find a high-converting product page and focus some SEO efforts there so you can reach users looking for your products, not your brand.
If you reach the end of your 30 minutes with no action plan, don't give up. Spend some time finding a recent success or failure. What's trending up? What's trending down? Try segmenting the data different ways. Make some theories, then plan some tests. Not to sound like a broken record here, but you can't go awry with a well-executed test.
I'll happily take suggestions for more ideas, too. I'd love to make one huge long list of your ideas for actionable data.
Ready? Go team!
When you're done, please come back here and tell me how it went.
PS: If you can't find one piece of actionable data to move with, then either you need to revamp your implementation, or congratulate yourself on a perfect website and implementation. In which case, you have free time on your hands to volunteer at the Analysis Exchange!
This is post 3 in my series on quickwins.
Pathing Reports have been covered over and over. Adam Greco summed them up beautifully back in 2008. He has since contributed quite a few more gems about pathing, so I'll try not to reinvent the wheel here.
So what WILL I cover?
First: pathing reports. I know you have them. They're out of the box. Use them. Play with them. Pat their heads and tell them you love them. Take 30 minutes to just play around with each of them. Think about other variables you might want to see pathing for that would require nothing more than enabling pathing on an existing variable; common ones include Internal Search Terms, Site Sections, and Page Type.
Then take it a step further and do some minimal implementation to give you more pathing reports to love.
Note: To have pathing enabled for any prop, you must contact ClientCare.
Easy Pathing Reports you could get with one line of code
Campaign Landing Pages
With one pathing-enabled prop (propX in this example) and one snippet of code in the s_code.js, you can see where your campaign landing pages are leading people. The code looks like this (placed in the s_doPlugins section of your s_code, somewhere after your s.campaign variable):
This code says: if a campaign tracking code has been set, pre-append it to the pageName. Otherwise, just capture pageName. This can give you a report that looks like this, where the page on the far left is a campaign landing:
I can see of the 24 users who came in off a certain campaign yesterday, 5 exited my site, 2 immediately converted (in yellow), 2 moved on to another offer (hmmm, maybe I can use that in my next campaign), and 2 went on to find out more about my brand. If I were just looking at a campaigns report, I would see 4 Form Submits, and would assume the other 20 users were "unsuccessful", at least in the short term. But now I know that campaign met some other success, just not the success I had predicted.
You can also use this to build a great Fallout report if your campaigns lead to a multi-step process.
Internal Search Page Paths
By simply enabling pathing on your Internal Search prop, you can see the the series of keywords a user might go through in one visit (what, not tracking Internal Search? For shame! See how easy it is?). But let's face it, without context it's hard to know what to do with that data. Users could be searching, adding to cart, then searching some more and adding more to cart- which is fantastic! Or, they could be searching, and searching, and searching, then jumping off a cliff. Not so good. Which search terms are frequently revised without leading to success? In other words, what are users searching for but aren't finding?
With one line of code and one more pathing prop, you can take that a step further and see how often users search, think they found what they want, go to a piece of content, then end up searching again; this gives you actionable data about possible interface problems, ways to improve your search engine, or promote content.
Here comes the code. Let's say your internal search prop is propY and your new "Internal Search Page Pathing" prop (with pathing enabled) is propZ:
This could create a path like this for a user trying to find the right Wug for their home:
>product detail page
>Search: blue wugs
>product detail page
>Search: blue radioactive wugs
>product detail page
If this were just one user, this would be "so what?" information. But if a significant number of your users had searches like this, you could now know that your radioactive wugs might make a nice internal promotion- if users are looking for them, let them find them!
Internal Search Conversion Paths
A slightly different approach to the same idea- let's see how searches lead to conversions (this would also be a great case for using a cross-visit participation eVar).
This could show you a user path like this:
Search: red wugs > Search: red wug > Search: blue wug > Conversion:Purchase
Or, on the other hand, it could show a series of searches that did NOT lead to a conversion.
Search: red wugs > Search: red wug > Search: blue wug > Search: radioactive wugs > exited site
Note: None of the above custom pathing variables will make a ton of sense as a traditional traffic report, at least, not without some filters. But you can easily do a search on "Search:" to filter out the non-search pages.
Also, be aware of how many unique values you might be getting into any of these variables. If you have over 50,000 unique search terms combined with pagenames in a given month, it would have serious implications for any pathing reports.
If nothing else, I hope this post has gotten you thinking about new ways to use pathing reports. I don't think you have to look far to find value in them.