Entity Graph untuk Produk dengan Banyak Varian

Satu sepatu, lima warna, sebelas ukuran.

Satu laptop, tiga kapasitas storage, dua warna, empat konfigurasi RAM.

Satu skincare serum, tiga ukuran kemasan.

Satu mobil, beberapa trim, warna, drivetrain, dan tahun model.

Bagi manusia, kita masih bisa bilang: “Itu produk yang sama, cuma variannya beda.”

Bagi sistem data, kalimat itu harus dijelaskan lebih presisi.

Mana parent product?

Mana variant?

Atribut apa yang membuat satu variant berbeda dari yang lain?

Apakah setiap variant punya SKU sendiri?

GTIN sendiri?

Harga sendiri?

Stok sendiri?

URL sendiri?

Dan kapan perbedaan sudah terlalu besar sehingga seharusnya dianggap produk berbeda, bukan varian?

Kalau product graph tidak punya jawaban yang konsisten, masalahnya bukan cuma schema. Feed commerce, internal search, catalog, marketplace, recommendation engine, dan AI agent bisa ikut mencampur produk.

Entity graph untuk product variants perlu memisahkan identity dari variation.

Product Group Bukan Sekadar Folder

Schema.org mendefinisikan ProductGroup sebagai kelompok Product yang berbeda hanya dalam dimensi tertentu yang bisa dijelaskan, misalnya size, color, material, atau atribut sejenis.

Google juga mendokumentasikan ProductGroup bersama `variesBy`, `hasVariant`, dan `productGroupID` untuk membantu merepresentasikan product variants.

Prinsipnya sederhana:

Ada satu kelompok.

Di dalamnya ada variant.

Variant berbeda pada atribut yang memang didefinisikan.

Ini lebih kuat daripada membuat 40 Product tanpa relationship lalu berharap mesin menebak bahwa semuanya keluarga yang sama.

Tetapi ProductGroup bukan excuse menggabungkan semua produk yang “mirip”.

iPhone generasi berbeda?

Mungkin bukan sekadar color variant.

Sneaker model A dan sneaker model B?

Beda product family.

Laptop 13 inch dan 16 inch dengan architecture berbeda?

Perlu business/product judgment.

Variant relationship harus mengikuti catalog truth.

Mulai dari Internal Product Identity

Sebelum schema, lihat database.

Contoh:

Parent:
KORA Runner 2

Group ID:
KR2

Variants:
KR2-BLK-40
KR2-BLK-41
KR2-WHT-40
KR2-WHT-41

variesBy:
color
size

Sekarang graph bisa dibaca.

ProductGroup:
KORA Runner 2.

Variant:
KORA Runner 2 Black Size 40.

Variant:
KORA Runner 2 White Size 41.

Each variant punya:

SKU.

GTIN if applicable.

Color.

Size.

Offer.

Availability.

Image.

Maybe URL.

Brand tetap sama.

Product group ID sama.

Ini clean.

Masalah muncul ketika spreadsheet berbeda menggunakan ID berbeda.

ERP:
KR2.

Website:
RUNNER2.

Marketplace:
KORA-R2.

Feed:
KRR-2026.

AI agent tidak “tahu” semuanya sama tanpa mapping.

Entity graph harus menjadi reconciliation layer.

Variant Identity Harus Stabil

Harga berubah.

Stok berubah.

Variant identity seharusnya tidak ikut berubah.

SKU yang stabil membantu.

GTIN jika valid.

MPN jika relevant.

ProductGroup ID.

Canonical URL.

Brand.

Attribute combination.

Jangan membuat SKU baru setiap kali price berubah.

Jangan memakai price sebagai identity.

Identity dan state adalah dua layer.

Identity:
Apa produknya?

State:
Berapa harga sekarang?
Ada stok?
Promo?
Delivery?

Agentic commerce makin menuntut distinction ini karena agent dapat perlu mengecek state terbaru sebelum action.

Graph yang mencampur identity dengan state menghasilkan stale confirmation.

URL Strategy Harus Diputuskan

Ada tiga pattern umum.

Satu URL untuk semua variants.

URL berubah parameter.

Satu URL per variant.

Semua bisa valid tergantung platform.

Yang penting consistency.

Jika satu URL:
Selected variant represented via page state.

If variant URLs:
Canonical relationships and product-group relation must be clear.

Google product variant documentation membahas dukungan untuk single-page dan multi-page website patterns.

Jadi tidak ada satu architecture wajib untuk semua store.

Business, UX, crawling, feed, dan inventory system harus sinkron.

Jangan membangun URL variant hanya karena schema mendukung.

User value dulu.

Variant Page Jangan Menjadi Thin Duplicate

Kalau setiap size punya URL:

/shoe-black-size-40/
/shoe-black-size-41/
/shoe-black-size-42/

Content hampir identik.

Ini bisa menghasilkan banyak page low-information.

Better architecture mungkin satu product page dengan selectable size.

Untuk some categories, separate variant URL berguna karena color mempunyai image, inventory, or query demand sendiri.

Again, graph design mengikuti product reality.

Entity-first bukan page-count-first.

One real variant can be one node even if not one indexable page.

Graph dan web page tidak harus one-to-one.

Brand, Manufacturer, Merchant Jangan Dicampur

Product graph sering kacau di commerce.

Brand:
KORA.

Manufacturer:
PT Kora Footwear.

Merchant:
Toko ABC.

Marketplace:
Platform M.

Product:
KORA Runner 2.

Offer:
Toko ABC sells KR2-BLK-40.

These are distinct entities.

Don't make merchant sameAs brand.

Don't make marketplace owner product.

Agent yang mencari:

“Siapa menjual product ini?”

butuh merchant.

“Siapa brand?”

butuh Brand.

“Siapa produsen?”

manufacturer.

“Apakah official store?”

relationship merchant-to-brand.

Entity graph harus bisa menjawab without collapsing.

Dialog yang Sering Terjadi di Commerce Team

Merchandiser:
“Black dan white satu product.”

Developer:
“ERP bilang dua SKU.”

SEO:
“Google maunya ProductGroup.”

Operations:
“Stock-nya per size.”

Data engineer:
“Berarti parent, variant, offer, inventory dipisah.”

Semua benar.

Product language manusia:
Satu product.

Operational database:
Many sellable units.

Graph menjadi bridge.

Tidak perlu memaksa satu worldview menang.

Model layer yang baik mengakomodasi keduanya.

Variant Dimensions Harus Canonical

Color naming bisa messy.

Black.

Jet Black.

Midnight.

Blk.

Hitam.

#000000.

Apakah sama?

Internal graph perlu canonical value.

Display label:
Midnight Black.

Color family:
Black.

Variant code:
BLK.

This helps feed mapping.

Size juga.

EU 40.

US 7.

CM 25.

Product-specific conversion.

Don't casually merge.

Variant identity depends on exact dimension values.

For fashion, size/color.

For electronics:
RAM/storage/color.

For furniture:
material/size/color.

For travel package:
Maybe not Product variant at all, depending business semantics.

Don't generalize.

Variant Rules Need Product-Type Policy

Set policy per catalog category.

Apparel:
size, color, material.

Electronics:
capacity, memory, color, connectivity.

Food:
flavor, pack size.

Beauty:
shade, volume.

Automotive:
trim, engine, drivetrain.

Then define when new dimension creates:

Variant.

New ProductGroup.

Separate Product.

This avoids each content editor deciding manually.

Graph consistency is governance.

Not markup syntax.

ProductGroup ID Jangan Berubah karena Redesign

Website redesign.

Slug change.

CMS migration.

Product group same.

Keep stable internal ID.

Public canonical URL can change with redirect.

But graph can map old URL → same entity.

If productGroupID also arbitrarily changes, history breaks.

Analytics.

Feed.

Reviews.

External references.

AI source reconciliation.

Stable identifier matters.

Version product data separately.

Identity persists.

Offer Is Not Product

This error creates commerce confusion.

Product:
KORA Runner 2 Black 40.

Offer A:
Merchant X sells at price A.

Offer B:
Merchant Y sells at price B.

Stock differs.

Price differs.

Product same.

If product entity includes one merchant price as permanent identity, graph stale.

Offers need timestamps/state.

For first-party store, Product and Offer live closely but still conceptually distinct.

Agent deciding purchase needs current Offer.

Entity graph tells what.

Commerce feed tells current transaction state.

Reviews Harus Menempel ke Level yang Tepat

Review can target:

ProductGroup.

Specific variant.

Merchant.

Order experience.

Brand.

Do not aggregate blindly.

Example:
“Color fades quickly.”

Maybe only red variant.

If review attached to all variants, misleading.

Graph can store review subject.

Variant-level review.

Group-level rating if platform legitimately aggregates.

Seller review not product review.

AI agents may summarize reviews.

Wrong attachment becomes misinformation.

Images juga Variant-Specific

Black shoe image should not represent white variant.

Variant graph can map:

Variant → image set.

ProductGroup → hero/general image.

This matters for visual shopping.

Structured data and product feeds should align.

Don't use same generic image for all if actual variation important.

Again, not ranking trick.

Accurate product representation.

Availability Is State, Not Identity

Stock:
in stock.

out of stock.

preorder.

backorder.

Changes frequently.

Graph may reference state service, but canonical entity shouldn't need new node each stock change.

Store timestamp.

Last verified.

Inventory source.

Agent queries fresh state.

This is especially important if AI agent performs purchase-oriented task.

Stale inventory can cause failed action.

Identity machine-readability becomes operational, not just search.

Variant Discontinuation Needs Lifecycle

ProductGroup active.

One color discontinued.

Don't delete variant identity if orders, reviews, or links exist.

Status:
discontinued.

Offer unavailable.

Replacement if any.

Legacy page maybe.

Agent should not recommend unavailable variant as current.

Search result may still show old page.

Visible page must say status.

Structured data/feed should align.

Temporal graph.

Same principle as entity drift.

Multi-Market Variants

Indonesia has storage 256/512.

Singapore has 128/256/512.

Color A only Japan.

Product identity can be global.

Offer/availability market-specific.

Don't create fake separate Product because market availability differs unless SKU actually differs.

Graph:

Product variant global.

Offer by market.

Merchant by market.

Price currency.

Inventory.

Local regulatory name.

This allows agent answer:

“Variant exists, but not officially available in Indonesia.”

Much better than false absence or false availability.

Product Variant and Localization

Name:
“Midnight Black.”

Indonesia marketing:
“Hitam Midnight.”

Still same color variant if product identity same.

Use aliases.

Don't create duplicate variant nodes just because language changes.

Canonical IDs prevent localization fragmentation.

Pages can translate.

Entity remains.

This is exactly where entity-first design helps multi-country ecommerce.

Knowledge Graph Bukan Alasan Menambah Semua SKU ke Public Schema

Catalog may have 500,000 SKUs.

Public page should represent products that are actually shown.

Do not dump internal discontinued/private SKUs into HTML just because graph has them.

Public projection follows page content.

Internal graph can be richer.

Feed can include eligible commerce items.

Website schema should match visible product context.

Separate systems.

Audit Product Variant Graph

For sample product groups, check:

Group ID stable?

Variant IDs unique?

variesBy correct?

No duplicate SKU?

GTIN mapping correct?

Brand correct?

Manufacturer correct?

Merchant not confused?

Offer separate?

Availability current?

Variant URL canonical?

Images variant-specific?

Discontinued status?

Market availability?

Reviews subject correct?

If any red, fix source data before adding more markup.

Bad source data + perfect JSON-LD = structured bad data.

AI Agent Use Case Membuat Identity Lebih Serius

Traditional search user might click product page and manually select.

Agent may need to act.

“Buy black size 41 under Rp2 million.”

Now system must resolve:

Which product group?

Which black?

Which size standard?

Which merchant?

Which offer?

Current stock?

Currency?

Shipping?

Identity error becomes transaction error.

This is why canonical product identity matters beyond SEO.

Agentic systems need stable entity boundaries.

But don't jump to claim “ProductGroup schema makes agents buy your product.”

No universal guarantee.

What we can say:

Machine-readable, consistent product identity reduces ambiguity for systems consuming catalog data.

That is defensible.

Schema ProductGroup Is One Projection, Not the Whole Graph

Internal graph may have richer relationships.

Variant compatibility.

Regional SKU.

Supplier.

Lifecycle.

Inventory source.

Merchandising hierarchy.

Public Schema.org representation exposes relevant subset.

ProductGroup.

hasVariant.

variesBy.

Product.

brand.

offers.

Identifiers.

Keep within vocabulary and visible truth.

Do not invent public properties because internal graph has edge.

Entity graph should map, not leak.

Human Page Must Still Be Good

Don't let variant modeling ruin shopping experience.

User wants:

Photos.

Price.

Availability.

Size.

Color.

Comparison.

Delivery.

Return.

Clear selection.

Graph works underneath.

Schema works underneath.

Feed works underneath.

If user cannot tell which variant they selected, architecture failed even if validator green.

Human and machine identity should converge.

The Best Product Graph Answers One Simple Question

“Apakah dua sellable items ini variant dari product yang sama, atau produk berbeda?”

If team can answer consistently, everything else becomes easier.

If answer changes by department, fix governance.

Product.

Variant.

Offer.

Merchant.

Brand.

Manufacturer.

Market.

State.

Separate these nodes.

Then connect them.

That is the foundation for product identity that survives marketplaces, feeds, search, and increasingly agentic interfaces.

Not more schema.

Better product truth.