views:

50

answers:

1

So I have this Omniture object. It's called s.

s

Inside s, we keep track of a bunch of information, inside "props" and "eVariables".

s.prop5  = 'foo'
s.prop22 = 'baz'
s.var6   = 'bar'

Which prop variables and which evars we choose to assign, depends on which page we're tracking. For example, on the homepage, we may wish to track prop5, prop6, and evar2, but on the registration page, we may wish to track prop4, prop5, prop9, prop10, evar4, evar5. It varies.

Each variable and each prop represents some kind of key analytics information.

Now, even though this solution is not ideal, because the prop#s can all blend together, we do have a master list that we keep internally, explaining which variable represents what.

prop5 means "page name"

prop6 means "page category"

(et cetera)

Now, this is fine, and it works well enough, but we often have to pass the code off to third parties so they can assign values themselves. We might have a 3rd party create a page, and we want to do analytics on it, but we need them to be able to get the appropriate information to track. To make it more readable, we were considering of implementing some mapping code.

companyName.pageName = 'This is the page name'
companyName.contentType = 'This is the content type'
companyName.campaignId  = 'This is the campaign ID'

This is more readable. We would then loop through the "companyName" object, and assign every value back to 's' where appropriate.

What do you guys think? Would this be a good practice?

+3  A: 

Honestly I can't see why you would use the cryptic property names in the first place. Why not use the names you would give to 3rd parties internally as well. Wouldn't it just make your life easier?

defrex
+1. There's no reason at all to use such incomprehensible names. The reference to "props" and "eVariables" (whatever they may be) suggest that this practice is tied to producing a representation of what types the data have in an unrelated system's data structures, rather than what those data *represent*. Get some semantics in there :-)
NickFitz
Oh, how I wish that were possible! Unfortunately, this is not our code, but Omniture, the analytics company that was recently acquired by Adobe. We ultimately need to use the "s" object, and we need to name the member variables accordingly. My question - is it worth it to add the layer of abstraction in order to improve readability?
Zachary Burt
@Zachary Yes!!!
Gabe Moothart
I appreciate the enthusiasm, but can you elaborate? It seems like the benefit is readability, the detriment is that it introduces a whole other occasion to introduce error.
Zachary Burt
I'd recommend using a different analytics company, if that's the kind of garbage their system spits out. If that's not possible, you should definitely create an additional layer between your systems and their crud to provide some meaning (and, presumably, to strip the meaning back out when going the other way).
NickFitz
omniture is an enterprise level tracking and analytics tool, used by pretty much anybody really serious about this sort of thing. The reason the variables are ambiguously named is because YOU define what they should mean. You decide that s.propX should represent xyz and you label it within Site Catalyst, and the label shows up in the reports. You then put together a Functional Spec Document (FSD) to keep a record of what each prop and eVar means, when and where it is supposed to be used, what value/format it should be populated with, etc.. and you give that FSD to the necessary people.
Crayon Violent

related questions