Exporters: From Yext to Your Listings

The Yext Knowledge Graph provides extremely flexible methods for storing data. From Custom Fields to Custom Field Types, Scheduled Updates to Multi-Language Profiles, and even Custom Entities, you can store any data in the way that best suits your business. The world of publishers in the Knowledge Network is less flexible, however. Each publisher Yext integrates with has their own schema: a very specific set of fields in an entirely predetermined format that integrating partners must adhere to.

Our Listings delivery pipeline is exceptional at ensuring your data stored in the Knowledge Graph appears on Listings everywhere consumers are asking questions, but adhering to hundreds of different publisher schemas just makes this problem more complex. How do we make sure your data is updated on all publishers as quickly as possible while still ensuring data is formatted properly for each endpoint? Yext's Listings exporters.

Think of Yext's Listings delivery as the Nile; the river we all learned about in geography class. Data flowing from Knowledge Graph passes down the river efficiently as one group. But once the end of the river approaches, water fans out forming a delta. These are the Listings exporters; taking the right data in the right format to each publisher.

Each Listings exporter is maintained by a separate code configuration; we have files for every publisher Yext integrates with including Google, Apple, Facebook, and even Hotfrog! Once data reaches the end of the Listings delivery pipeline, we send a copy of the data we wish to update to each Listings exporter. The exporter then goes to work formatting and mapping each field into something ingestible by its respective publisher.

Let's run through a few examples:

Starting with addresses, Yext stores the street name and number, city, state, region, and country for each location.

Google My Business's PostalAddress object looks like the following:

{

"regionCode": string,

"languageCode": string,

"postalCode": string,

"sortingCode": string,

"administrativeArea": string,

"locality": string,

"sublocality": string,

"addressLines": [

string

]

}

However, Facebook accepts slightly different parameters for address:

{

"country": string,

"city": string,

"city_id": int,

"latitude": string,

"longitude": string,

"locality": string,

"state": string,

"street": string,

"zip": string,

}

While both publishers want a similar set of data, there are slight variations. Google accepts both locality and sublocality fields while Facebook only wants locality and state. Facebook has the concept of a city_id, while Google does not. Google calls postal codes "postalCode" while Facebook refers to this field as "zip". As you can see, these slight differences can add up — and quickly cause confusion. The work done by our engineering teams to map data stored in Yext in a clean, easy to read format into every possible combination our publishers can come up with ensures your Listings are managed without extra effort.

Moving on to a second example, we can see data transformations in effect. The standard Yext format for hours that many of our publishers adhere to consists of a set of Days and Intervals. In Knowledge Graph, you can see days of the week and the open range.

In API format, this is transformed into:

{

"hours": [

"day": "MONDAY",

"intervals": [

"start": "09:00:00",

"end": "17:00:00"

],

"day": "TUESDAY",

"intervals": [

"start": "08:00:00",

"end": "17:00:00"

],

"day": "WEDNESDAY",

"intervals": [

"start": "09:00:00",

"end": "17:00:00"

],

And so on...

]

}

We take the time ranges from Knowledge Graph, split this data into intervals on the 24 hour clock, and format the json object by day of the week — all of this just to send your hours to many of our publishers!

Of course, not all publishers adhere to the standard Yext format, so we must transform hours data in unique ways preferred by the publisher. Take Foursquare: to represent the same data of open 9-5, Monday through Friday, expect for Tuesday opening an hour early, we need to transform data into:

'1,0900,1700;2,0800,1700;3,0900,1700;4,0900,1700;5,0900,1700'

Another publisher, another format.

All of this complexity is mostly hidden behind the scenes. Exporters are constantly working overtime to ensure your Knowledge Graph data appears on Listings everywhere consumers are asking questions. And we are adding new exporters every release! Yext constantly evolves to improve and expand our Knowledge Network. With each incremental publisher we add, a new exporter comes along with it. This constant effort keeps data clean and well formatted all across your digital presence.