It is amazing how many sites do not track well. Nearly ever tracking model I have walked into has problems, but the "right" tracking model is actually pretty simple. Avoid a lot of problems, and build it right from the start.
I know a lot of solutions use page tags (also known as web bugs or 1x1 transparent gif images or sometimes horrendously they are javascript calls), and that is fine and they mostly work (so long as cookies are required), but I actually favor a simple db write by the web server each time it serves a page. Web bugs add weight to a page, unnecessary traffic to the net, and there is overhead associated with the weight as well as the request /response time, and I am a purist. Also, do you really want google(for the free urchin based solution) knowing everything about every web site? Particularly if google is a potential acquirer of your startup you might want to think twice before showing them all your data. Also, it just annoys me to call someone else's site for anything within my domain. Oh I do it all the time in order to make deals happen, but it still annoys me. If you are going to drop a page tag (LOATH), put it at the end of your content so it loads last on the page after the used has their content, and you might even consider putting it in an iFrame if you or someone else is measuring your response time and you can beat the penalty by putting it inside the iFrame.
- Creative, Placement, Offer: An important concept related to advertising tracking. Every promotion that you use should be tagged with three id's, creative, placement, and offer, and these three variables should be recorded for every visit to your site. You will not need more than that, and if you use less, your tracking, segmentation, and optimization will become necessarily convoluted in order to accomplish your goals. Examples: creative = ABCD123 = 160x600 wide sky with the smiley face on it, placement = EFGH567EFGH = yahoo mail message sent page, offer = IJKL987 = buy 1 today and get one at 50% off.
- Visit table: For each visitor to your site, assign a session id that is absolutely unique and persistent through the visit. Attach all the standard http header info that you can stand to swallow with the session id as the primary key. I usually hold server timestamp, ip address, referring url, inbound url, and useragent at an absolute minimum, and it is nice to hold things like does the user accept cookies, what time zone are they in, what is their screen size, do they accept javascript, do they accept flash, quicktime, etc.
- Cookies: If the visitor does accept cookies, and has a cookie from you from something prior, attach the cookie number to the visit. This is where it is really nice to serve your own ads so that you can cookie on adserve and really track the marketing lifetime cost of a user. Some people like to put data in the cookie, some just like to drop a cookie number and do a db lookup for all the profile information, etc. I favor the latter but it doesn't really make too much difference and the latter can be more systems intensive.
- Userid: If the user logs in, grab that userid of course. You can use this to stitch together cookie erasers too by seeing a different cookie upon each visit. Presumably you can hold an obfuscated userid in a cookie. Make sure you differentiate in data between an authenticated userid and a cookied/remembered userid.
- Serial number: If you have something else that is stickier than a cookie on a site like a piece of installed software with a serial number, grab that too of course, and you can tie things together even better than with Cookie or userid potentially. For instance, you can re-populate the same cookie id and/or cookie data on subsequent visits if you have cookie information stored in your database (at least the most important cookie information like testing markers and userids. ou can use this same method to join different cookie ids together later using things like shipping address, payment information, etc.
- Page requests: Each time the user requests a page on the site, write the session id and timestamp of the request. You can also add super important things like log in state, userid, field entry data, as you see fit. Also, it is nice to be able to differentiate which link someone used to get to a page if there are multiple paths (eg, the home page link in page text vs the logo in the upper left corner). Among many other things, you can use this table to ssee which products people viewed but did not put in their shopping cart. This can help organize yourr site to convert best.
- Transactional tables: Almost don't need to mention this, but you will hold things like shopping cart data, shipping address, etc as needed to make your site work. Just make sure that you tie a session id to each of these and you will be able to trace everything that happens on the site back to creative, placement, and offer that brought you the transactions. Normally, hold a cart id for each shopping session that starts to build a cart, all the product in the cart, then if they check out you can join the cart to a payment table, shipping table, etc.
- Test tags: if you are doing random testing, somewhere you need to store which user experience a visitor to your site received and enforce persistence.
Sounds simple, but no one ever does this out of the box, and you need it to Market effectively.
No comments:
Post a Comment