Editor's Note: Originally published in spring 2017, this post still gets a lot of attention—and answers a lot of common questions. Give it another look as you prepare for your next review.
No one likes to start the day with a frantic email: a search won’t run or isn’t providing the expected results, and because you’re trying to complete a review project on a tight deadline, you have no choice but to fire off a panicked request for help to your litigation support team. But you don’t have to find yourself trapped in this position. A bit of better search hygiene can make all the difference.
There are many tools available to help you create accurate and healthy searches. Check out these most common searching snafus and their best methods of prevention to accelerate your review.
1. Confusing Static and Dynamic Searches: “What am I even looking at?”
Your search results keep changing. What you saw yesterday doesn’t match what’s coming up today, but you need to pick up where you left off and focus on a particular subset of documents. You want to look at documents marked as responsive to perform quality control on the first set of outgoing documents in a rolling production. However, review is ongoing and the data set is constantly changing.
This is where the difference between dynamic and static searching comes into play. The former incorporates new results as data changes in your workspace; the latter provides results from a particular point in time, independent of what else is happening in the data set.
How to Build a Better Search: For a search to stay static, it’s best to use mass edits to tag the documents with a unique field—one that isn’t going to be edited in the normal course of review. In the case of a production QC, you might call it “Production Number 1.” This provides a snapshot of things at that moment in time, which can be referenced without the results changing. Learn how to do this here.
2. Abusing Search Operators: “OMG, this is like so cool to use this operator.”
For decades we’ve heard the incorrect and overuse of the word “like,” and the trend of overusing “like” or “is like” operators happens when searching as well. Your review team will probably be advised not to use “is like” as a search operator because it’s not efficient. It may time out before returning results, and similar to its overuse in the movie Clueless, “like” should be avoided as much as possible.
How to Build a Better Search: There are times it’s unavoidable and you will need to use a “like” operator, so don’t hesitate to work with your litigation support team to find the best way to do it. But first, you can often try alternatives such as “contains” or “is” operators, depending on your goals. Give it a go and see what you get. Operators will vary depending on which type of search you’re performing, so check out documentation to get started.
3. Searching for “Stop” Words and Characters: “I can search for it. No really, I want to search for ‘it.’”
The most problematic terms to search for are ubiquitous words such as “it.” Are you searching for references to an IT department? If you are a Relativity user, you probably know that “it” is, by default, a “stop” word. Searching for “IT” means you must update your search index to include “it.” However, simply searching for the term by itself would be too broad. By using a proximity search—which will search documents for instances where two or more words are used together—to find “IT” used in conjunction with “department,” you can avoid excessive false positives.
How to Build a Better Search: If a stop word is on your search list, come up with creative angles that can help narrow your results. A proximity search is just one example. For instance, you can use analytics to perform keyword expansion, which will help you identify related terms within your data set.
4. Building Nests Within Nests: “Too much nesting and you’ll want to fly the coop.”
While it can be helpful to apply saved searches as conditions in other searches (the purpose of nesting), you may want to keep it limited and keep it simple. Ever navigated a saved search that has multiple nested saved searches which have their own nested searches? Ever find that some of the searches reference the same searches? When results don’t appear as expected in a hyper-nested search like that, it can be too tangled of a web for your litigation support professional to help you unwind.
How to Build a Better Search: This is another instance where doing some tagging can save you time, headache, and hassle. Use mass actions to tag all the documents in a saved search you need to reference, and then create a new search incorporating that tag instead of nesting the original search. Voila!
5. Improper Search Structure: “Syntax, schmyntax—it’s all the same, right?”
“Why isn’t oil w/10 gas hitting on any documents? I know these terms exist together in the data set!” In cases like this, upon troubleshooting your search, your litigation support team might find that you were simply using the wrong type of index for a proximity search—a keyword search won’t understand a proximity query, but a dtSearch will. Understanding the syntax you can or cannot use with a specific index or even in a specific review tool is key in creating accurate searches.
How to Build a Better Search: Having several searching options—such as dtSearch, Lucene, and keyword indexes—means you can accomplish more with your queries, but you need to know which one is ideal for each scenario. Fortunately, this is easy. Just keep a quick reference on hand so you can verify you’re using the right index while you’re searching through a data set. Here’s one for Relativity.
Many attorneys and lit support pros have made these mistakes at least once—encountering and overcoming them is part of the e-discovery learning process. Keep these tips in mind and ask your review manager for reference materials, guides, and best practices to keep improving.
You can also get ahead of the game by pursing your own training on healthy search habits and how to avoid trouble. Get started here.
