MetaLocator is commonly used for dealer locators, store locators and other scenarios where we find the following requirements:

Additionally, our customers may have multiple countries, teams, languages and other requirements.

This guide describes the best practices in data and category management, account setup and content management in MetaLocator for the above use cases. This guide will start with a simple locator and grow more complex as needs expand. Hopefully this will provide a roadmap to scaling data into multiple brands with potentially complex product lines delivered across multiple websites, countries and languages.

In this example, we will consider a common scenario where we have a single locator to build for one brand which sells outdoor equipment. Some locations sell camping equipment, others sell hiking and still others sell bicycles. The data is quite straightforward and appears as shown below. (Download)

Here we have one location for each row and the products offered by each location are provided in the Category1, 2 and 3 columns. When importing this file, we can simply leave the mapping options at the defaults.

This solution is pretty straightforward and requires minimal configuration. Notice above the category drop-down displays all of the categories in the system and the Interface displays all 12 locations and all of the categories at each location.

We will expand on the above scenario by briefly introducing category grouping. In the above, we have a list of products for each location. In this example, we will introduce a second drop-down for services available at each location, allowing the user to then search for products and services.

Our data file will change a bit in that we will designate the products and services as categories, and the headings will change to indicate the category group name as shown below. (Download)

During data import, since our category headings are now group names, we'll need to specify that these are categories by mapping each column to a sequential category column as shown below:

After importing the categories will be created as follows:

Category group names are only assigned when the category is first created, so if you have been following this tutorial, your Water, Run, Hike and other Products categories likely do not have a group name as shown above. To quickly remedy that, set the group name using the Bulk Actions menu as shown

Enter "Products" in the subsequent text box to set the category group name in bulk.

The interface, with no changes, will display as shown:
​

We can also adjust the Category "Show As" setting to create a dynamic set of drop-downs, one for each category group, as shown below.

Consider that the above solution is deployed on our outdoor brand Website and is working well. We would now like to introduce another locator for a different brand without disturbing this locator. We will consider that some locations may be shared between these brands, but we do not want the products and services for "Brand A" to be displayed in the "Brand B" locator.

We'll expand on our outdoor equipment example and consider Brand B as a coatings company that seals outdoor equipment like campers, boats and RVs against water, snow and the elements in general.

The data will be organized so we can see examples of where the locations between Brand A and B overlap, and where they do not. In Brand A, we have category groups Products & Services. In Brand B, we will still have Products, but instead of services we'll introduce an "Application" category group for Commercial v.s. Residential applications of the coatings products.

We've expanded our data set a bit to show how the category data is represented across multiple brands. (Download)

During import, we will again map the products, services and applications columns to Category columns, resulting in the following category layout:

Now, we want to ensure that our Brand A locator doesn't show the new categories under "Application", but also the "Super Seal" and "Water Zip" categories under the "Products" category group.

We will separate our categories by designating a Category Segment for each Brand. As shown below we have selected the Brand B options and will enter "Brand B" on the subsequent screen, shown after making the below selections and clicking "Go".

The desired result is as shown:

Now, to filter our Interface to show only Brand A categories, we will designate the Category Segment as shown below.

This setting will cause our search options to be limited to only Brand A categories and will also limit the results to displaying only Brand A categories. We will save and close this Brand A interface now that it is limited to only Brand A.

To create another locator for Brand B, let's first duplicate the interface above so we have two identical locators in our account, and we'll name them Brand A and Brand B.

Now we can modify the Brand B interface by setting the Category Segment to Brand B as shown below. Notice that the Products and Services drop-downs now show as Application and Products.

So far in this tutorial we have focused on filtering the Categories so that the search options can be controlled independently between Interfaces. In the Brand A and Brand B interfaces above we are showing each location including those locations in the Brand A locator that only stock Brand B. In many cases this isn't desirable. We want to have a data setup that allows us to easily control which locations appear in which locator while allowing for:

To meet all of the above criteria, particularly items 4, 5 and 6, we'll need to introduce a filter aside from categories that will allow us to quickly select the locations that should appear in a given locator. For this will we will use a custom field called Brands. (Download)

Notice that we have a few records that overlap and that include Brand A and Brand B. We also have one location in each brand that has no categories.

During import of the above, you can allow the import system to create a custom field on the fly called Brands:

Map the Products, Services and Application drop-downs as categories as in the above examples.

Now we can limit the locations in a given locator to only those locations attributable to a specific Brand by using the Field Filter option. We select Brands from the list of fields and then choose "contains" and then Brand A as shown below. We use Contains here because we're supporting the case where a given location may carry Brand A and Brand B.

You may notice a few records above with both Brand A and Brand B in the Brands column. This avoids the duplication of locations that support both brands. However, it can introduce a complexity if you receive data updates on a per-brand basis, which can be common in our industry. E.g. you receive a list of locations in Brand A with no indication of what overlap with your other brands B, C and D may occur in the Brand column.

If your data comes from multiple sources or is updated asynchronously, allowing duplication in the data isn't necessarily contrary to best practice. Duplicating locations so that you have a single row and unique key for Brand A and another for Brand B, where the address is the same, but it avoids the "Brand A, Brand B" type composite rows, allows you to more readily update data for a single brand without affecting others.

At this point it is worth mentioning that MetaLocator Teams also provides this level of brand isolation without introducing a custom field to manage brand. MetaLocator Teams is designed to address that scenario, but it requires an Enterprise agreement. In Teams, the Brand would be represented by a user group, which would automatically filter the categories, avoid duplicated locations and satisfy the other criteria above.

This example illustrated two brands operating in the same account, appropriately sharing locations where logical yet still allowing brand autonomy. Let's consider how this approach can scale at 20 brands, or 200.

One of the first issues to arise is managing hundreds of Interfaces. It is quite reasonable to manage 10 or 20 Interfaces, however; we commonly see implementations where the only variable to change from Interface to interface is one or more of the following:

In some cases we can instead leverage MetaLocator's dynamic parameterization features to pass in the above choices at run-time. See this article for examples of each. Leveraging the dynamic parameterization avoids the situation where an account has 20 or more interfaces and a simple change in requirements means an administrator must manually modify each interface.

This article has discussed the setup considerations of importing data and creating categories. However, we have not yet considered the steady-state of managing data, performing regular updates and the following use cases:

Since we have multiple brands, one of the first tasks is to designate the Brand column as an Admin Filter.

The Admin Filter designation allows us to easily search and sort data under Data > All Records by Brand.

Another critical aspect is to implement an External Key. External Keys are essential for uniquely identifying locations in MetaLocator during import, especially when other elements like addresses, names and phone numbers are constantly changing. For the bi-directional sync options used below we have introduced a per-location key column as shown. This key will not change during address, name and other field updates ensuring MetaLocator can unambiguously identify matches between incoming data and existing data. This value commonly comes from whatever system this data is originating.

To update data in the presence of a unique key the following options should be selected.

Be sure that the data file is complete in this scenario and contains a comprehensive update for all brands, all countries and comes in a single data feed.

If you are performing updates for a single Brand you can also leverage this option to limit bi-directional deletions to the Brand currently being imported:

When multiple brands share locations as described above, sometimes the sources of that data can vary, meaning one data feed may come from Brand A and another from Brand B and consolidating those data feeds can become an error-prone chore especially when considering overlap. Considering also when the administrative personnel may vary by Brand or country and managing those data feeds can become untenable.

MetaLocator Teams was introduced to solve this problem. MetaLocator Teams is an add-on available for Enterprise customers. It effectively allows brands to operate in an isolated environment while still allowing location records to be represented in multiple brands without duplication.

Following with our existing example, in MetaLocator Teams, Brand A and Brand B would be represented as user groups. Where certain locations would be in the Brand A group and the Brand B group. Contact your account representative to learn more about Teams. Additionally see the user guide here.