Electronics and consumer tech — Guides

Electronics has the largest required-attribute set of any commerce category. A $30 USB cable can carry twelve attributes that affect surfacing — wire gauge, length, connector type on each end, data transfer rate, power delivery rating, certifications. A $3,000 camera carries fifty. The catalog operators that win in AI search are the ones that treat attribute coverage as a product-by-product implementation task, not a one-time data import.

This guide covers the attribute stack for electronics and consumer tech, the schema patterns that map them, and the failure modes that keep otherwise-strong catalogs out of AI agent recommendations.

What “electronics” means here

Five sub-verticals with overlapping but distinct attribute needs:

Computing and peripherals — laptops, monitors, keyboards, cables, storage. Compatibility is the dominant attribute (works with what?).
Audio — headphones, speakers, microphones. Specs (frequency response, impedance) and use case (gaming, studio, casual) drive surfacing.
Cameras and imaging — system compatibility (mount, sensor format), specs (megapixel, ISO range), accessory compatibility.
Smart home — protocol compatibility (Matter, Zigbee, Z-Wave, HomeKit, Alexa). Without protocol attributes, the product surfaces for generic queries but never for the “works with [system]” queries that drive purchases.
Mobile accessories — device compatibility lists (works with iPhone 15, iPhone 16, Pixel 8, etc.). The list itself is the product’s identity.

This guide focuses on what’s common across all five. Camera mount-system specifics, smart-home protocol details, and mobile device compatibility lists each warrant their own treatment in follow-up content.

The eight electronics attributes

Ranked by impact on AI agent surfacing for electronics queries:

1. Brand

The single most-weighted electronics attribute. AI agents handle electronics queries with strong brand recall (“Sony WH-1000XM5”, “MacBook Pro M4”). Catalogs without brand populated lose surfacing in branded queries even when every other attribute is complete.

2. Model number (`mpn`)

Specific to the product variant — WH-1000XM5/B (black) vs. WH-1000XM5/S (silver). mpn is how AI agents disambiguate model generations and color/storage variants of otherwise-identical products.

3. GTIN (`gtin13`)

Universal product identifier. For brand-name electronics this is non-negotiable; the manufacturer assigns the GTIN and every reseller should use it. Catalogs that invent SKUs and skip GTINs compete with their own resellers and lose every time.

4. Compatibility

The attribute electronics catalogs most consistently underweight. Compatibility data lives in additionalProperty arrays:

"additionalProperty": [
  {
    "@type": "PropertyValue",
    "name": "Compatible with",
    "value": "iPhone 15, iPhone 16, Pixel 8, Pixel 9"
  },
  {
    "@type": "PropertyValue",
    "name": "Connector type",
    "value": "USB-C"
  }
]

For accessories, compatibility is the product. Compatibility-intent queries (“USB-C cable for MacBook Pro M4”) depend on the structured compatibility attributes being populated and parseable rather than buried in prose.

5. Technical specs

Category-specific specs that buyers compare on. For audio: frequency response, impedance, sensitivity. For displays: resolution, refresh rate, panel type. For storage: capacity, read/write speeds, interface.

The Schema.org pattern: additionalProperty array with one PropertyValue per spec, named consistently across the catalog so AI agents can compare across products.

6. Certifications

Important for safety-related electronics — UL listing, FCC, RoHS, Energy Star, EPA. For audio: Hi-Res certification, THX. For gaming peripherals: TÜV-rated refresh rate.

Same additionalProperty pattern. Certification-intent queries (“Energy Star monitor”, “UL-listed power strip”) depend on the certification appearing as a structured attribute rather than only in marketing copy.

7. In-the-box contents

What ships with the product. Important for buyers comparing “complete kits” vs. “body only” purchases.

8. Power requirements

For powered devices: voltage, amperage, plug type. For battery- powered: battery type, capacity, included or sold separately.

The schema pattern

Built on the Product schema base, extended with electronics-specific properties:

{%- assign variant = product.selected_or_first_available_variant -%}
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": {{ product.title | json }},
  "description": {{ product.description | strip_html | json }},
  "sku": {{ variant.sku | json }},
  "mpn": {{ product.metafields.product.mpn | json }},
  {%- if variant.barcode -%}
  "gtin13": {{ variant.barcode | json }},
  {%- endif -%}
  "brand": {
    "@type": "Brand",
    "name": {{ product.vendor | json }}
  },
  "category": "Electronics > {{ product.product_type }}",
  "additionalProperty": [
    {%- if product.metafields.product.model_year -%}
    {
      "@type": "PropertyValue",
      "name": "Model year",
      "value": {{ product.metafields.product.model_year | json }}
    },
    {%- endif -%}
    {%- if product.metafields.product.compatibility -%}
    {
      "@type": "PropertyValue",
      "name": "Compatible with",
      "value": {{ product.metafields.product.compatibility | json }}
    },
    {%- endif -%}
    {%- if product.metafields.product.connector_type -%}
    {
      "@type": "PropertyValue",
      "name": "Connector type",
      "value": {{ product.metafields.product.connector_type | json }}
    },
    {%- endif -%}
    {%- if product.metafields.product.certifications -%}
    {%- for cert in product.metafields.product.certifications.value -%}
    {
      "@type": "PropertyValue",
      "name": "Certification",
      "value": {{ cert | json }}
    }{%- unless forloop.last -%},{%- endunless -%}
    {%- endfor -%}
    {%- endif -%}
  ],
  "offers": {
    "@type": "Offer",
    "url": {{ shop.url | append: product.url | json }},
    "priceCurrency": {{ cart.currency.iso_code | json }},
    "price": {{ variant.price | divided_by: 100.0 | json }},
    "availability": {%- if variant.available -%}
      "https://schema.org/InStock"
    {%- else -%}
      "https://schema.org/OutOfStock"
    {%- endif %},
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

The pattern scales — for each new technical spec the catalog needs to expose, add a metafield, populate it per product, render conditionally in the additionalProperty array.

Reviews

Electronics is a comparison-shopping category — buyers frequently make decisions by comparing competing products’ specs, prices, and reviews. The structured review data (aggregateRating and the underlying review HTML) is one of the inputs that downstream commerce surfaces read.

The exact weighting AI agents apply to review structured data when generating product comparisons is not publicly documented. What is documented is that Google Merchant Center reads aggregate ratings, Bing reads them via its structured-data documentation, and review HTML rendered server-side is what indexers can read. Stripping review schema removes the input that feeds those indexed surfaces.

Catalog-side discipline:

Populate aggregateRating from real review data only. Faking it is a Google Merchant Center policy violation.
Render the underlying review HTML server-side rather than only in a JavaScript widget.
For accessory catalogs running third-party reviews providers, watch for duplicate aggregateRating injection from the provider plus the theme’s own schema layer — pick one source.

See Review and AggregateRating schema after Google’s 2024 changes for the breakdown of which surfaces continue to read review schema after Google’s narrowing.

Q&A pairs as a sibling FAQPage block

Electronics pages typically carry compatibility Q&A — “will this work with X,” in-the-box clarification, setup difficulty. When the catalog has this content, render it as a sibling FAQPage JSON-LD block alongside the Product block. The two are separate Schema.org types; they sit as peer <script type="application/ld+json"> blocks on the same page, not nested. See Product schema for Shopify for the rendering pattern.

The contrarian take

Most electronics SEO content focuses on title optimization (model numbers in titles, etc.). Title optimization helps a little; what matters more is the additionalProperty array. AI agents querying “USB-C cable with 100W power delivery” embed against the structured data, not the title. A title with “100W” in it but no additionalProperty value scores worse than a title without “100W” that has the value structured.

The right work is metafield definition and population: define every spec a buyer would compare on, populate it per product, render it into additionalProperty. Title optimization is the smaller lever.

Where it breaks

Refurbished and used inventory. Two enums to keep straight: Schema.org’s OfferItemCondition uses the IRI form (https://schema.org/NewCondition, UsedCondition, RefurbishedCondition, DamagedCondition); Google Merchant Center accepts the short tokens (new, refurbished, used, damaged). Catalogs that mix new and refurbished inventory often default everything to the new value, which is technically incorrect and costs surfacing on refurbished-intent queries.
Bundle products. Camera kits with body, lens, and accessories don’t fit the standard Product model cleanly. Sell each bundle as its own SKU with a clear additionalProperty listing the contents.
Software and digital products. Use SoftwareApplication schema for downloadable software; it carries operating-system, version, and requirements fields that the generic Product type doesn’t.
Pre-orders and pre-announced products. Use availability: PreOrder and availabilityStarts to signal launch date — without these, the product surfaces in current-availability queries and fails to deliver.

What to ship this week

Audit the top 20 SKUs by revenue. Identify which of the eight attributes are populated and which aren’t.
Define metafields for the missing attributes. Start with compatibility (highest impact) and model_year (easiest to backfill).
Update the Liquid template (or the equivalent in your platform) to render the additionalProperty array.
Sync the new attributes to GMC via the supplemental feed.
Validate ten products end-to-end.

The work scales with catalog size and how much of the underlying attribute data is already in the catalog. Track the AI surfacing shift in your own analytics rather than expecting a specific timeline.