The way you manage your Boolean queries differs from tool to tool. Some tools let you build queries that you can file in folders, like Sprinklr with its topics and topics groups; other tools let you build queries and subqueries, as a way to categorise your search – so for a query looking into Apple products, you may have a subquery for each Apple product (tools like Synthesio support that functionality).

Brandwatch handles queries differently, letting you set various filters (tags and categories) and rules around them to “supercharge” your dashboards.

The problem that plagues all of these tools, however, is that as time passes you end up with so many overlapping queries: you may find two or more queries covering the same topic (thus retrieving the same mentions), or multiple duplicate queries. The likelihood of this happening will only increase as you start sharing the platform with more users.

So, how do you manage queries to make sure that your social listening platform doesn’t get too unwieldy and cluttered with queries? I’ve seen a lot of social analysts use different ways to manage queries, but I’ve settled with one method that works best with me: using a catch-all query.

What’s a Catch-All Query?

Instead of setting up different queries for different aspects of your brand, the catch-all query works as your “master query” that catches all these mentions. This query consolidates all the other queries that pull any mentions about your brand, making sure that you don’t have any duplicate mentions.

This catch-all query pulls in any mentions of anything related to your brand, including:

  • brand names: the full brand name, any variations of it (used by yourselves and by consumers), and trading name. For example, brand names for include “British Telecommunications” OR “British Telecoms” (full name), “BT” (variations used by the brand as well as its consumers), and “BT Group PLC” OR “BT-A.L” (trading name).
  • brand products: any products owned by you, both current and discontinued. You may choose to add any mentions of future products you know are going to be released, but remember you’re sharing this query with other people who may not know this info, or may not have signed an NDA for it.
  • brand services: any services you provide, including customer services, consultations etc.
  • brand properties: any mascots, buildings and other properties owned by your brand, e.g. in this case British Telecom may want to track mentions of their iconic BT Tower, including . Online properties are part of this too, so include any website(s) and other digital estates owned by your brand (e.g. apps).
  • brand social accounts: usernames of all your social accounts.
  • brand people: names of people in your C-suite (CEO, CMO, CTO, CXO and the rest), as well as any influential people working for the company or related to it. For instance, a catch-all query for Microsoft would definitely include (CEO), as well as and only when mentioned in the context of Microsoft. Provided your tool supports proximity operators, you would end up with this as part of your query: 
"Satya Nadella" 
OR (("Bill Gates" OR "Steve Ballmer") 
NEAR/10 Microsoft

Add anything else that may be relevant and related to your brand, including things that people mention in that context.

Managing the Catch-All Query

One of the benefits of having a catch-all query is that you don’t have to fiddle with so many queries just to get by: you know that all mentions about anything brand-related are pulled by this one query, so you don’t have to wonder which query to edit, and you only need to make one change once.

For this method to work you need to have a few rules in place:

  1. Update: this catch-all query must always be up to date. If anything new happens with your brand (e.g. a new CEO, a new product release), you need to add the relevant keywords to the query. By doing so, you know that dashboards built on top of this query are always current. Related to this, make sure you also review the query from time to time, to make sure that it’s still working for you, and to make sure that it’s not pulling in any unwanted mentions.
  2. Ownership: whoever creates the catch-all query is officially the owner of the query. However, ownership goes beyond being the one who created the query: you’re also responsible for its maintenance. Feel free to share this responsibility with others, but don’t spread this responsibility too thinly: the people who can edit this query need to be well versed in the tool, knowing how to update the query without breaking its logic. Also, when it comes to giving someone admin access to this query, remember they may be able to delete the query too, so choose wisely.

    A few tools out there, like Brandwatch, will let you “lock” queries, so you can rest assured that only authorised people can make changes to the query. When a query is locked, only admins can make any changes to that query, and as you wouldn’t give admin permissions to anyone left and right, it’s one way to prevent any unwanted changes to this query.

  3. Audit: this master query may end up powering the majority of your dashboards, so you need to make sure that you keep an eye on any changes made to it. Depending on which tool you’re using, you may or may not be able to do full audits (e.g. seeing the full list of who edited what and when). Auditing this query also means making sure that the query isn’t pulling more mentions than you can afford based on your allowance (not to worry about if you have unlimited mentions).
  4. Visibility: changes you make to this query can have a big impact on other people’s dashboards. Bear in mind that people might have dashboards they rely on for their reporting, some might get their performance scores, baselines and KPIs from these dashboards. What may appear as a small change to you could dramatically change these metrics for them. Send out an email to let your other team members know that you’ve updated the catch-all query, and how you’ve updated it: that will assure them that the query and dashboards that feed from it are always up-to-date. Even though the rest of your team won’t be able to make changes to the query, have workflows in place that let these team members suggest addition for other changes to the query.

Before You Replace Your Old Queries

Using this method could dramatically change the way you manage your queries for the better. What about all the queries that may be replaced by this catch-all query? Before you go ahead and delete them, make sure you store them somewhere safe. I’ve used repositories in the past to save all my queries, and I still do.

Here are some of the tools I recommend:

  • Evernote (Windows, Mac): create a notebook to save all queries, and tag them based on their purpose so you can easily access them later.
  • OneNote (Windows, Mac): similarly to Evernote, create a notebook to save all your queries.
  • Snippets Lab (Mac): an easy-to-use repository for queries. This tool lets you add your own notes too throughout the query, a great way to explain the logic behind how you’ve built the query (especially if you’ll need to refer to it later on).
  • Quiver (Mac): heavyweight code repository, which lets you mix queries and notes too. A trial is available for this too, if you want to test it before purchasing.
  • Brackets (Windows, Mac): an open-source code editor where you can write up your queries.

I currently use a combination of Brackets and Dropbox, both of which I can use on my personal laptop (Mac) as well as my work laptop (Windows): I write my queries in Brackets, and save them all in their dedicated folder in Dropbox. I can always see these in Brackets, where I can always see queries side by side (to track changes or just make comparisons) and work on them, while knowing that any changes are saved immediately to Dropbox (cloud FTW!).