Alberto Vena

Replatforming is one of those moments that can either unlock a step-change in organic growth—or erase years of SEO equity overnight. 

A new commerce stack can improve speed, flexibility, and long-term maintainability. It most likely also breaks URL structures, buries content, and confuses search engines at scale. A 20–40% traffic dip in the first months after launch isn’t unheard of when fundamentals are missed, and the revenue impact can be painful. The upside, though, is equally real: treat SEO as a first-class citizen throughout the migration and you can come out with faster pages, cleaner architecture, and a stronger growth engine than you started with. 

As we repeat as a mantra, and it applies to every aspect of a migration, especially with SEO, to try to change as few things as possible during the migration, and patiently wait until the improvements are easy and safe to implement.

This guide blends hard-won lessons from complex e-commerce migrations with practical checklists you can use right now. We’ll cover the technical foundations *and* the organizational dynamics that make or break replatforms. Because SEO fails less often in code editors than in project plans.

## Pre‑Migration Audit & Benchmarking

### Establish a Baseline Before You Move Anything

If you can’t describe exactly how your site performs today, you can’t diagnose what changed tomorrow. Start with a thorough SEO audit and a shared benchmark doc that the stakeholders agree to protect.

At minimum, benchmark:

- **Traffic & revenue baselines:** Segment by channel (organic/non-brand vs. brand), device, market, and key templates (home, category/PLP, product/PDP, content hubs, blog, help center). Tie organic sessions to revenue where possible.
- **Rankings and visibility:** Track head terms and long-tail queries per template, Capture average ranks and note which terms drive conversions.
- **Crawl data & index footprint:** Export from your crawler and Google Search Console. Inventory indexable vs. non-indexable pages, canonicalized duplicates, parameterized URLs, pagination, and index bloat.
- **Top-performing pages and link equity:** Identify the top 10–20% of URLs that drive 80% of organic value. Map internal links to these pages and log external links you must preserve.

Document technical debt you plan to fix on the new stack: render-blocking scripts, slow templates, thin content, overlapping intent, and legacy parameters. Include dates on every report to ensure post-launch comparisons are apples-to-apples.

## URL Mapping & Redirect Strategy

### One-to-One Redirects Are Non‑Negotiable

Your URL structure is your site’s skeleton. Change it without a precise redirect plan and the body collapses. For any URL that changes, implement **one-to-one 301 redirects** from the old canonical to the new canonical. Avoid chains and loops; every additional hop dilutes signals and slows users down.

**Homepage and category dumps are rank-killers.** Blanket-redirecting old PDPs to the homepage (or to their parent category) is a fast path to irrelevance. Search engines treat irrelevant redirects like soft 404s—you don’t preserve equity, and users bounce because intent isn’t met.

### Practical Tips for Redirect Excellence

- **Build the map early.** Start from your top-value URLs and work down. Include query parameters that resolve to unique content (e.g., `/size=xl` may be ignorable; `/color=navy` may map to a canonical color page if that’s how your new platform works).
- **Normalize everything.** Decide on trailing slashes, case sensitivity, and default file extensions. Enforce consistently to prevent duplicate paths.
- **Keep UTMs safe.** When implementing your redirects, be sure you are not removing UTMs (or any other query params) from the URLs, otherwise you might compromise attribution tracking.
- **Test before launch.** Validate your redirect file in staging with a crawler. Check for 200/301/404 distributions, chains, loops, and relevancy (old product → closest new product or guide).
- **Deploy at the edge.** If possible, run redirects at your CDN/edge layer for speed and reliability.

### Treat Content as the Oxygen of SEO

During migrations, content gets “cleaned up” or rewritten. That can be good—but accidental pruning is common. Titles, H1s, product descriptions, and alt text are easy to strip when templates change. Structured data is often left behind or auto-generated with gaps. If there are content mistakes that can be addressed along with the migration, stop doing it and take a note for later. Again, it’s better not to change too many things together; otherwise, it will be hard to understand where SEO issues originate. 

### What to Preserve—and Improve

- **Metadata parity:** Ensure title tags, meta descriptions, H1s, and canonical tags carry over. Where templates change, confirm variables resolve correctly (e.g., brand + model + key attribute).
- **On-page copy and attributes:** Preserve unique product copy, comparison tables, FAQs, and reviews. Standardize units and naming conventions to avoid duplicate content from near-identical variants.
- **Media and alt text:** Maintain image URLs where feasible, or redirect them. Keep descriptive alt text for accessibility and image search.
- **Structured data:** Recreate JSON-LD for Product, Breadcrumb, Review, Article, FAQ, and Organization. Validate with Google’s Rich Results Test and ensure parity with visible content.

**Manual review is mandatory.** Pick the top 50–200 URLs by organic value across templates and review them page-by-page in staging. Look for lost copy chunks, missing schema, and new UX that hides or defers critical information. If something feels “lighter,” it probably is.

## Technical Considerations

### Replatforming Is a Chance to Upgrade, Not Just Replicate

Perfect preservation isn’t realistic. Your new platform will bring its own SEO opinions, often better than what you had before, and some of them are non-negotiable. Shopify’s URL structure, as an example, is fixed. That’s not a threat; it’s a constraint you can leverage. Treat these standards as a built-in upgrade path: use the move to clean up crawl paths, modernize rendering, and lift Core Web Vitals where possible. The key here is balancing touching only things that have a real impact or are in a no-risk zone. Some examples:

**Robots & index controls:**

- Align **noindex** and **canonical** rules to your new architecture. If you consolidate filters or change pagination, update rel=“prev/next” strategies and canonicals accordingly.

**Sitemaps:**

- Generate clean, modular XML sitemaps (≤50k URLs per file) by template and locale. Exclude noindex/redirecting/404 URLs. Host them on the primary host and reference them in `robots.txt`.

**Rendering & performance:**

- Prefer SSR or SSG for content-critical templates; hydrate interactivity progressively. Ensure your SPA routes are indexable and expose canonical, meta, and schema on initial HTML;
- Use the migration to improve **Core Web Vitals**. Compress and lazy-load media, reduce JS bundle size, and adopt modern image formats. Measure template-by-template rather than sitewide averages.

**Internationalization:**

- If you operate in multiple locales, validate `hreflang` across the new structure. Misaligned language-region pairs or missing return tags can throttle international visibility.

## Pre‑Launch Testing

### Treat Staging Like Google

Your staging environment is where good intentions meet reality. Crawl it with enterprise-grade tools and with Googlebot-like settings. The goal: catch anything that could impair discovery, understanding, or measurement. 


> In Shopify, crawling a store has been historically a problem, as the platform was failing to distinguish genuine and controlled crawls and malicious bots. They recently released an update to allow SEO specialists to use [Web Bot Auth](https://datatracker.ietf.org/doc/html/draft-meunier-web-bot-auth-architecture) to authorize tools to crawl the website and complete audits. 

**What to QA before launch:**

- **Canonical tags:** Are they self-referential and stable? Watch for environment URLs sneaking into canonicals.
- **Meta and headers:** Confirm `noindex`, `nofollow`, and caching headers are correct by template.
- **Structured data:** Validate JSON-LD at scale. Check Product offers/prices/availability match the page.
- **Internal links:** Ensure navigation, breadcrumbs, related products, and in-content links point to production paths (not staging) and use consistent trailing slash rules.
- **Pagination & filters:** Verify canonical strategies and indexability of facets. Decide which filters deserve indexation and which should be `noindex`.
- **Analytics & tags:** Confirm GA/GTM (or your stack), conversion events, and ecommerce schema fire correctly. Deduplicate events to avoid inflated revenue.
- **Sitemaps & robots:** Generate production sitemaps from staging, then disable staging in `robots.txt`. Dry-run the production `robots.txt` to avoid surprises.

## Post‑Launch Monitoring

### The First 4–6 Weeks Are the Danger Zone

Launch day isn’t the finish line; it’s when the real work begins. Search engines will revisit, recrawl, and reinterpret your site. Tiny issues can compound into big problems if you’re not watching closely.

**Daily (and weekly) checks:**

- **Crawl errors:** Monitor 404/5xx spikes in logs and Search Console. Prioritize legacy URLs with external links.
- **Redirect health:** Watch for chains and high-latency routes. Patch mismapped redirects quickly.
- **Indexation & coverage:** Track valid vs. excluded pages. Investigate sudden swings in “Duplicate, Google chose different canonical” or “Crawled – currently not indexed.”
- **Rankings & traffic:** Compare to pre-migration baselines by template and market. Watch non-brand first—brand often masks issues.
- **Sitemaps:** Ensure new URLs are submitted and rising in “Indexed” count. Remove retired sitemaps.
- **Core Web Vitals:** Check for regressions by template. Tracking scripts and A/B tools often bloat JS unexpectedly.

## Ongoing Optimization

### The Migration Is the Beginning of a New SEO Cycle

With the new stack live, resist the temptation to “set and forget.” The best-performing teams set a 90-day post-launch roadmap to convert the migration into momentum.

Focus on:

- **Internal linking refinement:** Use crawl and click data to push equity toward high-value pages—new collections, seasonal hubs, or evergreen guides. Revisit nav and breadcrumbs with real user behavior.
- **Backlink reclamation:** Outreach to update important external links that still point to redirected URLs. Every updated link removes a hop and strengthens relevance.
- **Content re-optimization:** Compare pre- and post-launch rankings. Refresh thin or underperforming pages. Expand FAQs based on emerging queries. Build content around new capabilities the platform unlocks (e.g., better comparison components or dynamic bundles).
- **Schema enrichment:** Add missing structured data types and test eligibility for new SERP features.
- **Technical hardening:** Keep pruning parameter cruft, improve caching, and continue shrinking JS. Treat Core Web Vitals budgets as part of your web performance SLOs.

## Final Takeaway: Paranoia and Precision Protect SEO

Replatforming is equal parts engineering project and change-management exercise. The teams that win keep SEO at the table from discovery to post-launch, blend caution with ambition, and treat baselines as a contract with the business. Precision in redirects, content parity, and technical configuration prevents avoidable losses. Paranoia—healthy skepticism and relentless verification—catches the edge cases that otherwise compound.

Most importantly, view replatforming as the start of a stronger SEO engine. Take advantage of all these tasks to clearly understand what’s needed to fix crawl waste, speed up templates, consolidate content, and build richer experiences once you are on the other side. Done right, you won’t just protect your rankings—you’ll future‑proof your visibility and open new lanes for growth.

If you’re planning a replatform or recovering from one and want an experienced partner to guide the process, **let’s talk**: [https://nebulab.com/contact](https://nebulab.com/contact).

How to Ensure SEO Integrity During a Replatform

Alessandro Desantis

In the first three articles of our series on Experience-Led Commerce, we explored [why customer experience is emerging as a powerful lever for sustainable growth](https://nebulab.com/blog/ecommerce-growth-customer-experience), [how to think about customer experience for your brand](https://nebulab.com/blog/what-is-ecommerce-cx), and what it takes to [operationalize CX investments across your business](https://nebulab.com/blog/ecommerce-digital-roadmaps). Now it’s time to face a tougher question:

If customer experience is so important, why do so many brands still struggle to act on it?

For digital-native startups, weaving customer feedback and iteration into their DNA is almost second nature. But for established, complex commerce organizations, the friction is real. It often boils down to this: being "data-driven" sounds great in theory, but is much harder in practice.

In this article, we’ll look at what actually holds teams back from building data-driven CX programs—and how to evolve your approach without grinding your business to a halt.

## The Two Biggest Barriers to a Data-Driven Approach

Adopting a data-driven mindset when it comes to CX requires overcoming two very common (and very human) challenges.

### 1. Short-Term Goals Override Long-Term Investments

For most commerce organizations, especially when they’re under pressure from economic headwinds, the priority is hitting the week’s revenue target. CX investments often feel too abstract, too slow to return, or too far removed from the conversion funnel to warrant resourcing.

But the reality is that neglecting CX can sabotage long-term performance. A short-term focus might get you a few wins, but it often comes at the expense of brand equity, retention, and customer lifetime value.

And yet, the solution can't just be telling brands to be more strategic. Brands need to balance the long-term nature of customer experience investments with short-term business constraints, finding quick wins through fast and measured experimentation.

### 2. Decisions Are Made by Guts, Not Data

All the brands we’ve worked with over the years have claimed to be data-driven. In practice, many are still reliant on hopes, intuitions, and the occasional good HiPPO, the Highest-Paid Person’s Opinion.

While it’s easy to point fingers, the reality is that this approach doesn’t stem from ignorance, but rather from the fast-paced nature of the average consumer brand. By the time you're done running your three-month audit, consumer sentiment has shifted, results are nowhere to be seen, and leadership is asking how fast you can launch that new sitewide sale.

As a result, in the best-case scenario, most leaders and operators end up relying on their gut. In the worst-case scenario, they cover their personal opinions under a thin layer of spurious numbers only meant to reinforce their original assumptions.

Again, simply trying to bash through and tell brands that they should be more data-driven is not helpful, and is often met with understandable nods and eye rolls.

## Building Trust One Step at a Time

For XLC to be adopted, you need to make the data collection process manageable for a busy team and build trust in the data.

Luckily, the Hierarchy of Experimentation Evidence provides exactly that: a way to improve how decisions are made, without requiring your organization to grind to a halt. First designed by experimentation expert Ronny Kohavi, this framework helps brands evaluate the strength of the data behind their decisions.

We can visualize it as a pyramid with five levels. From bottom to top, we have:

- **Anecdotes and expert opinions.** Observations, gut feelings, HiPPOs, UX/UI audits are all useful data sources for generating hypotheses on friction points and improvement opportunities, but they are not reliable evidence.
- **Observational studies.** These encompass dashboard analytics, funnel analysis, user behavior patterns, etc. They can help identify issues and suggest potential data correlations, but they cannot be used to prove causality.
- **Uncontrolled experiments.** These are pre-post analyses (i.e., rolling out a change and verifying its impact) and other kinds of experiments that are vulnerable to confounding factors (e.g., seasonality, marketing campaigns, pricing adjustments).
- **A/B tests.** The gold standard for establishing causality. We have published two entire articles on [what makes a good A/B test](https://nebulab.com/blog/ecommerce-ab-testing) and [how to avoid the most common types of biases when A/B testing](https://nebulab.com/blog/ecommerce-ab-testing) (it’s harder than you think), so we encourage you to read up on the matter!
- **Meta-analyses.** Aggregating results across tests, either through systematic reviews or sequential testing methods, is the strongest form of evidence, but it’s also exceedingly rare in digital product development and e-commerce (and, in many cases, unnecessary).

As you have probably guessed, the data at the top of the pyramid is the most reliable, but it’s the hardest to collect; the data at the bottom of the pyramid is the least reliable, but it’s the easiest to collect.

## How To Use the Pyramid

You can use the pyramid to map your data collection maturity. In doing this, it’s important to distinguish between data you *collect* and data you *trust*:

- Understanding what data you collect is easy. In our experience, most brands stop at observational studies or uncontrolled experiments. While A/B testing is common in e-commerce, it’s rarely done with the rigor required to produce useful insights.
- Understanding what data you trust is trickier and more political. As an example, if you collect granular data on the performance of your merchandising strategy, but then you throw it all away when the CEO sends you a Slack message, that data is being collected but not trusted.

Once you have this understanding, your goal should be to graduate to the next level of trust.

But that doesn't mean flipping a switch overnight. The transition from one layer to the next is less about chasing perfect alignment and more about creating structured opportunities to challenge your assumptions with more reliable evidence.

For instance, imagine your analytics suggest that customers are dropping off at the shipping step of your checkout. A pre-post analysis might show a lift after simplifying that step, but it's hard to isolate the cause. So you run an A/B test that confirms the shorter form improves conversion—but only on mobile. That result contradicts a prior assumption that desktop was the problem, and it gives your team stronger footing to explore mobile-first optimizations.

**The point isn't to confirm what you already believe. It's to upgrade the quality of your decision-making, even when the results surprise you.**

By doing this, you’re allowing your organization’s approach to customer experience to mature more gradually. That means your team doesn’t have to pause all work for a six-month analytics overhaul. Instead, they can start small, run a focused A/B test, or build a hypothesis from behavioral data, and incrementally build momentum.

When CX leaders adopt this model, they gain the credibility to win time and budget for long-term projects (solving the short-termism problem), and Gget everyone making decisions based on the facts, not opinions (solving the trust problem).

Over time, organizations become more data-driven, trusting rigorous evidence over intuition and making faster, more confident decisions.

## Small Steps, Compounding Impact

The brands that win on customer experience aren't necessarily the ones with the biggest budgets or the flashiest tech stacks. They're the ones that build feedback loops, run smart tests, and act on what they learn, week after week and quarter after quarter.

You don’t have to wait for a replatform or an executive offsite to start. Identify your current level of evidence maturity. Run one better experiment. Make one stronger decision. Then do it again.

This is how transformation happens: not with a bang, but with a rhythm.

Need help getting your team in the right rhythm? [Let’s talk.](https://nebulab.com/contact-us)

Why Your Brand Is Not Really Data-Driven (And What to Do About It)

In the first two posts of our series on Experience-Led Commerce, we laid the foundation for why customer experience (CX) is one of the most powerful (and most underutilized) levers for sustainable e-commerce growth.

We saw that in an environment of rising acquisition costs and changing consumer behaviors, [brands that invest in customer experience can outperform their peers across virtually every metric](https://nebulab.com/blog/ecommerce-growth-customer-experience): lower CAC, higher LTV, and improved conversion rates. We introduced *Experience-Led Commerce* (XLC) as a structured approach to making that investment count.

[We also explored how customer experience spans three dimensions](https://nebulab.com/blog/what-is-ecommerce-cx): when, where, and why customers interact with your brand. Combined together, these three angles provide a clearer and more actionable framework than traditional customer personas.

But with the foundation laid out, we are now faced with a critical question: where should you start if you want to start investing into your brand’s customer experience? With today’s [“messy middle,”](https://www.thinkwithgoogle.com/consumer-insights/consumer-journey/navigating-purchase-behavior-and-decision-making/) so many touchpoints to optimize, and so many technologies to adopt, even the most sophisticated brand operators can end up feeling overwhelmed, which can lead to bad investments or analysis paralysis.

This article is our answer to that conundrum. We’ll outline the exact process we follow at Nebulab to go from unstructured data to structured insights to prioritized opportunities. By the end of the article, you’ll have a modular framework that you can easily replicate for your own brand based on your resources and level of maturity.

Without further ado, let’s take a look!

## Step 1: Collect the Right Data

To improve your customer experience, you first need to understand what it looks like today—not just in theory, but in the messy, real-world interactions your customers have with your brand across channels, platforms, and moments in time.

As you may imagine, this understanding can only come from data, both qualitative and quantitative. By continuously collecting and analyzing data about the state of your customer experience, you can start forming a picture of the state of play.

The data that we typically collect during a CX audit includes:

- **Anecdotes:** Strategic priorities, internal assumptions, and departmental pain points. The stuff that your gut tells you to be right. For some organizations, this is unfortunately the only data source that matters. Others will scoff at this in favor of a pure-play data-driven methodology. We think neither approach is correct, and we’ll see why in a second.
- **Expert heuristics**: UX/UI audits, competitor benchmarking, and other heuristic reviews to spot points of strengths, points of friction and gaps in your customer experience. [Baymard](https://baymard.com/) is the state of the art when it comes to e-commerce UX. We rely on their library extensively, but we also combine it with our own expertise and the client’s business/operational context.
- **Market research**: Consumer confidence trends, macroeconomic factors, pricing sensitivity, and industry forecasts. These will give you an idea of what consumers are looking for, what trends to ride and what ships to abandon. At the same time, you should be mindful that market research can only give you a map, and the map is not the territory.
- **Voice of the customer**: As the name suggests, this is quite literally what your customers are telling you about your brand and experience. Customer interviews, first- and third-party product reviews, on-site surveys, social media comments all fall under this category. However, you should know that people will often lie about their intentions and desires, even when they don’t realize they’re doing so.
- **Behavioral analytics**: Not what your customers are saying, but rather what they’re doing. This includes funnel analytics, session replays, heatmaps, return rates and reasons, and the results of your A/B test experiments. While more reliable, behavioral analytics are inherently partial (they tell you what, not why) and backwards-looking (they analyze the past and cannot predict the future).

One common pitfall you may run into here is to go too deep on one data source at the expense of all the others: collecting one year of customer reviews may not be as important as collecting the latest three months of customer reviews and pairing those with quantitative data about the return rates and return reasons of different product categories. This is one of those cases where variety matters more than volume.

Furthermore, data has an expiration date. Market research from two years ago may be generally interesting, but it’s likely the economy and your industry have shifted significantly since that report was produced. This means that going too deep on one data source isn’t just useless: it can actually be counterproductive by polluting your data set.

This may sound hard already, but collecting data is actually the easy part. The real challenge lies in making sense of it.

## Step 2: Turn Data Into Insights

The second step in your data-driven journey is synthesis. This is where you look at the data and start poking at it to answer questions such as:

- Where do stakeholder perceptions align (or not) with customer sentiment?
- Which complaints show up in product reviews, focus groups, and support tickets?
- Where are users dropping off in the funnel, and what are they saying when they do?

Good synthesis is more art than science, and it requires both pattern recognition and critical thinking. It involves looking for friction and flow—moments that either propel users forward or send them backward. With one client, for instance, we observed that users were often confused by the site's taxonomy. This friction was surfaced in the UX audit, confirmed in session replays and bounce rates, and ultimately traced back to a lack of backend tagging standards that also hampered merchandising and CRM—something that was lamented in stakeholder interviews.

Artificial intelligence can be a powerful ally in this phase, especially when you're dealing with large, complex datasets:

- For qualitative data, AI can cluster open-ended responses, extract sentiment trends from hundreds of reviews, or summarize transcripts into digestible themes.
- For quantitative data, it can automatically flag anomalies in metrics, identify statistically significant shifts in conversion rates, or correlate changes in performance with external factors like promotions, ad spend, or inventory levels.

Used well, AI helps you explore multiple hypotheses quickly, highlight non-obvious connections, and surface the signals buried in the noise. What it *shouldn’t* do is replace human interpretation. Think of it as an accelerator—it helps you go faster, see broader patterns, and zoom in on what matters, all so you can focus on decisions, not data wrangling.

Here are a few example prompts you might use to synthesize insights:

- "What are the top 3 recurring complaints in these reviews?"
- "Summarize this interview transcript by theme and tone."
- "Group these support tickets into top 5 issue types with example quotes."
- "Highlight any statistically significant drop-offs in this conversion funnel."
- "Which campaigns had the highest impact on AOV last quarter?"

When running audits, we follow a battle-tested AI-assisted workflow that involves progressive summarization and distillation of the data:

1. We store the raw data from each data source in an internal database.
2. We ask the AI to summarize the key insights from each datapoint.
3. We ask the AI to further cluster the summaries by each data source.
4. Finally, we use the AI to produce a single executive summary.

At every step, we store the AI’s output as its own artifact, which allows us to either drill down into the individual datapoint or get the ten-thousand foot view by reading the executive summary, which helps us have informed discussions for different purposes and at different levels of granularity. It also allows us to find areas of alignment and contradictions between datapoints or data sources (more on how to handle these in the paragraphs below), which helps us validate the integrity, quality and thoroughness of our research.

By this stage, you should have an executive summary that clearly outlines the state of your current customer experience from multiple different perspectives and viewpoints.

The next step is to understand what opportunities those insights open for your business.

## Step 3: Turn Insights into Opportunities

This is the phase where a strategy finally begins to take shape.

At this point, you’re not just looking at what’s broken—you’re figuring out how to fix it. To do that, you need to bridge the gap between what the data tells you and what action you can take. For each insight you've uncovered, ask yourself: what can we do about this?

For example:

- If your qualitative research shows customers consistently complain about a confusing checkout flow, your opportunity is to redesign the checkout—possibly starting with small experiments like simplifying the shipping form.
- If analytics reveal a high return rate on a specific product category, the opportunity may lie in improving product detail pages, sizing information, or the product itself.
- If reviews and support tickets highlight unmet expectations around delivery timelines, the opportunity could involve improving operations or setting better expectations through copy and UI.

Each problem statement then becomes a candidate opportunity. But not every opportunity is worth tackling immediately. That’s where the **ICE framework** (Impact, Confidence, Effort) comes in. You should assess each opportunity by its:

- **Impact**: How much value could this create for your users and your business?
- **Confidence**: How confident are you that this change will solve the problem?
- **Effort**: How complex or costly is the solution?

Scoring each opportunity across these three dimensions allows you to build a prioritized backlog. Quick wins (high impact, high confidence, low effort) go to the top and will usually be executed right away. High-effort or low-confidence ideas go into your long-term roadmap.

Turning insights into opportunities is where both intuition and industry expertise become critical. Matching symptoms to solutions is not enough; you need to understand what’s *really* driving the friction and how it plays out in your specific context.

A DTC supplement brand notices that many customers cancel their subscription after the first month, citing “didn’t see the benefits.” A less experienced team might respond by offering deeper discounts or extending the trial period. But a closer look reveals that customers often don’t take the supplements consistently—or aren’t sure what to expect. The real opportunity is to design an onboarding flow that educates users on dosage, timing, and expected outcomes, paired with reminders and habit-building tips.

This is why cross-functional collaboration, paired with seasoned judgment, often makes the difference between good ideas and transformative ones.

But even experienced operators are not infallible, which is why we don’t just blindly roll out our solutions. Instead, we generate multiple hypotheses and validate both our assumptions about the root cause and the potential effectiveness of each solution. We do that by borrowing another concept—this time, it’s called Lean Validation.

## Step 4: Execute, Measure, and Iterate

Lean Validation comes from the Lean Startup methodology, where the goal is to maximize learning while minimizing waste. Instead of committing fully to a solution, you test it as early and cheaply as possible. The aim is to understand whether the direction you’re heading in is sound and reduce the risk of spending significant resources on something that doesn’t work.

You can validate ideas leanly with:

- A/B tests on key journeys
- Unmoderated user tests on wireframes or prototypes
- Email experiments or landing pages to test messaging or demand
- “Fake door” tests to gauge interest before building the full solution
- Clickable prototypes to observe usability without writing production code

If you’ve paid attention, you’ll notice that lean validation is where the loop closes: you’re effectively returning to the data collection stage, except this time your goal is not to understand the original problem, but rather to validate whether your proposed solution is effective. In technical terms, your research has now shifted from generative to evaluative. Then, equipped with more data about the validity of your solution, you can decide whether you should roll it out or go back to the drawing board and try a different approach.

To learn more about this mindset and how to operationalize it, we recommend reading our post on [applying digital product management to e-commerce](https://nebulab.com/blog/ecommerce-product-management), where we explore how to build and evaluate solutions through rapid experimentation and continuous discovery.

## Putting It All Together

Experience-Led Commerce is a playbook that helps brands move beyond discounting wars, beyond channel fragmentation, and beyond gut-feel roadmaps. It gives you the clarity to see what your customers need, the structure to act on it, and the systems to keep learning as you grow.

Now you’ve got the blueprint—one that scales with your brand as you grow. But if you want help building it out, you don’t have to do it alone. [Let’s talk.](https://nebulab.com/contact-us)

From Data to Growth: A Framework to Build Your E-Commerce Roadmap

*This is the second article in a series about enterprise e-commerce replatforms. The first article is about [running discovery workshops](https://nebulab.com/blog/replatform-discovery-workshops), which lay the foundation for a successful migration strategy.*

Replatforming is one of the riskiest moves an enterprise e-commerce team can make. For brands processing thousands of orders an hour, the thought of switching platforms conjures visions of downtime, lost sales, and panicked operators scrambling to fix errors. It’s no surprise that many CTOs and e-commerce managers hesitate to move to Shopify Plus, even when their legacy platform is holding them back.

But it doesn’t have to be that way. At Nebulab, we’ve developed a phased, risk-mitigated approach to Shopify replatforming that allows enterprise brands to make the switch incrementally—without downtime, feature freezes, or disruptions to daily operations. The key? A zero-risk rollout strategy that begins with a comprehensive Discovery Workshop.

## How to Roll Out Shopify Without Risk

One important tradeoff to consider with this approach: while it may slightly increase the overall project timeline, it significantly shortens your time-to-value. Because you're launching a lean implementation early in the process, your team begins learning, iterating, and delivering value from day one—long before a traditional big-bang launch would go live.

Our rollout strategy begins by identifying a part of the business that can be safely isolated. This might be a low-volume country, a non-core sales channel, or a product line with minimal business impact. We then build a lean Shopify implementation for that segment, prioritizing reliability over feature parity.

Once live, we run both platforms in parallel. To maintain data consistency, we implement bi-directional sync mechanisms between Shopify and the legacy platform. Orders, inventory updates, and customer data are pushed in near real-time via middleware or a shared OMS. For instance, when an order is placed on Shopify, it is instantly mirrored on the legacy platform, and vice versa. This ensures fulfillment, accounting, and analytics teams can continue operating without change.

Depending on the systems involved, we may use webhooks, direct API integrations, or tools like Matrixify—especially when data is already formatted for its use. Where necessary, we normalize data structures across platforms to avoid inconsistencies and edge-case failures. The result is a seamless flow of information, so business teams don’t need to alter their workflows.

We also implement robust monitoring and logging for every sync operation. This allows us to detect and resolve any data mismatches or delays before they become operational problems. By this stage, Shopify is already live in production—but the real value lies in observing its performance with real traffic and users.

Let’s break down the phases of a hypothetical rollout plan:

## Phase 1: Run Shopify Side-by-Side

In the first phase, we establish a dual-platform setup.

![](https://cdn.sanity.io/images/kqgmf0g2/production/61212d99d708984bdd92ed04f5614daa3bf15178-2572x1408.png?fit=clip)

Here’s how it works:

* We launch Shopify for a single, low-risk market or sales channel. This might be a small international market or a limited product line.
* Users in that segment interact solely with Shopify, while other markets continue using the legacy platform. A useful trick here: leveraging Shopify’s new Customer Accounts. These accounts use one-time passwords, so we can migrate only the relevant users’ orders without needing password data. Later, we can connect accounts with a custom [identity provider](https://help.shopify.com/en/manual/customers/customer-accounts/new-customer-accounts/identity-provider) if needed.
* Shopify and the legacy platform are tightly integrated. Products and collections sync from the legacy platform to Shopify, preserving PIM processes. Orders placed on Shopify sync back to the legacy system or a shared OMS, so downstream integrations and operations (fulfillment, finance, support) remain unchanged.

This setup lets us test Shopify in a real-world environment without disrupting existing operations. If needed, rollback is simple: we redirect traffic back to the legacy platform without affecting back-office systems.

## Phase 2: Scale Up, One Market at a Time

The second phase is about expanding Shopify’s footprint through multiple, incremental iterations.

![](https://cdn.sanity.io/images/kqgmf0g2/production/ad05fda4084d4ded3afcb43eab002a0db60c5252-2558x1442.png?fit=clip)

We do this by:

* Selecting the next market or sales channel with lower business impact.
* Identifying gaps between current Shopify features and that market’s requirements—such as shipping methods, currencies, or languages.
* Filling those gaps to prepare Shopify for increased traffic.

For example, we might help a brand expand from a single EU market to several, simply by iterating on localization and shipping options. As each iteration proves successful, we redirect traffic and repeat the process, steadily building confidence.

Eventually, all segments are running on Shopify—a sign that the migration is functionally complete.

## Phase 3: Shut Down the Legacy Stack

Now that all traffic has moved to Shopify, we begin dismantling the old platform.

![](https://cdn.sanity.io/images/kqgmf0g2/production/e2a91030b561cf780cfba72648c210221d07946f-1874x1438.png?fit=clip)

This phase is essential for reducing technical overhead and cost. Rather than replacing all integrations at once, we decouple each one individually, each with its own rollback plan. This reduces the risk of introducing widespread issues.

A typical sequence might start with analytics, followed by CRM and other integrations. Each step gives us a chance to verify behavior and performance before moving on to the next.

By the end, every integration runs directly through Shopify, and we can fully decommission the legacy system with confidence.

## What This Looks Like in the Real World

With a parallel architecture in place, we expand Shopify’s role country by country, channel by channel. Each new launch is reversible. If issues arise—UX bugs or operational hiccups—we simply reroute traffic to the old system.

In one recent project, we started with a few low-impact countries. The initial Shopify build handled basic operations but deliberately omitted full feature parity. This allowed rapid testing and iteration. As each market validated the setup, we introduced localized features and content. Eventually, the platforms became so similar that migrating the core markets felt like a natural final step.

Another client, using a headless setup, took a slightly different route. They began by migrating their image CDN—a feature included in any Shopify plan. This alone offset the cost of their plan. Next, they moved PDPs to Shopify’s Storefront APIs. PLPs are next, still powered by Algolia, which remains synced with the old platform. Bit by bit, they’re building a safer, modular migration path.

## When Is a Phased Rollout Worth It?

This phased, dual-system approach is ideal for large, complex e-commerce operations. A full cutover is too risky: even a single hour of downtime can cost tens of thousands and cause long-term brand damage. With deep integration needs across ERPs, OMSs, CRMs, and analytics platforms, maintaining operational continuity is non-negotiable.

Running both platforms in parallel creates a safety net that justifies the extra engineering effort.

One important tradeoff to consider: while this approach may slightly extend the overall project timeline, it significantly shortens your time-to-value. Because you're launching a lean implementation early, your team starts learning, iterating, and delivering value much sooner than with a traditional big-bang launch.

Smaller brands may not need this level of complexity. If your tech stack is simpler, with fewer integrations and lower order volume, a direct switch might be more efficient. At Nebulab, we help clients choose the right strategy based on their scale, risk tolerance, and operational maturity.

## Replatforming Without Regret

Traditional replatforming aims for full feature parity before launch. That usually leads to long timelines, bloated requirements, and fragile go-lives that can’t be reversed.

Our approach is different. We start small, test early, and scale with intention. With robust data sync, meticulous planning, and real-world validation, we make each phase of migration safe, reversible, and rooted in operational reality.

Enterprise replatforming doesn’t have to be an all-or-nothing gamble. With the right strategy, you can migrate to Shopify Plus in a safe, phased, and fully reversible way. [Let's do it together!](https://nebulab.com/contact-us)

A Dual-Run Strategy for Zero-Downtime Shopify Replatforms

As executives at enterprise and mid-market brands increasingly turn to more modern commerce platforms for their flexibility and ecosystem advantages, the stakes have never been higher. A failed replatform doesn't just mean cost overruns—it means lost revenue, damaged team morale, and potentially catastrophic business disruption.

The solution isn't more sophisticated technology or larger budgets. It's a disciplined approach to discovery that surfaces what truly matters before a single line of code is written.

## Why Most Agencies Get Discovery Wrong (And Why That's Expensive)

Here's the uncomfortable truth: most agencies treat discovery as a checkbox exercise. They'll send a brief questionnaire, schedule a few calls, and call it done. The reason is simple—*thorough discovery doesn't scale*. It requires senior talent, takes weeks to execute properly, and can't be easily templated across clients.

But this shortcuts approach creates predictable problems:

- **Misaligned stakeholders** discover fundamental disagreements three sprints into development.
- **Hidden technical debt** surfaces when legacy systems refuse to integrate cleanly.
- **Scope creep** becomes inevitable when requirements weren't properly captured upfront.

The financial impact is severe. We've seen brands burn through millions (yes, really) in development costs before realizing their initial assumptions were wrong. One client came to us after three failed projects in which different agencies had attempted to migrate the brand's custom subscription model to Shopify—failures that could have been prevented with a proper discovery process.

## The Executive Case for Deep Discovery

Consider discovery an insurance policy for your replatforming investment. A properly executed discovery workshop costs 5-10% of your total project budget but can prevent 50-80% of the risk factors that typically derail implementations:

- **Risk mitigation** is the primary value proposition. Discovery workshops identify integration challenges, stakeholder misalignments, and technical constraints before they become expensive problems.
- **Accelerated time-to-market** follows naturally. Teams aligned on clear requirements move faster than teams constantly having to change course.
- **Improved team dynamics** emerge from collaborative planning. Discovery workshops reveal communication patterns, decision-making processes, and internal politics that will impact your project's success.

## Nebulab's Discovery Framework: A Five-Phase Approach

Our discovery process has evolved through countless replatforming projects over the years. It's designed to surface critical information and design an implementation plan that minimizes risk and maximizes alignment.

### Phase 1: Stakeholder Alignment and Baseline Setting

Before any workshop begins, we identify the right participants. This isn't about including everyone—it's about including the *right* people. We need at least one representative from each department that will either execute the replatform or be impacted by its results.

**The stakeholder selection process matters more than most teams realize.** Include too few people, and you'll miss critical requirements. Include too many, and the workshop becomes unwieldy. We typically aim for 6-8 participants maximum.

Each stakeholder receives a comprehensive questionnaire covering their role, current systems, performance metrics, and concerns. The survey is tailored to uncover the specific information we'll need for productive workshop discussions.

The questionnaire serves two purposes: it gives us baseline context and starts stakeholders thinking strategically about the project. When people arrive at the workshop, they're already mentally prepared for deeper discussions.

### Phase 2: Envisioning Success and Failure

Every workshop begins with alignment on what we discovered during stakeholder interviews. We present our findings and ask: "Does this accurately reflect your situation?"

**If everyone agrees, we proceed. If there's disagreement, we've identified a critical issue.** Internal misalignment often masquerades as technical complexity. Better to surface and resolve these conflicts in week one than discover them in month six.

Our first collaborative exercise involves **envisioning success.** Each stakeholder writes down what their ideal end state looks like—not just technical specifications, but business outcomes. Fast-forward to six months post-launch: what does success look like for your specific role and responsibilities?

**The counterpoint exercise, a Pre-Mortem, follows immediately:** if everything goes horribly wrong, why did it fail? This approach consistently surfaces risks that wouldn't emerge through traditional requirements gathering.

These exercises reveal stakeholder priorities and potential conflicts. When the marketing director envisions "flexible campaign landing pages" but the IT director fears "maintaining custom functionality," we know there's a conversation to be had.

### Phase 3: Architectural and User Journey Mapping

**Understanding your current state is prerequisite to designing your future state.** We map your existing technical architecture, focusing on data flow and system integration. We answer questions such as:

- What are the third-party systems you integrate with?
- How do inventory updates flow between those systems?
- What happens when a customer initiates a return?

We then conduct a user journey mapping exercise, **giving equal dignity to both customers and internal users.** Your operations team, customer service representatives, and marketing coordinators all have their own user journeys, with their own points of friction that impact business performance. A replatform that optimizes for end-customer experience while creating (or failing to address!) friction for internal users is a failed replatform.

The architectural and journey mapping exercises run in parallel, with insights from one informing the other. Technical limitations often explain customer experience friction, while user behavior patterns reveal why certain integrations are critical or what integrations are missing that would facilitate the user's life.

### Phase 4: Solutioning

In the fourth part of the workshop, we move into solutioning, where we design the new reality.

**In doing this, we typically aim to be very conservative with the consumer's user journey:** unless there's compelling business justification for dramatic change, the post-replatform consumer UX should closely mirror the existing one. This might seem counterintuitive: after all, isn't the whole point of the replatform to _improve_ the user experience?

While the answer is yes, that doesn't mean you should do it immediately. Postponing the UX improvements reduces development complexity, contains implementation costs, and minimizes the risk of alienating your users with a completely new UX. We've discussed this (somewhat counterintuitive) approach at length in [our article about replatforms:](https://nebulab.com/blog/ecommerce-replatforms) **time and time again, we've seen a more conservative approach outperform big-bang replatforms.**

Architectural changes, however, can and should be more transformative: during this phase, we redesign your e-commerce infrastructure to support your business objectives and enable future evolution. This means dropping legacy tools, improving how you use them, or adopting new ones, with the two-fold goal of streaminling your internal operations and enabling future evolution for your consumer UX.

### Phase 5: Launch Strategy and Risk Mitigation

In the fifth and final stage, we have a good understanding of where you are and where you want to be. All that's left to figure out is how to get there.

To do that, we design your launch strategy, and we do it **based on your scale and risk tolerance.** While smaller brands might opt for a coordinated launch across all channels and markets, enterprise clients typically require phased rollouts, beta testing with select customer segments, or market-by-market deployment.

The launch strategy is usually a mix of business considerations (e.g., will team members have to operate two systems until we're fully switched over?) and technical considerations (e.g., how are we going to keep data in sync between different systems during the interregnum?).

We also go deep on risk mitigation: what can go wrong at different stages of the project, how are we going to minimize that risk, and what is our recovery process for the worst-case scenario?

This phase concludes the workshop and produces your implementation roadmap, complete with timeline, resource requirements, and risk mitigation strategies.

## What Discovery Workshops Do (And What They Don't)

As you have seen, discovery workshops have several benefits:

- **They set the stage for a successful replatform.** Clear requirements, aligned stakeholders, and realistic timelines create conditions for successful partnerships, preventing friction and second-guessing.
- **They generate returns that extend far beyond replatforming projects.** The architectural diagrams, user journey maps, and stakeholder alignment achieved during discovery become valuable assets for future initiatives.
- **They improve your internal communication and decision-making processes.** The skills and frameworks learned during discovery transfer to other strategic projects.

However, a discovery workshop is not a panacea! No matter how thorough your workshop, you will never be able to capture your full spectrum of requirements, and you will still be left with unanswered questions. That's alright: the purpose of the workshop is not to eliminate uncertainty, but rather to identify the areas of biggest uncertainty so that you can adress them head-on during the project rather than pretend they don't exist.

If you're looking to replatform and could use some help running a discovery workshop, [reach out!](https://nebulab.com/contact-us) We've run countless workshops over the years and would love to help make your replatforming project a success.


Better E-Commerce Replatforms Require Better Discovery Workshops

It's that time of the year! After spending considerable time going through [Shopify's Summer 2025 Edition](https://www.shopify.com/editions/summer2025) and experimenting with some of the features that became available over the last few months, we are excited by the platform's latest releases: Shopify continues to push the boundaries of what's possible in e-commerce, with remarkable new features and expanded capabilities.

Still, while the overall direction is encouraging, we've also identified some implementation challenges, particularly for the type of mid-market and enterprise client we serve.

Let's take a look at what's changed, what it means for developers and merchants, and where we think Shopify should focus next!

## Horizon: Who's Thinking About the Developers?

![](https://cdn.sanity.io/images/kqgmf0g2/production/2c1d263d8905534742e7b134c45f61f38d02d978-800x450.webp?fit=clip)

[Shopify's new Horizon theme](https://www.shopify.com/news/summer-25-edition-merchant) created a lot of excitement, especially with the no-code/low-code crowd: with the new nested blocks and [AI-powered block generation](https://www.shopify.com/blog/expanding-your-ai-horizons-summer-edition-25), merchants have more flexibility than ever.

While we appreciate all the love that went into [Horizon](https://themes.shopify.com/collections/horizon-themes), our team also had some concerns:

- "What happens to Dawn now?" was the recurring question. With Horizon being the new standard, we expect Dawn to be left behind, forcing agencies and merchants to adjust.
- As most developers learn at some point, giving non-technical users more content management flexibility often comes at the expense of UX and brand consistency. Could Horizon be _too_ flexible for a merchant's own good?
- While Horizon is great, it primarily addresses Shopify's SMB merchants. Meanwhile, developers still need to build custom CI/CD pipelines if they want a robust theme management workflow.

The Shopify theme ecosystem is already renowned for its friendliness towards non-technical users. As Shopify gains traction in the mid-market and enterprise segment, we were also expecting the platform to invest in more robust primitives, tooling, and workflows for theme development—especially since larger merchants are increasingly choosing Liquid over headless in an effort to simplify (more on this below).

As an example, an improved GitHub integration could streamline theme development significantly, and it would be the perfect complement to Shopify's marketing- and simplicity-centered narrative.

## Markets: Segmentation Evolves Beyond Geography

![](https://cdn.sanity.io/images/kqgmf0g2/production/4224e88863540e39b12e9556cf23fbba6c15ba13-1280x720.jpg?fit=clip)

With the latest updates, Shopify has turned Markets from an internationalization tool into a more comprehensive segmentation platform. Merchants can now [segment markets by customer type (B2C vs. B2B), geography and channel (online vs. retail)](https://www.shopify.com/blog/markets), all from a unified interface.

However, despite the new experience finally putting an end to the discrepancies between B2B, POS, and the old Shopify Markets, we also think there's room for improvement:

- The new Markets interface requires a learning curve—the parent-child market relationships aren't immediately intuitive, which is understandable given the complexity of the problem Shopify is solving.
- While Shopify has fixed a number of bugs related to Markets and New Customer Accounts, some were left unaddressed. As an example, the "Buy Again" button still defaults to your primary market rather than the purchase market.

We're also a little concerned by the state of the ecosystem around Shopify Markets: in our experience, very few third parties are able to integrate with Markets at the moment.

Alberto from our team raised an important consideration: "With the new Markets, the ecosystem will need time to align. It took three years for some apps to start supporting the current Markets architecture, and these updates may require them to redo some of the work."

## Next-Gen Dev Platform: So Far So Good

![](https://cdn.sanity.io/images/kqgmf0g2/production/1a7cee517c85cff09117135aa8d89a57347ac715-800x450.webp?fit=clip)

[Shopify's next-gen developer platform](https://shopify.dev/beta/next-gen-dev-platform) shows real promise, with local development capabilities, declarative metaobjects/metafields definitions, monitoring and logging, and much more.

The direction is encouraging, even though some core challenges remain:

- The new localhost architecture is exciting and could really speed up the development of custom apps. Unfortunately, it doesn't support webhooks or Shopify Flows yet—both of which we use heavily. We do recognize these are tough problems to solve, but we're also confident Shopify can figure them out!
- Declarative data definitions are an interesting solution to the ancient problem of Shopify schema management. However, because the resulting metaobjects and metafields are app-owned, they can't be used across different apps, which is problematic in large builds where merchants have multiple custom or third-party apps that need to be integrated.
- The [unified Polaris Web Components](https://shopify.dev/beta/next-gen-dev-platform/polaris) are incredible, but will require yet another migration. Alas! At least there's [an MCP server](https://github.com/Shopify/dev-mcp) to help with the job.

As we excitedly wait for the next batch of improvements, we'll continue to complement Shopify's built-in capabilities with some of our custom tooling, such as [Shopify Toolkit](https://github.com/nebulab/shopify_toolkit).

### AI: One MCP Server to Rule Them All

![](https://cdn.sanity.io/images/kqgmf0g2/production/f98633309e66df5cc87c4530e5fee392ddf07c81-2840x2130.webp?fit=clip)

Quite frankly, the early iterations of Shopify Sidekick were underwhelming to say the least: the agent would hallucinate more often than not, unable to answer even the most basic queries.

Today's version tells a different story entirely. With sophisticated reasoning capabilities and deep platform integration, [Sidekick](https://www.shopify.com/blog/expanding-your-ai-horizons-summer-edition-25#3) now delivers usefulinsights on conversion metrics, bounce rates, and sales performance, and can even take action on behalf of the merchant. While we don't see larger brands dropping more sophisticated analyticsa and BI tooling for Sidekick, it is undeniably come a long way.

But Shopify is not using AI just for operational efficiency. With Perplexity, ChatGPT, and Google all recently announcing their AI shopping features, the platform is investing heavily in standardized and interoperable data access. As a couple of examples:

- The [Global Catalog](https://changelog.shopify.com/posts/introducing-shopify-catalog) allow LLMs to retrieve structured, real-time catalog access optimized for AI consumption. Also, Global Cart and Checkout should be launching soon, allowing LLMs to enable end-to-end conversational checkout experiences.
- The [Storefront](https://shopify.dev/docs/apps/build/storefront-mcp/servers/storefront) and [Customer Accounts](https://shopify.dev/docs/apps/build/storefront-mcp/servers/customer-account) MCP servers open new possibilities for AI-driven shopping experiences: think a wine sommelier chatbot with full inventory awareness and transactional capabilities.

While most of these products are in their very early stages, we'll keep experimenting over the next weeks and months to get a sense of all the potential use cases, so stay tuned!

## The Road Ahead

While this Edition was impressive as always, here's _what else_ we would have liked to see but didn't!

### Search & Discovery Needs Some Love

First of all, Shopify's Search & Discovery continues to lack advanced capabilities:

- Empty collections appear prominently in search results with no built-in way to hide them, creating a poor user experience that directly impacts conversion rates, especially for international merchants that might only sell certain collections in specific markets.
- The inability to use metafields for search indexing forces merchants into awkward workarounds—like copying metafield data into product descriptions just to make it searchable.

When merchants invest heavily in rich product data through metaobjects and metafields, that investment becomes worthless if customers can't discover products through that enhanced information.

As a result of some of these issues, one of our clients recently switched back to their custom search solution after finding Shopify's native search inadequate for their catalog complexity.

For a platform now positioning itself as enterprise-ready, we're hoping to see more investment flow into Search & Discovery to fully integrate it with the rest of Shopify's ecosystem.

### Whatever Happened to Hydrogen?

Perhaps the most interesting omission from the Summer 2025 Edition was the near-complete absence of Hydrogen updates, which might seem even more puzzling considering how much attention it has received in [Summer '24](https://nebulab.com/blog/shopify-editions-summer-2024) and [Winter '25](https://nebulab.com/blog/shopify-boring-edition).

However, given what we're seeing in the market, we were not too surprised that Hydrogen is taking a backseat: the reality is that most brands are currently choosing Liquid themes over headless solutions, prioritizing simplicity and reliability. Even brands that initially launched on Hydrogen are migrating back to Liquid themes, finding that the promised flexibility doesn't justify the additional overhead in the current economic climate.

To be fair, Shopify did release [Storefront Web Components](https://shopify.dev/docs/api/storefront-web-components), allowing merchants to embed the Shopify experience off-site and anywhere they can use HTML—we have some demos coming soon!

All in all, we're confident that we'll see more news about Hydrogen in the upcoming months, but for the time being, the market—and Shopify with it—have focused elsewhere.

## What This Means for You

Shopify's Summer 2025 Edition brought meaningful progress, although some annoying gaps persist. While we expect Shopify's future updates to address some of these pain points, brands should also strive to understand what Shopify does exceptionally well and where additional investment may be necessary to meet their specific business requirements.

At Nebulab, we're excited to help clients leverage these improvements while building complementary solutions where needed. If you need any help integrating Shopify into your business, [don't hesitate to reach out!](https://nebulab.com/contact-us)

Beyond the Horizon: An Honest Take on Shopify’s Summer 2025 Edition

In our [previous article](https://nebulab.com/blog/ecommerce-growth-customer-experience), we established why customer experience has become a **critical differentiator** in today's challenging e-commerce landscape.

In our work at Nebulab, we've seen firsthand how CX can help brands stand out in increasingly competitive markets. We've begun to call this approach "Experience-Led Commerce" (XLC)–a systemic and systematic process that brands can adopt to **leverage customer experience to increase revenue and profit, minimize operational costs, and achieve their strategic objectives**.

Experience-Led Commerce was designed to accomplish two goals:

- It helps brands decouple their value proposition from product and pricing alone, allowing them to escape the race to the bottom ignited by price comparison and use their customer experience as a competitive differentiator, which **reduces Customer Acquisition Costs (CAC)** by minimizing a brand's reliance on aggressive discounting and other promotional tactics.
- It helps brands maximize the impact of their performance marketing activities. Once your acquisition funnel brings customers to your website, a superior experience ensures they **convert at higher rates and return more frequently**, creating a virtuous cycle that increases Customer Lifetime Value (CLV) and improves profit margins.

In this series, we are gradually unveiling the entire XLC process—from collecting qualitative and quantitative data about your customer experience, to synthesizing the data to extract actionable insights, to building an insight-informed CX roadmap that delivers **measurable, sustainable, and repeatable brand growth**.

The first step in that journey is to understand what we mean by "customer experience." In this article, we're going to do just that.

## A Structured Framework for E-Commerce CX Analysis

Over the years, the idea of customer experience has been used and abused to serve a wide array of interests. As it often happens, customer experience has become an empty vessel, much to the detriment of vendors genuinely interested in pushing the space forward and brands looking to develop a comprehensive CX strategy.

While the CX universe is vast and nuanced, building a shared understanding is possible, and it starts with unpacking the three core dimensions of customer experience. Rather than starting with rigid customer personas, which often become overly theoretical or fluid in practice, our framework focuses on the **actual touchpoints, motivations, and mechanisms that directly shape how real customers interact with your brand**.

### 1. When: The Purchase Journey

A brand's purchase journey unfolds over time across five key phases: Awareness, Discovery, Consideration, Conversion, and Retention. Each phase comprises multiple touchpoints where customers interact with your brand:

- **Awareness**: The customer becomes aware of your brand through ad campaigns, retail displays, word of mouth, PR coverage, social media, industry events, or organic search.
- **Discovery**: The customer actively explores your offerings through browsing (online or in-store), product demonstrations, catalog review, content marketing, store visits, or marketplaces.
- **Consideration**: The customer evaluates options by reading reviews, consulting with sales associates, examining product specifications, requesting samples, comparing alternatives, or seeking advice from their network.
- **Conversion**: The customer makes a purchase decision, whether through an in-store transaction, online checkout, through a distributor, or via a wholesale order.
- **Retention**: The customer maintains a relationship with your brand through product usage, service interactions, loyalty programs, subscriptions, community participation, or advocacy.

Each touchpoint represents an opportunity to strengthen or weaken a brand's relationship with customers. By mapping these interactions (e.g., through User Journey Mapping), brands can **identify the moments that matter most and invest resources where they deliver the highest ROI**.

### 2. Where: The Sales Channels

Customer experiences happen across multiple channels in today's omnichannel reality:

- **Owned digital**: Desktop and mobile sites, native mobile apps with specialized features like AR try-on or barcode scanning, social commerce integrations on Instagram or Facebook, and increasingly, livestream shopping events.
- **Third-party digital**: Marketplace storefronts on Amazon, eBay, or Etsy, comparison shopping engines like Google Shopping, affiliate marketing partnerships, social media marketplaces, and specialized vertical marketplaces relevant to your industry.
- **Owned physical**: Flagship stores designed as brand showcases, smaller format concept stores, pop-up experiences tied to product launches or seasonal themes, showrooms focused on product education rather than inventory, and other brand activation events.
- **Third-party physical**: Department store concessions or shop-in-shops, specialty retailers carrying your products, wholesale distribution through boutiques, strategic retail partnerships, and temporary collaborative spaces with complementary brands.

Different customers might prefer different channels, and their expectations can vary significantly by context. For instance, a customer might expect comprehensive product information when shopping on your website, but prioritize speed and convenience when shopping at a grocery store.

The most successful brands understand **what channels deliver the highest profit margins** at different stages of their purchase journey, what incremental value each channel brings to the table, and how to optimize the sales channel mix accordingly—all while ensuring a consistent brand experience across all touchpoints.

### 3. Why: The Customer Motivations

Understanding why customers engage with your brand at different stages and in different channels reveals the deeper motivations driving their behavior.

These motivations operate at three distinct levels:

- **Economic motivations** (rational/financial): Customers seeking value, savings, and financial optimization. These pragmatic concerns are typically top-of-mind during economic uncertainty or in highly competitive categories where price comparisons are easy.
- **Functional motivations** (practical/operational): Here, customers focus on problem-solving, convenience, and utility. They ask: "Does this product or service efficiently solve my problem?" Functional excellence is particularly important for repeat purchases and utilitarian categories.
- **Aspirational motivations** (identity/values): The most powerful drivers involve self-expression, status, community belonging, and personal values like sustainability or innovation. When satisfied effectively, these emotional and identity-based motivations create the **strongest brand loyalty and highest customer lifetime value**.

It's crucial to recognize that customer motivations are fluid and contextual, which is why they warrant their own dimension.

A customer might be functionally driven when purchasing running shoes from a brand for the first time, but then develop economic drivers when they engage with the brand's recycling program, or aspirational drivers once they enter the brand's customers-only local running club. Understanding these motivational shifts allows brands to design experiences that respond appropriately to the same customer's different purchasing contexts.

While brands will typically lean more towards one or two of these drivers, depending on their category and positioning, the most compelling customer experiences address motivations at all three levels in a way that **reinforces the brand's competitive differentiation**.

## Aligning the Three Dimensions for Business Growth

Understanding your brand's customer experience across these three dimensions provides a comprehensive view of your current state. This framework intentionally avoids rigid customer personas in favor of focusing directly on interactions, channels, and motivations—the elements that shape experience in real time for real customers.

The real challenge—and opportunity—lies in understanding the current state of your customer experience across these three dimensions and then aligning them so that the result resonates with your target audience, regardless of where they are in their journey, which channel they choose to engage with, and what is driving their decisions.

Our clients who have successfully implemented this framework have seen **impressive  results**:

- **Reduced acquisition costs** by creating more memorable and shareable experiences
- **Increased conversion rates** by aligning experiences with customer motivations
- **Higher average order values** through better cross-channel experience integration
- **Improved customer retention** leading to stronger Customer Lifetime Value metrics

How to achieve these results is the topic of our next article. Stay tuned!

The Three Dimensions of E-Commerce Customer Experience

When building custom applications for your Shopify store, one of the most consequential architectural decisions you'll make is how your app will interact with Shopify's data.

There are two primary approaches, each with distinct advantages and tradeoffs that can significantly impact your development process, maintenance overhead, and application performance:

1. **Database Sync Approach**: Maintain a synchronized copy of Shopify entities in your application's database, creating a local representation that your code can work with.
2. **API-First Approach**: Make direct API calls to Shopify whenever data is needed, avoiding local storage and working with the freshest possible data.

Having implemented both approaches across a number of enterprise Shopify integrations, I've seen firsthand how this seemingly technical decision can have far-reaching business implications.

Let's explore both models in depth!

## The Database Sync Model: Your Own Data Kingdom

The database sync approach creates a mirror of relevant Shopify data within your application's database.

This typically involves initial data import during setup, webhook subscriptions to capture real-time updates, background jobs to periodically reconcile and verify data integrity, and ORM-style data access in your application code.

In essence, you're creating a localized representation of the Shopify world that your application can efficiently query and manipulate.

### The Business Case for Database Sync

This approach shines in several key scenarios that leverage the power of local data access and relationship modeling:

* For data-intensive applications that need to perform complex operations across multiple Shopify entities, having local database access can dramatically improve response times.
* The ability to model relationships between Shopify entities in your own database allows for more sophisticated data handling. This becomes invaluable when your business logic depends on understanding connections that aren't directly exposed via Shopify's API.
* Shopify's API primarily focuses on current state, but many business decisions require historical context. By maintaining your own data store, you can preserve change history and implement point-in-time analysis.

In other words, whenever you need full ownership over your data, a database sync is the recommended approach.

### The Challenges of Database Sync

Despite these advantages, this approach comes with significant considerations that must be managed throughout your application's lifecycle:

* Your synced data is only as current as your last update. While webhooks provide real-time notifications for many events, there are edge cases where changes might not be captured immediately. This can lead to situations where you need to refresh objects before using them, as they might have been updated in Shopify but not yet reflected in your local copy.
* Maintaining a reliable sync mechanism requires ongoing attention to webhook management and error handling, rate limits during bulk operations, recovery mechanisms for missed updates, and schema evolution as Shopify's API changes. A home goods retailer experienced this challenge when Shopify updated their metafield architecture, requiring significant rework of their sync implementation.
* Building a robust sync framework adds complexity to your initial development effort. This includes modeling Shopify entities in your database schema, implementing reconciliation logic, managing webhook subscriptions, and handling edge cases and conflict resolution.

To mitigate these challenges, it's imperative to:

* Implement comprehensive webhook coverage to capture all relevant data changes.
* Develop reconciliation processes to catch missed updates and ensure data integrity over time.
* Consider write-through caching for critical updates that need immediate reflection in both systems.
* Include data freshness metadata on synced entities to help identify stale data, and implement circuit breakers to fall back to API when sync issues occur.

## The API-First Approach: Always Fresh, Always Direct

The API-first approach maintains minimal local state and relies on direct Shopify API calls whenever data is needed.

This approach features no comprehensive data mirroring, direct GraphQL or REST API calls for read operations, webhooks for triggering specific business logic, strategic caching for performance optimization, and more procedural code patterns for data access.

### The Business Case for API-First

This lighter-weight approach offers compelling advantages in scenarios where simplicity and up-to-the-moment data accuracy are paramount:

* By removing the complexity of data synchronization, you can focus development efforts on core business logic. This often leads to faster time-to-market and reduced maintenance overhead.
* For applications where decisions must be made on the absolute latest data—such as inventory allocation or pricing—the API-first approach eliminates any risk of working with stale information.

If your application treats Shopify as the definitive source of truth and doesn't need to extend its data model significantly, the API-first approach aligns perfectly with this philosophy, keeping your architecture simpler and more focused.

### The Challenges of API-First

The direct approach isn't without its own set of considerations that can impact application performance and development complexity:

* Shopify enforces rate limits on API requests, which can become restrictive for data-intensive operations. Without careful design, applications can hit these limits during peak usage.
* Working directly with Shopify's API means accepting its query patterns and limitations. Complex filtering, sorting, or relationship traversal that would be trivial in a local database might require multiple API calls or be impossible to perform efficiently.
* Without an ORM-style data layer, code often becomes more procedural and tightly coupled to Shopify's API structure. This can reduce code readability and make maintenance more challenging over time.

To mitigate these challenges, we strongly recommend that you:

* Design for efficient API usage patterns to minimize request volume and avoid rate limiting.
* Implement strategic caching for frequently-accessed data to improve performance without sacrificing freshness where it matters.
* Use GraphQL to minimize request volume by retrieving exactly the data you need.
* Build resilience for API unavailability through fallback mechanisms, and monitor rate limit consumption proactively to avoid disruptions.

## The Hybrid Approach: Best of Both Worlds?

Increasingly, sophisticated Shopify applications are adopting hybrid architectures that combine elements of both approaches to maximize advantages while minimizing drawbacks.

This balanced strategy might include syncing frequently-accessed reference data with long refresh cycles, maintaining critical calculated values locally, directly querying time-sensitive operational data, and using event-driven architectures to update local state selectively.

It's a pattern we've been experiment with lately with good results—stay tuned for future updates!

## Making the Strategic Choice: A Decision Framework

Rather than presenting this as a binary choice, consider these five key factors that should influence your architectural decision:

1. **Data Volume and Complexity**: The more Shopify entities you need to work with simultaneously, and the more complex their relationships, the more compelling the database sync approach becomes. High-volume data processing with complex relationships typically favors the database sync model.
2. **Real-Time Requirements**: If your application's core functionality depends on split-second current data (inventory, pricing for checkout), the API-first approach eliminates sync latency risks and ensures you're always working with the most current information.
3. **Development Resources**: The API-first approach typically has a lower initial development hurdle, though it may become more complex over time as caching and optimization needs grow. Teams with limited resources might start with API-first and evolve as needed.
4. **Business Continuity**: A local data store provides resilience against Shopify API outages or rate limiting, allowing core functionality to continue even during connectivity issues. Applications with high uptime requirements often benefit from the database sync approach.
5. **Analytics Requirements**: Applications with significant reporting and analysis needs benefit tremendously from local database query capabilities, making the database sync model particularly valuable for business intelligence applications.

## Align Your Technical Architecture with Your Business Strategy

The choice between database sync and API-first approaches isn't merely technical—it directly impacts your ability to deliver on core business requirements. By understanding the tradeoffs and aligning your architecture with your specific needs, you can build Shopify custom applications that provide lasting business value.

The most successful implementations I've seen share one common factor: they began with a clear understanding of the business requirements and let those drive the technical approach, not the other way around. Whether you're building your first Shopify custom app or evolving your existing architecture, taking the time to make this fundamental decision thoughtfully will pay dividends throughout your application's lifecycle.

Need expert guidance on your Shopify integration strategy? Reach out to schedule a consultation! Our team specializes in building high-performance custom apps and would love to help.

Designing Your Shopify App’s Data Architecture: A Primer

Michela Frecchiami

In e-commerce, a smooth and intuitive shopping experience can make all the difference—helping customers find what they need faster, increasing the chances they'll complete a purchase, and increasing their basket size.

While Shopify offers several features to enhance product presentation and purchasing flows, many merchants struggle with how to effectively display related products—such as variations, complementary items, and customizable sets—while keeping the their online store’s shopping experience intuitive.

In this article, we're going to showcase three different ways to present related products in a Shopify store and give you a clear framework for understanding what tool to use depending on your specific scenario.

Let's take a look!

## LAKE's Product Presentation Challenge: A Case Study

While working with premium sleepwear brand LAKE, we encountered multiple product presentation challenges that illustrated the importance of selecting the right tool for the job. LAKE's diverse product catalog—featuring style variations, complementary products, and customizable bundles—called for a deep understanding of product relationships before implementing technical solutions.

By analyzing how LAKE's products related to one another and how customers interacted with them, we were able to present an approach that addressed their specific business objectives. Specifically, LAKE wanted to explore different business scenarios:

* Enhance the product browsing experience by showing style variations (like sleeve length) on product pages.
* Implement more effective product recommendations using straightforward solutions.
* Create a customizable experience for bundled items that were being treated as single products.

After a thorough analysis of their customer journey, we discovered that no single Shopify app would address all these needs. Instead, we explored a hybrid approach based on the different types of product relationships.

## Three Solutions for Product Cross-Selling

Based on LAKE's needs and the different types of product relationships, we proposed three distinct solutions for cross-selling:

### 1. Combined Listings for Style Variations

For closely related style variations (like the same pajama top in short-sleeve and long-sleeve versions), we recommended Shopify Combined Listings. This feature (available exclusively on Shopify Plus and enterprise-level plans) allows merchants to display multiple related products as variants within a single listing while keeping them as separate products in the backend.

This means each product can have its own:

* Product title, product description, and metadata
* Unique image gallery
* Independent product URL for better SEO

Why it works for style variations:

* Customers can easily toggle between short-sleeve and long-sleeve options without leaving the page
* The variations are genuinely different versions of the same core product (same fabric, design, and general style)
* It provides a seamless browsing experience while keeping separate product URLs for better SEO and inventory management

<figure>
	<img src="https://cdn.sanity.io/images/kqgmf0g2/production/0e7ef79ee680f895fdcfa1e7762645e7c17c4ed7-1600x1052.jpg?fit=clip">
  <figcaption>A prototype for LAKE, showcasing a men's pajama set with two style variations.</figcaption>
</figure>

Another use case is using Combined Listings to display separates (i.e. top, bottom) that are often bought together.

<figure>
	<img src="https://cdn.sanity.io/images/kqgmf0g2/production/13771e641a9ab5940cc706364b59b131a59c4491-1600x1052.jpg?fit=clip">
  <figcaption>An example of how separates can be shown usinf Combined Listing.</figcaption>
</figure>


### 2. Quick Add to Cart for Complementary Products

One of the options LAKE asked us to explore was a flexible way to display matching products on the product page. For example, a women's pajama set and its matching version for children are perfect for a "mommy and me" moment. While these items are designed to complement each other, they are separate products targeting different users, not variations of the same item.

In this case, a Quick Add to Cart functionality works best:

* A women's pajama set and a child's pajama set are separate products rather than variations of the same core item, unlike short-sleeve and long-sleeve versions of a t-shirt
* A Quick Add button allows customers to add the matching children's set to their cart instantly, making it easier to purchase both and increasing the overall AOV
* Each pajama set retains its own product description, sizing chart, and imagery, ensuring clear product details and avoiding confusion

<figure>
	<img src="https://cdn.sanity.io/images/kqgmf0g2/production/ba256f0f864d3111809f4a6648b5e700e867cee6-1600x1052.jpg?fit=clip">
  <figcaption>Another prototype for LAKE, to explore the Quick Add to Cart solution.</figcaption>
</figure>

### 3. Bundling Apps for Customizable Sets

When customers need to personalize their purchases beyond what Combined Listings can offer, bundling apps from the Shopify App Store provide the necessary flexibility while still creating a cohesive shopping experience. These specialized apps excel in scenarios where:

* Customers need to select products in different sizes for related items (like tops and bottoms)
* Merchants want to offer mix-and-match sets with special bundle pricing as an upsell
* There's a need to maintain accurate inventory tracking for each item

For example, HoneyLove sells women's underwear, providing a sophisticated shopping experience that allows customers to select different sizes for tops and bottoms without navigating between product pages, streamlining the path to checkout.

<figure>
	<img src="https://cdn.sanity.io/images/kqgmf0g2/production/c31fe6803eda7868b77853a1f1dd8d8a0f523ea2-3200x2104.jpg?fit=clip">
  <figcaption>Honeylove showcases an activewear bundle with coordinated separates, allowing customers to mix and match pieces.</figcaption>
</figure>


## Implementing the Right UX for Your Cross-Selling Needs

As we've seen, these approaches aren't mutually exclusive—they can be combined strategically based on your specific business goals and product relationships.

To help streamline the decision between different cross-selling experiences, we suggest looking at your product relationships through two key dimensions:

* **Variation Complexity:** How different are the products? This ranges from simple variations like color and size to entirely separate but complementary products.
* **Purchase Intention:** How likely are customers to want these items together? This can range from items that are almost always purchased together to those that are only occasionally complementary.

By understanding where your products fall on these dimensions, you can choose the right tools to create an intuitive shopping experience that aligns with your business goals.

When you take time to analyze how your products relate to one another, you create shopping experiences that improve customer experience and increase transaction value, boosting sales and setting your brand apart from competitors.


Related Products in Shopify: Picking The Right Tool for the Job

Nick Belzer

If you're coming from a traditional e-commerce platform like Solidus or Magento, working with Shopify can feel like a significant adjustment. Unlike these open platforms where you can modify virtually any aspect of the codebase, Shopify operates more like a black box. You can't simply rewrite core functionality or directly access the underlying systems.

But that doesn't mean customization is impossible. Shopify has evolved to provide specific extension points where developers can inject custom functionality. These carefully designed interfaces allow you to expand Shopify's capabilities while maintaining the platform's stability and security.

Let's take a look at each one of them!

## 1. Theme Blocks: Customizing the Storefront Experience

When you install apps on your Shopify store, they can expose theme blocks that render within your storefront. This allows you to add new functionality to your theme without directly editing theme files.

Theme blocks come in two main types:

### Section Blocks

These render inside existing theme sections. If a section supports app blocks, you can include blocks exposed by your installed apps. The app defines the liquid template that gets rendered, the data being used, and the settings available.

For example, a ratings app might display a star rating block that shows both the average rating and individual reviews.

### Embedded Blocks

These are smaller UI elements that aren't specific to a section but appear throughout your site. Examples include helper tags, accessibility features, or customer service elements.

This approach is especially valuable when you don't have control over the theme but need to introduce visual elements. At Nebulab, we've used this for our Sprout app, creating visual elements in merchants' themes by exposing theme logic through app blocks.

For more details on implementing theme blocks, check out [Shopify's Theme Blocks documentation](https://shopify.dev/docs/storefronts/themes/architecture/blocks/theme-blocks/quick-start).

## 2. Web Pixels: Tracking Solutions for Checkout

Shopify is transitioning to a new checkout experience that will be fully controlled by the platform. By August 2025, all stores will be required to use this new system, which has significant implications for tracking and analytics.

The primary impact? **You'll no longer be able to add custom JavaScript to checkout and order status pages.** This limits your ability to track events using client-side tracking.

To address this limitation, Shopify has introduced web pixels - isolated containers that exist around tracking pixels:

### App Pixels

These are included with apps you install on your Shopify store. Examples include Instagram or TikTok pixels. Once installed and connected to your ad accounts, they automatically subscribe to relevant events and send data to their respective platforms.

Some, like TikTok, employ a hybrid approach:
- Client-side tracking through the app pixel
- Server-side enrichment by using the app's API credentials to fetch additional order information

### Custom Pixels

If you need to send data to a platform that doesn't offer an official Shopify app, you can create custom pixels. These allow you to:
1. Subscribe to specific events (like checkout completion)
2. Import the tracking platform's pixel 
3. Use their API to send the data provided by Shopify

This approach creates a unified tracking system across your theme and checkout pages, despite Shopify's checkout limitations.

Learn more about implementing web pixels in our blog post: [Web Pixels on Steroids: How To Enrich Your Shopify Analytics](https://nebulab.com/blog/shopify-web-pixels).

## 3. Shopify Flow: Merchant-Controlled Automation

Shopify Flow enables merchants to create their own automation workflows through a user-friendly interface. While Shopify provides many built-in triggers, conditions, and actions, the real power comes from custom extensions.

As developers, we can extend Flow by creating:

1. **Custom Triggers**: Events that initiate workflows (e.g., "subscription created" or "subscription renewed")
2. **Custom Actions**: Operations that can be performed (e.g., "pause subscription")

By exposing these elements to Shopify Flow, we empower merchants to build their own business logic without developer intervention. 

For example, a merchant might create a workflow where when a subscription containing a specific product is created, an email notification is sent to their fulfillment team. This creates powerful automation possibilities without custom development for each use case.

For more insights, read our post on [Building Custom Shopify Automations](https://nebulab.com/blog/custom-shopify-automations).

## 4. UI Extensions: Customizing Key Experiences

As Shopify takes more control over critical customer touchpoints like checkout and account pages, they're providing UI extensions to maintain customization possibilities. These extensions let you inject custom UI elements at specific points:

### Checkout UI Extensions

With Shopify's new checkout experience, you can add custom elements like:
- Product information displays
- Upsell opportunities
- Delivery information
- Custom fields

At Cometeer, we use checkout extensions to display virtual product information, helping customers understand what's in their cart, and to offer relevant upsells.

### Account Portal Extensions

As Shopify's new customer account experience gains adoption, UI extensions let you integrate custom functionality. For subscription businesses, this might include subscription management interfaces directly within the customer account.

Like admin UI extensions, these must use Shopify's component libraries and follow their design patterns.

For a hands-on guide, check out our tutorial on [How To Build Your First Shopify POS UI Extension](https://nebulab.com/blog/building-shopify-pos-extensions).

## 5. Admin UI Extensions: Enhancing the Shopify Admin

Admin UI extensions allow you to render UI elements at specific points within the existing Shopify admin. Unlike embedded apps, these extensions integrate directly into admin pages like orders, products, or customers.

For example, we implemented an extension at Cometeer that displays coffee mapping details directly on the order page:

- When a customer orders a virtual product (like a coffee box)
- The extension shows which specific coffees were selected
- It displays the scoring logic used to select those coffees
- Operators can see this context without leaving the order view

Admin UI extensions must use Shopify's component libraries, ensuring they maintain the admin's look and feel. This creates a seamless experience where your custom functionality feels like a native part of Shopify.

Learn more about implementing these in our post: [Into the Light: Bringing Visibility to Your Shopify Customizations](https://nebulab.com/blog/custom-shopify-uis).

## 6. Embedded Apps: Creating Admin Interfaces

Embedded apps provide the most flexible way to extend Shopify's admin interface. When a merchant installs your app, it appears in their admin navigation. Clicking on it renders an iframe containing your custom interface.

This approach gives you complete control over the UI and functionality, allowing you to build complex interfaces for managing custom data and workflows. For instance, a subscription app might use an embedded app to display:

- All active subscriptions
- Detailed subscription information
- Management controls (pause, cancel, etc.)

While you have freedom in what you render, using Shopify's Polaris component library creates a native-feeling experience that integrates seamlessly with the rest of the admin.

Embedded apps support multiple pages and navigation, making them ideal for complex workflows that require dedicated interfaces.

For a detailed guide on building embedded apps, see [Shopify's Embedded App documentation](https://shopify.dev/docs/apps/auth/oauth/getting-started).

## 7. Shopify Functions: Injecting Custom Logic

Shopify Functions represent the closest thing to the traditional plugin architecture found in open platforms. They allow you to inject custom code directly into Shopify's processing flow at specific extension points.

These functions receive inputs from Shopify, process them according to your logic, and return outputs that influence Shopify's behavior. Current extension points include:

- **Discount Functions**: Create custom discount types beyond what's available in the admin
- **Location Rules**: Control which fulfillment locations are chosen during checkout
- **Validation Rules**: Define when orders can proceed through checkout

Functions come with constraints:
- Limited execution time
- Restricted code size and resource usage
- Must be deterministic
- Written in Rust or JavaScript
- Hosted on Shopify's infrastructure

Despite these limitations, Functions enable powerful customizations. For example, a loyalty program might use a custom discount function to provide member-specific discounts on certain product combinations - something not possible with standard Shopify discounts.

For more information, refer to [Shopify's Functions documentation](https://shopify.dev/docs/api/functions).

## Conclusion: Choosing the Right Extension Approach

When extending Shopify, selecting the right approach depends on what you're trying to accomplish:

- **For visual customizations**: Theme blocks let you inject UI components into the storefront without theme modifications.
- **For tracking and analytics**: Web pixels provide a standardized way to capture checkout events despite Shopify's checkout restrictions.
- **For merchant-controlled workflows**: Shopify Flow extensions empower merchants to create their own business logic.
- **For checkout and account customization**: UI extensions maintain customization as Shopify standardizes these experiences.
- **For enhancing standard admin pages**: Admin UI extensions integrate directly into existing workflows.
- **For complex admin interfaces**: Embedded apps give you complete control over custom management interfaces.
- **For custom business logic**: Shopify Functions let you modify platform behavior at specific points.

The extension landscape continues to evolve as Shopify balances merchant customization needs with platform stability. Staying current with these options ensures you can deliver the custom experiences clients need while working within Shopify's constraints.

Remember that sometimes combining approaches yields the best results. For instance, an embedded app might manage configuration while Shopify Functions implement the actual logic.

If you need expert guidance on your Shopify integration strategy, [reach out!](https://nebulab.com/services/shopify) At Nebulab, we specialize in building high-performing Shopify store for midmarket and enterprise brands, and we'd love to help you build the e-commerce experience you need to shine.

The Nebulab