The 5 Most Common Data Analysis Mistakes

Data-driven decisions are the backbone of modern online businesses. As too many learn, however, the only thing worse than not using your data is using it incorrectly. Here are five mistakes that we’ve seen companies make (before getting their ecommerce analytics on the right track with RJMetrics).

1. Not Accounting for Age

Aggregate analysis of customer behavior can be extremely misleading. For example, consider a company that has acquired customers through Google Ads for years, but only recently started spending money on Sponsored Tweets. An analysis of “customer lifetime spending by acquisition source” would likely show that Google-acquired customers, on average, have spent more than Twitter-acquired customers. But, this doesn’t mean that Twitter is an inferior source of leads—it’s just a misleading way of slicing the data. Of course the average Google customer has spent more: they have been a customer for a longer amount of time and had more opportunities to make repeat purchases.

This is an extremely basic example, but variations on this oversight lead to a surprising amount of confusion in companies of all sizes. To avoid this problem, use cohort analysis to segment customers by common attributes like when they made their first purchase. This allows for apples-to-apples comparisons of customer cohorts that can then be expanded into more insightful and actionable analyses.

CohortAnalysis

A sample cohort analysis

 

2. Not Planning Next Steps

Before you invest time in running an experiment or conducting an analysis, it’s important to understand how the results will impact your behavior. There will always be countless ways to slice and dice your data, and the best way to avoid analysis paralysis is to focus on metrics that will drive you to act.

To determine if a metric is actionable, simply consider the possible results of your analysis and ask yourself how your strategy or behavior will change based on the results. If it won’t, maybe your time would be better spent elsewhere.

 

3. Ignoring Test Significance

Whether you’re running an A/B test or performing ad hoc analysis on your data, remember that the sample size of your data set is key to the significance of your analysis (i.e., how likely it is that your observation is representative of the total population).

Many tests are not worth running, and you can save lots of time being realistic about when data may or may not hold the answers. Sites like test significance can help you determine how costly a given test might be and what it takes to reach significance.

Online Test Significance Tool

Online Test Significance Tool

 

4. Stopping at the Surface

Imagine that a company is studying which referral sources yield the most valuable customers. If they find that one source is superior, they have discovered a correlation between referral source and Customer Lifetime Value (CLV). However, this does not mean that referral source is causing CLV to be higher for those customers—all it means is that they are linked.

Unseen “lingering” variables could be the true reason for the correlation. Perhaps your online store is not well optimized for a female audience and the best-performing referral source is simply the one that refers you the highest percentage of male shoppers. In this case, blindly shifting all of your spend to that referral source could backfire if their demographics shift.

The smarter move would be to redesign your homepage, which would lift CLV across all channels. The only way to discover this opportunity, however, is to dig deeper within your data. Look at all of the characteristics of your customers – not just the ones tied directly to marketing spend – and you may discover far more meaningful metrics to act upon.

 

5. Modeling Growth Projections By Percentage

I worked in venture capital prior to starting RJMetrics, and I quickly learned that most company financial models (which forecast future growth) are exercises in fantasy. One of the main reasons is that so many models are driven by inputs like “percentage growth per month.” In these models, a slight change in that  parameter can be the difference between a billion-dollar company and a dud.

This blanket “percentage growth” methodology says nothing about what’s driving that growth or what such growth actually means in terms of the number of customers added, where they came from, and how they were monetized.

Rather than an exercise in fantasy, make it a model that demonstrates the fundamental economics of scaling your business. Build a “bottom-up” model by using more granular inputs that are specific to your business model. This will lead to a more productive conversation and help set you apart from the pack.

 

 

RJMetrics Winter 2013 Hackathon Results

After the last RJMetrics hackathon, I didn’t think our team could possibly cram more innovation into a 24-hour period.  They just did.

The Projects

Team members unveiled some amazing projects, including:

Spotlight search in our new dashboard UI to provide users with fast access to charts, dashboards, and trends.

Customizations to Zendesk to make our customer support exchanges more streamlined.

customized sales video generator to provide a personal touch to our sales prospects.

Shaun Presents His Video Generator

Shaun Presents His Video Generator

BallerBoard, a TV display engine that automatically shows stats from RJMetrics, Twitter, and other services in a format that’s easy on the eyes.

BallerBoard

An End-User Query Browser to allow advanced users to query their data warehouses directly using SQL syntax.

A deployment system for MySQL stored procedures, which will greatly increase the number of analyses we can run natively in MySQL.  Last Hackathon’s Median/Percentile feature will be deployed using this system.

A trend-line overlay system that will allow users to fit regression lines to their data and forecast future data points based on these models.

TrendLine

A system for self-auditing and approving RJMetrics Trend/Metric definitions through our UI.

A new concept and 3D rendering of a new RJMetrics conference booth.

Conf

An improved RJMetrics deployment system.  This is an extension of our new AWESOM-O deployment system and its client application Butters.

Drastic improvements to our physical office environment, including a new reception area and accent walls throughout the office.

Working Capybara integration tests to monitor our UI.

 

The Results

Francis “Buck” Ryan took the crown this time around for his work on trend-line overlays.    This was a suggestion that came directly from our feature request page.  Existing users can keep an eye out for it in the beta tests of our new dashboard UI.

Buck will enjoy the grand prize: $500 cash to be spent all in one night.

I can’t wait for Spring.

 

 

RJMetrics Round-Up (11/28/2012)

The hits keep coming at RJMetrics!  Here’s some of the recent progress we’ve made:

Product Updates:

  • Our new chart builder made its public debut. All users can now participate in beta testing this tool. Read more about it in our documentation.
  • We changed the font throughout our dashboard. Say hello to Proxima Nova.
  • We have expanded our time zone support. Charts with a time frame relative to “right now” will be calculated against your time zone, which administrative users can change in the settings page.
  • Email summaries now include a warning if they contain stale data – that is, data for a time period that RJMetrics has not finished calculating. These email summaries are automatically resent once that data is current.
  • Our “Cohort Analysis 101″ guide is now live at www.cohortanalysis.com.
  • We have increased the parallelization of many of our calculations, resulting in significant speed boosts.
  • We have updated our integration to support many of the improvements to the Google Analytics API recently – specifically allowing the visitors trend to be grouped across many more dimensions.
  • There are now fewer constraints on restriction sets for repeat event probability charts.
  • We’ve sped up the dashboard-wide “change all dates” tool.
  • We’ve sped up the auto-complete drop downs in the chart builder.
  • We made major improvements to file uploader, including auto-detection of the file structure for new uploads.
  • We have begun beta testing a data mapping tool that uses zipcode information as an input – stay tuned for more on this.
  • We finished production of the promotional video that was created at our last hackathon – it can be viewed at https://www.rjmetrics.com/index2

Company News:

  • Our CEO Robert J. Moore has been busy getting the word out:
  • We’re currently interviewing candidates from Drexel University’s Co-Op program for participating in next year’s RJMetrics co-op.

RJMetrics Fall 2012 Hackathon

This past weekend, we had one of the most successful events in our company’s history: 16 team members participated in a 24-hour Hackathon. With a massive trophy and a fancy steak dinner on the line, everybody came to win. 

The Rules

This was our first Hackathon, so we asked our friends at other startups about their own best practices. We settled on the rules below.

Logistics:

  • Everyone in the company is encouraged to participate, but it’s not mandatory for anyone.
  • All normal work except for time sensitive customer support should stop for participants.
  • The event kicks off at noon on Friday and ends with “pencils down” at noon sharp on Saturday. Demos and voting will immediately follow.
  • Hackathon projects can be literally anything related to the company in some way. Code, prose, images, audio, video, data analyses, web pages, physical objects and anything else are OK.
  • Participants can brainstorm ideas and form teams at any time between the announcement and the start of the Hackathon. The definitive teams need to be documented no later than one hour after the start of the Hackathon.
  • Teams can be any size with any mix of company role.
  • Normal testing/feedback/QA/review rules are not mandatory for work done during the Hackathon.
  • Hackathon projects might end up being re-written, changed, becoming a core part of what we do, or being completely discarded after the Hackathon.
  • Open source technology may be used as a component of your project.
Presentations and Voting:
  • Demos take place at the end. Each team gets up to 5 minutes for a demonstration and up to 5 minutes for questions. Presentation order will be randomly drawn.
  • Vote for the team that you feel generated the most value for RJMetrics during the time of the Hackathon. If most of the work was done ahead of time, but the final 5 percent was done during the Hackathon, they get 5 percent of the credit.
  • All Hackathon participants will cast votes in the style of instant runoff voting, but they cannot vote for their own team.
  • The winning team get their names on a trophy and a $300 gift card to Del Friscos. The trophy will circulate among the desks of the winners until the next Hackathon, á la the Stanley Cup.

Ample food was always in supply

The Projects

In the end, eight submissions were presented. Our customers should keep an eye out for some of these making their way into our product in the coming weeks.

Adding medians and percentiles to our dashboards: medians aren’t native functionality in most SQL languages, which required the implementation of special stored procedures to make them work.

Automated Training: a team used Kera.io to build interactive online tutorials in which new users can learn by manipulating their own dashboard environments.

Nate and Xiao hammering out the user community project

User Community: a tightly-integrated online community for user discussions and sharing best practices.

Responsive iPad UI: a new user interface for our dashboards that allows iPad users to have an even easier navigation experience in our product.

More Data Sources: integration with Zapier to allow us to easily connect with third party APIs like Shopify, Salesforce.com and Zendesk.

Sales Video: this sweet video was built using PowToon and VoiceBunny and may soon be appearing on an A/B test on our homepage.

New Logo: an impressive prototype for a new RJMetrics logo.

MySQL to MongoDB Query Translator: a tool to translate a traditional MySQL query into its eqivalent in MongoDB.

Red Bull gives Rohan wings

The Results

Our main conclusion from this event: Hackathons are awesome. The time flew by, we all had tons of fun and the output was extremely impressive. It reaffirmed to everyone that there really are no weak links on this team– everyone was a real competitor.

The crew enjoys the final presentations

The Query Translator and iPad UI teams took home first and second place, and both will be enjoying steaks at Del Frisco’s soon.

As for the rest of the crew, an anonymous follow-up survey revealed that over 90 percent of participants would be “extremely likely” to participate in another Hackathon. At this rate, our next one may be just around the corner.

RJMetrics Round-Up (10/02/2012)

September was a busy month for us here in the RJMetrics office. Take a look at what we’ve been up to:

Product Updates:

  • Work on the beta chart editor continues, including a new trend-selection screen during chart creation, better restriction sequence validation and many UI enhancements.
  • We’ve added support for up to 20 Google Analytics goals.
  • The current period can now be optionally included or excluded in a cohort chart via step 2 in the chart builder.
  • We fixed a bug that caused subscription trends from displaying properly in our trend editor.

Company News:

  •  We gave www.rjmetrics.com a facelift – check out some new pictures of our office and staff on the about us page.
  • Watch Bob speak in this interview from Start Up Philadelphia.
  • Our trip to Denver for the Shop.org exhibition was a great success. We loved meeting so many of our customers in person.

    Jake and Shaun, talking data.

    Shaun and Xiao set up the booth.

What’s Next:

  • We’re happy to announce the first ever RJMetrics internal Hackathon, which will take place Friday October 12 and Saturday October 13 as an all night event.

RJMetrics in Geckoboard

Today, we are proud to announce new, more comprehensive support for adding RJMetrics charts to your Geckoboard dashboards.  You can now add any RJMetrics chart to your Geckoboard using the RJMetrics “widget” that exists within their interface.

Using this widget, you can feature things like cohort analysis, repeat purchase probability, and advanced customer segments with just a few clicks.  This allows you to add new RJMetrics-powered charts to your Geckoboards like the ones shown below.

RJMetrics Line Chart in Geckoboard RJMetrics Bar Chart in Geckoboard

To use the widget, simply click “Add Widget” from any Geckoboard, select the RJMetrics widget from the “Sales and Finance” category, enter your RJMetrics API Key, and choose the chart you’d like to add.

For complete details on how to configure your API key to be compatible with Geckoboard, view the related article in our help center.

How to save acquisition data from Google Analytics in your database to create awesome marketing metrics

In this post we will explain how to save Google Analytics (GA) acquisition channel information into your own database – namely the sourcemediumtermcontentcampaign, and gclid parameters that were present on a user’s first visit to your website. For an explanation of these parameters, check out the Google Analytics documentation. Then, we will explore some of the powerful marketing analyses that can be performed with this information in RJMetrics.

Why?

If you’re just looking at the default Google Analytics conversion and acquisition metrics, you aren’t getting the whole picture. While seeing the number of conversions from organic search versus paid search is interesting, what can you do with that information? Should you spend more money on paid search? That depends on the value of customers coming from that channel, which is not something Google Analytics provides. [Note: Google Analytics eCommerce Tracking does mitigate this problem by storing transaction data in GA, but this solution doesn't work for non-eCommerce sites, and certain tools like cohort analysis are not easy to do in the GA interface].

What if you want to email a follow-up deal to all customers acquired from a certain e-mail campaign? Or integrate acquisition data with your CRM system? This is impossible in GA – in fact, it is against the Terms of Service for Google Analytics to store any data that identifies an individual.  But that doesn’t mean you can’t store this data yourself.

The Method

Google Analytics stores visitor referral information in a cookie called __utmz. After this cookie is set (by the Google Analytics tracking code), its contents will be sent with every subsequent request to your domain from that user. So in PHP, for example, you could check out the contents of $_COOKIE['__utmz'] and you would see a string that looks something like this:

100000000.12345678.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=rj metrics

There is clearly some acquisition source data encoded into the string, and I have done some testing to confirm that this is the visitor’s first acquisition source. Now we just need to know how to extract the data. Luckily, Justin Cutroni has previously described how this encoding works, and shared some javascript code to extract the key bits of information.

We took this code and translated it into a PHP library hosted on github.   To use the library, include a reference to ReferralGrabber.php and then call

$data = ReferralGrabber::parseGoogleCookie($_COOKIE['__utmz']);

The returned $data array will be a map of the keys source, medium, term, content, campaign, gclid and their respective values.

We recommend adding a new table to your database called, for example, user_referral, with the columns like: id INT PRIMARY KEY, user_id INT NOT NULL, source VARCHAR(255), medium VARCHAR(255), term VARCHAR(255), content VARCHAR(255), campaign VARCHAR(255), gclid VARCHAR(255). Whenever a user signs up, grab the referral information and store it to this table.

How to use this data

Now that we’re saving user acquisition source, how can we use it?

Lets suppose we are using a SQL database and have a users table with the following structure:

id email join_date acq_source acq_medium
1 john@abc.com 2012-01-24 google organic
2 jim@abc.com 2012-01-24 google cpc
3 joe@def.com 2012-01-25 direct -
4 jess@ghi.com 2012-01-26 referral techcrunch.com
5 jen@ghi.net 2012-01-30 other organic

For starters, we can count the number of users coming from each referral channel by running the following query against your database:

SELECT acq_source, COUNT(id) as user_count FROM users GROUP BY acq_source;

The result will look something like this:

acq_source user_count
google 294
direct 156
referral 55
other 16

This is interesting, but of limited use. What we would really like to know is the growth rate of these numbers over time, the amount of revenue generated by each acquisition source, a cohort analysis of users coming from each source, and the probability that a user from one of these channels will return as a customer in the future. The queries required to do these analyses are complex – which is why we built RJMetrics. Armed with this information we can determine our most profitable acquisition channels and focus our marketing time and money accordingly.

My colleague Xiao has also written a blog post detailing how to generate these and other useful marketing analyses using RJMetrics for you to check out.

RJMetrics Round-Up (5/29/2012)

To wrap up May, here’s a quick run-down of what’s been going on in our office:

Product Updates:

  • We’re in the middle of rolling out the new charting library
    on a client-by-client basis. Roughly 40% of our clients have received these updates, and we’re upgrading more clients every day.

Company News:

  • We were featured in this past Sunday’s issue of the New York Times. Read all about it here.
  • Last Monday, Bob presented at a Business Data Tech Meetup in NYC. Coverage of the event can be found here.
  • We’re happy to welcome new engineer Rohan Shah, and designer Zach Kozak, who both start the first week of June. New analyst Sharon pan will become a part of our team in July, as will engineer Nate Vecchiarelli.

What’s Next:

  • Our five undergrad interns arrive next Monday, to begin a long and productive summer internship.
  • If you’ll be in Chicago, come out and see Jake, Shaun, Xiao and Ted at the IRCE on June 5-7. Info on the conference can be found here.
  • Jake is giving an insparq webinar on wednesday.

Check back in two weeks for more RJMetrics news and updates.

Lessons learned in error tracking

Here at RJMetrics we pride ourselves on providing one of the leading hosted solutions in business analytics. One of our product’s highlights is the ability to replicate and warehouse client’s data in our data servers. Replication is not an easy task. It is driven by a set of very complex algorithms spanning across a number of different modules. Such algorithms are prone to latent bugs and vulnerabilities. They are hidden away in edge cases, just waiting for the right time to reveal themselves.

Why logging is not enough

No matter how good of a developer you are, bugs are inevitable and the best way to deal with them is to always expect them. That is why every good software engineer should always provide some means of error tracking. Traditionally this is achieved through logging, also known as tracing. Logging has the benefit of allowing the development team to go back at any given time and trace back the exact code path an operation took.

Logging is not a silver bullet though, and for it to be useful an alert system has to be in place to make it obvious to the development team that something is wrong and someone has to attend to it. Without a good reporting mechanism, bugs in fundamental areas of the system are never discovered and resolved, and any further enhancements to it are made on the false assumption that the core of the system is reliable.

The problem with email alerts

Usually development teams handle error reporting by injecting email alerts whenever an exception is caught. These emails often go to a single recipient, or to a mailing list. The problem with email alerts going to a single person is simply NO transparency. The rest of the team will have no clue about these issues unless they are forwarded/delegated to the rest of the team.

Email alerts are not any more useful if they are sent to a set of developers because it provides no accountability. Everyone in that mailing list will just expect everyone else to attend to them. Furthermore such email alerts will eventually get lost in someone’s inbox with no good way of going back to them or tracking them.

Our take on error reporting

The same exact scenario was playing when I first started working here. One of the first assignments I was tasked with was to replace all of the annoying, at best, emails with a much better system that would allow us to be more aggressive and proactive in resolving bugs. The initial solution was:

1. Provide a web interface through which at any time we could see any errors that occurred in the replication process

2. The interface would include detailed information along with a full stack trace, exception messages, as well as the frequency at which an issue has been happening

3. Reporting would occur for every distinct combination of replication job type and construct.

You might rightfully say, “how was that a better solution than emailing everyone in the team!”. It wasn’t much different, but it allowed us to make our error reporting even more useful by just taking small incremental steps with no significant effort from our development team.

Our next step was to dedicate one person in every sprint cycle to attend to all the issues being reported, and to make sure that any false positives are filtered out and any critical issues are resolved. This was obviously already working much better that the email alert system but it was still not providing enough transparency to the rest of the team. Unless we all took the time to check, we wouldn’t know how many errors got generated and how many of them got resolved.

The solution was to integrate our error tracking and reporting mechanism with fogbugz. New tickets get created when replication job errors occur, and they are handled just like any other high priority tickets in our sprint. We can now track replication job errors through our familiar ticket tracking system and even get to use our own product to make a more intelligent analysis of bugs in our system.

Conclusion

In just a few sprint cycles we were able to bring down the number of replication job errors from affecting around 20 clients close to none at any given time. We were able to uncover and resolve some really obscure bugs and we can now be confident that when something goes wrong we will be addressing it at a timely manner and before it affects any of our clients.

Data Driven Hiring: Hiring an Assistant

As a start-up focused on capital efficiency, the idea of an assistant always seemed frivolous. After all, what self-respecting entrepreneurs can’t answer their own phones?

As we recently learned, that strategy is all well and good until the phones really start ringing. Or your staff grows large enough that you have to choose between keeping the kitchen stocked or doing code reviews. For us, it was finally time to hire some help– two weeks ago we posted a job opening for an Administrative Assistant.

As everyone knows, the job market is not great right now. The day we posted the Administrative Assistant job, we got close to 100 applicants. The number grew to 200 by the end of that week.

With our time more precious than ever and (obviously) no administrative support to manage the process, we were at risk of burning far too much time choosing an applicant. But that’s not our style. We hired the most outstanding candidate with under 8 hours of total work. Here’s how.

From 200 to 100: WMYU?

At the beginning of every job application, we make a simple request: “In 150 characters or less, tell us what makes you unique.” We got this idea from The Resumator, which is the awesome system we use to track applicants. The “WMYU” question is a great opportunity for the applicant to showcase their personality. It also turned out to be a great way to rapidly filter out unqualified candidates.

Don’t get the wrong idea — no one was rejected based on what they said. It was how they said it that caught our eye. As it turned out, half of our applicants could not provide a single-sentence answer without also including a grammar, spelling, or punctuation mistake. For a job where the top requirement was “excellent written communication skills,” this kind of mistake was a deal-breaker. (Note: we happily allowed Twitter-like abbreviations and other understandable/creative quirks.)

Some of the more ridiculous responses are shared below to give you a sense of what we were dealing with…

The triple threat: spelling mistake, capitalization mistake, incomplete sentence.


Furthermore, if you paste into a 150-character box it will cut off your answer.


Computer illiteracy wasn’t one of the job requirements.


Multiple people did this. If uniqueness is not applicable to you, you’re going to be looking for a job for a while.

From 100 to 50: Cover Letters

All applicants were required to submit a cover letter as part of their application. These letters gave us a good sense of the long-form writing skills possessed by the remaining applicants. Again, writing letters and e-mails is a major piece of this job, so any glaring mistakes were grounds for elimination.

Here again, it was much more about the quality of the writing than the actual content of the message.

From 50 to 25: Resumes

At this point, the experience and other qualifications of the applicant started coming into play. This is where we stopped looking for reasons to reject and started looking for good applicants to move forward. Ambition, education, experience, and an interest in technology made 25 applicants stand out from the rest.

From 25 to 12: Project Completion

At this point, every single applicant was perfect on paper: outstanding qualifications, impeccable writing skills, and a genuine interest in the job. So, now what? Interviewing all 25 of them would have been overwhelming. We needed to get creative.

So, we decided to test who was really willing to go the extra mile. I sent a bulk bcc e-mail to the 25 remaining applicants.

The e-mail began with key information about the job: salary, benefits, working hours, vacation policy, etc.

Next, it asked them to complete a special project as soon as possible. Applicants were asked to reply to the e-mail and attach a ZIP file that contained two PDFs: a writing sample and a set of e-mail templates that we could use in response to specific situations. These situations ranged from simple (scheduling a call) to more complex (dealing with a dissatisfied customer).

My e-mail ended with this paragraph: “Once you have replied to this e-mail with the ZIP file attached, please call my cell phone and leave me a short voicemail to let me know that the e-mail has been sent and explaining why you feel RJMetrics is a good fit for you. I have intentionally not included my cell phone number here. Someone as resourceful as you should be able to track it down easily (hint: it starts with 856).”

This e-mail accomplished many things at once:

  • It ensured that any applicant choosing to move forward was comfortable with the exact compensation and expectations of the job. This would save us from negotiations, confusion, or other time-consuming hiring issues later.
  • It served as a further test of the applicant’s writing skills.
  • It tested the basic technical competency of the applicant (creating PDFs, creating ZIP files).
  • It provided us with a voice recording of each applicant to test their verbal communication skills.
  • It assessed their willingness to be creative and conduct online research to track down information (in case you’re wondering how hard that was, googling “robert moore rjmetrics 856” reveals my phone number in about a dozen places).

Only about half of the applicants completed the project.

From 12 to 6: Project Results

The results of the project were extremely telling. We could immediately identify the applicants who knew how to follow instructions, had good insights and written tact, and were excited about this specific job for reasons that made them likely to thrive here.

Half of the responses stood out as both flawless and indicative of a good fit.

From 6 to 2: Phone Interviews

At this point, conducting 30-minute phone interviews was a practical thing to do. We spoke to each of the remaining applicants about their specific experience, their interest in our company and the space in which we operate, and their interest in the job.

To be honest, all of these applicants were outstandingly qualified and any one of them would have done a great job. At this point, it was about their ability to contribute to our specific company’s unique needs and their likelihood to come in every day and enjoy the work they were doing and the people they were doing it with.

Jake and I each spoke with 3 applicants and selected one each to make it to the next round.

From 2 to 1: In-Person Interviews

We brought the two top applicants into our office to meet us face-to-face. They were obviously both exceptionally well qualified, which left us with a very difficult decision to make. After some thoughtful analysis, we made our final decision and our applicant accepted the offer on the spot.

Conclusion

For anyone out there applying for a job in this environment, please keep in mind that every little detail of your application may be scrutinized, and employers may be on the lookout for reasons to reject you before they start looking for reasons to hire you.

For those out there looking to make a hire in this environment, you are in the fortunate position of having many options. Don’t get intimidated by them– if you employ a disciplined approach to narrowing the field, you will end up feeling good about having made the right hire.