Third-party cookies didn't die on the schedule everyone planned for. Google walked back the Chrome deprecation, and a lot of teams quietly shelved the first-party data project they'd started in 2023. That was a mistake, because the signal loss that made first-party data urgent in ecommerce never depended on Chrome. Safari has been capping script-set cookies at seven days for years. iOS App Tracking Transparency already broke a chunk of Meta's attribution. Gmail and Yahoo's bulk sender rules, live since February 2024, will throttle you if your spam complaint rate crosses 0.3% — and the fastest way to cross it is emailing a list you scraped together instead of one people actually joined.
So the deadline moved. The reason didn't. What follows is the specific set of fields we capture on Shopify builds, where each one lives, and what you actually do with it once it's there.
Shopify gives you three capture points, and one of them is fenced off
Before the field list, know what you can and can't touch.
Pre-checkout is wide open. Cart attributes and line item properties work on every plan. Anything you can render in the theme — a pincode input on the product page, a gift toggle in the cart, a fit quiz — can be written to the cart and it lands on the order.
Checkout itself is fenced. Adding a custom field to the information or shipping step needs checkout UI extensions, and those need Shopify Plus. On a standard plan you get the fields Shopify gives you and nothing more. This is one of the few genuine arguments for the upgrade, though rarely on its own — we've talked plenty of brands out of Plus when the only justification was a checkout field they could have collected in the cart.
Post-purchase is open again to everyone. Thank-you and order status page extensions work across plans, which matters more than people realise, because that's where honest answers come from.
One thing to check if you're on an older build: checkout.liquid customisations are gone. Shopify sunset them for the checkout steps in August 2024 and for the thank-you and order status pages in August 2025. If your data capture was a script injected there, it stopped running. We still find dead capture scripts on stores whose owners think they've been collecting for two years.
The fields, in the order we'd add them
1. Email, plus consent state, timestamp and source
Everyone collects the email. Almost nobody stores the other three properly. Shopify's customer object holds emailMarketingConsent with a state, an opt-in level and a consentUpdatedAt timestamp — use all of it. When a deliverability problem hits and you need to prove that the 40,000 addresses you're sending to actually asked for it, "we've got their email" is not an answer. Consent state with a date and a source is.
Source matters commercially too. A subscriber from a birthday-discount popup behaves nothing like one who joined from a back-in-stock alert. Tag it at capture. You cannot reconstruct it later.
2. Phone, in E.164, with a separate consent flag
Store +919876543210, not 98765 43210. Every WhatsApp and SMS platform wants country code, and cleaning 80,000 badly formatted Indian numbers after the fact is a job nobody enjoys. Shopify keeps smsMarketingConsent separate from email consent, which is correct: someone who wants order updates on WhatsApp has not agreed to promotional blasts. Under India's DPDP Act, with rules still settling, consent has to be specific to a purpose. Two flags, two purposes.
3. Delivery pincode, captured before checkout
The single most useful field for an Indian store, and it costs you one input on the product page. Write it to a cart attribute. It gives you COD serviceability before the customer commits, a real delivery estimate instead of "5-7 days", and — over a few months — a map of where your demand actually sits. Most brands we work with assume they're a metro brand and find that tier-2 is 40% of orders and growing faster.
4. Payment behaviour as a derived attribute
Not something you ask. Something you compute. Tag customers with prepaid-only, COD-only, or mixed, based on order history. It changes what you show them: COD-only repeat buyers respond to prepaid incentives, prepaid regulars should never see a COD fee.
5. Birthday — month and day, not the year
Customer metafield, collected in the account area or a post-purchase form. Ask for the year and completion rates drop, because people can do arithmetic about what you're profiling. Month and day is all a birthday campaign needs.
6. Category, size or fit preference
This is the field that pays for the whole exercise on apparel, footwear and beauty. A skin type, a shoe width, a preferred fit. Collect it once through a short quiz or the account page, store it as a customer metafield, and use it to segment sends instead of blasting the full catalogue. A returning customer who told you they wear a 42 narrow should never receive a launch email for a style you don't make in that width.
7. Gift or self
A line item property, one checkbox in the cart. Gift purchases have different return behaviour, different repeat probability, and they should not pollute your "customers who bought skincare" segment with people who bought it for their sister. Also lets you suppress the invoice from the parcel.
8. GSTIN and company name, if you sell B2B at all
Customer metafield plus an order attribute. Even a small share of business buyers justifies it, because the alternative is a WhatsApp thread with your accounts person after every order. Validate the format at input — 15 characters, the first two being the state code.
9. How they heard about you — post-purchase only
Never in checkout. You will lose conversions to shave a point off your attribution error. On the thank-you page, after the money has moved, ask once with five options and an "other" box. Store it as an order metafield. It's self-reported and noisy, and it's still the only signal you have for the podcast mention or the WhatsApp forward that no pixel will ever see.
Where to put it: metafields, tags, or somewhere else entirely
Metafields for anything with a value — size, birthday, GSTIN, skin type. They're structured, queryable through the Admin API, and they survive a theme change.
Tags for anything binary that you segment on constantly. Shopify's segment editor handles tags fast, and Flow reads them cleanly. But tags rot. We've inherited stores with 300+ customer tags, half of them typos of the other half. Set a naming convention on day one and put one person in charge of it.
Your ESP or CDP for behavioural history and cross-channel identity. Shopify is a good system of record for who someone is. It's a poor one for what they did across email, WhatsApp, ads and support.
A worked example, because the naive action on good data usually loses money
Say you're running 1,000 COD orders a month, AOV ₹1,600, contribution margin 35% — so ₹560 per order. Blanket RTO of 20% means 200 parcels come back. Cost per RTO: forward freight ₹75, reverse ₹75, repack and QC ₹40. That's ₹190, or ₹38,000 a month.
Now you've got pincode data and you can see the worst 5% of pincodes — 50 orders a month — run at 45% RTO. Twenty-two returns, ₹4,180 of cost. The obvious move is to block COD there.
Run it. If 60% of those 50 buyers convert to prepaid, you keep 30 orders and lose 20. Twenty lost orders at ₹560 contribution is ₹11,200 gone, against ₹4,180 saved. You're down roughly ₹7,000 a month for having acted on your new data.
The alternative: keep COD, but send a WhatsApp confirmation to those 50 orders before dispatch. If it cuts RTO in that cohort from 45% to 30%, that's 7.5 fewer returns, ₹1,425 saved, on message costs of a few hundred rupees. Smaller number, right sign.
Those inputs are illustrative — plug in your own. The point holds regardless: the field earns its keep, and the first thing you're tempted to do with it doesn't.
Feeding first-party data back into ads
Shopify's Customer Events (the Web Pixels API) is where your tracking should live now, not in theme.liquid. It runs sandboxed, it doesn't break when the theme updates, and it's the supported path for passing hashed customer data server-side to Meta's Conversions API and Google's enhanced conversions. Server-side matching is what recovers the events an ad blocker or ITP eats.
What that means practically: the more identity fields you hold at checkout — email, phone in the right format, city, pincode — the higher your event match quality, and the better Meta's optimisation gets on the same spend. It's a quieter win than a new creative, and it compounds.
Shopify Audiences, worth noting, is Plus-only and limited to a few markets. If you're selling from India into the US, check eligibility before you build a plan around it.
What we'd skip
Gender, unless your catalogue genuinely splits on it. Full date of birth. Income bands. Anything from a "tell us about yourself" form with nine fields, which nobody fills in and which trains your customers to close popups.
The test is simple and we apply it to every field a client asks for: name the campaign, segment or automation that uses it, and name the person who owns it. If neither exists, you're collecting a liability. Under DPDP you'll need a lawful basis and a retention answer for every field you hold, and "we thought it might be useful" is not one.
Start with two fields, not twelve
Pick the pincode and the preference field. Ship both in a week — a cart attribute and a customer metafield, no app required, and any competent developer can do it in an afternoon. Watch the fill rate for a month. If people are answering, add the next one. If they're not, the problem is where you asked, not what you asked.
If you'd rather have someone look at what your store is already capturing and where it's leaking, our free audit covers the data layer alongside speed and conversion. And if the work needs hands rather than a report, you can bring on a Shopify developer for the build.