The OrderMesh team spends a lot of time talking about what I call “the product data problem” in print-on-demand. It’s actually not one problem, it’s many...

Here are industry groups trying to solve some or all of these problems:
https://promostandards.org/
https://www.printing.org/library/standards/specifications-for-print-production
https://gwg.org/
https://initiative-online-print.de/en/

1. The Preview Fidelity Problem

(also known as: "The Proofing Gap," "What-You-See-Isn't-What-You-Get")

Definition: The gap between the product’s digital preview/proof and the physical object that shows up. Color, placement, scale, and material texture all shift between screen and substrate. Best thought of as a “what you see is what you get” problem. 

Why it's not like other problems: This isn't a data-modeling problem so much as a visualization and color science problem that data has to compensate for. Things like safe zones, bleed, DPI floors, color profiles, print-method-specific quality ceilings can come into play. Variances between suppliers and equipment types makes this harder to deal with. Really common examples: Print placement collar drop distances (how far below the collar the print starts). Wraparound drinkware printing accounting for things like how close the print gets to the handle of a mug or the edge of an item. 

What to think about in managing a POD network: Every vendor integration ends up needing its own "print expectations" documentation because the preview-to-production gap is often print-method and placement-specific, not product-specific.

2. The Print Locations Problem

(aka: "The How-and-Where-Can-I-Print Problem")

Definition: Print locations and print methods keep expanding, and which locations/methods are available varies by vendor, inter-facility, across equipment, and even by specific blank. 

Why this problem is hard: This isn't "products have variants" — it's that the same variant can be producible at one facility and not at another, and the list of possible print locations and types is still actively growing industry-wide. We all have to deal with the concept of adding new "print spaces" and types to catalogs and data architectures after launch, not designed in from day one. Change and equipment advancements are inevitable (and good). A common example of this problem in apparel: Neck-tag printing and sleeve printing were bolted on as new decoration areas years after core catalogs existed, and even then, availability is facility and blank-specific. 

What to think about in building your print network: Two print facilities who appear to have “redundant” catalogs may not be able to replicate print locations, outcomes, or methods. Vendor "print capabilities" have to be modeled per vendor facility and then rolled up to a global catalog level to enable cross-facility routing and load balancing. 

3. The Product Parity Problem

(otherwise known as "The No-Common-Identifier Problem”)

Definition: Matching "the same" product across different suppliers, vendors, or marketplaces without a shared, reliable identifier. Most POD products don't carry a GTIN/ UPC at all, and even when an identifier exists, systems conflate it with unrelated fields. Answering the question “is Vendor A's product the same as Vendor B's product" usually means fuzzy matching or lots of manual review rather than a database join.

Why it's distinct: This is fundamentally an identity and source data problem, separate from the data- completeness problem below, as even with perfect, complete product data from two vendors, there's often no key to reliably map product sets as like-for-like.

4. The SKU Structure Problem

(could also be described as "Configurable Rules-Driven SKUs vs. Flat SKUs” and end result is usually “SKU or Attribute Explosion")

Definition: Multiple fundamentally different ways of modeling a printable product, the most common being a flat SKU with attributes (a fixed, enumerable list of variants — size × color × print location) versus a rules-engine configurator where the choices depend on other choices already made, with thresholds, compatibility groups, and default cascades. Most creator/seller-based POD platforms are built around the first model; a lot of real-world print vendors — especially commercial/document print — operate on the second. Then there’s promo and retail…

Why this matters: This is the product data structural mismatch that makes cross-industry vendor integrations either simple or extremely hard, independent of any single product's complexity. This is why it’s hard for Platform A to integrate with Vendor A from a “new” industry and speak a common language. 

Examples:

• Apparel (usually flat SKU model): A t-shirt SKU is usually the blank, the attributes are usually ways to print on that blank. 
• Commercial/document print (rules-engine model): A single "Booklet" product might have   a page-count range of 3–740, 4 binding types, 2+ cover treatments in a dozen-plus colors each, optional folding/cutting/hole-punching — where folding *disables* hole punching, binding options are gated by page-count thresholds, and grommet count on a banner depends on both orientation and size simultaneously. This is not enumerable as flat SKUs  without either an explosion of mostly-invalid combinations or a second rules engine built just to keep the vendor integration honest.
• Home goods (blended model): A canvas print is usually close to a flat-SKU (type × size × orientation),  but framed/mounted versions add conditional logic (i.e., certain mounting options are only valid for certain sizes or substrate)

5. The Quantity-Break Problem

(alt names: "Volume-Dependent Production Rules," "Threshold Pricing & Method Switching")

Definition: Print method, file requirements, and pricing can all change based on order quantity, not just the price per unit, but which production process is even used, and how that price is composed. A single design might legitimately need two different production pipelines (and two different source files) depending on whether it's ordered as a one-off or a bulk batch. 

Why it's distinct: This crosses product data, pricing data, and file-spec data simultaneously, as a quantity threshold isn't just a price break, it can flip the entire production method and therefore the file format required.

Examples across categories:

• Apparel: Below a volume threshold, DTG is standard (raster artwork, per-unit digital printing); above it, screen printing becomes viable and often required, which needs fully vectorized artwork (e.g., EPS files) instead of raster files, a color-separation process, and materially different turnaround times. Some printers even run a hybrid ("digital squeegee") process specifically for the mid-volume range where neither pure DTG nor traditional screen printing is cost-effective. 
• Paper/commercial print: Finishing thresholds are quantity-and-thickness gated. A binder's maximum page count differs by paper stock (e.g., standard paper vs. cardstock have very different max-page ceilings for the same binder size), and past a certain page/quantity threshold, more finishing options become unavailable entirely rather than just more expensive.

Pricing composition isn't one number: the promotional-products industry's own data standard splits pricing into a dedicated service (distinct from product data) that explicitly itemizes decoration charges, setup charges, and run charges on top of base product cost. Traditional print typically runs on a quoting/estimating process. Techy POD-native platforms assume a standard base catalog cost. 

7. The Americans Don’t Use the Metric System Problem (and other unit inconsistencies)

(alt: "Measurement & File Format Standardization")

Definition: No single standard for expressing dimensions, resolution, or file types across (or even within) print — inches vs. centimeters, feet vs. inches within the same vendor's own catalog, DPI vs. PPI, raster vs. vector requirements that vary by print method — and, at the file level, no single "print-ready file" standard either. Why it's distinct: This looks like a trivial "just convert the units" problem from the outside, but it's a real source of production errors because unit ambiguity plus inconsistent internal usage (not just cross-vendor differences) causes silent misinterpretation. 

Examples across categories:

• Within a single commercial print catalog: Banners and signs are commonly sized in feet (e.g., "3ft x 5ft"), while posters and business cards from the same vendor are sized in inches (e.g., "24 x 36"). In the catalog data, no unit is attached to the raw number in much of the data so the unit has to be inferred from the product type.

File standardization is segment-specific, not universal: the Ghent Workgroup, which maintains the print industry's PDF/X file-exchange standards, publishes over a dozen different "variants" of its specification depending on whether the job is commercial offset, digital print, sign & display, or packaging. As of recently, its own specification committee is actively recruiting expertise in textile and 3D printing because those segments aren't covered yet. That's direct, named evidence that file-level standardization is significantly more mature in traditional paper/commercial print than in apparel or home-goods POD, which mostly operate without an equivalent safety net.

International/global POD: Any platform selling internationally has to reconcile paper sizes (A4/A3 vs. Letter/Legal), imperial vs. metric garment measurements, and regional color-profile conventions (e.g., CMYK variances by region), none of which have one universal standard the way currency or timezone do.

‍

Interested in how the OrderMesh team can help solve these problems for your print on demand business? Get in touch! 

‍