Structuring Your Knowledge Graph

My name is Jessie and here at Yext I am one of our Yext Administrators. As a Yext Administrator I build and structure Knowledge Graphs for brands across different industries, sizes, geographies, and more. This requires me to set goals, build a structure, and think creatively and strategically based on each organization's requirements and KPIs.

In this post we are going to discuss strategy and give you some tools to effectively think about structuring your own brand's Knowledge Graph!

The backbone of the Yext Search Experience Cloud is the structured data that makes up the Knowledge Graph. This is the hub for all the facts about a brand and is stored in the format of an "Entity".

In its simplest form, an Entity is a collection of related data points that allow us to store structured data. An entity can represent physical things like Locations, Professionals, Financial Advisors, Doctors, Hospitals, Events, Products, etc.. They can also represent conceptual things such as Job Postings, FAQs, Services and more! Entities are the foundational building blocks of your Knowledge Graph and your brand's structured data.

Each Entity has its own relevant facts and data points that make it unique. Let's consider the example of a Location, Job and Product Entity. Each of these might host different data points and information in comparison to the other. Here are just a few facts and data points that may be relevant to each entity:

The Entity is very flexible — you can use one of Yext's built-in Entity types, or create your own by combining together the relevant fields (including custom fields)! Entities are designed to give you the flexibility you need to make your brand successful. You have complete control of their name, definition and use.

But how do you know which Entities you should include in your Knowledge Graph? How do you begin building the foundational data upon which all of your customer experiences will rest? I'm not sure where to start!

Don't worry - we got you.

To get started, you need to decide which types of Entities will comprise your Knowledge Graph. To do this, you should think about the following things:

1. Think about your ultimate goals and work backwards. It's often helpful to do a working session and draw your ultimate goals back to the solution you want to create. For example, imagine you are a financial services business, and your ultimate goal is to drive lead generation up by 2x. To expand your existing funnel, you want to capture more unbranded intent around common customer questions. This is a perfect use case for FAQ pages, and therefore you will need FAQ entities. Or instead imagine you are a brand new medical technology company that is about to launch a new website, a new product, and is looking for investors. Your goals are two-fold - 1) consolidate information for investors to feel comfortable partnering with you, and 2) gain a better understanding of your end-user (investor or customer) based on their online journey. This is the perfect use case for an Answers experience that includes information on FAQs, products, and the leadership team.

2. Consider all the Yext products you aim to implement. You want to keep in mind which Yext products you are ultimately looking to implement. This will inform whether you utilize built-in Entity Types or Custom Entity Types. Have you purchased Listings? Pages? Answers? If so, there are some considerations you'll need to take into account.

• Listings: Yext has pre-built entity types that are purposefully built to sync information out to Yext's Listings Publisher Network. If you are looking to sync data to 3rd-party services you should plan to take advantage of those types such as: Locations, ATMs, Healthcare Professionals & Healthcare Facilities.

• Answers: Answers can accommodate any sort of Entity Type, so there is a lot of room to be creative here! With Answers specifically, you should think through the lens of conversions (what types of entities will drive conversions) and user intent (what are users normally looking for on your website). Most Answers experiences will include FAQs at a minimum. The FAQ is a very flexible Entity type that can answer a wide breadth of questions. Including FAQs is also a great way to answer consumer questions on your website, and mitigate expensive support calls! Beyond that, it is often illuminating to look at your company website. The navigation items in your header are often indicative of where you normally drive your users, and can be a good place to start when considering Entity Types.

Pro Tip: You can always start small, and launch with fewer Entity Types, then leverage real user data post-launch to determine what Entity Types might be valuable to add.

3. Be forward thinking. Do you eventually want to launch your Loan Officers on listings? If yes, you should utilize the standard location entity type or any of the relevant built-in Entity types that can accommodate Listings functionality. Are you thinking about adding Answers or Pages in addition to your current Listings Solution? Perhaps you want to think about incorporating custom information that doesn't necessarily sync out to our Listings Publisher network, but would be great to include for landing pages or Answers searchability!

4. Consider entity relationships & how you may want to leverage them. The Knowledge Graph is a brain-like database that has the ability to relate different Entities together. These relationships are built via Custom Field linkages and are most applicable for simply organizing your data (think — relating a loan officer to the specific branch they work at) and leveraging them in Answers search results!

5. Extra Credit! Consider Automation Opportunities. If the data you are inputting into the Knowledge Graph is changing all the time, consider establishing some sort of integration with your source of your truth for ease of maintenance in the future. Learn more about our APIs and integration basics in the Introduction to APIs module.

Once you've finalized the Entity Types you want to include in your Knowledge Graph, you're ready to start building. Wahoo!

6. Enabling Built-in Entity Types. As a reminder, if you're using any of the built-in Entity types that aren't the default type within your account, you'll need to go into Account Settings and enable those types. These should be used as the default unless you have a specific use case that requires a custom type. Only these Entity types have the ability to sync information to our Publisher network.

7. Building Custom Entity Types. First things first, remember you CANNOT sync information to our Listings Publisher network via Custom Entity Types (CETs). Common use cases for CETs include brands that are taking advantage of Answers or Pages, or brands that are looking to store information and use the Knowledge Graph as their central database. When you create a Custom Entity Type, the only fields that are automatically included are the "Name", "Entity ID", "Label", and "Folder" — beyond that, the world is your oyster!

• Utilizing built-in fields vs custom fields. The fields in Yext are categorized similarly to the Entity Types — there are built-in fields associated with all built in Entity Types, or you can create a Custom Field if none of the built-in fields serve your project needs. As a rule of thumb, use built-in fields wherever possible. This reduces redundancy and limits the number of superfluous custom fields.

Pro Tip: Custom Fields can be used across multiple Entity Types, so it's smart to name them generically in case there is a future use case that can expand to another Entity Type.

• [Answers Only] Consider Backend & Frontend when building CETs:** If you'd like to feature any sort of description or photo on the frontend of Answers with this entity, those are easy fields to start with. You'll also want to incorporate 2 Call to Action fields which will eventually be leveraged as the calls-to-action within Answers. You should also consider what sort of fields or data you might want to index on the backend — for example, if you have a Product Entity you might want to include "Brands" as a field, so end users can query specific product brands and see relevant results.

8. Now that you've built your Knowledge Graph, think about new & cool ways you can use your structured data. For example, if you have always wanted a ChatBot feature on your site, consider perusing our App Directory for all our ChatBot partners. Perhaps your Event management software right now does not have a friendly user interface, and the information would be better managed from Yext and pulled into your internal software using an API.

For all information related to our APIs & App Directory Partners, check out developer.yext.com and apps.yext.com!

Keeping all this in mind, remember that you don't have to lay out elaborate blueprints and build everything in its entirety from the get-go. Here at Yext we believe strongly in the power of iterative development and incremental building - start off with a few critical elements and add on as you go.

When it comes to building your Knowledge Graph this is just the tip of the iceberg! These are just a few of the things I think about when structuring a Knowledge Graph for a brand, but everyone has their own goals, necessities, and style. To get a full training on how to structure a Knowledge Graph, check out the Knowledge Graph track and earn your badge!