Entity Resolution untuk Brand Indonesia: Masalah yang Tidak Selesai dengan Schema Saja

Sebuah tim sudah melakukan semuanya yang biasanya masuk checklist teknis.

Organization schema ada.

sameAs ada.

Logo ada.

Legal name ada.

Contact point ada.

Validator hijau.

Lalu AI tetap menjelaskan perusahaan dengan data yang salah.

“Jadi schema buat apa?” tanya founder, agak kesal.

Pertanyaannya fair.

Jawabannya: schema berguna, tetapi entity resolution bukan masalah schema saja.

Entity resolution adalah proses menghubungkan berbagai nama, atribut, URL, relasi, dan sumber publik untuk menentukan apakah mereka merujuk entity yang sama atau berbeda.

Structured data bisa memberi mesin representasi yang lebih jelas tentang halaman kita.

Tetapi public identity brand hidup jauh di luar satu JSON-LD block.

Ia hidup di website, press release, marketplace, directory, profile founder, media, social account, partner page, regulator, customer review, dan historical web.

Kalau semuanya tidak konsisten, schema tidak bisa diharapkan menjadi penghapus semua konflik.

Brand Indonesia Punya Complex Identity Surface

Banyak perusahaan Indonesia tidak memakai satu nama saja.

Ada nama legal.

Nama brand.

Nama grup.

Nama product.

Nama founder yang sangat melekat.

Singkatan.

Nama cabang.

Nama toko.

Nama marketplace.

Nama social handle.

Contoh ilustratif:

Legal entity:
PT Langit Biru Teknologi Indonesia.

Brand:
LangitAI.

Product:
Langit Copilot.

Marketplace:
Langit Official.

LinkedIn:
Langit AI Indonesia.

Media:
Langit Teknologi.

Dalam kepala internal, semua jelas.

Di web, sistem melihat beberapa strings dan harus membangun relationship.

Jika official website tidak pernah menjelaskan:

“LangitAI adalah brand milik PT Langit Biru Teknologi Indonesia,”

machine harus infer.

Kadang benar.

Kadang tidak.

Schema Membantu Menyatakan, Bukan Membuktikan Sendirian

Organization structured data dapat membantu search system memahami detail administratif organisasi dan disambiguate organization.

Itu valuable.

Kita bisa menyatakan:

name.

legalName.

url.

logo.

sameAs.

identifier.

address.

founding information bila appropriate.

Tetapi structured data adalah statement dari publisher sendiri.

Mesin masih bisa melihat public ecosystem.

Kalau schema bilang headquarters Jakarta tetapi contact page Bandung dan LinkedIn Surabaya, conflict muncul.

Kalau schema bilang product A tetapi visible page tidak pernah menyebut product tersebut, markup tidak selaras dengan content.

Google juga menekankan structured data harus merepresentasikan content yang visible dan tidak misleading.

Jadi schema bukan invisible cheat layer.

Ia harus mencerminkan truth yang sudah ada.

Entity Resolution Butuh Canonical Identity Page

Banyak website punya About page yang terlalu generik.

“Kami hadir untuk memberikan solusi terbaik.”

“Sejak berdiri, kami berkomitmen pada inovasi.”

Tidak ada yang salah secara branding.

Tetapi dari sisi entity, page itu miskin informasi.

Canonical entity page perlu menjawab dengan natural:

Siapa organisasi ini?

Nama legalnya apa jika relevant?

Brand name apa?

Domain resmi apa?

Apa yang dilakukan?

Di mana beroperasi?

Produk atau layanan utama?

Relationship dengan group/parent/subsidiary?

Founder/leadership jika public dan relevant?

Kapan rebrand terjadi?

Apa source resmi untuk press/contact?

Tidak harus seperti Akta Pendirian.

Tetap feature-readable.

Tetapi facts harus cukup untuk distinguish entity.

Ambil Adegan di Ruang Meeting

Head of marketing:
“Kenapa AI masih bilang kita agency? Kita sekarang SaaS.”

Product lead:
“Website lama masih punya 60 artikel agency.”

Developer:
“Schema homepage udah SaaS.”

PR:
“Media 2024 masih nyebut kita agency.”

Founder:
“Jadi kita harus hapus semua sejarah?”

Tidak.

Justru relationship harus dijelaskan.

“Company evolved from agency model into SaaS platform in year X,” jika faktanya memang begitu dan bisa didukung.

Historical truth tidak perlu dihapus.

Yang perlu dihindari adalah public web punya dua present-tense identities yang sama kuat tanpa timeline.

Entity resolution butuh temporal context.

Nama Legal dan Brand Jangan Dipaksa Sama

Kesalahan lain adalah menghapus legal name karena takut membingungkan AI.

Padahal legal name punya fungsi.

Brand punya fungsi lain.

Schema.org bahkan menyediakan legalName sebagai property untuk official registered name organisasi.

Yang perlu dilakukan adalah relationship yang jelas.

Brand X is operated by PT Y.

Atau:

PT Y, trading as Brand X.

Sesuaikan dengan fakta dan legal context.

Jangan membuat wording yang salah secara hukum.

Jika legal relationship kompleks, libatkan legal team.

Entity clarity tidak boleh mengorbankan accuracy.

Founder Bukan Organization

Di bisnis founder-led, personal brand kadang lebih besar daripada company.

Media menulis founder.

Podcast memakai nama founder.

Social media lebih aktif di account founder.

Website company tipis.

AI kemudian menjelaskan company melalui person.

Ini bisa useful tetapi juga risk.

Person dan Organization adalah entity berbeda.

Hubungkan:

Founder of.

CEO of.

Board member.

Spokesperson.

Bukan sameAs.

sameAs berarti identity yang sama.

Founder bukan company.

Hubungan yang tepat lebih penting daripada memaksa semua URL masuk satu bucket.

Product Juga Bukan Organization

Brand punya product dengan nama mirip.

Contoh:

Company: Atlas.

Product: Atlas AI.

Service: Atlas Pro.

Jika schema dan content tidak membedakan, AI bisa menganggap product sebagai company.

Canonical architecture perlu type clarity.

Organization page.

Product page.

Service page.

Person page.

Relationship.

Jangan semua page diberi Organization hanya karena brand ingin “entity kuat”.

Type yang salah menciptakan graph yang salah.

Indonesia Punya Masalah Nama Usaha Generik

Nama generik memperbesar ambiguity.

“Sumber Jaya.”

“Mitra Abadi.”

“Nusantara.”

“Garuda Digital.”

“Karya Teknologi.”

Banyak kemungkinan collision.

Entity resolution membutuhkan attributes tambahan.

Legal registration details bila public and appropriate.

Location.

Industry.

Official domain.

Phone.

Logo.

Founding date.

Founder.

Unique identifier.

Branch structure.

Tetapi privacy dan relevance tetap penting.

Jangan publish data sensitif hanya demi machine clarity.

Public identity harus cukup, bukan berlebihan.

Third-Party Consistency Tidak Berarti Semua Harus Identik

Ini nuance.

LinkedIn description tidak harus copy homepage.

Media tidak harus memakai wording yang sama.

Directory bisa lebih singkat.

Yang perlu konsisten adalah core facts.

Nama.

Industry/category.

Location.

Official website.

Current status.

Product relationship.

Legal relation.

Leadership if stated.

Diversity of wording is fine.

Contradiction of facts is not.

Jangan mengejar keyword consistency.

Kejar entity consistency.

Schema Validation Tidak Sama dengan Entity Validation

Rich Results Test atau validator menjawab technical questions.

Syntax valid?

Required properties ada?

Type recognized?

Itu bukan proof bahwa entity representation benar.

Entity validation perlu human audit.

Apakah URL official?

Apakah sameAs benar-benar same entity?

Apakah legalName current?

Apakah address operational atau registered?

Apakah product relationship benar?

Apakah person role current?

Apakah legacy name documented?

Technical validation adalah satu layer.

Semantic validation layer lain.

Keduanya wajib.

Knowledge Graph Internal Bisa Membantu Governance

Untuk organisasi besar, buat internal entity registry.

Tidak harus public.

Record:

Entity ID.

Type.

Canonical name.

Legal name.

Aliases.

Official URLs.

Parent.

Subsidiary.

Products.

Founders/leaders.

Locations.

Status.

Effective dates.

Evidence source.

Ini menjadi source of truth untuk content team dan developer.

Ketika website membuat structured data, data berasal registry.

Ketika PR menulis company description, facts sama.

Ketika marketplace profile update, reference sama.

Entity resolution dimulai dari internal governance.

Kalau internal team sendiri punya lima versi nama company, web pasti ikut kacau.

Entity Drift Harus Dipantau

Brand berubah.

CEO berganti.

Office pindah.

Product discontinued.

Company acquired.

Subsidiary merger.

Rebrand.

Kalau change tidak dipropagasi ke public sources, old facts tetap hidup.

AI bisa menarik old version.

Buat change workflow.

Saat entity fact berubah:

Update canonical page.

Update structured data.

Update contact/about.

Update relevant product pages.

Update official profiles.

Issue public announcement if material.

Notify partner/directories if practical.

Monitor AI output.

Entity resolution bukan one-time project.

Ia maintenance.

SameAs Harus Curated

Schema.org mendefinisikan sameAs sebagai URL reference page yang secara tidak ambigu menunjukkan identity item.

Jadi list sameAs sebaiknya curated.

Masukkan:

Official social profile yang jelas.

Wikidata/Wikipedia jika memang valid entity page.

Authoritative directory/profile yang benar-benar same entity.

Jangan masukkan:

Founder profile.

Product listing.

Random article.

Partner page.

Competitor.

Search result.

Page yang cuma menyebut brand.

Banyak URL tidak otomatis lebih baik.

Clarity > quantity.

Evidence di Luar Website Penting

Website adalah self-asserted source.

Third-party evidence membantu corroboration.

Media.

Industry association.

Regulator.

Conference.

Research.

Partner.

Client case study with consent.

Directory terpercaya.

Tetapi jangan membuat link scheme hanya demi entity.

Hubungan publik harus genuine.

Kalau brand mengaku “award-winning” tetapi tidak ada source award, problem.

Kalau brand mengaku partner company besar tetapi partner tidak pernah menyebut, claim lebih lemah.

Entity resolution adalah tentang identity.

Trust layer adalah tentang evidence.

Keduanya saling mendukung.

AI Audit Harus Menguji Disambiguation, Bukan Cuma Mention

Query testing:

Brand name.

Brand + industry.

Brand + location.

Brand + product.

Brand + founder.

Legal name.

Old name.

Compare outputs.

Catat:

Correct entity.

Mixed entity.

Wrong entity.

Source.

Critical facts.

Confidence.

Repeat runs.

Kalau wrong entity hanya pada nama pendek, mungkin natural ambiguity.

Kalau wrong pada legal name + official domain, serious.

Testing membantu memprioritaskan.

Jangan memperbaiki semua public web tanpa tahu titik confusion.

Entity Resolution Tidak Sama dengan “Masuk Knowledge Graph Google”

Tim sering menyederhanakan:

“Kalau entity sudah benar, kita masuk Knowledge Graph.”

Kita tidak punya akses penuh untuk melihat semua internal representations search system.

Jangan membuat claim yang tidak bisa diverifikasi.

Kita bisa mengoptimalkan identity clarity.

Structured representation.

Public consistency.

Evidence.

Canonical relationships.

Kemudian observe Search/AI behavior.

Itu defensible.

Jangan menjanjikan node tertentu di internal system.

Operational goal lebih useful:

Sistem eksternal semakin konsisten mengenali siapa kita.

Itu bisa diuji.

Bukan cuma dibayangkan.

Schema adalah Bagian dari Stack, Bukan Seluruh Stack

Entity resolution stack untuk brand Indonesia kira-kira:

Internal source of truth.

Canonical website content.

Structured data.

Public profiles.

Third-party references.

Temporal updates.

Relationship mapping.

Redirect/canonical governance.

Monitoring.

AI observation.

Human audit.

Schema duduk di tengah.

Penting.

Tetapi bukan fondasi tunggal.

Kalau source of truth internal salah, schema mempercepat penyebaran salah.

Kalau content inconsistent, schema konflik.

Kalau third-party outdated, ecosystem tetap fragmented.

Kalau relationship tidak jelas, sameAs bisa salah pakai.

Kapan Masalah Dianggap Membaik?

Bukan ketika validator hijau.

Bukan ketika schema deployed.

Bukan ketika satu query benar.

Gunakan observation.

Repeated queries.

Cross-model.

Across time.

Entity accuracy.

Source consistency.

Hallucination frequency.

Jika wrong-entity rate turun dan correct identity bertahan, kita punya evidence improvement.

Masih jangan overclaim causality.

Tetapi operational result jelas.

Balik ke Meeting Awal

Founder tadi bertanya:

“Jadi schema buat apa?”

Jawabannya:

Schema membantu mesin membaca statement terstruktur tentang entity.

Tetapi company identity tidak hidup di schema saja.

Ia hidup di seluruh jejak publik.

Jika ingin AI memahami brand dengan benar, jangan hanya bertanya:

“Markup kita valid?”

Tanya juga:

“Apakah seluruh web punya cukup alasan untuk percaya bahwa semua nama, domain, produk, orang, dan lokasi ini memang terhubung seperti yang kita klaim?”

Entity resolution dimulai dari sana.

Schema membantu.

Consistency menguatkan.

Evidence mengoreksi.

Monitoring memastikan perubahan benar-benar terlihat.

Masalahnya tidak selesai dengan satu script.

Karena identitas brand sendiri memang lebih besar daripada script.