Merit · PIM · Proposal for engineering review

Regional versions as a variant axis

Sellers list the UAE, International and US version of the same phone as separate products. Here is what we want the customer to see instead, how we propose to build it, and the five things we need you to confirm before anyone starts.

From Brian Arfi Faridhi, Product
For Muneeb Meer, Usman Abbas, and the Tintash team on E-commerce Core and PIM
Agreed with Ghaith Fakhouri, Operations, 18 August 2026 · recording
Date 19 August 2026

What we need from you

Sections 1 to 4 are the proposal, and they are settled on the product side. Section 5 is the ask. Five questions, short answers are fine, and question 1 is the one that decides the size of the job.

01The problem

Three symptoms, one cause. The cause is that regional versions have no home in the model, so sellers invent one.

3 to 4

iPhone 17 listings competing with each other for the same customer, because each seller creates their own product for their own regional version.

Split

Ratings and reviews divided across those listings, so none of them shows the trust the product has actually earned.

Picking
errors

The warehouse operator cannot tell which physical unit an order is for. Ghaith called this high operational risk in warehouse operators.

Why we cannot just merge them

The difference is physical, not cosmetic. The UAE unit ships one nano SIM plus one eSIM. The US unit ships dual eSIM. Fold those into one undifferentiated listing and the customer receives a phone that does not take their SIM. That is a returns problem, not a labelling problem.

So the answer is not one listing, and it is not four. It is one listing that still shows the difference.

02What the customer sees

One product detail page for iPhone 17 Pro, with a version selector at the top. Pick a version and everything below it changes. Try it.

Live mock · iPhone 17 Pro · click a version

Storage

Colour

SIM

Description

Sellers and Buy Box

Greyed and struck-through options are the ones that version does not have. They are shown greyed here to make the filtering visible; on the real page they would simply not be offered.

Three rules that fall out of that

Storage and colour filter down to what the version actually has. If the UAE unit only comes in black, the buyer never picks blue and then discovers it is unavailable.
The seller list filters too. Only sellers who carry that version appear against it.
Buy Box competes inside a version. A seller who is the only one carrying the UAE unit wins the Buy Box for it. They are not beaten on price by an international seller offering a physically different product. Three UAE sellers compete against each other, not against the international sellers.

Two constraints on the content

The description stays generic, with no region or SIM wording in it, because it is shared across all three versions. The difference lives in the attributes, the images, and a comparison table.

Scope is UAE, International and US only. Saudi Arabia is out for now, because Saudi sellers are expected to offer only their own version, so the added complexity buys nothing today.

03How we propose to build it

One sentence, and then the four things it inherits for free.

Add region as a third variant axis on the Smartphones category, with three allowed values: UAE, International, US.

Smartphones category, variant axes

The cap is five variant axes per category. Smartphones spends two today, so region is the third, and nothing else is queued for this category.

Why this route rather than a new grouping layer

Everything in section 2 falls out of the model we already have, instead of needing a new one:

One product with variants is already how a product detail page works.

No new page type, no new entity, no group-resolution step.

Offers already carry a mandatory variant_id, and offers compete per product plus variant.

This is the important one. It means Buy Box is already scoped to a version, so the rule Ghaith asked for is delivered by code that is already specified rather than written from scratch.

Variants already compete only against their siblings on a product detail page.

Never against variants of another product. That is the ordering behaviour we want, already specified.

Variant-level attributes and images already have a PRD.

Which is what makes the SIM difference and the per-version photos possible.

The alternative we considered and rejected

Keep the three versions as separate products and group them for display on the storefront. We rejected it because that grouping layer does not exist anywhere: no schema, no behavioural spec, and a service boundary running through the middle of it. Buy Box would also have to be rebuilt on top of it, because variants of different products never meet on one page.

It is the bigger build, not the smaller one. If you know of grouping capability that is already there and we have missed it, say so in section 5 and we will look again.

04The rules that come with it

Not optional extras. These four are what stops the model drifting back apart later.

Rule	Why it is load-bearing
`region` has a fixed list of allowed values UAE, International, US. Admin-defined, not free text.	This is what holds the scope to three. Adding Saudi Arabia later is a change to that list plus a decision, not a build. Without it, region becomes a free-text field and we get "UAE", "U.A.E." and "Middle East" inside a month.
`allow custom axes` stays OFF For Smartphones and Electronics.	Sellers cannot invent a fourth region or a fourth axis. A rule that lives only in a document gets rebuilt by whoever configures the category next, so this one has to be set in the schema.
`model_number` must NOT be identity-defining for Smartphones	The part number differs per regional version by design. If we key product identity on it, the three versions are forced apart into separate products again and this whole proposal unwinds. This is the one that is easiest to get wrong, because `model_number` is mandatory for Electronics and looks like a natural identity key.
Add a `sim_type` attribute to Electronics	It does not exist today. It is what makes the eSIM difference visible to the customer, and it is what the comparison table renders from.

05Confirm these five

This is the ask. Short answers are fine. Question 1 decides the size of the job, the other four decide whether the design in section 2 is buildable as drawn.

Question 1 · the one that matters most

Does the system generate every combination of axis values as a child SKU, or are variants created only from the combinations a seller actually enters?

The PIM PRD says both things and we cannot tell from the document which one is built. FR-17 says each unique combination of variant axis values generates a child SKU with its own barcode, stock and price fields. FR-16 says the seller gets a variant builder, which reads like the seller picking the combinations that exist.

If generation is eager, one phone looks like this

15 a seller actually carries 33 nobody sells

Why it changes the job

Storage times Colour times Region on a single phone is 48 records, each carrying a barcode field and a stock field. On the availability shown in section 2, only 15 of them are real. Across the phone catalogue that is several hundred rows somebody has to suppress or ignore.

If it is explicit, region costs us three values on one category and nothing else. If it enumerates, we still want to do it, and we also need a suppression rule for variants with no offer, which we would rather scope now than discover in testing.

The 15 and the 48 come from the worked example above, not from a query against the catalogue. Nobody has counted real Smartphones variants yet. The ratio is the point, not the exact number.

Can a variant axis be pinned to an admin-defined list of allowed values, and is that built?

This is FR-19. It is the mechanism that holds the scope to three regions, and it is the same mechanism that already constrains Size on Fashion. We want to know whether it is implemented or only specified.

In the system as built, does an offer bind to a specific variant, so Buy Box competes within a variant rather than across the whole product?

The PRD says yes, with variant_id as a mandatory foreign key. We want to know whether the implementation matches, because the entire Buy Box rule in section 2 rests on it.

Can a variant carry its own attributes and its own images, distinct from its siblings?

Section 2 needs the SIM type and the product photos to change when the version changes. If images are per product rather than per variant, the comparison table needs a different answer.

Adding a third axis to a category that already has live products: what does that take?

Is it a configuration change, or does it need a migration of existing Smartphones products and their offers in the new PIM? This is the question most likely to move the date, and nobody has asked it yet.

06What happens next

If question 1 comes back as explicit variant creation, we write the schema change and this goes straight into a ticket. If it comes back as eager generation, we still do it, and we add a suppression rule for variants with no offer.

Please answer before anyone starts building

There is an older decision on record that says the opposite of this one: that region is not a variant axis, and that the regional units should be separate products keyed on model_number. It has been superseded, but it is still written down in places, and one scheduled action still points at it.

We do not want two teams working from two different models, which is exactly what happens if this is picked up before section 5 is answered.

Merit Incentives · PIM · Regional versions as a variant axis
Prepared by Brian Arfi Faridhi, 19 August 2026. Agreed with Ghaith Fakhouri, Operations, 18 August 2026.