Listings Accuracy | Yext Hitchhikers Platform

Yext Listings syncs facts about your business to 200+ publishers in our Publisher Network . This presents the common questions like “how can I check if my listings are actually accurate?” or “which listings need my attention?”. Up until now, the only way to understand if a given publisher listing is reflective of your data in the platform was to visit the listing on the publisher site and manually review each field. As you can imagine, tracking this at scale was not realistic.

In an effort to promote maximum transparency of the Listings product, we have built a new system known as the Verifier that is able to determine the accuracy of listings. The Verifier determines if data in the platform appears correctly on the corresponding listing data displayed to consumers. This accuracy calculation happens at the field-level for each entity across each publisher.

Here is an example of an entity in the platform and its corresponding Google listing:

In this example, the Verifier would determine the business name, address, phone number, hours of operation, and more appear correctly on Google. We’ll deep dive into how we calculate listings accuracy, where you can find this information in the platform, which publishers and fields are in scope, and what you can do when data does not appear correctly on a listing.

Automated Scanning

Keeping up with all of the potential data display changes on the publisher network is quite the task. Every publisher has their own unique method for receiving data from Yext and displaying it on their site. To ensure that we can provide transparency into the most up-to-date listings data possible, we use a process called “scanning” to constantly fetch the data the publisher is displaying on their listings. This is known as the scanning process.

We use a dual scanning process to not let changes slip though. First, we have a real-time scan initiated every time an entity is updated in the platform and that change is sent to the publisher. Second, we have a recurring backup scan to catch any changes that may have been missed. For high-trafficked publishers like Google, we scan very frequently. For publishers with less traffic, we’ll scan less frequently.

Both of these processes work together to pull in the latest snapshot of which data appears on a listing. Once we have that snapshot, we can compare what is displayed on the listing with what is expected to be displayed (which is what is in the platform!).

Publisher, Field, and Languages Supported

Not all publishers support real-time scanning or provide a time-of-receipt of the exact data they are showing on their listings. Because of this, we can only support listings accuracy verification on many but not all of our publishers.

Below is the list of Publishers, Fields, and Languages that support listings accuracy verification today. We expect this list to continuously grow over time.

Publisher and Fields

	Apple	Google	Facebook	Yelp	MapQuest	AroundMe	Cylex	Gelbe Seiten	iGlobal	BundesTelefonbuch	Dialo
Name
Address
City
Region
Country
Postal Code
Lat/Long
Phone
Hours
Closed Status
Website URL

Languages

*While the Verifier is supported globally, the system will have more difficulty with verifications in this language and may be prone to lower listings accuracy. This may occur for fields like Name, Address, City, etc. where the field standards and formatting typically vary by country.

Listing Detail Page

Now that we’ve scanned the publisher network for the latest snapshot of data displayed to consumers, we can display in the UI, for each field on each listing, if the displayed data is accurate. This requires us to compare the displayed publisher data to the corresponding data in the platform.

On the Listing Detail page you will see the following columns:

• Field: The display name of the field in the platform.
• Entity Data: The value of the current data stored in the platform for this field, even if we last verified the listings with a previous version of content.
• Publisher Data: The latest verified publisher data.
• Status: Processing, Data Mismatch, Verified, Field Not Synced

• If a field is not supported on the publisher site, it will not display in the table.
• Table will only appear if the listing is Synced. If the listing is Processing, Opted Out, or Not Synced it will display the corresponding status in a single row on the page.

Statuses

• Verified: The current data in the platform matches the data on the publisher site.
• Processing: The data was updated recently so we need to wait for another scan to occur. Then, we will show “Verified” or “Data Mismatch” based on the status of the scan.
• Field Not Synced: The data is not being synced based on the Field Syncing & Mappings settings (found in the Configuration tab of the Publisher Detail page)
• Data Mismatch: Data in the platform does not match the data on the publisher site.

Data Mismatch Details

• If the last verified data in the platform does not match the data on the publisher site, the publisher data will be in red text in the table.
• If data in the platform is blank, and the publisher data is not, you will see in the Entity data column.
• If data in the platform is filled out, and the publisher data is blank, you will see in the Publisher Data column.

Actions on the Page

• Force Sync: Resend data from the platform to the publisher.
• View Listing: View the listing on the publisher site.
• Scan: Fetch the publisher data and re-verify.
• Opt In: Opt into this listing - only appears for listings that are currently opted out.

Handling Mismatches

Data Mismatches occur when the data in the platform and the data on the listing do not match. There are many reasons this may happen, and we’ll review what actions can be taken in each case.

Listings Accuracy in Report Builder

Metrics

Listings Accuracy: The percent of fields with accurate data on Listings.

How metric is calculated: The number of fields (within the given filtered and dimensioned set of data) with accurate data divided by the total number of fields (within the given filtered and dimensioned set of data).

Use cases

Over Time

By Field

Applicable Dimensions

• Time > Days of Week / Days / Hours / Months / Week Number / Weeks
• Entities > Country / Entity / Entity Groups / Entity Types / Folder / Labels
• Listings > Sites / Listing Field

Applicable Filters

• Entities > Country / Entity / Entity Groups / Entity Types / Folder / Labels
• Listings > Sites / Listing Field

Verifier Comparison Logic

Verifications will either be determined as either a Match or No Match. At first glance, this is a seemingly simple problem that the Verifier is solving – “why not just check if the strings match up?” However, verification becomes much more complicated due to Publisher Transformations.

Publisher Transformations

Often publishers will slightly transform data before they publish it to the end user. One example of this is when publishers remove the “Inc” suffix:

Pat’s Pizza Inc ➡️ Pat’s Pizza

In this example, the publisher removed “Inc” from the business’ name. While these two values would fail a literal string comparison, we still want the Verifier to count this as a match, seeing as there’s no way to surface “Inc” in our business’ name - the publisher will inevitably remove it. In this case, the Listings product is executing its job properly, but the data in Yext and Publisher systems will never exactly match.

That being said, there are many other scenarios where the business names are slightly different, but are not caused by a publisher transformation. Instead, these scenarios occur when a publisher is using the wrong data to display to consumers. Here is an example:

Pat’s Pizza Inc ➡️ Pats Pizza Inc

These scenarios require some investigation since we know that publishers don’t really strip the possessive apostrophe (‘) from business names, and it’s likely that something failed along the way. The new Verifier should identify these scenarios so we can:

1. Raise it to the user’s attention
2. Determine if the issue is Yext-actionable or client-actionable

We would count the first example to be a Match and the second example to be a No Match. As you can imagine, these Publisher Transformations can be very nuanced and pretty tricky, which is why we built the specialized Verifier system to consistently identify them. Additionally, publishers do not provide an explicit list of transformations - we are only aware of the ones that we’ve encountered before, which may also change over time. So while we can always discover emerging examples, we built the Verifier system to handle quick iterations to keep up with the pace of our findings.

Below are a set of lists outlining publisher and field verification logic which we’ve built into the Verifier.

Note: we will continuously iterate this list as we encounter new edge cases

Publisher Specific Logic

Apple

• May remove geomodifiers from business names
• Does not allow tracking parameters on URLs

Facebook

• Does not accept Name field from Yext and any desired changes need to be updated directly on the listing

Yelp

• Frequently interchanges “http” and “https” in the Website field

Field Specific Logic

Name

Address (address + address2)

Hours

Note: for Hours, our goal is to check if the hours match conceptually – not text based. As such, we disregard various display nuances like 12 vs. 24 hour formatting, open 24 hr representations, closed representations, etc. A good rule of thumb is: “if a consumer showed up during the listed hours, would your business be open?”

Country Code

Phone

Note: for Phone, our goal is to check if the phone numbers match conceptually – not text based. As such, we can disregard various phone formatting representations. A good rule of thumb is: “if a consumer called both phone numbers, would they arrive at the same phone line?”

Website URL

Note: for Website, our goal is to check if the URLs match conceptually – not always text based. However, in some scenarios formatting actually is important (e.g., case sensitivity after the domain). A good rule of thumb is: “if a consumer clicked on both URLs, would they land at the same webpage?”

Lat/Long

The Lat/Long field is unique as we only check for the distance between the two sets of coordinates. We’ll use the below guidelines:

• If the business address is VISIBLE in Yext (e.g. non service area business) → confirm they are less than 500 meters apart
• If the business address is HIDDEN in Yext (e.g., service area business) → confirm they are less than 5000 meters apart

City

Region

Postal Code

Closed Status