Server, Region, Rank, Platform: How to Normalize Account Attributes Before Listing on Multiple Marketplaces

Why attribute chaos costs account sellers money

Most sellers think about price and stock first. But for game accounts, attributes are what buyers search and filter by: server, region, rank or level, platform, included items, and login type. If those values are messy, you pay for it in three ways:

• Rejected or half-filled listings. Marketplace forms often expect a value from a fixed list. Free text like "Europe West (fast)" won't match.
• Invisible listings. A buyer filtering by region or rank skips an offer where the field was left blank or set to a near-miss value.
• Reconciliation pain. When a sale comes in, you need to know exactly which account it was. If your internal record says "Plat 2" and the listing says "Platinum II", matching gets slower and more error-prone.

Normalizing attributes once, before upload, fixes all three.

Step 1: Separate internal attributes from marketplace attributes

Start with two layers:

1. Your canonical attributes: the clean, consistent values in your own spreadsheet or inventory source.
2. Marketplace-specific values: whatever each marketplace form accepts for the same concept.

Your canonical sheet should never be shaped around one marketplace's dropdown. If you do that, adding a second or third marketplace later means reworking the whole sheet. If you're planning that expansion, see the multi-marketplace expansion playbook.

The canonical layer is where you decide that "Europe West" is always written one specific way. The mapping layer is where that value gets translated for each destination.

Step 2: Define a controlled vocabulary per attribute

A controlled vocabulary is a short list of allowed values for each column. Anything not on the list is an error to fix, not a new value to invent.

Keep the list short. If a value appears only once in a hundred rows, it's probably a typo.

Step 3: Split "filterable" from "descriptive"

This is the most useful distinction in the whole workflow.

• Filterable attributes are things a buyer picks from a dropdown or filters on: region, platform, rank, level range. These need exact, controlled values.
• Descriptive attributes are things you explain in the title or description: notable skins, rare items, account history, delivery notes. These can be more flexible but should still follow a template.

A common mistake is cramming filterable data into the title because it feels faster, then leaving the structured field empty. Buyers using filters won't see the listing. Fill the structured fields first, then use the title for what makes this account stand out. For title structure, see listing ID and title naming conventions.

Step 4: Build the mapping table for each marketplace

For every filterable attribute, record how each marketplace expects it. Do this once per game or category, not per listing.

A simple mapping sheet has one row per canonical value and one column per marketplace:

Fill each cell by checking the actual form or accepted values in that marketplace for the game you sell. Don't assume two marketplaces share a naming scheme, and don't assume a field you see for one game exists for another. Required fields and allowed values vary by marketplace, game, and category, so verify against what each form actually asks for.

If a marketplace has no equivalent field for an attribute, mark the cell clearly (for example "put in description") rather than leaving it empty. Empty cells are ambiguous; explicit instructions aren't.

Sellerbot's field mapping is built for exactly this step: you connect your source columns to each marketplace's listing fields so a bulk upload doesn't depend on retyping. You can see how that looks in the preview and check which marketplaces are covered on the platforms page.

Step 5: Validate the sheet before every batch

Before a bulk restock, run a quick validation pass on the canonical sheet. This takes minutes and prevents most upload failures.

Blank and duplicate checks

• Filter each filterable column for blanks. Any blank in a required field is a stop.
• Check your internal ID column for duplicates. Two rows sharing an ID will cause sold-stock confusion later.

Vocabulary checks

• Use a pivot or unique-values view on each controlled column. If you expect five regions and see eight values, you have spelling variants.
• Sort rank and level columns. Outliers and text in numeric columns jump out immediately.

Whitespace and case checks

• Trim leading and trailing spaces. "EU " and "EU" look identical to you and different to a system.
• Pick one letter case for controlled values and stick to it.

This pairs naturally with the bulk restock batch prep checklist, which covers the rest of the pre-upload routine.

Step 6: Handle edge cases deliberately

Some accounts don't fit the vocabulary cleanly. Decide in advance how to handle them.

• Multi-region or transferable accounts. Pick one primary value for the filterable field and describe the rest in the description. Don't invent a combined value.
• Unranked or placement accounts. Add an explicit "Unranked" value to your vocabulary instead of leaving the field blank.
• Accounts with several platforms linked. Choose the platform the buyer will actually play on and note the rest.
• Games with no fixed list on a marketplace. Use the closest accepted value and put precise details in the description, so the buyer isn't misled by the filter.

Never pick a filter value just because it gets more views. A mismatched region or rank leads to disputes, and disputed stock is expensive. If you've dealt with that, the returned stock relisting workflow explains how to avoid putting bad stock back up.

Step 7: Keep the sheet alive after listing

Normalization isn't only a pre-upload task. Once listings are live, your canonical sheet should remain the record of what each account is.

• When a sale syncs back, mark the row sold in the sheet using the internal ID so the attribute record and the stock status stay linked.
• When you change an attribute on a live account (for example the rank changed after you leveled it), update the canonical sheet first, then the listings.
• When a marketplace changes a form or adds a field, update the mapping table once instead of fixing hundreds of rows.

That last point is the real payoff. With a canonical layer and a mapping layer, a form change is a one-row fix, not a re-edit of your whole catalog. This is also why overselling prevention depends on clean IDs and attributes: you can't sync what you can't match.

A quick normalization checklist

• Canonical sheet exists, independent of any single marketplace
• Controlled vocabulary written down for region, server, rank, platform, level, and login type
• Filterable fields filled first; titles used for differentiators only
• Mapping table completed per game for every marketplace you use
• Blank, duplicate, whitespace, and spelling checks run before every batch
• Edge-case rules written for multi-region, unranked, and multi-platform accounts
• Sold rows updated by internal ID after sync

Getting started

Pick your highest-volume game, write the vocabulary for its five or six filterable fields, and build the mapping table for the marketplaces where you already sell. Run one small batch as a pilot, confirm the fields land correctly in each marketplace, then scale up. When you're ready to automate more of the process, look at the Sellerbot plans and the full feature list, or browse more workflows on the Sellerbot blog.