Reminder: What the SDC Tag Builder can do for you

We’ve seen a lot of “How can I track …” questions lately that can be readily answered by one answer:  “Use the latest SDC tag, it will do what you want and more.” 

Webtrends’ TagBuilder creates your tag for you, ready to be dropped into your site.  It has some powerful advanced features that take a lot of page customization work off your plate entirely.

Here is a quick list of many of the possibilities in the Additional Options section of the TagBuilder.  If any of these are news to you, go to http://TagBuilder.webtrends.com and take a close look.

1. Off-site links automatic tracking – the tag looks for links going somewhere else and records clicks on those links.  No need for passing those clicks through a redirect or using ondown/onclick coding on each offsite link.   They all get automatically picked up.  Woo hoo.  Saves the day when your marketing department adds new offsite links without telling you.
2. Untaggable download files tracking – Tracks clicks on links that go to file types that cannot hold a tag:  .txt, .pdf, .whatever.  Tracking links to files that cannot be tagged is one of the downsides of using javascript page tagging, but it’s not a problem with the TagBuilder tag.  You get to choose what file types get tracked, of course.  This is another lifesaver because those prolific pdf writers at your company don’t need to inform you when they add a new one to a page.  (Important note – we purposely used the phrase “links that go to files” because that’s all SDC does, is track clicks on those links.  If a link to a PDF exists on somebody else’s site, people will request that PDF without SDC being aware of it.  Unlike server logs.  Thank you Michael for reminding us.)
3. Form submit button clicks – Captures all clicks on form “submit” buttons, four common types of them:  (they covers 99% of situations, in my experience):  a)  <form> tag with method=get, b)<form> tag with method=post , c)  <input> tag, no enclosing <form> tag , d)  <button> tag, no enclosing <form> tag.  No need for special coding on form buttons.  Tracking form conversion becomes a certainty if you don’t always use thank-you pages.
4. Anchor link tracking (those # suffixes that have to do with within-page links).  Great for understanding things like the popularity of individual questions on a FAQ page.
5. Clicks on image map areas – no need for individually altering the code of image maps’ area-by-area hyperlinks.
6. Mailto: clicks automatic tracking  (hyperlinks using the mailto: protocol).  No need to pass these through a redirect or use ondown/onclick code.  This is great for those long, constantly changing lists of salespeople on your Contact Us page.
7. Javascript: clicks get automatically tracked.  Automatically tracks hyperlinks that use the javascript: protocol).  No redirects or ondown/onclick coding for each of these hyperlinks.  We actually don’t turn this one on very often in the tags we build, because it can result in double-tracking.
8. Variations in how cookies are tracked:  you can get SDC to generate one cookie for your main domain and another for a subdomain if you want to.  Or not.  You can tell SDC to use a site-generated cookie instead of the WebTrends cookie, or use a session cookie instead of a persistent cookie.  The latter is handy for government sites that don’t allow persistent cookies.
9. Extract part of a cookie value and put it into a parameter (that can be the basis of reports).  Does a cookie contain the data of the first visit, for example?  Grab it and turn it into an analyzable parameter with this option. 
10. Rename (i.e. map) existing parameter names to WebTrends auto-report parameter names, for example record parameters such as “prodcat=15″ as ”WT.cg_n=15″.  Another example would be your on-site search engine’s unchangeable parameter names for ”number of results found” or “keyword” on the results page URL.  This is a life saver if you are tagging an existing site that can’t be re-engineered to work with those WebTrends auto-config reports.
11. Divert data for a subdomain to a completely different dcsID.  This one saves money and keeps dev-site, UAT-site, or staging-site data out of your analysis.  It eliminates the need to create filters in WebTrends reporting that filter out your dev or staging site (thereby avoiding dev or staging site hits being applied to the license quota, as long as you don’t analyze the diverted data).
12. Multi-send data to WebTrends and also to your Ad Director or Quantcast account – no need for a separate tag for these two products.  Hey WebTrends, keep ‘em coming in this department!

All of the above are individually activated in TagBuilder UI.  You turn on the ones you want, then the TagBuilder spits out a tag that you just drop into your web site. 

The TagBuilder absolutely changed our lives here at Outsider Un-Central.  It’s always surprising  to see that not everybody knows about it.  We hope this post changes a few more lives out there.

Oh, I almost forgot.  A nice touch in this tag is that each different event type gets its own little parameter that identifies the event type.  It’s a simple parameter, WT.dl, that contains a value corresponding to the event type that’s tracked.  For example, the parameter WT.dl=24 appears in every hit that is an offsite link hit, and WT.dl=23 appears on all hits that involve a mailto: click.  This little detail makes it easy to build filters for event types.  The list of WT.dl values is here.

(Please note that if you are already using the dcsMultiTrack functionality to do any of 1-7, you’ll have to do a little cleanup before taking advantage of the TagBuilder tag.  Please call WebTrends for some guidance.)

Tags

Ad Director, automated tracking, domain management, downloads, extract from cookie value, form buttons, image maps, javascript clicks, mailto, offsite links, Quantcast, SDC tag, tag builder, tagbuilder

Somewhat Related Posts

No related posts