Notes On Terminology

Database / Feed: Properly speaking, a feed is the transmission of a data file from one place to another, while the database is the temporary residence of your data while it is on its way from point A to point B. However, it is common to refer to a product or a column as existing in the “database” or in the “feed” so these terms are sometimes used interchangeably.

Field / Attribute / Column: These names are often used interchangeably to refer to a certain column in a database.

Feed Build: The process of importing and mapping data, writing transformers, and setting up an export for your transformed data.

Perform a Pre-Build Check

Before beginning a feed build, it is a good idea to perform a few checks to make sure that you have everything you will need to finish the build. Answering “No” to any one of the questions below about your Feedonomics database may prevent a successful feed submission to the Google Merchant Center.

• Do you have a dynamically updated feed import?
  

• Do you have the expected number of products?
  

• Do you have accurate pricing?
  

• Do you have accurate availability?
  

• Do you have the requisite product identifiers: brand, mpn, and gtin?
  

• Do you have tax and shipping info, either in the feed or in the Google Merchant Center?
  

This may not be a comprehensive list, so we suggest developing and maintaining your own Pre-Build Checklist.

Database Building Best Practices

Use Consistent Field Names

A Google Shopping feed is the most commonly prepared feed in Feedonomics. For this reason, we advise adopting Google Shopping’s naming conventions for the field names in your database. If your import file has a field called “product_name”, for example, consider mapping that field into Feedonomics as “title”, if that is the purpose that it serves. Many other advertising services, including Bing Ads and Facebook, allow Google-formatted feed submissions, which provides further reason to adopt Google’s naming convention.

This will not only be easier for you—you’ll know exactly where to look for for certain information when switching between different databases—it will also be more convenient for your colleagues who may pick up work on a database that you created.

If you do need to create fields that don’t match one of Google’s defined fields, consider following Google’s field name rules: use lowercase letters, numbers, and underscores only.

Use Name-Based File Maps

Using a Name-Based Map ensures that the data in your feed remains consistent even if the column ordering of your import file changes. If, for example, the “price” column in your import file changes from column position 3 to position 5 from one day to the next, a Name-Based Map will ensure that the price data is mapped into the correct column in Feedonomics.

Choosing a Name-Based Map is encouraged for all databases. Make sure to click Submit File Map at the bottom of the page after making this selection.

Set Up An Alerts Email

Sometimes things don’t go according to plan with an active feed. Perhaps the FTP password for your Google Shopping feed is changed without your knowledge, or the feed import URL provided by your client was accessible yesterday but not today. Having your email address in the Alerts box will ensure that you are emailed immediately in cases like these.

Build a Feed in Stages

Breaking a feed build down into stages adds structure that can make the build process faster and more efficient. In addition to that, transformers in one field in Feedonomics can build off of data that has already been transformed in another field (see Setting The Field Execution Order) so beginning your build with some of the more foundational attributes makes subsequent attributes easier to deal with.

We suggest approaching a feed build in these four stages.

1. Data clean-up & simple data conversion
   

• Converting availability from ‘1’ and ‘0’ to ‘in stock’ and ‘out of stock’
  

• Generating full links and image links from handles
  

• Formatting price to include currency
  

2. Classification
   

• Gender
  

• Age Group
  

• Brand
  

• Product Type
  

• Google Product Category
  

3. Attribute population
   

• Color
  

• Size
  

• Material
  

• Pattern
  

4. Fine Touches
   

• Title optimizations
  

• Custom labels
  

Consider a database which contains video games and related apparel. After classifying your items in step 2, you may find that only 30% of the products are apparel. You can now save time in step 3, knowing that you only need to populate size and color for that 30% of the feed. Finally in step 4, you can leverage all of your previous work to quickly make highly optimized titles by dynamically inserting variant attributes that are specific to a product’s category.

Create a Feed Proposal

A feed proposal is a document that describes three things for each task in your feed build

1. What you plan to do
   

2. How you plan to do it
   

3. How long you expect it to take
   

A feed proposal is completely optional, but investing some time here can reduce the overall build time in the end, as it requires you to think critically about your approach to optimizing a feed before you even begin. A proposal document can be a personal work plan or it can be reviewed by other members of your team so that you can share ideas on the most efficient approach to completing a certain task.

Generally, you may have one short section on your proposal for each attribute that you plan to optimize. For example, the section of your proposal addressing Google Product Category may look like this.

Google Product Category
Task: Populate Google Product Category for all products

Method: Use keywords from Product type
Ex. If [product_type] contains ‘shoe’
Then [google_product_category] = ‘Apparel & Accessories > Shoes’

Estimated Time: 45 minutes

You may also want to place attributes on your proposal in the order in which you plan to optimize them. Consider setting the order to match the outline in the Build a Feed In Stages section.

Customize The Field Execution Order

In Feedonomics, transformers can build off of the work of previously-transformed fields. The Field Order Execution page in the Transformers menu allows you to customize the order in which your fields are transformed.

Placing your title field toward the end of that order, for example, allows you to leverage the optimized data in all of the fields that appear higher on the Field Order Execution list, like perhaps Product Type, Color, and Size. This allows for much easier and more robust title transformations.

Carefully consider your Field Execution Order before you begin writing transformers and revise the order to match the order outlined in your proposal (see Create a Feed Proposal). Again, we recommend aligning this order with that in the Build a Feed in Stages section above.

As you begin writing transformers on your fields, you create dependencies across multiple attributes. Revising the Field Execution Order after transformers are written can break some of those dependencies if you’re not careful, causing transformers to work differently than you intended or not at all.

Transformer Best Practices

Build And Refine Your If Statement With Queries

The If statement of a transformer defines the set of products that the Then transformation will be applied to. To ensure that you’re applying a transformer to just the right set of products, begin with a simple query on the Transformed Data page and continue to refine that query until you have the exact product set you’re looking for. You may also want to query for the complementary set* to see which products your transformer will not apply to.

When you have fine-tuned your query in the Transformed Data page, copy the exact query into the If statement of your transformer. It is helpful to keep separate Transformed Data and Transformers tabs open in your web browser throughout this process.

*To make a complementary query—that is, to query for all of the rows which aren’t included in another query—wrap your entire query with NOT ( ). For example, if there are 100 rows in a database and [title] contains ‘red’ OR [title] contains ‘blue’ returns 40 rows, then  NOT ( [title] contains ‘red’ OR [title] contains ‘blue’ ) will contain precisely the 60 rows which didn’t show for the first query.

Balancing Transformer Flexibility and Transformer Accuracy

If transformers are too specific, they may not help to optimize products added to the feed in the future. For example, consider the If statement below.

This may be based on the set of IDs present in in the feed when it was originally built, so it will do nothing for future products that are added.

Now consider this transformer on the other end of the spectrum.

This would include titles with partial word matches like ‘stop’, or ‘click-top pen.’

Efficient transformer design is about finding a good balance between precision and flexibility. In this case, perhaps looking for a short word in the title is not the best approach. If a broader attribute like Product Type is available in the feed, it may be better to use something like

By using contains_word and referring to a broad classification attribute like Product Type, this transformer reduces the potential for false positives, and also ensures that future products with a Product Type containing ‘tops’ will be given the correct Google Product Category.

Combining Statements with AND, OR, and ( )

In Feedonomics, AND operates before OR. This means that the following two statements are equivalent.

This will select women’s shoes or boots of any gender, which may not be what was intended. The correction below will select only boots and shoes which have a gender of female.

( [title] contains ‘boot’
OR [title] contains ‘shoe’ )

AND [gender] contains ‘female

To help provide clarity and to prevent mistakes in logic, it is advisable to use parentheses anytime that AND and OR operators are mixed in a transformer.

Preventing Transformers from Overwriting Existing Data

When writing a transformer on a field, you should consider whether that transformer should be allowed to overwrite pre-existing data in that field.

Suppose you want to populate the [color] field with ‘blue’ when the title contains ‘blue’ but you want to keep any previously-set color values in place. Adding [color] equal ‘’ to your If statement will help accomplish this.

Method 1: Allow rewriting of existing [color] values

Method 2: Do not allow rewriting of existing [color] values

There are a couple of use cases for this. In this example, there may be products in the feed with more specific colors like ‘Sky Blue’ or ‘Royal Blue’. Using Method 2 will preserve those more specific values whenever possible.

Another common scenario is that you’ve written transformers to populate Product Type for 95% of your products, but the remaining 5% of products can’t be populated as easily. This may require transformers that have more room for error. In this case, you would not want to allow those transformers to overwrite the data set by your previous transformers.

Modifying Existing Transformers vs. Adding New Transformers

Suppose that you have created the following transformer on Google Product Category, which is followed by many other Google Product Category Transformers.

You later identify that the only remaining products in your database without a Google Product Category are Blu-ray movies, which belong in this same Google Product Category. One possible fix would be to add another transformer on Google Product Category to handle these extra products, however a cleaner approach would be to revise the existing transformer like so.

This will reduce the number of overall transformers, making your feed easier to maintain.

This approach may not be possible in all cases, but it is worth considering whether these types of “patch” fixes will require additional transformers or whether they can be handled by modifying existing transformers.

Common Transformer Mistakes

[field_1] not_contains [field_2]
The following transformer will return an error if the [color] field is empty for any products.

To avoid this, you should add a first statement to verify that color is not empty.

False Positives When Using ‘Contains’
Using [field] contains ‘string’, it can be easy to forget about larger words that might also include the search string. For example, the string ‘men’ is included in ‘women’, so writing an If statement that simply says [title] contains ‘men’ will target products of both genders.

Instead, use [title] contains_word ‘men’, which requires that ‘men’ be surrounded by spaces or appear at the start or end of the title, or use [title] contains ‘ men’, with a space before ‘men’.

As always, carefully refine your If statements with queries to prevent these types of mistakes. Refer to Build And Refine Your If Statement With Queries.

Adding Multiple Fields To The Title At Once
At first, the transformer below might not seem problematic.

However, if color and/or size are empty for certain products, you could end up with titles like “Lightweight Denim Jacket in  Size ”. The better approach is to split this into one transformer for each attribute so that you can verify that the attribute is not empty before you insert it.

Transformer 1

Transformer 2

This will ensure that no empty attributes are inserted into the title.

Creating a “Transition” Feed

What Is a Transition Feed?

If you are preparing to transition an active Google Shopping feed to Feedonomics from another platform, you may consider making a “transition” feed. With a transition feed, you will write transformers specifically to match the current Google Shopping data as much as possible, not to improve the quality of the data. In this way, though you’ll now be submitting your feed from Feedonomics, you’ll effectively be sending the exact same data, minimizing potential for any drop in campaign performance.

To evaluate the accuracy of a transition feed, the best approach is to

1. Download a copy of the active product feed from the Google Merchant Center
   

2. Import that file into Feedonomics as a Join import
   

3. Map in the columns from that file, choosing names like “title_mc” and “product_type_mc”
   

4. Query your Transformed Data for [title] not_equal [title_mc] to see which titles in Feedonomics don’t match their corresponding title in the Google Shopping feed
   

5. Write the necessary transformers on [title] to get your two title columns to match
   

6. Repeat steps 4 and 5 as much as necessary, for all attributes you want to transition
   

When this is complete, you can confidently replace your current Google Shopping feed with your Feedonomics feed knowing that your campaign will not be adversely affected.

What do I do after making a transition feed?

To verify stability, we suggest avoiding any significant changes to the feed for two to three days after submitting your transition feed to Google. After that, you may begin to optimize your data either by adding new transformers on top of those you created during the transition, or by carefully deleting certain transition transformers.

Just remember that at this point your Feedonomics database will be connected to the Google Merchant Center so any changes you make to the feed will be submitted during the next scheduled Google export.

Should every account I migrate to Feedonomics have a transition feed?

No, not necessarily. If the shopping campaign is performing poorly and you plan to rebuild it, you may decide to skip the transition process and proceed with an optimized feed build, including the restructuring of bidding attributes like Product Type. After you submit your new optimized feed, you can begin rebuild your campaign according to the new feed data.

In any case, you should always verify that product IDs in your Feedonomics feed match those in the pre-existing Google Merchant Center feed to preserve item performance history.

Export Best Practices

Always Set An Export Count Threshold

Google Shopping, Bing Ads, and many other advertising platforms use a “purge and replace” method for updating feeds. If you export 35,000 products to Google one day and the only 5,000 products on the next day (perhaps due to an error in your import file) then those missing 30,000 products will no longer be available for advertising.

Setting a minimum product count in your export will send you an alert email and will stop feed exports when the product count drops too low. (See Set Up an Alerts Email)

Carefully Coordinate Export and Import Timing

Make sure that export schedules are in line with your import schedules. If you import data at 1 AM and export data at 2 PM, then your data is already 13 hours old by the time it is exported.

Title Optimization Best Practices

Avoid Duplicate Titles

Having two or more different products with the same title in your feed can be a sign that there are relevant keywords missing from the titles that would otherwise distinguish those products.

For example, all five sizes of a certain denim jacket in your feed may have the same title if you are not including size in the title. By writing a transformer to add size to the title, your products will see increased impressions for lower-funnel search queries like “Denim Jacket Size Large.”

A quick way to check for duplicate titles is to export your feed and use Excel’s conditional formatting to highlight duplicate values on your title column.

Place Most Relevant Information At The Front of a Title

Consider what information is most import for a product of a certain category or a certain brand, and place it as close to the beginning of the title as possible, to ensure that this information is always visible with the product ad.

For example, brand is nearly always a good piece of information to have in the title, however you may decide to place the high-profile brand names at the beginning of their respective titles and the lower-profile brand names at the end.

Always Trim Spaces

Unnecessary space at the front or end of your title (or of any other field) can easily be removed with the trim_spaces( [field] ) transformer. Make sure to place this at the end of your transformers on a field, to prevent re-introducing leading spaces after you’ve trimmed them.

Custom Label Best Practices

Name The Field According To Its Purpose

Creating a field called “custom_label_0” in Feedonomics can be confusing, as it doesn’t tell you what type of data the field contains. If you instead create a field called “price_brackets”, for example, then you can simply map the “price_brackets” field to “custom_label_0” in your Export Map. This will help you keep organized with what data you’re sending to which custom label when looking at your export map.

Indicate a Custom Label’s Purpose Directly In Its Data

Regardless of your field names in Feedonomics, when they’re exported as “custom_label_1” to Google, you’ll lose that that field name. So, if you create an attribute called “price_brackets” in Feedonomics and populate that with values like “1-100”, “101-200”, etc., it will be impossible to tell within AdWords what that data represents. Is it 1-100 clicks? 1-100 purchases?

To prevent this confusion, set the values in your custom labels to be “$1-$100” or “1-100 Clicks” so that you can determine the purpose of a custom label directly within AdWords.

Check the Logs