A quick label is harmless—until someone needs to trust it six months later.
A report shows a sale tagged spring2, but was that an email, a creator post, a paid ad variation, or a landing-page test? Once the answer lives only in someone’s memory, attribution is already unreliable.
Improvised SubIDs tend to fail quietly. Names drift (ig_reel, instagramreels, IG-R), one code gets reused, and a spreadsheet becomes the only translation layer. That makes comparisons slow and fragile: a campaign may look weak simply because its conversions were filed under several labels. A naming convention is decision infrastructure, not a tidying exercise. It gives every link a readable, consistent identity, so reports can answer what ran, where it appeared, and which version earned results—without detective work.
Decide what every SubID must explain
A useful SubID answers a few consistent questions wherever it appears. The usual core is:
- Source: where the visitor came from, such as
email,ig, orsearch - Property: the site, newsletter, or social account sending traffic
- Page: the article, landing page, or content group
- Placement: the location within that page, such as
hero,sidebar, orfooter - Campaign: a time-bound promotion or test, when applicable
- Creative: the specific button, text link, image, or ad variation
Not every link needs all six. A permanent editorial link may only need property, page, and placement; a paid campaign may also need campaign and creative. The test is simple: if a field cannot change a publishing, budget, or optimization decision, leave it out.
Extra detail has a cost. Longer links are harder to scan, fields are more easily mistyped, and optional labels drift into competing spellings. Keep product names, audience notes, and internal comments in a spreadsheet or campaign brief unless reporting genuinely requires them.
Check the platform’s limits first
A naming plan only works if every platform can carry it unchanged. Before settling on field names, check each affiliate network’s documentation or test link builder for parameter names, available field count, maximum value length, allowed characters, capitalization rules, and whether SubIDs survive redirects.
A format such as src_blog_us_spring_banner may be clear internally but fail if a network permits only two fields, strips underscores, lowercases values, or drops parameters at a tracking redirect. Some merchant programs reserve particular parameter names, while regional setups may use separate rules and reporting labels. Amazon Associate IDs by country, for example, may need their own country-aware treatment rather than a single universal string.
Record the tightest limits in a small reference sheet. Then design the shared core around those limits; use a network-specific fallback where necessary. A shorter, consistent code is more useful than a detailed label that disappears before reporting.
Create one sample link and follow it through every redirect. Confirm the final tracking report shows each SubID exactly as sent.
Put every field in the same position
Choose a sequence and keep it unchanged across every link. For example:
source_site_page_placement_campaign
A compact SubID might be:
ig_recipehub_pasta_bio_spring24
Read from left to right:
- ig — traffic source: Instagram
- recipehub — site or account
- pasta — page, post, or content group
- bio — link placement
- spring24 — campaign
The particular labels are less important than their positions. If the fourth segment always means placement, reports can be filtered and compared without guessing whether bio is a campaign name or a page label.
Use one delimiter, such as an underscore, throughout the system. Mixing underscores, hyphens, and periods makes parsing harder and creates near-duplicate values that split reports. Short, lowercase terms also reduce typing mistakes and keep links manageable.
When a field does not apply, use a standard placeholder such as na: ig_recipehub_pasta_na_spring24. Omitting the segment would shift everything after it and break the pattern.
Use a controlled dictionary
A schema only works when its values mean the same thing to every contributor. Keep a short, shared dictionary for each field, especially channel and placement. Contributors should select a listed code rather than inventing a near-match.
Define the allowed forms
| Field | Approved examples | Avoid |
|---|---|---|
| Channel | email, social, search, display |
e-mail, soc, paid social |
| Placement | newsletter, bio, story, sidebar |
emailblast, IG bio, side-bar |
| Campaign | spring_sale, gift_guide |
Spring Sale, gift-guide |
Use lowercase, ASCII letters and numbers, and one separator: an underscore. Do not use spaces, punctuation, emojis, or special characters unless the affiliate platform explicitly supports them. That makes ig_bio, IG Bio, and ig-bio impossible to treat as separate sources.
Set one date style when dates are needed: YYYYMMDD, such as 20250308. Keep abbreviations deliberate and documented: ig may mean Instagram, but fb should never alternate with meta. Add new codes through a single owner or shared change log, then retire duplicates rather than letting both survive.
A link is not the archive
A compact code such as ig_rl_ss25_c1842 works when a lookup table holds the details.
Long descriptions invite typos, hit limits, and become inaccurate after edits.
A permanent content ID, such as c1842, is usually safer.
Slugs may change for search optimization, vanish after a redirect, or differ when an article is republished. The ID keeps reporting tied to one record.
Keep the link to stable codes; add titles, owners, audiences, and notes in the table.
The table can be corrected or expanded without rewriting historic links.
Run the convention as a small publishing control
-
Publish a one-page schema
Keep one current page showing field order, delimiter, required versus optional fields, character rules, maximum length, examples, and the platform-specific fallback for any restricted field.
-
Maintain one shared code dictionary
List every approved source, placement, campaign, and creative code with its meaning and status. Retire old codes rather than silently reusing them for a new purpose.
-
Name a responsible owner
One person or small operations role should approve new codes, resolve collisions, and update the schema. Contributors can suggest additions, but should not invent production labels.
-
Offer templates or a simple generator
Provide copy-ready URL templates for common placements, or a shared spreadsheet generator with dropdowns. This removes most typing and keeps field positions intact.
-
Validate before publishing
Before a link goes live, check that required fields are present, each code is approved, the full value fits the limit, and no existing live link already uses the same SubID for different content.
A lightweight review is usually enough: a second pair of eyes or a generator check catches many avoidable reporting splits.
A missing code is a signal to update the dictionary, not a reason to type an unofficial shortcut. A short request form can capture the proposed code, meaning, owner, and intended first use.
For urgent publishing, use a documented temporary placeholder and replace it through the normal approval process. That preserves a visible audit trail without delaying every link.
Prove the trail before relying on it
Create one end-to-end sample before rolling out a new pattern. Publish a test link with known values, click it, and confirm that the affiliate platform records the same SubID. After the report or export updates, check that each field splits correctly and joins to the intended page record in the lookup table.
A click test proves capture; a test conversion, where a programme permits one, also confirms that the value remains attached through the sale. Record the expected result beside the test link so a mismatch is obvious.
Keep bad values from accumulating
Schedule a weekly or monthly export check for:
- blank SubIDs, including placeholder-only values;
- malformed values that fail the delimiter, field-count, or character rules;
- invented codes not present in the controlled dictionary.
Flag exceptions rather than silently correcting them. The source link can then be fixed, and the reason noted before the same error spreads.
Clean labels make page-level revenue credible, keep EPC comparisons from mixing unrelated placements, and reduce reconciliation work at month-end. A small audit is usually easier than rebuilding attribution after a reporting period closes.
Make the next link the first consistent one
A workable convention does not need every possible detail. Start with three to five fields that answer the reporting questions used most often—perhaps source, placement, campaign, and creative. For each field, publish the permitted codes, delimiter, and empty-value rule in the schema.
Set a firm launch date, then require the template on every affiliate link created from that day onward. Older links can remain as they are while they are inventoried. This clean cutoff prevents a never-ending retrofit and gives later reports a reliable line between legacy data and consistent data.
10 responses to “Build an Affiliate SubID Naming Convention That Scales”
I like the controlled dictionary idea, although I worry it becomes another little bureaucracy nobody updates. Who should own it in a small team—the affiliate manager, content lead, or whoever builds the links?
Give one person clear ownership, usually the person accountable for affiliate reporting, but make updates lightweight. A short approved-code list plus a simple request process is enough for a small team. The important part is that nobody silently invents a second code for an existing source.
Would love a sample one-page schema someday. Not a giant governance doc—just an actual example of field order, allowed codes, date format, placeholders, and a couple of valid/invalid links.
People understand rules much faster when they can compare `email_top_spring25_cta1` with a bad example like `SpringEmail-banner-finalFINAL` 😅
A concrete example is often more useful than a long policy. A good one-page schema should include the field order, delimiter, allowed values, maximum length, placeholder, owner, and 3–5 examples of valid and invalid strings. I also recommend putting the same examples directly into link-building templates so the document is not the only place people encounter the convention.
Question on the “link is not the archive” section: if an article gets substantially rewritten six months later, do you keep its original content ID or issue a new one? We have seasonal buying guides that retain the same URL but basically become a new page each year.
Usually keep the permanent content ID when it is genuinely the same URL/page lineage, then record the seasonal edition or major revision in the lookup table. If the new version has a distinct campaign purpose, audience, or commercial setup, create a new content ID rather than trying to encode that history into the SubID.
We do this with a `season` column in our lookup sheet. Same page ID, but the 2024 and 2025 refreshes can still be separated in analysis. Much less painful than changing every old link.
Our old convention had `ig`, `insta`, `instagram`, and somehow `gram` all appearing in the same quarter. Reporting was technically possible, if you enjoy pivot-table archaeology.
Moved to lowercase codes and one underscore delimiter last month. Small win, but it already caught a typo in the pre-publish check.
This worked for us once we stopped treating the SubID like a notes field. We now use `source_location_campaign_creative` every time, with `na` for a missing creative, and our monthly export no longer needs the ridiculous “what did Jen mean by fb2?” spreadsheet.
The fixed placeholder point is easy to overlook but it made a huge difference.
Exactly. A placeholder can feel wasteful until the first time a missing field shifts everything to the left and breaks a report. Keeping the position stable matters more than packing every possible detail into the link.