Archive for February, 2011

Ads on Sites

Tuesday, February 15th, 2011

Congratulations, you’ve finally created a popular abode for the denizens of the web. I guess the next step is attempting to monetize it! Chances are you’re thinking about putting ads on it.

One import thing about putting ads is that you’ve obtained your current positioning by putting content and users first. While it’s great to use the above heat map from Google Ads, it’s also very import to note that they’ve specified to think about how your users use your site, and to also put your users first.

There is a diminishing marginal return on ads. More ads do not mean more money. In fact, it might negatively impact the revenue on other ads, so it’s very important to take the placement, saturation, user-base, and usage of your site into account before placing ads willy-nilly. The heat map is used more as a “guideline” more so than the end-all-say-all of ad placements.

Your site is valuable to advertisers because users go to it; the users find it valuable for it being what it is. If you change what your site ultimately is, your user-base might react negatively to it, and your site can no longer be as effectively monetized.

Modify as Little as Possible

Thursday, February 10th, 2011
modify as little as possible

modify as little as possible

Today’s post is going to be on my opinion on modifying existing systems. Unless you’re a one-man-coder-army, and if you are… kudos, but often times, you’ll find yourself working with other people’s code. When working with code that you’re not too sure of its functionality, you should tread extremely carefully. Make small changes, review the effect, and then proceed. I’ve seen a lot of projects go wrong when they change multiple elements of a system to get to a specific result, only to fail, and then absolutely have no idea what went wrong.

By making small incremental changes, you can change the direction of the project when you’re getting unexpected results, you’ll also know what went wrong, and you can also correct it quickly. That being said, you can probably feel more confident making these changes if you were in a TDD (test driven environment), since you can run a regression test on the existing system to make sure nothing is broken and everything is working the same. On the other-hand, a TDD environment introduces its overhead. Unless you have a TDD environment, it’s probably best to stick with the practice of making your changes small incremental bursts followed by a lot of review.