Market

At sign-up you entered your goal as “fat loss”, your level as “intermediate” and your sex as “male”. Where does the shelf read these from?

Your segment is born of three fields: your training goal tag, your level tier and your sex.

All three are read from your profile spine — the single record where onboarding and profile edits converge. The mapping is one-to-one: goal tag `fat_loss` → fat loss, `muscle`/`toning` → muscle, `strength` → strength, `health` → health; level `L1` → beginner, `L2` → intermediate, `L3`/`L4` → advanced. An unrecognised or empty value does not fall into a silent assumption: sex drops to “unspecified”, goal to “health”, level to “beginner”. The segment is derived on the server; there is NO segment field in the request body, because the segment is the strongest arm of the scoring and a client able to write it would choose for itself which products reached the shelf.

If your shelf feels foreign, the first place to look is the goal and level in your profile; fix those and the shelf changes on the next load.

The system calls this the “profile spine”.

When the shelf request goes out, what does the phone tell the server, and what does it not?

The phone carries only catalogue context; the server builds the decision’s inputs from its own store.

Sent: the catalogue’s product ids, product tags, the product→sub-category and sub-category→root-category maps, the week key, and what was shown and bought this week. Not sent, and why: (a) THE ACTIVE PROMOTION LIST — a promotion bonus is a discount entitlement; a phone sending a fabricated promotion could award its own product both points and a badge; (b) THE SEGMENT — the strongest arm of the scoring; (c) THE SAFETY FLAGS (pregnancy / breastfeeding / age / blood thinners) — whoever writes the decision would also open the gate; (d) CARDS PER CATEGORY — fixed on the server; sendable, a legitimate eight-item request would turn into a load computing the whole catalogue. These four fields are not constructed in the request body even as empty values.

Updating your health declaration narrows the shelf immediately; that is not a restriction but the decision having been taken out of the phone’s hands.

The system calls this “server-authoritative input”.

If apparel cards appeared under the “Supplements” heading, no counting test would catch it: 8 sections, 64 cards — the counts right, the pairing wrong.

The response is unpacked without trusting order ALONE; each section’s id is compared against the category asked for.

The endpoint returns an answer in the same order and of the same length as the category list asked for. The client makes two independent checks: does the count match, and does each section’s category id match what was expected. If either fails, NO section is served — there is no partial acceptance, because even with seven of eight rails correct, the wrong one is the rail where the user sees the wrong product. If the category list exceeds the ceiling the client closes without going to the network at all; silently truncating would lead you to take the last rails for “no products”.

The shelf either arrives correct as a whole or does not arrive; you never see half a shelf.

The system calls this an “identity-checked batch response”.

The first card on the supplement rail reads “Need”, the second and third “Promotion”, the rest “Discovery”.

Each slot is filled by a priority chain, and which arm filled it is written onto the card.

The chain runs: (1) if there is a measurable need signal, that product; (2) failing that, an active promotion targeting your segment; (3) failing that, segment-general discovery; (4) failing everything, deterministic fill by catalogue order. The server does the classification and attaches it to the card; the device derives nothing. A product that must be suppressed never becomes a card at all — the card object has no “do not show” state, that product simply never enters the list.

If your shelf is all “Discovery” badges, the system found no measurable signal about you: logging meals and workouts turns the shelf towards the need side.

The system calls this “priority slot fill”.

Several sellers list the same product. One price appears on the card; who chose it?

The server picks the winning offer; the phone reads no offer store.

Reading a device-side copy of offers would produce a second truth diverging from the store, even if the value read were never used. The service hands over only a list saying “I am asking about these products”. Because the endpoint accepts at most fifty products per request, the list is split into batches of fifty and the batches are joined in order; splitting does not change the decision, since the winning offer is picked per product. If even one batch comes back closed, an exception is thrown and the page is not drawn with priceless cards.

Not seeing a price on a product does not mean “out of stock”; it means the pricing decision could not be made at that moment.

The system calls this a “fail-closed buy box”.

The cart reads ₺1,109.20 and the order summary shows the same figure. Why are they always the same?

There is one place that produces the amount: the checkout preview endpoint.

Both the cart and the order summary ask the same endpoint; tax, delivery and discounts are computed there. The cart multiplying on its own would produce a different figure at the payment screen and leave you unsure which to trust. If the preview cannot be fetched, the cart shows a subtotal from line prices but marks it “Estimated” — an unmarked estimate would read as a final figure.

If the cart and payment amounts differ, the gap is delivery or a coupon; both are itemised in the payment summary.

The system calls this the “single pricing authority”.

Your connection dropped during payment and you tried again. Did two orders get created?

Every order-creation call carries a unique key, and if the same key arrives again the server returns the same order.

The key is tied to a single tap rather than the button’s state; a request arriving with the same key within twenty-four hours is treated as a repeat. There is a second protection on top: retrying an order id already paid in this session takes the screen straight to success, and retrying one that failed takes it straight to the error screen — in neither case is a new call made.

If a payment stalled, do not open a new order; continue from My Orders with “Complete payment”.

The system calls this an “idempotency key”.

The screen reads “Shipped”. Where does that word come from, and what happens when you switch to English?

The server sends a status CODE; the word on screen is produced from that code.

The codes are kept in a fixed list and the mapping is done in one place. If an unrecognised code arrives, no status is invented: it falls into an “unknown” bucket and that order appears not in the narrow tabs but only in “All” — because filing an order whose stage we do not know into a tab would be a lie, while hiding it from the list would erase an order that may already be paid for.

Change the app’s language and the order stays in the same tab; the tab looks at the code, not the word.

The system calls this “code-driven status”.

You have the product but the box arrived crushed. Should you open a return or report an issue?

A return deals with money; an issue report deals with the order itself.

A return opens only on a delivered order and starts a refund process; its record is written inside the order record and a second pending return cannot be opened for the same order. An issue report falls into one of four fixed headings, goes to the support queue and requires no delivery — if a parcel is lost in transit no return can be opened, but a report can. Put in the same box, a user reporting a delivery problem would land in the refund queue.

If you want your money back, open a return; if something went wrong with the order itself, report an issue. There is a link from the return screen to issue reporting and back the other way.

In product terms this is “separate responsibility, separate queue”.

The shelf you looked at in the morning is the same in the evening. The next week it has changed.

The shelf is tied to a week key and stays fixed within the day.

A shelf computed within the same week is written to the ledger and not asked for again; a shelf that changed on every open would leave you unable to find a product you saw yesterday. The ledger is invalid in two cases: you bought a product in the meantime, or a product became ineligible at the safety gate — for instance if you just ticked a pregnancy declaration. Then the ledger is cleared and the shelf is rebuilt.

If you want your shelf to change immediately, update your profile or health declaration; an ordinary reopen will not change it.

The system calls this “weekly caching with invalidation”.