My Photo


  • Clicky Web Analytics

Your email address:

Powered by FeedBlitz

« Creating an Analytics Agency of Record - the Analytics Watchdog Webinar Follow-up | Main | Seventh Inning Stretch »


I asked for sprop to set the same as evar all the time from my previous job. Reasons:
1. I have large number of marketers and many campaign mini-sites, these individual sites most often than not were created and designed by different agencies.
2. The cost of educating each agency dev on the difference between sprop and evar is not worth my time
3. Instrumentation planning cycle is very short as these sites have shorter life and are always needed to be done yesterday because media execution date (SEM, Display) is hard to change
4. The cost of going back to the page to modify when a business requirment arised later on is higher than I simply just pre-populated sprop
5. I can go back to datawarehouse to run custom reports if needed, sprop give me additional reports I can run


I'm with you. Trying to explain the difference between an sProp and an eVar to your Agencies is a sure prescription for gray hair and frustration! If you need those sProps, then I'd probably recommend a careful standard that simply tells Agencies how to set each and every variable. But if you have the variables to spare, you'll be right far more often than not by just duplicating them.


view thoughts:
- pageName in an eVar: I’d always capture the pageName in an eVar to see how many eventX’s happened on a given page. The Pages report wouldn’t show that because it uses linear allocation

- props/correlations: What I don’t like most about them is the label “Page Views” (it shows instances) and the amount of “unspecifieds” if you use a prop for a business unit and set it on every server call. In that case eVars (exp. on PV) are more flexible, but I agree with you the standard contracts limit the amount of full subrelations. (going away in v15)

- VISTA: s_code is usually executed within milliseconds and adding a few lines of code doesn’t hurt at all. Compressing a jpg will save those 2kB you just added. I have a pretty complex s_code which is 30kB gzipped. Any single jpg on the page is bigger.
The only reason to use VISTA rules are DB VISTA rules. Any logic that I can built into s_code without lookup tables, I’d do in the s_code. Easier to maintain and especially to debug. Only if you have huge lookup tables I’d definitively recommend a DB VISTA.
Processing rules might change my point of view, but I like to have all logic in one place, so I guess, I keep putting it into the s_code.


The comments to this entry are closed.