In this episode of the International Web Effectiveness Podcast, Bill Hunt and Bill Scully take a closer look at the benefits of product information management and effective category mapping for businesses. They discuss how applying schema, consolidating product information, and integrating digital asset management systems can streamline operations and strengthen customer relationships. The conversation also highlights the importance of starting small, adapting to changing requirements, and leveraging insights from tools like Google to improve international product listings and accessibility.
Key Takeaways
- Importance of starting small with product management and category mapping.
- Utilizing schema to enhance product information and listings.
- Aggregating product data to save time and improve efficiency.
- Leveraging digital asset management (DAM) systems for better organization.
- Importance of flexibility in adapting to changing product requirements.
- Using Google’s tools to identify and categorize products effectively.
- The role of machine translation memory in maintaining international listings.
- Need for consistency across multiple markets regarding product attributes and images.
- Encouragement to get started with organizing product data, regardless of scale.
Catch the Full Episode
YouTube: https://youtu.be/PVyVEW5opO8
Spotify: https://open.spotify.com/episode/6rHaTOjFrheRbEieFfg26d?si=HjnVk7vfStue39OAEfrC3w
Transcript
Bill Scully:
Welcome to episode fourteen of the International Web Effectiveness Podcast. Bill Hunt and I, Bill Scully, focus on the strategies and techniques necessary to improve your web presence and manage global websites. In our last episode, we discussed the benefits of a uniform URL structure, sharing tips on how to implement consistency and make the case for doing so.
In today’s episode, we’ll continue that conversation, but focus on product information management. We’ll discuss the benefits of managing product information and how we’ve approached this from a global perspective.
But first, there was a great article by Chris Long on Search Engine Land titled, “Retailers: Google’s Becoming Your New Product Category Page.” It shows images of Google displaying results in an Amazon-style layout. Bill, have you seen that?
Bill Hunt:
Yeah, it’s pretty cool, and I think it fits perfectly into our topic today—how people should organize their product information and images to take advantage of this new opportunity. It’s pretty incredible how you can drill down, almost like you would on a website, to navigate to the product you’re interested in. Google is using categories and metadata—you almost don’t need to do any research anymore; it’s all done within a single search.
Bill Scully:
I think that’s brilliant because it’s exactly what we’ve been telling people for years. As users go through what I’ve always called a “searcher continuum,” they start with something broad. Chris uses the example of espresso machines, but you could start with “coffee maker” and then learn about the different types.
Bill Hunt:
What Google seems to have done, and interestingly, they have the data, is that they understand how people search. I realized this after the Bing launch years ago. I thought Bing, either manually or through automation, understood all the variations of a particular query. What Google has done is essentially put this into action.
In Chris’s examples, you see options like, “Do you want a grinder? Is it automatic? What size do you want?” It takes all the feature-function sets and lets you click through them. You can also filter by brands, sizes, and other attributes.
Bill Scully:
That’s powerful. Do you think this could be the new category page?
Bill Hunt:
It’s still up for debate, but I like the potential. I’ve been talking about shelf space for years. Imagine if a brand like Delonghi, which has multiple models with different functions, had their product feeds dialed in, their pages optimized, and schema properly implemented. Could they dominate this? Another thing we’ve been advising for years is to think about segmentation, intent clustering, and interest clustering.
This all ties back to our topic today. Chris also talks about scrollable product images. You click in, and a pop-up block shows descriptions and dimensions. This is convenient and directly ties into today’s discussion. If you haven’t seen it yet, I definitely recommend checking it out.
Bill Scully:
Some might argue, “Oh, it’s just Google disintermediating us,” but at the end of the day, they’re not selling these products. They’re directing users to retailers who’ve ticked all the right boxes. And that’s what we want to focus on today—whether your products are set up in a way that makes them more discoverable in the future.
Bill Hunt:
Exactly. We’ll add a link to the show notes so you can read Chris’s article, but you can also search for “Google is Becoming a New Category Page” on Search Engine Land.
Now, let’s get into the show. Imagine having all your product information in one place, with consistency across all marketing and sales channels. That includes metadata like the product name, description, links to images, sizes, weights, regional availability, and target markets. You can even include physical assets like data sheets, exhibit models, and trade show giveaways. Having everything in a single database ensures consistency.
It also helps ensure your product looks consistent across all platforms. This data can be fed into Google Merchant Center, which helps get your products to market faster by streamlining the process of adding and updating product details and distributing them to your channels.
Bill Scully:
That’s a good point. The problem is that this data often exists in multiple places within an organization, but it’s rarely centralized. Someone updates the information, but it doesn’t get updated across the board.
Bill Hunt:
Right. So, Bill, when you’re working with companies that don’t have their product information organized, where do you start? How do you approach it?
Bill Scully:
Well, first, I’d try to establish a framework to organize the data. Many companies have some form of product information management, but as you said, it’s scattered all over the place. I remember working with a Fortune 100 company once and asking, “Do you have a list of all your products and categories?” They responded, “I don’t know… maybe?” So, I just started scraping Wikipedia for it.
Bill Hunt:
Wow.
Bill Scully:
Yeah, it was like pulling teeth. A couple of months later, we found out some people within the organization actually had this information organized, but no one was using it. That’s the first step—centralizing the data. There are a lot of tools out there. We won’t get into specifics, but if you Google “product information management,” you’ll find plenty of options.
Bill Hunt:
There are two parts to this process. We’ll talk about the second part—digital asset management—later in another episode. But today, we’re focused on product information. You nailed the benefits. Instead of people digging through different files and folders, we’ve all heard it before: “Yeah, we had the list of URLs, but someone went and changed the Google Doc and broke everything.”
Bill Scully:
Exactly. And while many companies may have this well organized for one market, if you ask them, “Do you have it for France? Japan? Germany?” they might say, “I don’t know” or “No.” Even more important is whether they’ve connected it all. Do they have a master version that links to other markets?
Bill Scully:
When you start thinking about this, in theory, we should have a system where we can pull up a product name or ID and instantly see a clean layout. If I want the version for France, it should be ready, with models, variations, feature descriptions, tech specs, and links to product diagrams. If it’s technology-related, there could even be a link to a Visio image.
When I worked with Cisco, it was insane how many people were looking for the Visio image to build data center mockups. These small details, like an image you can pull into Microsoft products to build workflows or documents, are crucial.
Oh, I was going to ask you—what’s a Visio image?
Bill Hunt:
It’s the icon used in a flowchart.
Bill Scully:
Ah, an icon in a flowchart. Got it.
Bill Hunt:
Exactly. People look for that because they need a specific server icon, for example. It’s interesting—let me segue for a moment. We once worked on a model for a bicycle query matrix, which included about thirty million phrases. We broke them into categories, and one was “build.” We found that people were specifically searching for Visio images tied to a product name.
Cisco had them, but they were buried on a long A-to-Z list, probably fifty or sixty printed pages, with just product IDs. When you clicked one, it brought up the Visio image—a small thumbnail that people could right-click, save, and insert into their document. We realized that when people were searching for these, they were likely building data center mockups to secure budgets. When we pointed this out, the light bulb went off—they realized they needed to get these images onto the product pages.
Bill Scully:
Right, so as we started framing this out, we emphasized starting with the category first. Whether it’s a server, an ACMY Superwidget, a jacket, or a boot, that’s your starting point. Then, you can begin stacking additional details. Many organizations already have this in some form in a database. From there, you can start adding things like sizes and regional variations.
For example, in the U.S., you might have one SKU, while the UK might have a different one. This is where things get interesting. If I were setting this up, I would start with something like a global product ID. This ID acts as the primary key in a database, an alphanumeric name or code that serves as an easy lookup. No matter the SKU variations in different regions, they all tie back to this global product ID.
Bill Hunt:
This makes sense, especially over the life of a product, as there will be revisions, generations, or updates. While it might not be the exact same product, you want to maintain the same ID to track and manage legacy and current versions. You can extend the root name or number by adding a suffix like -A or -2 to signify updates or generations.
For example, Cisco might sunset a product like the Cisco 8500 server, but then introduce an updated model with a similar name like 8500-27 or 8500-G. The core product is still the 8500, but they’ve revised it. What we often found was that when a model was discontinued, the content associated with it would disappear too, with no tieback to legacy versions. This creates confusion for people still using older models, like IBM’s AS/400, which was later rebranded as the X series but is still referred to as AS/400 by many.
Bill Scully:
Maintaining a global product ID allows you to maintain a consistent historical reference across different generations and regional variants. It’s also useful for things like Hreflang, where you need to match the UK, U.S., Australian, and other regional pages. We always recommended using a global product ID to map these to each other, even if they have different SKUs in each market.
Interestingly, many companies use their SKUs to designate either the markets they’re in or the supplier’s location, which isn’t a universal identifier like a UPC. When selling a product globally or through regional merchant programs like Google or Amazon, you’re required to use a Global Trade Item Number (GTIN), which is a 14-digit identifier that normalizes products across markets.
So, in the U.S., we might have a six, eight, nine, or twelve-digit UPC or SKU, but the GTIN must be used. What’s interesting is that we’ve talked about this in previous episodes: the amount of money big companies spend organizing their merchant feeds and the information for other purposes. They don’t always consider doing it for this purpose. Again, we’re simply building this in.
Bill Scully:
What if we had this central management system and could export data out? For example, “Hey, give me a product feed that meets Google specifications for France,” or “Give me an export for Amazon in Germany,” and it ties everything together.
Bill Hunt:
Let me give you a little history of my introduction to product management and information management. I was with a company before it was acquired by Siemens. We acquired twenty-eight different companies in a span of three years, going from thirty products to about two hundred. I was responsible for building out the new website, so I had to figure out how to organize these products. We had products in new categories, we had products in the same category, and we also wanted to ensure that we could get the navigation from the homepage to the right product. We’re talking, you know, way back when it was mostly HTML navigation.
So, we basically broke it down into applications and processes. It was a challenge to use the categories that would fit and to determine the type of filtering that would be necessary. It was pretty hard to get everyone to agree on where their product fit because everyone wanted all their products included.
We finally got that done, and then, like a year later, the CEO decided to call the front desk of a couple of the offices to ask for a product that wasn’t in the office. They didn’t know who they could talk to, and that set the company off on this whole PIM project. It took about two years, but they really nailed it down. The first goal was “one call, one answer,” and that turned into all the information and storage processes.
Bill Scully:
Now, with Amazon, Walmart, and Google, you can use all that information to get your products up. I think that’s key. If someone were starting today—if you’re the search person or a web manager—I talked to someone recently who was selling his agency. He was telling me about a client he was struggling with. They were rebuilding the website and trying to get all the products sorted to build a feed.
Bill Hunt:
As you said, they needed to move from an HTML structure, which they were still using, into the current century and utilize a dynamic structure. It was like pulling teeth. When I asked, “Can I get an output of the database?” they replied, “Well, we never output this; we just query it.” The people maintaining it didn’t even know how to extract the data because they were used to displaying it on a screen.
That’s where I would start: understanding what we have and where it’s located. Start by trying to aggregate this information. Long before you even seek out tools to do this, consider what you can start with in Excel. You might also use an easy-to-use database like Airtable or Notion. Heck, you could probably even take these Excel files, dump them into ChatGPT, and it would organize them for you. But start collecting this information.
At the same time, build relationships with people—like the logistics team and those who ship products. They probably have data. And don’t forget the call center—I love the call center! Where do they look up information when a customer calls about our products?
I remember working on a project with Dell, and they told me they dreaded Mondays because that’s when they’d get a half dozen emails from Michael Dell asking why he couldn’t find certain information. He had a pet peeve about acquisitions. Whenever Dell acquired a company, he immediately wanted to ensure that the new company’s data set and product information appeared in Dell.com’s site search. That was key because when people heard “Dell bought them,” they’d search for the product on Dell’s site—even if it hadn’t made it to product navigation yet.
So, all of these pieces come together. As we saw from Chris’s article, think about those things. What are the features? What are the functions? What are the attributes?
And here’s something that a lot of SEOs miss. I was recently scolded for mentioning keywords—not in the traditional keyword research sense, but in the broader sense of words. What are people using to find you? Someone told me, “We don’t use keywords anymore. We use entities.” Well, sorry folks, that’s still a keyword. Maybe your customers haven’t received the memo. The people who provide us with the terms we use in search haven’t caught up with that yet.
A question isn’t an entity. It’s a phrase.
Bill Scully:
Exactly.
Bill Hunt:
Right. But let’s talk about entities. There’s real power in that. And the reason we have so many entity SEO gurus now is that they recognize that Google is using entities—these descriptors of what something is. There are a dozen tools out there. Our friends at Milestone Internet have a schema builder, and there are others, like InLinks, which does a great job of identifying entities on your site.
So, what if we folded that in? If we sell computers and laptops, those are entities we can tag. Now, if we have a link to a product or category in our database—like computers being a category and laptops a subcategory—we can tie that to all our linguistic equivalents.
The cool thing is, we could export a list of all our category names for every market from this database. This also allows us to creatively double-check our schema. We’ve got product schema, and as Chris pointed out, Google now shows us things like prices, attributes, shipping, and availability.
We need this data, but I’ve seen people trying to construct schema from scratch using a JSON file, even though they have a merchant feed or licensing database that could provide it.
Again, starting from zero, go find people who already have this data. Don’t reinvent the wheel. When I worked on a project at IBM, we received a patent for faceted navigation. My job was to ensure everything was tagged with these attributes: categories, subcategories, and features. Once we did this on IBM.com, I was loaned out for forty-five days to Samsung to help them implement the same process.
At Samsung, one task was to take it even further. For example, Samsung would allow you to enter the dimensions of your TV cabinet. If you had a TV cabinet with a specific slot size, you could search for the list of TVs that would fit in that space.
Bill Scully:
Oh, so it was a filter.
Bill Hunt:
Yes, exactly. And it was one of many facets. It helped customers filter by type—plasma, LCD, flat-screen, and so on. The end result was over a hundred million possible combinations to build URLs. We had to reverse that and create rules to limit the URLs to around a million, which still required a series of factors to make the lookups work.
We used the facets, like category, subcategory, and features, to help us define URLs and avoid generating millions of unnecessary pages.
Bill Hunt:
We had to implement this for XML sitemaps to feed it into Google because, guess what? Google doesn’t have clickability. It can’t go in and say, “I want this, this, and this,” and build a URL. So, we had to reverse the process.
We knew that we wanted to build these work streams: categories, subcategories, and then products—attributes, attributes, attributes, product ID. Because we understood these rules, we could build URLs and include them in the XML sitemap.
Many companies may already have some of this in place, which is why we say, go ask people. Imagine if you could start combining this. And then, like we mentioned, can you share this in different markets? One of the big challenges is if you have licensees. For example, a company like Brooks Brothers licenses its products to different countries.
The licensee in that country may or may not use all the products, but for the ones they do use, they need a way to pull them from the database. We need a way to map these pages for Hreflang, for analytics, and for various other reasons.
There are so many benefits to this approach. As you mentioned from your experience, it took a couple of years to get everything organized. I don’t want to scare people away, but I want everyone to think about what five things they can start merging today.
To clarify, the team continued to build on this, eventually integrating it into a customer relationship management system. If a sales rep tagged the product they were going to sell, the system would pull up all relevant PDFs. I was part of the team, but I don’t want to take full credit. I was more on the periphery of the web side of things. They took the system and bolted it right into the business. It saved a lot of time, though it was a ton of work up front.
Bill Scully:
That’s really impressive.
Bill Hunt:
Before we continue, I did a quick search on Google for “espresso machine.” One of the things I would do when building your list is check what filters are available. For example, they show filters like: by date, on sale, used, for commercial use, with a grinder, automatic, and with a steam wand.
If you only have one product in a certain category, you’d still want to note its features, like whether it has a grinder or steam wand. There are also obvious filters: price, automatic vs. manual, brand, and many of these are already in schema. For example, is it on sale? Is it new or used? What’s the price? These attributes are embedded in the schema.
So, if you fold this back into your product information sheet, you’ll have this valuable data. Even if you’re stuck, another great idea is to check what Google has already done for you. For example, you’ll see pills (filters) at the top of key categories. If you search “coffee maker,” Google will show things like pour-over options or other product attributes.
As you drill deeper, Google has likely already done a good job segmenting this data, especially based on user behavior or their own data sets. This is why entity SEO has become so powerful—because Google has been doing this classification for a long time.
Once you connect it to a category or one of these classifications, it removes the ambiguity. The real power of this becomes evident when we start to take it international. I don’t remember the exact schema name for it, but it’s something like an “alternate category.” People have used this for international pages—it’s the same as. You can map products across different languages like French, Japanese, Chinese, Belgian, or German.
Once you have the data in your database, it’s easy to populate these fields. So, start small and even let Google assist you. Some of these key things can already be figured out by Google.
Bill Scully:
That’s a really good point.
Bill Hunt:
This isn’t going away. Especially with AI, we’ll be able to understand search intent, product demand, and availability more efficiently. It’ll prevent you from having to look in forty different places. Aggregating this information is going to be crucial as we move forward.
When we talk about DAMs (Digital Asset Management), Google now has APIs that can analyze an image for you—everything from the image’s connotation, to ethnicity, to the expression on the subject’s face. These details are becoming very powerful.
And now, with a lot of products, you can have multiple sizes for carousels. You’re familiar with this concept, especially with things like recipes where you offer different sizes. All these things start to make sense when we can manage them efficiently. And don’t forget about machine translation memory—if you update a description in English, it should flag translation management in other markets so they can update the description or feature in their language as well.
Bill Hunt:
I think these features, functions, attributes—whatever we want to call them—are critical. If you look at a lot of the generated results in Google, it’s often scraping these bullet points. Not just from your page, but from other people who’ve reviewed it. These give the sound bites of what it is. So again, I think there’s a lot we can do with this. Our recommendation is to assess what we already have, determine what more we can incorporate, and figure out how to bundle it across the globe.
Start small, aggregate, and iterate as you go. To Bill’s point, think about where else in your business you can use this. Maybe it’s useful for burst answering a phone, where they can put in an ID or name and see that you actually have this product in multiple places.
Bill Hunt:
I really like the idea of just getting started. There’s a lot of time to be saved if you could map your website’s data. For instance, how many people know where their images are for a specific product? Is the image okay for one market but not another? Or do you have market-specific images? And if one little thing changes, like the weight of a product, you now need to figure out where that information is in all your PDFs.
So, it’s good to just get started. But looking ahead, I came across a stat while doing some research: Amazon, Granger, and Target changed their product requirements more than 100 times in 2022. This shows how important it is for your system to be flexible. The requirement could be a tag, a mandatory feature, or even a description length change. This stuff is coming at us fast, so we need to start thinking about it.
Bill Hunt :
Yeah, you’ve got to get started somewhere. And what’s nice, if you’ve got a dataset and one of those stats changes, you can go in, update it in one place, and it will flag all the others. For instance, weights and prices—many product management systems will automatically update calculations.
If you update the weight, which is the same product being sold everywhere, systems often have calculators that will automatically update the weight in every market, changing it from pounds to grams or kilograms. All of this can be done just by entering the data in one place, as long as it’s the same product.
Bill Hunt :
Good stuff! I think it’s only going to get more complex and demanding, so just start. We’re seeing more and more people asking for help and guidance on this. Whether you need to build a cost-benefit analysis or just make a simple diagram for the MBAs in the room on why we need to organize this, just get started somewhere.
Bill Hunt :
Great, I think that wraps us up nicely. I want to remind everyone to join our Facebook group, where you can ask questions, and we’ll answer them. Also, if you like what you hear, I’d really appreciate it if you could rate us on your podcast listener app. Thanks to everyone who’s listening, and I hope you have a great day and stay safe.
Bill, any final words?
Bill Scully:
No, no, I think it’s all good. I concur, just get out there and get it done.