You’re combining course listings from several sources, and two of them carry the title “Introduction to Sustainability”: one from an aggregator, one from a university’s own site. If they are one course published in two places, they belong in a single listing. If they are two unrelated courses with a generic name, merging them makes one of them disappear.
Table of Contents
Two opposite errors, with different costs
- A wrong merge (two different courses treated as one): a real product vanishes, folded into another. It’s hard to notice later, because the folded item looks handled.
- A wrong split (one course listed as two): the same course appears twice, with its reviews and offers divided between the copies. Ugly, but visible and cheap to fix.
A wrong merge hides a product and a wrong split merely duplicates one, so the safe default under uncertainty is to keep listings separate. Merge only when the evidence is strong. Treat merging as the operation that needs scrutiny and splitting as the forgiving one.
A wrong merge hides a product; a wrong split only duplicates one. When in doubt, keep them apart.
Why the title can’t decide
A title is a label, and labels collide for two unrelated reasons. A re-hosted course carries the same title because it is the same course. A coincidence shares a title because the subject is generic: “Project Management”, “Financial Accounting” and “Business Statistics” exist independently at dozens of institutions. The string is identical in both cases, so matching titles can only tell you a pair is worth a look, never that it’s the same course.
Real identity lives in the source’s own stable identifier, such as a course code in the URL, an enrollment key or a provider field, and in the content behind it. A shared title is one more case of a catalog label that lies: treat it as a hint, never as the identity.
Same title on two or more different stores.
Source's own id / course code + the content, not the title.
One store's name in another's URL; matching content. One entry, many offers.
Distinct institutions & codes, different syllabi. Separate entries.
A wrong merge HIDES a product; a wrong split only duplicates one. Under doubt, keep apart; merge only on strong evidence.
Signs that a course really is re-hosted
Syndication leaves traces that a coincidence doesn’t:
The strongest re-host signal is one store’s name sitting inside another’s URL or course key.
- One store’s name inside another’s identifier. An aggregator re-hosting a partner’s course often puts the partner’s name in the URL or course key (
.../partner-name-course-slug). It’s the strongest single signal, because the host is saying outright whose course this is. - Matching content, not just a matching title. Compare both descriptions, the durations and the instructors. A re-host reads as the same course (same summary, same teacher, same structure) once you allow for each store’s formatting. A coincidence diverges at once: different institutions, different syllabi, different lengths.
- A shared upstream code. If both records trace back to the same provider code or the same original page, they are one course. Distinct codes from distinct institutions point to a coincidence.
A typical coincidence looks like this: two universities, each with its own course number, two different instructors, two different syllabi, and the same three words in the title.
Don’t trust a cheap signal on its own
An automatic “is this a re-host?” filter helps you sort the pile, but it’s noisy, and the noise is instructive. A plain substring match fires when one store’s name is contained in another’s: a store called “OpenLearn” matches “OpenLearning”, a different platform. A match on hosting fires when two sources merely run on the same infrastructure. Treat any such signal as a candidate, then check the content before you merge. A false merge costs you a hidden product; a thirty-second look at two descriptions is cheaper.
The same goes for automatic grouping by title. A tool that proposes merges from title matches will over-group, so use it to generate candidates and never as the decision. Many proposed groups turn out to be coincidences, and a few bundle three genuinely different courses under one generic name. Confirm each group, reject the false ones, and split the mixed ones apart.
When you do merge, choose the main listing on purpose
Merging several offers of one course means choosing which listing is the main one: it keeps its URL and supplies the description, and the others become alternative offers on it. Choose it with a rule you can explain, such as the most visited edition, the one with the fullest description, or the original source over the re-host. Then record that choice. If you leave it to whichever record your system saw first, the next full rebuild of the catalog can quietly make a different listing the main one and change its URL.
The short version
A title shared across different stores is either one course re-hosted (merge into one entry with several offers) or two courses with the same generic name (keep separate entries), and the title can’t tell them apart. Decide on the source’s own identifier and the content: a re-host puts one store’s name in another’s identifier and matches on description, duration and instructor, while a coincidence comes from distinct institutions with distinct codes. A wrong merge hides a product and a wrong split only duplicates one, so keep listings apart by default and merge only on strong evidence. Treat any automatic match as a candidate, and when you merge, pick and record the main listing.
Frequently Asked Questions
The two listings are the same course but show different prices. Is that a problem?
No. Price, start date and enrollment terms belong to each offer, not to the course. A re-hosted course often costs something different on the aggregator than on the provider’s own site, and a merged entry should keep both as separate offers so a reader can compare them. Different prices are not evidence that the courses differ; check the identifier and the content as usual.
Does the same check work for products other than courses?
Yes. Any catalog that pulls listings from several sources, such as books, software plans or event tickets, meets the same two cases. Look for the source’s own identifier first (an ISBN, a vendor SKU, an event ID) and use the title only to find pairs worth checking.
