The pincode data you already have and have never exported

Three files, one key

Every measure below comes from three exports that already exist, joined on a six digit number.

File	Source	What it uniquely holds
Order export	Shopify admin	Shipping postcode, revenue, order date
Serviceability file	Courier or 3PL dashboard	Expected transit days, COD and reverse pickup flags
Invoice with status	Courier billing	Actual freight charged, delivered or returned status

The join key is the pincode column, present in all three.

Nothing here requires a data warehouse, a pipeline or an analyst. It is three downloads and a pivot table, and it takes about ninety minutes the first time.

The reason it does not happen is not difficulty. It is that no one system produces the combined view, so no dashboard ever prompts anyone to build it.

Export 1: Shopify orders, and the four columns that matter

From the Orders admin, export to CSV with a date filter covering twelve months. Twelve rather than three, because a shorter window lets one festive spike rewrite the entire ranking.

The export carries dozens of columns. Four do the work.

Column	Role in the pivot	Notes
Shipping postcode	Join key and pivot row	Never use billing postcode
Order total or net sales	Primary measure	Deduplicate before summing
Created date	Bounds the window	Also enables month-on-month reads
Fulfillment or delivery status	Flags returns	Refine later from the courier invoice

Keep the order identifier as a fifth column. It is not a measure. It exists so you can deduplicate, which matters more than any other single step here.

Column header names vary slightly between Shopify export versions, so match on meaning rather than on an exact string. Confirm which postcode column you have before doing anything else, because billing and shipping both appear and they are not the same map.

Two limits are worth knowing before you start. No default Shopify report ranks revenue by shipping postcode, since the prebuilt regional view groups by billing country and region, so this pivot cannot be selected from a menu. And the native CSV export contains no line item property columns, so any per-item custom data needs the API or a third-party export app.

Export 2: the courier serviceability file

Download the current serviceability master from your courier or 3PL dashboard. Do not use the copy in the shared drive from onboarding.

Three columns matter for the pivot: pincode, expected transit days, and the cash on delivery flag. Reverse pickup coverage is worth keeping for later work.

This file is typically far larger than your order map. A courier serving five thousand pincodes against a brand shipping to three hundred and twenty means most rows will not join, which is expected and is itself informative.

Left join from orders to serviceability, not the other way round. Joining in the wrong direction produces thousands of empty rows for pincodes you have never sold into, and buries the analysis you wanted.

Flag any order postcode with no serviceability match. Those are usually typos or format errors in the address, and they need cleaning rather than analysis. The wider uses of this file are covered in serviceability data is a marketing asset.

Export 3: the courier invoice with delivery status

This is the export most brands skip, and it supplies the two most decision-relevant numbers.

The invoice carries actual freight charged per shipment, which is not the same as the shipping rate you charged the customer. It also carries the final status, which is where return to origin becomes visible.

Shopify’s fulfillment status will tell you an order was fulfilled. It will not reliably tell you the parcel came back, because a return to origin is a courier event that may never write back to the store.

Pull at least six months. RTO is a rate, and a rate calculated on one month of a low volume postcode is a rate calculated from two events.

Normalise the status values before joining. Courier status vocabularies are inconsistent, and mapping their strings to a simple delivered or returned flag has to happen manually, once.

The pivot: one key, six measures

Pivot on shipping postcode. Six measures come out, and none of them exists in any single source system.

Measure	Computed from	What it decides
Orders	Count of deduplicated order ids	Whether the postcode clears a volume floor
Net revenue	Sum of order totals	Concentration ranking
Average order value	Revenue divided by orders	Whether depth or volume drives the zone
RTO rate	Returned status over total shipments	Whether the zone is expensive
Transit days	Serviceability lookup	Delivery promise and expansion priority
Contribution after freight	Revenue, margin and invoice freight	Whether the zone is actually profitable

Sort by orders first to establish the ranking, then re-sort by contribution after freight.

The gap between those two sorts is the finding. A postcode that appears in the revenue top ten and the contribution bottom ten is where money is leaking, and no dashboard in either source system would have shown it.

Set a volume floor of three orders a month before drawing conclusions from any row. Below that, the RTO rate and average order value are both artefacts. The ranking method downstream of this pivot is in why your best customers sit in six postcodes.

What the pivot cannot tell you without channel data

The map produced above answers where. It does not answer how they got there, and the two questions lead to different budgets.

Consider two postcodes with 38 orders each, identical average order value and identical RTO. One was built by a regional creator whose audience is concentrated there. The other came from organic search and has no channel behind it at all.

Those are opposite situations. The first is a relationship to renew and the second is a defensible position to protect, and treating them the same is how creator budgets get allocated by geography rather than by effect.

Shopify’s referring site and landing site fields carry some of this and lose most of it, particularly for traffic arriving through apps, dark social and any link a customer retyped.

Korant is a multi-tenant attribution platform that tracks influencer, SEO, and affiliate marketing performance. Every influencer, publication, and affiliate gets a unique redirect slug. Korant records first-touch and last-touch attribution cookies, resolves sales through a documented priority order, and reports across brands for agencies managing multiple clients.

Adding a channel dimension to the pincode pivot converts a density map into an acquisition map. The resolution order matters when reading it: discount code to influencer, discount code to affiliate, last-touch cookie to influencer, last-touch cookie to affiliate, then cookie to publication.

One consequence is specific and easy to miss. A geo-gated discount applies automatically with no code, so it never enters the first two checks, and zone-driven orders will read as unattributed unless you account for that deliberately.

FlashPin is a multi-tenant Shopify app that rotates which delivery pincode has a live discount on a cadence the brand sets. Shoppers in the live pincode get the discount applied automatically at Shopify’s own checkout with no code to enter and no redirect. Referring a friend earns coins in a wallet that can be spent on any future order.

Six export mistakes that corrupt the pivot

Each of these produces a plausible looking ranking that is wrong.

Summing without deduplicating. The order export is line-item level, so a three item order produces three rows. Depending on version the total repeats or appears once. Check, then deduplicate on the order identifier.

Pivoting on billing postcode. Produces a ranking that looks reasonable and points at the wrong zones.

Using a three month window. One festive month dominates and the ranking will not reproduce next quarter.

Treating Shopify fulfillment status as delivery status. Fulfilled means despatched. RTO has to come from the courier invoice.

Leaving postcodes unnormalised. Leading zeros stripped by a spreadsheet, spaces, and six digit fields stored as numbers all split one postcode into several rows.

Including cancelled and test orders. Filter on financial status before exporting rather than after, or they quietly inflate low volume postcodes.

When this analysis is not worth running

Korant is not for stores with a single paid channel, and it is not for brands that only need Shopify’s native reports. If one channel drives everything, the channel dimension adds nothing to the pivot and the map alone answers your question.

Volume disqualifies the whole exercise separately. A brand with orders in 40 postcodes has a scatter plot rather than a distribution, and every measure in the six column table will move on single events.

Uniform delivery removes the point of two of the three files. If your courier reaches everywhere at the same cost and speed, the serviceability and invoice joins produce a constant, and the analysis collapses to a revenue ranking you could have got faster.

The limitation worth stating is that this pivot is a snapshot of where demand landed, not of where it exists. Every postcode in it is one you already reach and already sell into, so the map is shaped by your own historical distribution as much as by underlying demand.

It will reliably show you where to concentrate and it will systematically fail to show you where to expand. Treating the top of the ranking as a strategy keeps you exactly where you already are, and the offer mechanics that act on the map are in pincode marketing as a geo lever.