Ecommerce and Entrepreneurship Blog | About | Contact | Store

How Do Social Media Sites Make Money: An Infographic

Posted on May 24, 2012 by Josh

I thought this infographic was really interesting as it shows what most social media sites are using to make money. Check it out and leave a comment with what you think.

How Social Sites Make Money

PayPal Proves That They Can't Be Relied On

Posted on October 29, 2010 by josh

Back on June 1, 2010, I wrote another post related to PayPal downtimes and, more specifically, why having a backup payment processor is valuable. PayPal proved me right, again, today.

PayPal was basically completely down.
On their live site status page, they said:
Impacted Service/Product:
Live Site
- PayPal APIs
- Website
- Website Payments Standard
- Website Payments Pro Payflow Edition
- Express Checkout

Seriously yuck! But, for us, it was no big deal. In fact, if we hadn’t decided to build an error email when PayPal was returning transaction errors, I never would have noticed they were down. Our backup simply gracefully took the transactions on, with only a minor delay to customers at checkout. For those who are curious, we were affected from about 8:15am to 9:30am and from about 11:30am to 12:00pm.


Google Annouces A URL Shortener

Posted on October 7, 2010 by josh

For all of the Twitter users, you are very aware that a shortened URL is a beautiful URL. Google is starting to understand that and is jumping on the bandwagon by announcing there very own URL shortener.

Google’s URL shortener now has a website where anyone can go to make short’s. It was only available as part of certain Google products (I used it as a Chrome extension), but now anyone can just go to to make their own shortened links.

Aside from standard and simple shortening of a URL, Google says they want to make it “...the stablest, most secure, and fastest URL shortener on the web.” Also, a neat new feature allows you to track clicks to your shortened URLs:


Google URL Shortener Stats

 I know there are a lot of shorteners out there right now but with the analytics and the fact that Google will be backing it with additional changes and updates, this is a pretty solid URL shortener to consider using.



Google Wave is Dead

Posted on August 9, 2010 by josh

Google recently announced that they will not continue to develop Google Wave as a standalone product. Back in November, 2009, I wrote my first impressions of Google Wave. I have to admit, at the time, I was incredibly excited to get a developer invite. I love to geek out and try new things (naturally I love to try new Google products). I fully expected to use it for collaborative efforts and projects; but honestly, I rarely logged in. The reason? Low adoption. This is the same reason that Google sited for discontinuing development. I wanted to like Google Wave, I even wanted to use Google Wave, but none of my friends or colleagues did. Even when I recommended it as a collaborative platform, others plainly said “No”, instead opting for something that was already comfortable for them.

Google Wave Logo

One of my developer friends, Matt, even said to me in one of my first Waves, “Google Wave will be one of Google's biggest flops yet. This is hopelessly worthless, inefficient, and out of touch. This is NOT what email would look like if we designed it today.” Though I disagree with Matt that Wave is “hopelessly worthless”, I do have to admit that it flopped. However, I have hope for future Google products though, and I can’t wait to see some of the real-time elements introduced to Google Apps.



Communicating Service Outages to Your Team

Posted on July 22, 2010 by josh

If you're in charge of keeping critical systems going for your organization, it will be necessary, from time to time, to explain to your management team (or your customers, if you operate a service) why a service outage occurred. Whether it's your network, your phone system, your payment/checkout system, your website, or your {fill in one of the dozens of services you manage}, it's critical that you communicate what happened, who caused it, when it happened, where it occurred in your infrastructure, and how it affected your operation.

Below, I've created a simple sample of one of these communications (for demonstration purposes only):

Hello Team,

This communication is intended to provide you with a formal explanation for the service interruptions that we experienced on Thursday, July 21, 2010, which resulted in a downtime on our website.

We experienced a downtime on our website from 9:48pm to 9:59pm. No pages could be reached during this period.

Escalation Taken
Alert messages of the downtime were sent to the alert team at 9:48pm that there was a potential downtime. The tech team mobilized and immediately began testing systems to determine a cause.

Root Cause
Upon investigation, it was found that a family of pygmy mouse lemurs had taken refuge in our data center. One of the adorable animals had pressed the power button on our web server, as it was shiny. This turned off our web server.

Corrective Actions
We turned the web server back on by pressing the power button and the web site resumed normal activity within a minute or so. Sadly, we also had to evict the cute but culpable creatures.

Next Steps
In the coming week, we will be installing a mesh screen on the server's rack to deter any new intruders. We've also begun plans to scale our infrastructure to support load balancing and redundancy across multiple web servers in multiple locations to help to mitigate future issues like this.

Should you have any questions, please do not hesitate to email or call us. Sorry for any inconvenience!

Best regards,

Your IT Guy

Issues are going to happen, and they're not always in your control. The key here is to communicate quickly and accurately. As soon as you've got the situation under control, and you have the facts, communicate it out. You want to address concerns quickly, because your team may be wondering why sales dropped between 9:48pm and 9:59pm. You want to be as accurate as possible because you may not realize that your marketing team had scheduled a report to be uploaded to FTP (which lies on another server that may have also been affected) at 9:45pm. Don't worry. Chances are, your team (or your customer) doesn't care as much about being down as they do about how you respond and how well similar future issues are addressed. Try not to use uber-technical language, as you may be communicating with non-technical personnel. Be ready to answer lots of questions and make yourself available to them. You may have satisfactorily resolved the issue, but others may still be left without closure on an issue. Do a great job of communicating what was, what is, and what will be. Your team will appreciate it immensely.


Tips for Managing eCommerce Development

Posted on June 30, 2010 by josh

I have the fortunate duty of building some amazing solutions for our sites and systems. Being honest and up front in your position, with yourself and others, can play a key role in your success as an IT or Development manager. Here is a short list, not comprehensive, on some things you must do as an IT or Development manager:

Have thick skin

You can't make everyone happy... and you won't. The needs of the organization frequently do not meet the perceived needs of all individuals. But your team has to be able to critique you. Listen, and be honest with yourself. Also, you aren't perfect. You will screw something up. How you respond is likely as important to evaluation of your performance as the initial task. So, don't take criticism personally. Take it in, measure it against the organizational needs, discuss it with your management team, and build on it.

Let your management team know, in advance, if you're...

    • going to be making changes that could affect their teams ability to do their job: If you’re up front, chances are they'll be willing to help you meet a deadline or do some testing if it means that their team will get new tools or increased productivity.


    • going to make changes that may affect how your site gets indexed by search engines: If you make major infrastructural changes to your backend architecture, make it clear that it could have short term drawbacks and make the long terms gains that you're shooting for equally clear. Your team will appreciate your candor.


    • going to make changes that may affect conversion: If you're in eCommerce and you're working on, say, your shopping cart, chances are you're going to see some numbers change on whatever reports you and your team pay attention to. Aside from taking a page from Amazon and making smaller, more easily measured, incremental changes, if you are making changes that you think may have an impact, even slight, mention it to the team.


    • going to be releasing something that is 80% tested: In development, there are lots of good reasons for doing this. On some projects 80% tested or 80% complete, yields 98% of the desired functionality. Frequently, the other 20% is easier to address in the wild with real users. Be honest with your team about this and help them to understand why the additional cost of testing or completing the final 20% may not be as cost effective as releasing. Of course, I am NOT making a recommendation to do this on every project. This technique should only be applied when justified and appropriate and when it meets the needs of your organization (and probably when it doesn't display to the public in some embarrassing way).


  • going to do something that affects their work life... {this list goes on forever}

Understand that everything is a priority, even if it isn't

You don't get to make every decision, but you must be sensitive to other's needs. Do your best to make clear what is prioritized and why. Also, know that the members of your management team are, at least in part, judging your work based on what you've done for them. Toss in a quick feature, or fix an easy bug every now and again. Even if it's not next on your priority list, the human element here can be powerful. It can help you to build a better relationship with others, increase morale for an individual or a team, it can even help to make them look better if it helps them to be more productive. Besides, it may buy you some grace the next time you need it (and you will). These things can't always be measured in dollars and cents, but they can be felt in quality of life.

Be vulnerable, you can't solve every problem and you can't do everything all the time

I know you're amazing. You have tremendous problem-solving skills and you have pulled some rabbits out of some hats in your career. But people don't want to hear about how you're going to get everything done perfectly. It's a lie. You can't. Be honest with yourself and others about how well you'll do with the tasks that lie ahead and the resources you've been given. They need this from you and you need this from them.

Don't speak over people

There are two things to pay attention to here. The first thing is that you need to listen. Before many people finish their sentences you've got it more than half worked out in your head. But, you have two ears and one mouth for a reason. Even if you disagree with someone because they are requesting something that you believe is technically infeasible, stop coming up with ways to rebut and force yourself to listen. Don't immediately fire off a "NO". Try to understand the need and let them know that you want to understand the need before you help them by working together to design a solution. The second thing you need is to learn to speak to your audience. It's easy for you to say to another techie that a system update caused a legacy service to crash, causing dependent services to also fail. But not everyone is going to understand what you're talking about. It sounds really simple to you. But you have to help them understand why and how it happened. You don't have to use elementary words, but you do have to use words that your audience will understand. Know your audience.

I'd love to hear some additional thoughts from other IT and Development managers out there...


Google Launches CodeLab

Posted on June 15, 2010 by josh

On May 4, 2010, Google Webmaster Central Blog announced a codelab called Web Application Exploits and Defenses.  The codelab is for use in learning/training about common web vulnerabilities. It's built around a micro blogging application that is riddled with security holes. The goal is to provide users with an opportunity to apply white-box hacking to learn and understand some of the most common web vulnerabilities and exploits. The bugs are real bugs. The application is real.

I love this idea. If you've never applied any of the hacking techniques addressed in the CodeLab, it's tough to know how to prevent them. This is similar to WebGoat, which is also useful for learning web application security. Even if you don't use the same programming technologies or web development language presented in the lab, it's still completely applicable in understanding exploit techniques and how they apply in your environment.


Why Building a Backup Payment System is Worth It

Posted on June 1, 2010 by josh

PayPal Payment Processor Payment Processor

You may or may not know that on Thursday, May 27, 2010, PayPal suffered from a significant issue. This was nothing like the $2,000 per second outage that PayPal faced in August of 2009. A logic error with PayPal's risk model led to a higher-than-normal chance of transaction decline. According to a source at PayPal, the issue affected PayPal's direct payments system (not PayPal Express Checkout) and their virtual terminal. I was told that this was an "all hands on deck" incident for PayPal.

The issue began just before 8:30AM PST and lasted until about 4PM PST. I was notified by our customer service team that there was an issue with transactions just before 9AM. They came to me to let me know that a number of transactions were declined for, seemingly, no good reason. Later in the day, I received an update that the issue affected approximately 15% of transactions for PayPal. Although, we were likely to see a higher fail rate in our customer service center, since customer's who had experienced an issue were likely to contact us, try again, and fail, again. We saw a fail rate of closer to 50 - 60% during the issue period.

In development, we had already planned to begin development shortly on a backup payment processor process. In August of 2009, we had been directly, and severely, impacted by an downtime. We knew that we would face payment processor issues, again, at some point. Apparently, it's inevitable. Given the number of customers who contacted us about the current issue, and the untold number of customers who did not contact us, and the thousands of dollars in lost revenues, and the poor customer experience, we knew that we would need to bump this project in priority to A1 status. So, at this point we had already had experience transacting securely with two payment processors, and had already begun work in mapping out the new process. The dev began.

By about 4PM we had wrapped up testing the new process and were ready to push it live when I received a contact from PayPal that their risk model issue had been resolved and that transactions had returned to normal. Classic. Well, we didn't beat the PayPal clock, but we did learn some things.

1) Payment processors fail. As much as I'd like to believe that they're committed to five-nines up-time, I know that will never happen.

2) Customers hate getting errors at checkout, especially after they've already entered their credit card information. I know it makes me uneasy when it happens to me; you don't have to have more than one phone call from a panicked customer to know that you've really wrecked the whole experience.

3) It's not a very difficult problem to solve. Chances are you have spent a great deal of time, energy, and resources negotiating rates and developing a system and reading through an API manual and following PCI requirements.

Building a backup system is still likely worth the time and effort, if not for the untold number of lost transactions, for the customer experience. Now I am left wondering, though, 'What happens when both processors fail at the same time?! ... I am kidding, of course; we just direct them to use Google Checkout.



Why Bloggers Can’t Share Everything They Have Learned

Posted on March 25, 2010 by josh

This blog post is one that won't explain, instruct, or enhance any measure of your working life; but there's a good reason for it. Managing two critical departments for an eCommerce company, IT and Development, can be extremely challenging and fun. Often, we come up with incredible solutions for complex problems that I know others are going to traverse. As much as I want to share all of our experiences on how we've navigated some tough roads or saved/made the company thousands, or even tens of thousands, of dollars, I can't. It's not that I want to hoard all of our awesome developments or ground-breaking discoveries or money-saving ideas. It's that I have two very ominous risks ahead of me in sharing: Secret Sauce and Security.  And it's something that other bloggers have to take into consideration when they post as well.

Secret Sauce

How many of your blog readers are your competitors? I know for a fact that the employees of some of our biggest competitors follow our company's, and my personal, Twitter. How much can I say without saying too much and giving away our secret sauce? Well, in some departments, giving a general idea of how to execute high level processes might be ok. But in the world of Development, if we talk too much about how we figured out how to leverage more with less, at very little cost, we potentially give our competitors whatever competitive advantage we've garnered from such an effort. It stinks, because I empathize with other development managers that are out there facing an issue that I know is or will be familiar to them. I want to help them out.


In both IT and Development, the more I speak publicly about the systems we've implemented, the more we put ourselves at risk. If potential hackers, thieves, bandits, jerks, pirates, etc. don't know what we're running, the attack surface is much bigger for them and it makes their nefarious activities much more difficult. If, however, we reduce the security footprint by revealing implemented systems, any Googler can query common vulnerabilities or techniques to leverage our property. Though I realize that it's our job to ensure that such vulnerabilities are covered, it still doesn't make sense to improve their chances for things like zero day exploits.

You likely read this blog because you want to hear about the secret sauce and the awesome systems and I appreciate your ear. The members of my departments and I will do our best to share as much as we can, without letting it create any liabilities.


Google Apps Stops IE6 Support

Posted on February 25, 2010 by josh

We received a communication from Google Apps this month that I was delighted to see. Google Apps is finally phasing out support for Microsoft Internet Explorer 6.0. Hooray!

People have been saying that IE6 is dying for quite a while, but it maintained its grip throughout 2009. Lots of admins have been slow to upgrade because of support of legacy applications/pages that required much extra effort to get working properly in the now-antiquated IE6. Finally, Google Apps stops support and, hopefully, this means that admins and users will be forced to update in order to sustain usability.  Trevor recently predicted for 2010 that standards would take a step forward and this is a strong indicator that they will be/have.

It's not that I don't like IE6, it's that I hate it (Trevor, too). When we work on changing, updating, or adding some design element to our websites, invariably we have to budget time to support IE6. Not just older browsers, mind you, IE6 specifically. If I didn't think it would affect conversion, I'd add something like to our websites. Google will be telling their users, "Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser."

Thanks Google.