What Is programName Schema?

programName is a Schema.org Text property that names the program providing a ProgramMembership.

It belongs on ProgramMembership and accepts a simple string such as a loyalty program name. The property remains available, but an entity relationship through program is preferable because MemberProgram can carry a stable @id, hosting organization, tier catalog, URL, and reusable connections. programName therefore appears most often in older, lightweight, or transitional implementations. It should not be mistaken for the name of the member, the membership tier, or the membership record itself.

• Place programName on ProgramMembership.
• Use a Text value that matches the visible program name.
• Prefer program when a MemberProgram entity can be modeled accurately.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Primary specification: Schema.org definition for programName.

programName supplies a label, while program provides the durable entity relationship needed by richer loyalty graphs.

programName is used on ProgramMembership and should not be placed directly on Person, Organization, MemberProgram, MemberProgramTier, Offer, or Reservation.

A MemberProgram has its own name property. An Organization can offer a program through hasMemberProgram. A Reservation can reference ProgramMembership through programMembershipUsed. A tier can point to its parent through isTierOf. Using programName outside its domain creates a misleading shortcut that collapses several distinct entities into one string. Correct placement matters even during migration because legacy templates often reuse the same field across program, account, and reservation contexts.

1. Identify ProgramMembership as the subject.
2. Confirm the text names the associated program.
3. Keep tier, organization, reservation, and member labels separate.
4. Plan a MemberProgram entity when richer relationships are needed.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Keep programName on the membership relationship and let each adjacent entity carry its own identity.

program is preferable because it links ProgramMembership to a MemberProgram entity instead of storing only a disconnected Text label.

A text name cannot reliably distinguish similarly named programs, represent ownership, list tiers, support stable canonical identifiers, or connect commercial benefits. MemberProgram can do those things while retaining a readable name. The entity relationship also reduces drift: account pages, tier pages, offers, and policy pages can reference the same program @id. This does not mean every legacy label is invalid, but it sets a better target for sites building a consistent loyalty knowledge graph.

• Stable @id distinguishes the program.
• hostingOrganization records who offers it.
• hasTiers connects its tier catalog.
• Related offers and memberships can reuse the entity.
• Renames can be managed without creating unrelated nodes.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Choose program when the site can support one accurate, reusable MemberProgram entity.

A site may keep programName during a controlled migration when downstream templates or consumers still depend on the legacy label.

A coexistence window can reduce release risk, but it must be brief, measured, and internally consistent. Both properties should identify the same program, and the text must match the MemberProgram name. Do not use indefinite dual output as a substitute for finishing the migration. Record which templates and consumers still read programName, define an exit condition, and test account, reservation, email, locale, and partner variants before removal.

1. Inventory every producer and consumer of programName.
2. Create the canonical MemberProgram entity and @id.
3. Publish program alongside the matching text temporarily.
4. Compare rendered output across all variants.
5. Remove programName after dependencies are retired.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Temporary coexistence is safe only when values agree and the team has a tested, time-bound exit plan.

Build one canonical MemberProgram per real loyalty program, give it a stable @id, and connect ownership and tiers only when supported by visible evidence.

Start from current program terms, the enrollment page, account experience, and customer support responsibility. Choose an @id that survives campaign URLs and template changes. Add name, URL, hostingOrganization, and hasTiers as appropriate. Do not create a separate program entity for every member, tier, locale, product, or partner page. Similar names do not prove two programs are the same, and different branding does not prove they are separate.

1. Define the real program boundary.
2. Choose a canonical URL and @id.
3. Add the current customer-facing name.
4. Connect the accountable Organization.
5. Attach real MemberProgramTier entities.
6. Reuse the node from ProgramMembership.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

A strong migration depends on one evidence-backed MemberProgram identity that every membership can reuse.

Multi-brand migrations should map each legacy programName value to the MemberProgram that actually governs its rules, not merely to the brand displaying the account.

A group-wide loyalty program may appear under several storefronts but still resolve to one MemberProgram. Independent brand programs need distinct entities even when their names or benefits resemble each other. Marketplaces and white-label operators can display memberships without owning the programs. Build a mapping table from legacy labels, aliases, locales, abbreviations, and former names to canonical program ids, then require human review for ambiguous rows.

• Normalize whitespace and punctuation without erasing meaning.
• Map known aliases to canonical program ids.
• Keep separate programs separate despite similar names.
• Review partner and marketplace labels manually.
• Preserve evidence for rebrands and acquisitions.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Migration maps should follow program authority and rules, not visual branding or convenient string matching.

Prevent conflicts by deriving programName and program.name from the same authoritative source and validating their agreement in rendered output.

Two independently maintained fields will drift. A content editor may rename one label while a backend constant preserves the old value; a locale file may translate the legacy string while the program entity uses a canonical brand name. Generate the transitional text from the program record whenever possible. Compare normalized values, but do not hide genuine differences behind aggressive normalization. A mismatch should block rollout until ownership, rebrand, or locale intent is understood.

1. Use one authoritative program record.
2. Generate legacy text from that record.
3. Compare every rendered ProgramMembership.
4. Segment results by locale and partner template.
5. Block conflicting output and investigate.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Dual output should be generated from one source so every membership tells one consistent program story.

Common mistakes include treating programName as a program entity, generating one MemberProgram per account, mismatching dual values, and removing the legacy field before consumers migrate.

Teams may also map tiers or hosting organizations as programs, merge unrelated programs with similar names, or duplicate programs by locale. Another risk is exposing membership numbers while touching account structured data. Syntax validation will not reveal a false ownership mapping or a downstream email parser that still expects programName. Successful migration requires data mapping, consumer discovery, privacy review, rendered testing, and a reversible rollout.

• Using Text where a MemberProgram node is expected.
• Creating a program node per member or page.
• Keeping conflicting programName and program values.
• Merging different programs because names match.
• Removing legacy output without consumer evidence.
• Expanding private account data during the change.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

A migration is complete only when identity, consumers, privacy, and rendered output all agree.