Tagging Plans that Don’t Rot

Description: Tagging Plans that Don’t Rot: Omniture from a practitioner’s perspective with timeless lessons.

Dialogue style intro

“Why did our conversion rate drop after the redesign?”

“Because half the new templates shipped without s.t calls and the rest are double firing event1.”

“But the spreadsheet says we mapped everything to eVar5.”

“The spreadsheet is from the spring. Your devs renamed the module ids in July. Also the campaign links are missing s.campaign from the new email tool.”

That was my morning. You have seen that movie. A tagging plan that looked tidy during kickoff slowly drifts until it is more rumor than source of truth. We use Omniture SiteCatalyst because we want answers that drive growth. The tool is fine. The rot sets in when the plan cannot keep up with the people and the releases.

This post is a field guide to building a tagging plan that does not rot. I am writing from active projects running SiteCatalyst 14 with s_code.js, SAINT classifications, Data Warehouse, and the occasional handoff into Discover. No tag managers. No magic. Just a plan that survives a redesign, a new email vendor, a mobile site, and a few late night deploys.

Evidence from the trenches

Here are patterns that keep showing up across retail, media, and lead gen. I am putting the common pain first, then the fix that sticks.

• Page names drift. A designer changes title logic and suddenly s.pageName starts to include query strings or extra prefixes. Trend lines look broken. The fix is a repeatable rule. Build pageName from a stable path not the title. Keep the same casing rules across all templates. Document the rule inside the code comment and in the plan. When a dev opens the file they see it. When an analyst opens the plan they see the same line. No guessing.
• Campaigns eat everything. A promo link sets s.campaign and then internal links keep the same value for five clicks. Every report becomes a campaign report. Set a hard rule for internal campaign clearing. Clear s.campaign on every internal click. Use a separate variable for internal promotions such as eVar for placement or prop for slot id. This protects paid reporting and keeps internal promo tracking useful.
• Events are overloaded. Everyone loves event1 because it exists. It becomes add to cart, video play, and newsletter sign up all at once. Split by intent. One event equals one action. Give each one a name and commit. If you run out, use a list var for soft actions or track counts in props with pathing.
• eVars lose meaning. A new team borrows eVar12 for a quick test and forgets to tell anyone. Next month your product finding method report is a soup. Owners prevent this. Assign one owner per variable. Owners are named in the plan and on the wiki. They approve any change. If you need a temporary reuse, set a clear end date and record it next to the variable.
• Classifications never get updated. Campaign reports are stuck at shortcodes. Use SAINT auto import from a single master sheet and schedule it weekly. The sheet is the truth. Not someone’s desktop. Keep the columns predictable. Code, Channel, Subchannel, Creative, Message, and Landing page. Your future self will thank you during Q4.
• QA is hand waving. Launch day arrives. People click around and eyeball reports. That is not QA. Build a short checklist with exact beacons and values for each tracked action. Test with Omniture Debugger or WASP. Save the console output. Attach it to the release note. No mystery later.

The strongest signal is boring. Teams that write things down in one place and keep ownership close do better. Not more variables. Not more tools. Just declared names and repeatable rules.

Implementation notes

Here is the plan I use when I set up or refresh a SiteCatalyst install. It works for a small site and it scales for a big one. Tweak the counts to fit your limits.

• Set a purpose per question. Start from business questions. For each question, name the report and specify the variable or event that answers it. Example. How many searches end in a lead? Answer with event for internal search, event for lead submit, and an eVar for search term with visit expiry. The report is conversion of search to lead by term.
• Reserve your name map. Create a short dictionary. pageName, channel, hier1, prop1 to prop5 for content, eVar1 to eVar5 for marketing, events 1 to 10 for core actions. Keep this map in a shared doc and in the top of your tracking plan. Add the owner next to each line.
• Use consistent casing. Pick lower case for values in eVars and props. Force case in code. Your reports will roll up without extra filters. It also helps SAINT rules match cleanly.
• Decide expiry up front. For each eVar, write the expiry in plain language. Visit, Visit and 7 days, or Purchase. State allocation too. Most recent or original. This prevents strange credit later. Place those choices in the admin and mirror them in the plan.
• Keep page naming simple. Use channel for top section. Use hierarchy for nested sections. Keep pageName unique and human readable. No query strings in pageName. Store the full URL in a prop if needed for debugging.
• Distinguish internal promotions. Store slot id and creative in their own variables. Do not reuse s.campaign. Build a report that pairs internal slot with landing page and downstream events. Easy to manage and it will not pollute paid numbers.
• Track search right. Use an eVar for the term, an event for search, and a prop to allow pathing on search refinement. Add a filter to ignore blank terms. Tie site search to results page and to next action.
• Own the products string. For commerce, keep the products string predictable. Category, SKU, quantity, revenue, and merchandising eVars as needed. Document the order and stick to it. Finance will care during forecast season.
• Classify campaigns weekly. All campaign codes must live in a single sheet with SAINT export. New vendors get a code rule before they send a single click. No code rule, no launch.
• Write a release note for tracking. Every change in tags gets a one page note. What changed, which variables, sample beacons, and the person who tested. Store it next to your plan. You will use this during audits and during staff changes.
• Build a small data layer. Even without a tag manager, you can expose a clean object with page type, user status, and product info. Read from that object into s.*. This stops copy paste drift across templates.
• Automate the boring checks. A simple script in QA can crawl a list of URLs and verify presence of s_code.js, fire a s.t call, and confirm that required variables are set. Save the output. It turns fear into facts.

For teams using Test and Target or ad serving scripts, make a tiny pact. Experiments can add classes and swap modules, but they do not rename ids or move the data layer object. Your analytics stays stable while you test layouts or copy.

Risks you can predict

Rot is not random. It shows up where there is churn and silence. You can plan for these and blunt the impact.

• Staff changes. When analysts or devs leave, context leaves with them. A variable owner list and release notes act like memory. Keep both in the same spot as your plan.
• New CMS or redesign. Template changes break naming and beacon order. Before you migrate, run a crawl and record current beacons and names. During the build, run the same crawl weekly. Any drift gets fixed early.
• Widget sprawl. Social buttons are everywhere now. They can redirect and hide clicks. If a widget matters, wrap the click with your own handler and send a proper s.tl call with a clear link name. Do not rely on the widget vendor to care about your reports.
• Mobile sites and apps. iPhone and Android are not a side note anymore. For mobile web, reuse the same naming rules. For apps, set a parallel plan that mirrors key names and events. Keep campaign logic consistent across links from email and banners into the app or site.
• Query string chaos. Affiliates and email tools love to attach extra parameters. Set a white list for campaign parameters and ignore the rest. Normalize case at the door.
• Flash interactions. Plenty of sites still run heavy Flash. Make sure deep interactions trigger clear events and that exit links carry campaign values when needed. Test with a packet sniffer if the debugger misses embedded calls.
• Timezone and day change. Reports shift when the account timezone moves. Lock the timezone and note it in the plan. When you launch in a new region, open a separate report suite unless you have a clear reason not to.
• Sampling myths. SiteCatalyst reports are not sampled in the way some free tools are. But tight variables and bloated props can slow you down. Keep variable counts sane and do not track noise just because you can.

Most of these risks fade when there is a shared source of truth and a small set of non negotiable rules. Names stay the same. Owners approve changes. QA is repeatable. That is it.

Graceful exit

Omniture is not the hero here. Your plan is. A plan that does not rot is plain on purpose. It has clear names, steady owners, and boring habits. It says pageName is built from this path. It says eVar7 is search term with visit expiry and most recent allocation. It says event5 is lead submit and nothing else. It says SAINT runs every Friday before lunch.

We are living through real change. The iPad is on coffee tables. Facebook buttons are on every article. Adobe just folded Omniture into its stack and everyone is watching what that means. With or without the next new thing, the teams that win write down the rules and keep them small. When your plan stays fresh, SiteCatalyst turns into a steady drumbeat of answers, not a monthly surprise.

If your current setup feels wobbly, start with three moves this week. Publish a one page variable map with owners. Lock page naming rules in code and in the plan. Schedule a weekly SAINT import and a fifteen minute QA crawl. That small routine keeps everything else alive.

When someone asks next month why conversion dipped, you will open the release note, point to the exact change, and either fix it or learn from it. No guessing. No folklore. Just a tagging plan that does not rot.