A critical part of successfully working with planogram data is understanding how it is organized. By the end of this article you’ll know how data is structured in planograms so that you can use it better in your merchandising and analytics.
Working with a planogram’s data can be overwhelming, especially for people new to category management. Lots of information in a planogram is dedicated alone to creating the visual representation of a virtual aisle. Stil more is non-visual and represents KPIs, segmentation, merchandising settings and even custom data. In total over 2,000 different kinds of information make up a planogram in Space Planning!
Each different kind of information is stored in a field. For example, a product’s UPC is stored in a field called, fittingly, “UPC”. These fields are then organized into objects. Each object represents either a physical component of a planogram (for example: a shelf), or a concept that connects two components (for example: various metrics on how well a product is selling on a specific planogram.) To keep track of how objects relate to each other, they are organized into a hierarchy.
How the hierarchy works
Through this article, we will build out the hierarchy in Space Planning from the top down. We’ll show the relationships between objects by drawing lines between them.
When two objects are related, the higher object is the parent of the lower object. For example, a planogram object is a parent of the fixture object. The parent-child relationship here is one-to-many: one parent can have multiple children, but a child only can have one parent. For example, a planogram object can have multiple child fixture objects, but a fixture object can have only one parent planogram object.
Let’s start from the top. When opening a planogram in Space Planning, the first thing you see is a window with a front view of a planogram. When opening multiple planograms at once, the window is organized with several tabs at the top, with one tab for each planogram. This window, regardless of how many planograms are in it, is a representation of the very top-level concept in the Space Planning object hierarchy, the project.
Project
Project diagram
The project object holds data that is shared among all the planograms you have open in the same window. Default merchandising attributes, whether all the products use UPC or ID as their unique identifier, whether to use inches or centimeters, and other custom pieces of information are stored in this object. When saving a planogram to a .PSA file, a file will contain everything within a single project object.
Digging into the project
Planogram
Planogram diagram
A project contains one or more planograms. These are exactly as you expect–physical representations of a way a category could be merchandised at a store. A specific name, the direction shopper traffic flows, how much total space is required to set the planogram at a store, the time period the planogram is in use at the store, aggregations of KPIs from components within a planogram, and more are stored at this level.
Product
Product diagram
A project also contains one or more products. A product contains the necessary metadata about a specific item in the category’s assortment. Things such as dimensions, packaging style, category segmentations, and KPIs are stored here.
One important thing to understand about the product object is that the information at this level is shared among all planograms in the project. For example, the Height field in the product object will be the same value no matter what planogram in the project, and indeed changing a product’s height when looking at it in one planogram will change it in every other planogram. This is intended, as updating things like dimensions becomes much easier when there is only one place you need to change it.
Combining planogram and product data
Keeping product dimensions in one place seems to make sense, but a product object also has KPIs like Unit movement. Just like the dimensions, changing this value will change it for all planograms in a project. So how do you have planogram-specific data for a product? This is where the performance object comes in.
Performance
Performance diagram
A performance is the combination of a product and a planogram. Data in this object applies to a specific product on a specific planogram. Many of the fields here are also in either the product or planogram objects, such as Unit movement. The values at the performance object level will be unique for each product/planogram combination though, and changes will not affect other planogram or product objects.
Inside the planogram
Segment
Segment diagram
A segment is a way of breaking a planogram up into smaller parts. Most often this is used to break up gondola fixturing used in aisles to align with the physical breaks they have, typically the width of the shelves slotted into them. Segmenting a planogram also makes printing easier as the pages printed can be separated by segment. The size of the segment and aggregations of KPIs from components within the segment are stored here.
Fixture
Fixture diagram
A fixture is a physical object that represents the permanent fixturing components used to merchandise the planogram. Things like shelves, pegboards, bins, rods and signs. Most of the fields here involve what the fixture should look like and how products can be merchandised on it.
Fixtures are usually placed within one or more segments of a planogram, so they also have a link to segment.
Drawing
Drawing diagram
A drawing is a visual aid added to the planogram that is not meant to be physically present in the actual store. Things like notes, lines and shapes can be placed to add additional details and context to a planogram. Fields are focused on the appearance of the drawing and what text it contains.
Drawings also can be placed within one or more segments of a planogram, so they have a link to segment.
Things on the shelf
Position
Position diagram
A position is the actual placement of a product on a planogram. Most of the fields here involve how the product should be merchandised, such as orientation and number of facings.
Because positions are also a combination of a product and planogram, they have a link to performance.
Divider
Divider diagram
A divider is a physical object used to keep positions separate from each other on a shelf fixture. Most of the fields here involve the dimensions and location of the divider.
Other things you’ll see
The following objects are ones you’ll see in various Space Planning screens, but are less often used.
Peg
Peg diagram
Pegs are sourced from the peg library included in Space Planning. They contain the necessary metadata about a peg, such as the number of pegholes used and its dimensions, where the price tag is and its dimensions, and unique identifiers. Similar to a product object, this data is shared across every planogram. Changing a peg in one place will affect all places that peg is used.
A peg isn’t placed on a planogram like a position or fixture. Instead, you set up the ID of a peg to use for a project, product or position, and the peg that matches that ID is automatically used when a position is placed on a fixture that uses pegs (for example, a pegboard.)
Configuration
Configuration diagram
The Configuration object is the secret boss of the hierarchy. It represents the Space Planning application itself and actually sits above the project object. All of the options you can find under File > Settings > Settings are stored here.
OLE Embedded Object
OLE Embedded Object diagram
OLE Embedded Object is very rarely used. It exists to allow you to embed documents from other applications like Word or Excel into a planogram. While this sounds exciting, Cantactix does not recommend doing this. Embedded documents can be tricky to work with and can really bloat the size of a planogram, negatively affecting performance. Also, this technology only works on Windows operating systems so the embedded documents will not be visible on other platforms such as Space Planning Web.
Pulling it all together
Understanding the object hierarchy is important! Knowing how objects are related will make it much easier for you to prepare, merchandise and analyze planograms. When you have planogram-specific product metrics you need to load into the planogram, you now know that loading to the performance object is the right place. If you need to find out where a product is placed and how many of it are there, you now know to use the position object. If you need to make a parts list for in-store execution, you now know to use the fixture object. And finally, you now have a much better idea of what all those objects mean when they’re listed in various areas in Space Planning’s interface!
In future articles, we’ll be putting this information to use for things like reporting and heatmaps. Stay tuned!